SILICON LABS UG305 Dynamická víceprotokolová uživatelská příručka

SILICON LABS UG305 Dynamická víceprotokolová uživatelská příručka

Obsah skrýt

Zavedení

Tento dokument popisuje, jak je software Silicon Labs navržen pro použití více protokoly na jednom bezdrátovém čipu. Dynamické multiprotokolové časové úseky rádia a rychle mění konfigurace, aby bylo možné spolehlivě provozovat různé bezdrátové protokoly současně.

Poznámka: Informace specifické pro Zigbee v tomto dokumentu platí pro verzi 6.10.xa nižší.
Podrobnosti o specifických dynamických multiprotokolových implementacích jsou uvedeny v následujících aplikačních poznámkách:
AN1133: Dynamický víceprotokolový vývoj s Bluetooth a Zigbee EmberZNet SDK 6.x a nižší
AN1134: Dynamický multiprotokolový vývoj s Bluetooth a proprietárními protokoly na RAIL v GSDK v2.x
AN1269: Dynamický multiprotokolový vývoj s Bluetooth® a proprietárními protokoly na RAIL v GSDK v3.x a vyšší
AN1209: Dynamický multiprotokolový vývoj s Bluetooth a Connect
AN1265: Dynamický multiprotokolový vývoj s Bluetooth® a OpenThread v GSDK v3.x

Terminologie

Následující seznam uvádí některé terminologie specifické pro implementaci dynamického více protokolů

Vrstva rozhraní rádiové abstrakce (RAIL): Společné API, přes které kód vyšší úrovně získává přístup k rádiu EFR32.

Provoz rádia: Konkrétní akce, která má být naplánována. Rádiový provoz má jak rádiovou konfiguraci, tak prioritu. Každý zásobník může vyžadovat, aby rádiový plánovač provedl až dvě rádiové operace (příjem na pozadí a buď plánovaný příjem, nebo naplánovaný příjem

Příjem na pozadí: Trvalý příjem, který má být přerušen naplánovanými operacemi a vrácen po jejich dokončení.
Plánovaný příjem: Příjem paketů nebo výpočet RSSI v určený čas a trvání. (Vývojáři pracující na RAIL, vezměte na vědomí, že ve smyslu rozhraní RAIL API se „plánovaný příjem“, jak je používán v tomto dokumentu, vztahuje na jakoukoli operaci příjmu, kromě RAIL_StartRx, a není omezen pouze rozsahem na RAIL_ScheduleRx.)

Plánovaná Transmit: Jakákoli z různých přenosových operací včetně okamžitého přenosu, plánovaného (budoucího) přenosu nebo přenosu závislého na CCA. (Vývojáři pracující na RAIL, vezměte na vědomí, že ve smyslu RAIL API se „Plánovaný přenos“, jak je používán v tomto dokumentu, vztahuje na jakoukoli přenosovou operaci a není omezen na RAIL_StartScheduledTx.

Radio Config: Určuje stav hardwaru, který musí být použit k provedení rádiové operace.

Rádiový plánovač: Komponenta RAIL, která rozhoduje mezi různými protokoly a určuje, který bude mít přístup k rádiu.

Přednost: Každá operace z každého zásobníku má výchozí prioritu. Aplikace může změnit výchozí priority.

Doba skluzu: Maximální čas v budoucnu, kdy lze operaci spustit, pokud nemůže začít v požadovaném čase zahájení.

Výtěžek: Zásobník se musí dobrovolně vzdát na konci operace nebo sekvence operací, pokud neprovádí příjem na pozadí. Dokud se zásobník neuvolní, plánovač nebude plánovat úlohy s nižší prioritou

Kernel RTOS (Real Time Operating System).: Část operačního systému, která je zodpovědná za správu úloh a meziúlohovou komunikaci a synchronizaci. Tato implementace používá jádro Micrium OS-5.

Architektura

Dynamic Multiprotocol využívá jako své stavební bloky hardware EFR32 a software RAIL. Zigbee, Bluetooth a/nebo jakékoli jiné protokoly založené na standardech nebo proprietární protokoly pak mohou být postaveny na těchto nestátních vrstvách pomocí Micrium ke správě provádění kódu mezi různými protokoly. Následující diagram znázorňuje obecnou strukturu softwarových modulů.

Počínaje verzí 2.0 vyžaduje RAIL předání popisovače rádiové konfigurace voláním RAIL API. Tato konfigurace popisuje různé parametry PHY, které zásobník používá

Micrium OS je RTOS, který umožňuje zásobníkům a aplikační logice sdílet čas provádění CPU.

Rádiový plánovač je softwarová knihovna, která inteligentně odpovídá na požadavky zásobníků na provádění rádiových operací, aby byla maximalizována spolehlivost a minimalizována latence. Rozhraní API poskytované společností RAIL, která nezapojují rádiové obcházení plánovače rádia.

Jádro RAIL konfiguruje hardware EFR32 v reakci na pokyny z rádiového plánovače.

Jeden obrázek firmwaru

Dynamic Multiprotocol umožňuje vývojářům softwaru generovat jeden monolitický binární soubor, který je načten do EFR32. Aktualizace softwaru se provádějí upgradem celého binárního souboru. Toho je dosaženo pomocí Geck otloader, jehož podrobnosti lze nalézt v UG266: Silicon Labs Gecko Bootloader User’s Guide for GSDK 3.2 and Lower a UG489: Silicon LabsGecko Bootloader User’s Guide for GSDK 4.0 and vyšší.

Nezávislý provoz zásobníku

Stohy Silicon Labs stále fungují nezávisle na sobě v situaci Dynamic Multiprotocol. Určité radiové operace s dlouhou životností budou mít dopad na latenci a vyhovující provoz jiného protokolu. Je na aplikaci, aby určila jakékoli zvláštní úvahy pro tyto události. Další informace naleznete v části 2. Plánovač rádia.

Plánovač rádia

Radio Scheduler je součástí RAIL (Radio Abstraction Interface Layer). RAIL poskytuje intuitivní, snadno přizpůsobitelnou vrstvu rádiového rozhraní a API, které podporuje proprietární nebo na standardech založené bezdrátové protokoly. Rádiový plánovač je navržen tak, aby umožňoval rádiové operace, které lze plánovat a upřednostňovat. Různé rádiové operace v každém protokolu mohou být více či méně důležité, nebo více či méně časově citlivé, v závislosti na situaci. Plánovač je může vzít v úvahu při rozhodování o konfliktech a jak je posuzovat

Pokud nevyvíjíte aplikace s vlastním protokolem na RAIL, většinu funkcí rádiového plánovače zpracuje automaticky základní zásobník a kód RAIL. Zásobník musíte používat pouze prostřednictvím jeho normálního rozhraní API.

Na vysoké úrovni zásobník odesílá rádiovou operaci (napřample a Plánovaný příjem nebo Plánovaný přenos). Provoz rádia je
zařazeny do fronty a následně obsluhovány v budoucnu na základě jejich parametrů. Když je čas zahájit provoz rádia, plánovač prozkoumá, zda existuje nebo neexistuje konkurenční událost a zda lze operaci zpozdit. Pokud plánovač nemůže událost spustit, vrátí výsledek vyšší vrstvě, která to může zkusit znovu s novými parametry.

Po zahájení rádiové operace může odpovídající zásobník poslat plánovači další operace na základě výsledků předchozí operace (např.ample čekání na ACK). Na konci každé operace nebo sekvence operací musí zásobník umožnit použití rádia.

Rádiový provoz

Každá událost v plánovači je rozdělena do prvků nazývaných rádiové operace, které jsou spojeny s konfigurací rádia a prioritou.

Každá operace má prioritu a je přerušena, pokud plánovač obdrží operaci s vyšší prioritou, která se časově překrývá. Rádiové operace s nižší prioritou, které nelze spustit na základě jejich plánovacích parametrů, selžou a je na příslušném zásobníku, aby je zkusil znovu. Jakmile plánovač aktivně spustí rádiovou operaci ze zásobníku, zásobník může pokračovat v odesílání dalších rádiových operací, dokud se dobrovolně nepodvolí, nebo dokud plánovač nepřijme rádiovou operaci s vyšší prioritou a nezabrání ji.

Příjem na pozadí
Plánovaný příjem
Plánovaný přenos

Každý zásobník může požádat plánovač rádia o provedení až dvou rádiových operací (příjem na pozadí a buď plánovaný příjem nebo plánované vysílání) najednou:

Každá operace má následující parametry:

Čas zahájení	Indikace, kdy v budoucnu bude tato rádiová operace probíhat. To by mohlo být „spustit hned teď“ nebo nějaká hodnota v mikrosekundách v budoucnu.
Přednost	Číslo, které označuje relativní prioritu operace. Při použití výchozího nastavení mají rádiové operace Bluetooth LE téměř vždy vyšší prioritu než operace Zigbee.
Doba skluzu	Doba, po kterou může být událost zpožděna po jejím začátku a stále může být přijatelná pro zásobník. Může to být 0, v takovém případě nelze událost posunout.
Doba transakce	Přibližná doba, kterou trvá dokončení transakce. Události přenosu mají obvykle mnohem přesněji definovaný čas transakce, zatímco události příjmu jsou často neznámé. To se používá k pomoci rádiovému plánovači určit, zda lze událost spustit.

Zásobník definuje tyto různé parametry vhodné pro prováděnou operaci. NapřampUdálosti připojení Bluetooth jsou často naplánovány v budoucnu a nemají povolený skluz, zatímco přenosové události Zigbee mohou být často o něco zpožděny a označeny později.

Z pohledu RAIL Radio Scheduler jsou plánované vysílání a plánované příjem totožné. Obě jsou jednoduše operace, které vyžadují použití rádia, a proto je nelze provádět současně. Rozdíl je patrný pouze na vrstvě RAIL API, kde se volá buď TX nebo RX API.

Příjem na pozadí

Toto je režim nepřetržitého příjmu, který má být přerušen jinými operacemi a po jejich dokončení se do něj vrátí. Pokud má příjem na pozadí vyšší prioritu než jiné operace, tyto rádiové operace nebudou naplánovány a nebudou spuštěny. Je na hromadách nebo aplikaci, zda změní prioritu nebo dobrovolně uvolní. Viz část 5.1 Přampsoubory s příjmem na pozadí, rádiem s výnosem a přechodem stavu napřampinformace o tom, jak příjem na pozadí interaguje s plánovanými operacemi.

naplánováno Příjem

Toto je příjem v budoucím čase se zadanou dobou trvání. Plánovač rádia vezme v úvahu čas přepnutí rádia při rozhodování, zda bude operace naplánována či nikoli. Pokud to nelze naplánovat, plánovač odešle událost selhání do zásobníku volání. Rádiový provoz se automaticky prodlužuje, dokud zásobník dobrovolně neustoupí, nebo plánovač obdrží operaci s vyšší prioritou a nepřeruší ji. Rozšíření příjmu umožňuje zásobníku pokračovat v rádiovém provozu na základě požadavků protokolu vyšší úrovně, napřample přenos odpovědi na základě přijatých dat.

Plánovaný přenos

Jedná se o přenos v budoucím čase s minimální dobou trvání. Tato minimální doba trvání může zahrnovat očekávané následné události, napřampzadejte ACK k přenosu IEEE 802.15.4. Minimální doba pro tuto operaci však nemusí zahrnovat neočekávané události, které mohou prodloužit dobu mimo minimální dobu trvání, napřampnedostatky v důsledku selhání CCA v IEEE 802.15.4. Rádiový plánovač bere v úvahu čas přepnutí rádia při rozhodování, zda bude operace naplánována či nikoli. Pokud to nelze naplánovat, plánovač odešle událost selhání do zásobníku volání.

Konfigurace rádia

Každá rádiová operace je spojena s předdefinovanou konfigurací rádia, která určuje stav hardwaru, který musí být použit k provedení operace. Radio Configs sledují aktuální stav zásobníku, takže budoucí rádiové operace budou používat stejné rádiové parametry. Rádiové konfigurace mohou být aktivní nebo nečinné. Pokud zásobník změní aktivní Radio Config, pak RAIL provede okamžitou změnu i v konfiguraci hardwaru, napřampZměna kanálu. Pokud není konfigurace rádia aktuálně aktivní, další naplánovaná operace rádia použije novou konfiguraci rádia.

Přednost

Každá rádiová operace má prioritu, která indikuje plánovači, která operace by měla být provedena, pokud existuje časové překrytí mezi více operacemi. Plánovač považuje prioritu 0 za nejvyšší prioritu a 255 za nejnižší prioritu. Rádiový plánovač umožní úkolu s nejvyšší prioritou přístup k fyzickému ra rdwaru. U většiny úkolů se řízení vrátí do rádiového plánovače až po dokončení, ale úkoly jako příjem na pozadí budou přerušeny v případě, že se stane aktivní úkol s vyšší prioritou.

Každý zásobník má výchozí sadu priorit založenou na analýze Silicon Labs, jak nejlépe spolupracovat, abyste maximalizovali pracovní cyklus a předešli výpadkům připojení v případě obecného použití. Konkrétní případy použití mohou mít různé potřeby. Priority jsou následující, od nejvyšší po nejnižší

Plánované vysílání Bluetooth LE
Plánovaný příjem Bluetooth LE
Jiný protokol Scheduled Transmit
Jiný protokol Příjem na pozadí

Tyto priority může aplikace přepsat nebo změnit. Je na rozhodnutí aplikace, za jakých okolností je změní. Část 4.2 802.15.4 Priorita RAIL a část 6.1 Priority Bluetooth obsahují více podrobností o prioritách pro jejich konkrétní instance.

Doba skluzu

Každá rádiová operace musí mít „čas skluzu“ nebo maximální čas spuštění, což znamená nejvzdálenější čas v budoucnosti, kdy lze operaci zahájit, pokud nemůže začít v požadovaném čase spuštění. To umožňuje plánovači obejít události s vyšší prioritou, které se vyskytují ve stejnou dobu, nebo události s vyšší prioritou, které přesahují očekávanou dobu trvání. Protokol obecně určuje, jaká může být doba skluzu, ale rádiový plánovač je schopen to zvládnout na základě jednotlivých operací, což zásobníku umožňuje prokluzovat některé události, ale ne jiné. Obecně má IEEE02.15.4 delší dobu skluzu a Bluetooth LE minimální dobu skluzu.

Výtěžek

Jakmile je aktivně spuštěna sekvence rádiových operací, může zásobník pokračovat v přidávání operací rozšiřujících počáteční operaci, dokud zásobník nebude mít pro konkrétní výměnu zpráv co dělat. Zásobník musí samovolně ustoupit, pokud neprovádí příjem na pozadí. Pokud zásobník neustoupí, bude pokračovat v rozšiřování svého rádiového provozu a rádiové operace s nižší prioritou pak spustí poruchu zpět na odpovídající zásobník, který si tuto rádiovou operaci vyžádal. Operace s vyšší prioritou nemůže přerušit aktuálně probíhající rádiovou operaci s nižší prioritou, která nepřinesla výsledek. Viz část 5.1 Přampsoubory s příjmem na pozadí, rádiem s výnosem a přechodem stavu napřampméně situací, kdy je nutné výslovně udělit rádio.

Přerušení rádiového provozu

Naplánovaný rádiový provoz může být přerušen, pokud je s ním v konfliktu operace s vyšší prioritou. K tomu může dojít za následujících dvou okolností:

Naplánovaný rádiový provoz trvá déle, než se očekávalo, a odpovídající zásobník nedává přednost tomu, že je třeba zahájit rádiový provoz s vyšší prioritou.
Rádiový provoz s vyšší prioritou byl právě naplánován v budoucnosti a je v konfliktu s již naplánovaným provozem s nižší prioritou

Rádiové operace s dlouhou životností

Některé rádiové operace s dlouhou životností mohou mít nadměrný dopad na správnou funkci produktu. Aplikace může potřebovat koordinovat tyto operace mezi protokoly. Pokud tomu tak není, budou mít priority rádiového plánovače přednost. NapřampEnergetické skenování IEEE 802.15.4 může vyžadovat, aby rádio zůstalo zapnuté, aby získalo dostatečné údaje o energii. Pokud aplikace správně nekoordinuje operace, skenování může být předčasně přerušeno kvůli operaci Bluetooth s vyšší prioritou.

Rádiový plánovač Přamples

Vše exampLes používá Bluetooth LE a Zigbee, ale principy platí pro jiné kombinace Bluetooth/802.15.4.

Plánovač začíná operací příjmu Zigbee na pozadí s nízkou prioritou. To představuje vždy zapnutý směrovač, který může potřebovat přijímat pakety IEEE 802.15.4 v neznámých časech. Připojení Bluetooth LE je také aktivní a vyžaduje, aby byl zásobník připraven k příjmu každých 30 ms. Stoh Bluetooth LE to může naplánovat s dostatečným předstihem kvůli rediktovatelné povaze připojení.

Prioritní plánování

To poskytuje základní example rozhodování o prioritách různých rádiových operací.

Zásobník Zigbee se rozhodne, že potřebuje odeslat paket. Může to udělat jako událost na vyžádání, což znamená, že zásobník se rozhodne, že chce poslat paket hned, aniž by o tom plánovač dostatečně předem informoval. To je v kontrastu s tím, jak funguje Bluetooth LE, kde jsou plánované operace známy dostatečně dlouho dopředu. Plánovač vyhodnotí, že je možné provést rádiový provoz Zigbee TX 1 a přesto v budoucnu obsluhovat událost příjmu Bluetooth LE s vyšší prioritou. Takže plánovač umožňuje přenos události. Zigbee stack provede všechny části této přenosové operace (čeká na MAC ack) a pak se dobrovolně podvolí. Odhadovaný čas transakce vysílacího rádia Zigbee NEZAhrnuje opakování.

V tomto example, Bluetooth LE je již naplánován pro příjem v budoucnu a zásobník Zigbee chce vysílat. Pro první operaci rádia Zigbee TX 1 je dostatek času před operací rádia Bluetooth LE RX 1, takže plánovač umožní zásobníku provést operaci. Později, když se zásobník Zigbee pokusí naplánovat Zigbee TX 2, plánovač zjistí, že před událostí Bluetooth LE RX 2 s vysokou prioritou není dostatek času. Nicméně, zásobník Zigbee naznačil, že tato akce může posunout čas zahájení. Rádiový plánovač určí, že s ohledem na očekávanou dobu trvání rádiové operace Bluetooth LE může operace Zigbee začít po této události a stále být v rámci doby skluzu indikované zásobníkem Zigbee.

Pokud vše půjde podle očekávání, dojde k prvnímu pokusu o přenos Zigbee bez jakýchkoliv selhání kvůli plánování.

Přednostní přerušení Přample

Tento example ilustruje operaci s vyšší prioritou přerušující operaci s nižší prioritou.

Tento example začíná stejným způsobem jako předchozí example. Zigbee a Bluetooth LE mají rádiový provoz, který je naplánován bez jakékoli kolize

Později se zásobník Zigbee rozhodne, že chce odeslat další paket pro událost Zigbee TX 2. Plánovač určí, že by mělo být možné naplánovat tuto událost a obsloužit událost Bluetooth LE RX 2 později, na základě minimální doby, kterou musí událost Zigbee TX 2 trvat. Událost Zigbee TX 2 však trvá déle, než se očekávalo, kvůli dlouhému náhodnému ústupu a nedává se včas. To způsobí, že událost koliduje s radiační operací s vyšší prioritou, a tak plánovač rádia přeruší událost Zigbee a vrátí selhání do zásobníku vyšší úrovně. K události Bluetooth LE dochází normálně a po jejím dokončení se dobrovolně podvolí jakýmkoli operacím s nižší prioritou.

Po obdržení selhání z rádiového plánovače se zásobník Zigbee okamžitě pokusí o opakování zprávy MAC. Plánuje operaci a zahrnuje dobu skluzu. V tomto okamžiku má zásobník Bluetooth LE přednost před rádiem, a proto nelze operaci ještě spustit, ale plánovač přijímá novou rádiovou operaci. Zásobník Bluetooth LE dokončí svůj plánovaný příjem a vydá rádio. Plánovač pak spustí operaci přenosu Zigbee, protože je stále v době skluzu počáteční operace spuštění. Po dokončení přenosu se plánovač vrátí do operace příjmu na pozadí.

Operace s vyšší prioritou, která je rozšířena

Tento example ukazuje, co se stane, když operace s vyšší prioritou trvá déle, než se původně očekávalo, a způsobí, že operace s nižší prioritou propásne svou příležitost

V tomto případě má Bluetooth LE naplánovaný příjem, který právě probíhá. Zigbee se rozhodne odeslat paket, ale momentálně jej nelze spustit. Plánovač přijímá operaci za předpokladu, že událost Bluetooth LE bude dokončena před koncem doby skluzu události Zigbee. Událost Bluetooth LE však trvá déle, protože mezi zařízeními jsou odesílány další pakety. Operace Bluetooth LE má prioritu, takže operace Zigbee nakonec dojde ke skluzu. Do zásobníku se vrátí chyba. Zigbee se rozhodne znovu odeslat paket. Opět platí, že zásobník Zigbee naznačuje, že operace by měla začít nyní, ale může sklouznout do budoucnosti. Plánovač je uprostřed změny konfigurace rádia, takže nemůže začít operaci okamžitě. Namísto toho o malý kousek posune čas zahájení provozu rádia a poté operaci provede.

Provoz s vyšší prioritou bez přerušení

V tomto examprádiový plánovač běží na uzlu fungujícím jako periferie Bluetooth LE a tento uzel má řadu připojení k různým centrálním zařízením. Má také pravidelný reklamní maják, který se vysílá. Následující obrázek ukazuje případ, kdy se tyto události vyskytují prakticky za sebou a neposkytují dostatek času na přepnutí zpět na konfiguraci rádia Zigbee. Proto vytvoří období, kde je zásobník Zigbee
nelze vysílat ani s dobou skluzu.

Zigbee požádá plánovače, aby naplánoval operaci přenosu rádia. I když plánovač ví, že událost selže kvůli naplánovaným operacím s vyšší prioritou, stále přijímá naplánovanou událost. To se děje ze dvou důvodů. Za prvé, okolnosti se mohou změnit a událost může být provedena. Za druhé, zásobník umístěný na rádiovém plánovači se může pokusit akci zopakovat. Pokud by byl výsledek neúspěšného plánování vrácen okamžitě, pak by pokus zásobníku o opakování pravděpodobně neuspěl, protože neuplynul žádný čas. Místo toho tím, že událost zařadíte do fronty a vrátíte selhání po uplynutí doby skluzu, má opakování (s vlastním časem skluzu) větší šanci na úspěch, protože sada nadcházejících rádiových operací bude jiná.

Příjem, když je spuštěna operace s vyšší prioritou

Tento example ilustruje, co se stane, když je Bluetooth LE aktivní a operace s nižší prioritou bude přijímat data.

V prvním případě, když je odeslána zpráva IEEE 802.15.4 a zásobník Bluetooth LE využívá rádio pro aktivní příjem, zásobník Zigbee nebude online pro příjem zprávy. Odesílatel zprávy pomocí Zigbee se však ve většině případů pokusí opakovat a s couváním a jinými změnami načasování nebude v konfliktu s jinými událostmi plánovaného příjmu Bluetooth s vyšší prioritou, které pravděpodobně nebudou kolidovat. Zpráva Zigbee byla úspěšně přijata

Druhý případ ukazuje, že v případě aktivního příjmu může být zásobník Zigbee stále přerušen a nepřijme (nebo nepotvrdí) zprávu. Úspěšná komunikace závisí na opakovaných pokusech na MAC nebo vyšší vrstvě pro opětovné odeslání této zprávy a ověření, že dynamické víceprotokolové zařízení zprávu přijme.

I když mohou existovat úvahy o tom, zda by měl být aktivní příjem přerušen, pro plánovače je obtížné toto rozhodnutí učinit. Obecně by měla robustnost protokolů umožnit úspěšné přijímání zpráv i při přerušení

Implementace multiprotokolů se zásobníkem založeným na 802.15.4

Tato kapitola nabízí obecné informace o implementaci zásobníku založeného na 802.15.4, jako je Zigbee nebo Connect, jako součást víceprotokolových aplikací. Pro podrobnosti o konfiguraci plugins a další podrobnosti specifické pro rtikulární protokol, viz jedna z následujících aplikačních poznámek:

AN1133: Dynamický víceprotokolový vývoj s Bluetooth a Zigbee EmberZNet SDK 6.x a nižší

AN1209: Dynamický multiprotokolový vývoj s Bluetooth a Connect

Podpora bezdrátového protokolu

Různé bezdrátové protokoly mají různé vlastnosti, které byly využity při návrhu Dynamic Multiprotocol. Napřample, Bluetooth Low Energy je velmi přísný a předvídatelný ve svém rozvrhu rádiových operací; inzerce a intervaly připojení se vyskytují ve stanovených časech. Naproti tomu protokol 802.15.4 je flexibilnější v načasování mnoha událostí zpráv; CSMA (carrier sense multiple access) v IEEE 802.15.4 přidává náhodné backoffy, takže zpoždění událostí je v řádu milisekund. To umožňuje odesílat zprávy IEEE 802.15.4 kolem událostí Bluetooth Low Energy a stále je spolehlivě přijímat

Priorita 802.15.4 ŽELEZNICE

Protokoly 802.15.4 mají v současnosti tři priority RAIL.

Žádný.	Jméno	Výchozí nastavení	Výstupní kritérium
1	Aktivní TX	100	MAC ACK přijato (nebo ne)
2	Aktivní RX	255	Paket filtrován nebo odeslán MAC ACK
3	Pozadí RX	255	Úkol s vyšší prioritou

Pokud je aktivní TX spuštěno, rádio bude uvolněno v době, kdy bylo přijato odpovídající potvrzení MAC (nebo nastal časový limit).

Pozadí RX ponechá rádio ve stavu příjmu připravené přijímat asynchronní zprávy. Pokud je aktivní priorita příjmu jiná než priorita příjmu na pozadí, priorita příjmu bude zvýšena vždy, když je detekováno synchronizační slovo, a snížena pouze tehdy, když je paket filtrován nebo dokončen a jeho ACK je odesláno, pokud bylo požadováno.

Vyvážení priorit

Jak je vysvětleno v části 6.1 Priority Bluetooth, ve výchozím nastavení je rozsah priorit Bluetooth mapován do rozsahu priorit RAIL 16 – 32. Obecně platí, že Bluetooth začíná s nízkou prioritou (32) a dynamicky zvyšuje prioritu až na maximum (16). potřebné, pokud zprávy nejsou úspěšné.

Jak je popsáno v předchozí části, zásobník založený na 802.15.4, jako je Zigbee nebo Connect, používá výchozí hodnoty priority RAIL 255 pro RX na pozadí, 255 pro aktivní RX a 100 pro aktivní TX.

V důsledku těchto výchozích priorit RAIL bude mít v multiprotokolové aplikaci 802.15.4 protokol-Bluetooth ve výchozím nastavení provoz Bluetooth vždy prioritu před provozem protokolu 802.15.4. To je dobrá volba pro mnoho aplikací, protože provoz Bluetooth má na rozdíl od protokolů 802.15.4 přísné požadavky na časování. Pokud je však zatížení Bluetooth velmi vysoké (napřample, odesílání velkého množství dat pomocí velmi krátkého intervalu připojení), je možné, že provoz protokolu 802.15.4 bude zcela zablokován v přístupu k rádiu kvůli jeho nižší prioritě a velmi malým oknům dostupného rádiového času, který Bluetooth zanechává. provoz

Poznámka: Následující informace jsou aktuálně použitelné pouze pro zásobník EmberZNet Zigbee. Silicon Labs Connect zatím nemá API potřebné ke změně priorit.

Pokud vyvíjíte dynamickou víceprotokolovou aplikaci založenou na 802.15.4 a je důležité, aby tento provoz uspěl v přítomnosti velmi vysokého zatížení Bluetooth, můžete upravit výchozí priority, jak je uvedeno v tabulce níže, pomocí následujícího rozhraní API:

Žádný.	Jméno	Výchozí nastavení
1	Aktivní TX	23
2	Aktivní RX	24
3	Pozadí RX	255

Protože Bluetooth zpočátku nastavuje prioritu RAIL na 32, tato nastavení priority 802.15.4 dávají provozu 802.15.4 vyšší prioritu než Bluetooth zpočátku, což dává protokolu 802.15.4 šanci úspěšně vysílat nebo přijímat provoz i v přítomnosti velmi velké zatížení Bluetooth. Na druhou stranu, Bluetooth dynamicky zvýší svou prioritu, pokud je naražen z plánovače provozem 802.15.4, až na vysokou prioritu 16. Po počátečním povolení přístupu protokolu 802.15.4 k rádiu bude Bluetooth v případě potřeby prioritu při dalších pokusech.

Tento přístup umožňuje oběma protokolům dělat kompromisy při používání rádia, aniž by jeden byl schopen zcela dominovat nad druhým.

. Implementace Multiprotocol s RAIL

Tato kapitola nabízí více informací o zvláštnostech RAIL pro uživatele, kteří využívají RAIL API přímo k vývoji proprietárních protokolů. Zejména nabízí podrobnosti o tom, jak pracovat s RAIL API pro řešení konkrétních případů rádiového plánovače.

Exampsoubory s příjmem na pozadí, rádiem s výnosem a přechodem stavu

Základy prioritního systému RAIL Multiprotocol jsou poměrně jednoduché: rádiová událost s vyšší prioritou (tj. menší v počtu) si vždy uzurpuje jakékoli jiné rádiové události s nižší prioritou. Toto téma se však zkomplikuje při zvažování přechodů mezi stavy a API, jako je RAIL_StartRx(), které uvádějí rádio do určitého stavu na neurčitou dobu. Tato část poskytuje několik ilustrací a příkladampdemonstrovat, jak se zachází s těmito časově neomezenými stavy a jak může aplikační vrstva používat API, jako je RAIL_YieldRadio() k jejich ovládání. Bývalýampsoubory jsou následující:

Přechody států s jednotným protokolem
Přechody států se dvěma protokoly
Přechody států se dvěma protokoly a monotónně rostoucími prioritami

V těchto examples, RAIL_StartTx() je zdrojem události TX, která přeruší RX na pozadí. Všimněte si však, že tyto exampsoubory jsou použitelné pro jakékoli rádiové API kromě RAIL_StartRx(). Jinými slovy, exampsoubory jsou použitelné pro jakékoli rozhraní API, které spouští rádiovou událost, která není RX na pozadí

Tyto exampilustrují očekávané multiprotokolové chování s ohledem na stavové přechody. Shrnout:

Při přechodu stavu se s novým stavem zachází jako s neurčitým rozšířením původní události se stejnou prioritou, dokud není zavolána RAIL_YieldRadio().

Události RX na pozadí nejsou ovlivněny RAIL_YieldRadio(). Pouze RAIL_Idle() může trvale odstranit protokol ze stavu RX na pozadí.
Událost s vyšší prioritou si vždy uzurpuje událost s nižší prioritou, bez ohledu na jakákoli jiná volání API.
Pouze příjem RAIL_StartRx() lze „vrátit“ z události s vyšší prioritou prostřednictvím RAIL_YieldRadio() nebo RAIL_Idle().

Všechny rádiové události jiné než RAIL_StartRx() vyžadují RAIL_YieldRadio() k ukončení a postupu k další události.
Volání RAIL_YieldRadio() nelze nahradit RAIL_Idle(). RAIL_Idle() vymaže všechny události pro daný protokol

.Přechody států s jednotným protokolem

Tento první example zkoumá chování rádia pomocí jediného protokolu (to znamená, že stejný AIL_Handle_t se používá pro všechna volání funkcí rádia). Rádio začíná v RX počátečním voláním RAIL_StartRx(), poté se přesune do TX s voláním RAIL_StartTx() s vyšší prioritou. Je důležité poznamenat, že po dokončení přenosu se rádio přepne do stavu určeného pomocí RAIL_SetTxTransitions() a zůstane ve stavu po neomezenou dobu se stejnou prioritou a kanálem jako TX, dokud není zavoláno RAIL_YieldRadio(). Poté se rádio vrátí na RX s původně určenou prioritou a kanálem.

Potřeba aktivně poskytnout rádio, a tím i RAIL_YieldRadio() API, byly nutné z velké části kvůli ACK’ingu. Filozofie designu je taková, protože TX i přijaté ACK jsou viewPokud v rámci stejné transakce uzel vysílá a očekává ACK, měl by být schopen jak přejít na RX, tak pokračovat v naslouchání ACK jako součást stejné operace (a tedy se stejnou prioritou) jako původní TX. Obecně však RAIL sama o sobě nemůže vědět, zda je nebo není vyžadováno ACK. To může záviset na dalších faktorech, jako je obsah paketů nebo jiná aplikační logika, a proto to nelze jednoduše určit kontrolou, zda bylo ACK'ing nakonfigurováno pomocí RAIL_ConfigAutoAck(). Proto je ponecháno na uvážení, kdy bude radiová transakce dokončena. tikace/zásobník.

V případě, že ACK není vyžadováno, Silicon Labs doporučuje zavolat RAIL_YieldRadio() jako součást zpracování události RAIL_EVENT_TX_PACKET_SENT. To způsobí, že zelená čára na výše uvedeném obrázku bude minimalizována až na dobu latence přerušení. Pokud aplikace očekává ACK, RAIL_YieldRadio() by měla být volána, když je ACK přijato nebo když se má za to, že vypršel časový limit.

Přechody států se dvěma protokoly

Tento scénář je podobný prvnímu scénáři týkajícímu se přechodů stavů po TX, ale zavádí jiný protokol.

V této situaci je důležité poznamenat, že RAIL_StartRx() lze volat kdykoli během transakce TX. Dokud je jeho priorita menší nebo rovna prioritě TX, RX vstoupí v platnost, dokud aplikace nezavolá _Yield Radio() na protokolu A. Když je RAIL_StartRx() voláno během TX, RX je pouze přidán do fronty událostí, které mají být zpracovány.

Dalším klíčovým bodem je, že ačkoli RAIL_YieldRadio() na protokolu A přejde z TX na protokolu A na RX na protokolu B, k přechodu z RX na protokolu B na RX na protokolu A je vyžadována RAIL_Idle() na protokolu B. Filozofií je, že RX na pozadí nelze ve skutečnosti získat, protože událost nikdy neskončila. Jediný způsob, jak ukončit, je zastavit RX na pozadí voláním RAIL_Idle().

Přechody stavů se dvěma protokoly a monotónně rostoucí prioritou

Konečný scénář je téměř totožný s předchozím, kromě toho, že volání RAIL_StartRx() na protokolu B má vyšší prioritu než volání RAIL_StartTx() na protokolu A.

V tomto případě, protože priorita druhého RAIL_StartRx() je vyšší než priorita volání RAIL_StartTx(), volání RAIL_YieldRadio() již není nutné. Protože druhá RAIL_StartRx() má vyšší prioritu, uzurpuje událost RAIL_StartTx(), převezme kontrolu nad rádiem a odstraní událost TX ze stavu. Kdykoli během tohoto RX na protokolu B lze zavolat RAIL_Idle() pro návrat k RX na protokolu A, stejně jako v předchozím příkladuample.

Zde si povšimněte, že když aplikace zavolá RAIL_Idle() na protokolu B RX, aplikace se nevrátí k TX přechodu protokolu A. Místo toho přejde přímo k RX na pozadí, i když aplikace nikdy nevolala RAIL_Idle() na protokolu TX od A. U plánovaných rádiových operací (tj. jakékoli rádiové operace spuštěné jiným API než RAIL_StartRx()) je událost rádia, jakmile je uzurpována událostí s vyšší prioritou, zcela odstraněna a nebude se k ní později vracet. Pouze příjem na pozadí, spuštěný pomocí RAIL_StartRx(), lze udržovat v thackground a „vrátit se“ prostřednictvím volání RAIL_YieldRadio() nebo RAIL_Idle().

Pro zdůraznění rozdílu mezi RAIL_YieldRadio() a RAIL_Idle() je důležité poznamenat, že pro všechny tyto exampVolání RAIL_YieldRadio() nelze nahradit RAIL_Idle(). RAIL_Idle() vymaže všechny události pro daný protokol – operace Background (tj. spuštěné RAIL_StartRx()) i Scheduled (tj. spuštěné jinými API než RAIL_StartRx()). RAIL_Idle() by skutečně stále způsobilo, že by aplikace opustila přechodový stav TX, ale také by vymazala pozadí RX, což by způsobilo návrat aplikace do nečinnosti, nikoli RX.

Implementace Multiprotocol s Bluetooth

Podrobnosti o tom, jak RAIL/Bluetooth světlo/přepínač multiprotokol example byl implementován a další informace o vývoji víceprotokolové aplikace s vaším vlastním protokolem na RAIL naleznete v AN1134: Dynamický víceprotokolový vývoj s Bluetooth a proprietárními protokoly na RAIL v GSDK v2.x nebo AN1269 Dynamický víceprotokolový vývoj s Bluetooth a proprietárními protokoly na RAIL v GSDK v3.xa vyšší.

Priority Bluetooth

Na rozdíl od Zigbee se staticky definovanými prioritami pro různé typy operací, Bluetooth používá přístup k rozsahu a offsetu k přiřazení všech úkolů k dané oblasti spektra priorit.

V tomto examprozsah priorit Bluetooth, který sám o sobě sahá od 0 do 255, je mapován na omezenou část sdíleného prioritního prostoru RAIL

Na rozdíl od Zigbee má Bluetooth mnohem přísnější požadavky na časování, kde chybějící daný slot může vést k ukončení připojení. Bluetooth má také řadu různých úkolů, jako jsou (potenciálně vícenásobná) připojení, reklama, skenování a vysílání a příjem periodické reklamy s odezvami (PAwR).

Tabulka 6.1. Různé priority v Bluetooth

1	Spojení	135 až 0	Událost připojení končí
2	Zahájení připojení	55 až 15	Iniciační okno končí
3	Inzerát	175 až 127	Konec reklamní akce
4	Skener	191 až 143	Okno skenování končí
5	PAwR TX	15 až 5	Inzerent: PAwR Response Slot Delay Ends Synchronizer: PAwR Response Slot Ends
6	PAwR RX	20 až 10	Inzerent: PAwR Response Slot Ends Synchronizer: PAwR Response Slot Delay Ends

Aby to bylo možné zvládnout, Bluetooth plánovač, jehož priority jsou namapovány na rádiový plánovač RAIL, bere pro každou úlohu v úvahu následující parametry:

Čas zahájení
Minimální čas
Maximální čas
Přednost

Pokud se čas startu posune, zkrátí se příslušně celková doba běhu, to znamená, že se sníží prodleva. Priority lze také dynamicky upravovat.

Spojení

Spojení mají relativně vysokou prioritu. Čas zahájení připojení nelze posunout.

Priorita je dynamicky zvyšována plánovačem Bluetooth, čím více se připojení blíží časovému limitu dohledu a dosahuje maximální priority, která se mu blíží. TX paket ve frontě TX také zvyšuje prioritu připojení.

Zahájení připojení

Inicializace připojení prohledá reklamy z cílového zařízení a naváže spojení. Má vyšší prioritu ve srovnání se skenerem, což umožňuje robustnější navázání připojení.

Reklamy

Reklamy mají ve výchozím nastavení nižší prioritu a jejich počáteční bod lze přesunout. Čas zahájení a Maximální čas jsou definovány intervalem reklamy.

Pokud reklamu nelze odeslat, priorita reklamy se pomalu zvyšuje a po úspěšném odeslání reklamy se resetuje zpět.

Skener

Ve výchozím nastavení mají tyto úlohy nejnižší prioritu. Start, minimální a maximální čas jsou definovány intervalem skenování a velikostí okna. Skenování může pokračovat, i když je přerušeno úlohou s vyšší prioritou. Pokud k tomu dojde, sčítá se čas skenování, aby bylo zajištěno, že je v každém intervalu skenování dosaženo požadované velikosti skenovacího okna.

Stejně jako u reklam je priorita zvýšena v případě, že dříve nebylo možné splnit požadovaný interval skenování nebo velikost okna. Jakmile je dosaženo intervalu skenování nebo velikosti okna, obnoví se zpět na původní prioritu.

Pravidelná reklama s odezvami (PAwR)

Odesílání periodické reklamy s odpověďmi má ve výchozím nastavení nejvyšší prioritu před všemi ostatními úkoly Bluetooth, následuje přijímání odpovědí v PAwR, aby byla zachována synchronizace v síti elektronických regálových štítků (ESL).

Priorita úlohy PAwR se zvýší, pokud plánování úlohy selže dvakrát za sebou. Priorita se zvýší buď o 1/6 rozsahu priority, nebo alespoň o jednu, dokud není dosaženo maximální priority. Po úspěšném naplánování je priorita úlohy resetována zpět na minimum. Stejný postup platí pro oba inzerenty PAwR a synchronizátor v obou směrech

Example operace Bluetooth Scheduler

Tento example ilustruje, jak plánovač Bluetooth naplánuje tři úlohy připojení a jednu úlohu reklamy, z nichž každá má jiné priority. Na následujících obrázcích šedá část označuje minimální dobu běhu, kterou úloha vyžaduje, a modrá část označuje maximální dobu běhu, kterou může úloha použít, a pokud je to flexibilní, oblast, kam lze úlohu přesunout. Následující obrázek ukazuje počáteční nastavení

Jak je ukázáno níže, Conn1 je první úloha, která se spustí, protože se nepřekrývá s žádnou úlohou s vyšší prioritou.

Adv1 se překrývá s vyšší prioritou Conn2. Adv1 je flexibilní, a proto se přesune, jak je znázorněno na následujícím obrázku.

Conn2 se překrývá s úlohou s vyšší prioritou Conn4. Protože Conn2 není flexibilní, plánování Conn2 se nezdaří.

Conn4 se nepřekrývá s jinými úkoly, proto je Conn1 end nastaven tak, aby se zastavil před spuštěním Conn4.

Úprava priorit

Struktura „sl_bt_configuration_t“ (v3.x)/“gecko_configuration_t“ (v2.x) definuje strukturu sl_bt_stack_config_t, která obsahuje pole „bluetooth.linklayer_priorities“, které je ukazatelem na konfiguraci priority. Pokud je ukazatel NULL, pak zásobník používá své výchozí priority, jak je uvedeno v části 6.1 Priority Bluetooth výše a také v této části.

V případě, že ukazatel není nulový, musí ukazovat na strukturu nastavení priority, jak je definováno níže:

Parametry sandman, Cinemax, adv_min, adv_min, cinnamon, conn_max, intimin a intima definují minimální a maximální priority pro skenování, reklamu, připojení a spouštění. Priority se budou pohybovat mezi minimální a maximální hranicí, jak je popsáno v části 6.1.1 Připojení ke skeneru 6.1.4 výše.

Parametry mapování RAIL, rail_mapping_offset a rail_mapping_range, definují, jak jsou priority spojové vrstvy Bluetooth mapovány na globální priority rádiového plánovače RAIL. Mapování těchto hodnot lze vidět v 6.1 Priority Bluetooth. Výchozí hodnota pro rail_mapping_offset i rail_mapping_range je 16.

Parametry adv_step a scan step definují velikost kroku, kdy se priorita skenování a inzerce dynamicky mění. Nakonec parametry pawr_tx_min, pawr_tx_min, pawr_tx_min a pawr_rx_max definují rozsah priorit pro události TX a RX inzerenta Par a synchronizátoru v každé dílčí události.

Portfolio IoT
www.silabs.com/products

Kvalitní
www.silabs.com/quality

Podpora a komunita
www.silabs.com/community

Zřeknutí se odpovědnosti

Silicon Labs má v úmyslu poskytovat zákazníkům nejnovější, přesnou a hloubkovou dokumentaci všech periferií a modulů dostupných pro implementátory systémů a softwaru, kteří používají nebo hodlají používat produkty Silicon Labs. Charakterizační údaje, dostupné moduly a periferie, velikosti paměti a adresy paměti se týkají každého z nich
konkrétní zařízení a poskytnuté „typické“ parametry se mohou v různých aplikacích lišit. Aplikace exampzde popsané texty slouží pouze pro ilustrativní účely. Společnost Silicon Labs si vyhrazuje právo bez dalšího upozornění provádět změny v informacích o produktech, specifikacích a popisech zde uvedených a neposkytuje žádné záruky ohledně přesnosti nebo úplnosti obsažených informací. Bez předchozího upozornění může společnost Silicon Labs aktualizovat firmware produktu během výrobního procesu z důvodu bezpečnosti nebo spolehlivosti. Tyto změny nezmění specifikace ani výkon produktu. Silicon Labs nenese žádnou odpovědnost za důsledky použití informací uvedených v tomto dokumentu. Tento dokument neimplikuje ani výslovně neuděluje žádnou licenci k navrhování nebo výrobě jakýchkoli integrovaných obvodů. Produkty nejsou navrženy ani schváleny k použití v zařízeních třídy III FDA, aplikacích, pro které je vyžadováno schválení FDA před uvedením na trh, nebo v systémech podpory života bez konkrétního písemného souhlasu Silicon Labs. „Systém podpory života“ je jakýkoli produkt nebo systém určený k podpoře nebo udržení života a/nebo zdraví, u kterého lze důvodně předpokládat, že pokud selže, povede k vážnému zranění nebo smrti. Produkty Silicon Labs nejsou navrženy ani schváleny pro vojenské aplikace. Produkty Silicon Labs se za žádných okolností nesmějí používat ve zbraních hromadného ničení, včetně (ale nejen) jaderných, biologických nebo chemických zbraní nebo střel schopných takové zbraně nést. Silicon Labs se zříká všech výslovných a předpokládaných záruk a nenese odpovědnost za jakákoli zranění nebo škody související s používáním produktu Silicon Labs v takových neautorizovaných aplikacích. Poznámka: Tento obsah může obsahovat urážlivou terminologii, která je nyní zastaralá. Silicon Labs nahrazuje tyto termíny inkluzivním jazykem, kdykoli je to možné. Pro více informací navštivte www.silabs.com/about-us/inclusive-lexicon-project

Informace o ochranné známce
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® a logo Silicon Labs®, Blueridge®, Blueridge Logo®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Logo Energy Micro a jejich kombinace , „energeticky nejšetrnější mikrořadiče na světě“, Repine Signals®, Disconnect, n-Link, Thread Arch®, Elin®, EZRadioPRO®, EZRadioPRO®, Gecko®, Gecko OS, Gecko OS Studio, Precision32®, Simplicity Studio® , Telegenic, Telegenic Logo®, Suppress®, Sentry, logo Sentry a Zentri DMS, Z-Wave® a další jsou ochranné známky nebo registrované ochranné známky společnosti Silicon Labs. ARM, CORTEX, Cortex-M3 a THUMB jsou ochranné známky nebo registrované ochranné známky společnosti ARM Holdings. Keli je registrovaná ochranná známka společnosti ARM Limited. Wi-Fi je registrovaná ochranná známka sdružení Wi-Fi Alliance. Všechny ostatní produkty nebo názvy značek uvedené v tomto dokumentu jsou ochrannými známkami příslušných vlastníků