SILICON LABS UG305 Dynamic Multiprotocol notendahandbók

SILICON LABS UG305 Dynamic Multiprotocol notendahandbók

Innihald fela sig

Inngangur

Þetta skjal lýsir því hvernig Silicon Labs hugbúnaður er hannaður til að nota margar samskiptareglur á einni þráðlausri flís. Dynamic multiprotocol tímasneiðar útvarpið og breytir hratt stillingum til að gera mismunandi þráðlausar samskiptareglur kleift að starfa áreiðanlega á sama tíma.

Athugið: Zigbee-sértæku upplýsingarnar í þessu skjali eiga við útgáfu 6.10.x og lægri.
Upplýsingar um sérstakar, kraftmikla fjölsamskiptareglur útfærslur eru veittar í eftirfarandi umsóknarskýringum:
AN1133: Dynamic Multiprotocol þróun með Bluetooth og Zigbee EmberZNet SDK 6.x og lægri
AN1134: Dynamic Multiprotocol þróun með Bluetooth og sérsamskiptareglum á RAIL í GSDK v2.x
AN1269: Dynamic Multiprotocol Development með Bluetooth® og sérsamskiptareglum á RAIL í GSDK v3.x og hærri
AN1209: Dynamic Multiprotocol þróun með Bluetooth og Connect
AN1265: Dynamic Multiprotocol Development með Bluetooth® og OpenThread í GSDK v3.x

Hugtök

Eftirfarandi listar upp nokkur hugtök sem eru sértæk fyrir kraftmikla fjölsamskiptareglur útfærslu

Radio Abstraction Interface Layer (RAIL): Algengt API þar sem kóði á hærra stigi fær aðgang að EFR32 útvarpinu.

Útvarpsrekstur: Ákveðin aðgerð sem á að skipuleggja. Útvarpsaðgerð hefur bæði útvarpsstillingu og forgang. Hver stafli getur beðið um að útvarpsáætlunarstjórinn framkvæmi allt að tvær útvarpsaðgerðir (bakgrunnsmóttaka og annaðhvort áætlunarmóttaka eða áætlaðar móttökur

Bakgrunnsmóttaka: Viðvarandi móttaka, sem ætlað er að trufla með áætlunaraðgerðum, og snúa aftur í eftir að þeim er lokið.

Áætluð móttaka: Fáðu pakka eða reiknaðu RSSI á tilteknum tíma og tíma. (Hönnuðir sem vinna á RAIL, athugaðu að hvað varðar RAIL API, vísar „Skeduled Receive“ eins og það er notað í þessu skjali til hvers kyns móttökuaðgerða, annarra en RAIL_StartRx, og er ekki bara takmarkað við RAIL_ScheduleRx.)
Áætlaður Transmit: Einhver af ýmsum sendingaraðgerðum, þar með talið tafarlausri sendingu, áætlaðri (framtíðar) sendingu eða CCA-háðri sendingu. (Hönnuðir sem vinna á RAIL, athugaðu að hvað varðar RAIL API, vísar „Skeduled Transmit“ eins og notað er í þessu skjali til hvers kyns sendingaraðgerða og er ekki takmarkað að umfangi við RAIL_StartScheduledTx.

Radio Config: Ákveður ástand vélbúnaðarins sem þarf að nota til að framkvæma útvarpsaðgerð.

Útvarpsáætlun: RAIL hluti sem ræður milli mismunandi samskiptareglur til að ákvarða hverjir munu hafa aðgang að útvarpinu.

Forgangur: Hver aðgerð úr hverjum stafla hefur sjálfgefna forgang. Forrit getur breytt sjálfgefnum forgangsröðun.

Slip Time: Hámarkstími í framtíðinni þegar hægt er að hefja aðgerðina ef hún getur ekki hafist á umbeðnum upphafstíma.

Afrakstur: Stafli verður að gefa eftir af fúsum og frjálsum vilja í lok aðgerðar eða röð aðgerða, nema hann sé að framkvæma bakgrunnsmóttöku. Þar til staflinn gefur af sér mun tímaáætlunarmaðurinn ekki skipuleggja verkefni með lægri forgang

RTOS (rauntíma stýrikerfi) kjarni: Sá hluti stýrikerfisins sem ber ábyrgð á verkefnastjórnun og samskiptum og samstillingu milli verkefna. Þessi útfærsla notar Micrium OS-5 kjarnann.

Arkitektúr

Dynamic Multiprotocol notar EFR32 vélbúnaðinn og RAIL hugbúnaðinn sem byggingareiningar. Síðan er hægt að byggja Zigbee, Bluetooth og/eða aðrar staðlaðar eða sérsamskiptareglur ofan á þessi óbundnu lög með því að nota Micrium til að stjórna keyrslu kóða á milli mismunandi samskiptareglna. Eftirfarandi skýringarmynd sýnir almenna uppbyggingu hugbúnaðareininganna.

Frá og með útgáfu 2.0 þarf RAIL að senda útvarpsstillingarhandfang til RAIL API símtöl. Þessi uppsetning lýsir ýmsum PHY breytum sem eru notaðar af staflanum

Micrium OS er RTOS sem gerir stafla og forritsrökfræði kleift að deila keyrslutíma CPU.

Útvarpsáætlunarmaðurinn er hugbúnaðarsafn sem svarar á skynsamlegan hátt beiðnum frá staflanum um að framkvæma útvarpsaðgerðir til að hámarka áreiðanleika og lágmarka leynd. API frá RAIL sem taka ekki þátt í útvarpinu fara framhjá útvarpsáætluninni.

RAIL kjarninn stillir EFR32 vélbúnaðinn til að bregðast við leiðbeiningum frá útvarpsáætlunarbúnaðinum.

Ein vélbúnaðarmynd

Dynamic Multiprotocol gerir hugbúnaðarframleiðanda kleift að búa til einn monolithic binary sem er hlaðinn á EFR32. Hugbúnaðaruppfærslur eru gerðar með því að uppfæra allt tvöfaldan. Þetta er gert með því að nota Geck otloader, nánari upplýsingar um hann er að finna í UG266: Silicon Labs Gecko Bootloader User's Guide fyrir GSDK 3.2 og lægri og UG489: Silicon LabsGecko Bootloader User's Guide fyrir GSDK 4.0 og nýrri.

Sjálfstæð staflaaðgerð

Silicon Labs staflarnir starfa enn óháðir hver öðrum í Dynamic Multiprotocol aðstæður. Ákveðnar langvarandi útvarpsaðgerðir munu hafa áhrif á biðtíma annarrar samskiptareglur og virkni í samræmi. Það er undir umsókninni komið að ákveða sérstakt tillit til þessara atburða. Sjá kafla 2. Útvarpsáætlun fyrir frekari upplýsingar.

Útvarpsáætlunin

Radio Scheduler er hluti af RAIL (Radio Abstraction Interface Layer). RAIL býður upp á leiðandi, auðvelt að sérsníða útvarpsviðmótslag og API, sem styður sér- eða staðlaðar þráðlausar samskiptareglur. Útvarpsáætlunin er hönnuð til að gera ráð fyrir útvarpsaðgerðum sem hægt er að skipuleggja og forgangsraða. Mismunandi útvarpsaðgerðir í hverri samskiptareglu geta verið meira eða minna mikilvægar, eða meira eða minna tímaviðkvæmar, allt eftir aðstæðum. Skipuleggjandinn getur tekið tillit til þeirra þegar hann tekur ákvarðanir um átök og hvernig á að dæma þau

Nema þú sért að þróa forrit með sérsniðinni samskiptareglu á RAIL, eru flestar útvarpsáætlunaraðgerðir meðhöndlaðar sjálfkrafa af undirliggjandi stafla og RAIL kóða. Þú þarft aðeins að nota staflann í gegnum venjulega API þess.

Á háu stigi sendir staflan útvarpsaðgerð (tdampmeð áætlaðri móttöku eða áætlaðri sendingu). Útvarpsreksturinn er
í biðröð og síðan þjónustaðar í framtíðinni miðað við færibreytur þeirra. Þegar það er kominn tími til að hefja útvarpsrekstur skoðar dagskrárgerðarmaðurinn hvort keppandi viðburður sé til eða ekki og hvort hægt sé að seinka aðgerðinni eða ekki. Ef tímaáætlunarmaðurinn getur ekki keyrt atburðinn skilar hann niðurstöðunni í hærra lagið, sem gæti reynt aftur með nýjum breytum.

Þegar útvarpsaðgerðin er hafin getur samsvarandi stafli sent tímaáætlunarbúnaðinum viðbótaraðgerðir byggðar á niðurstöðum fyrri aðgerðarinnar (td.ampég bíður eftir ACK). Í lok hverrar aðgerðar eða röð aðgerða verður staflinn að gefa til kynna notkun á útvarpinu.

Útvarpsrekstur

Hver atburður í tímaáætluninni er skipt upp í þætti sem kallast Radio Operations, sem eru tengdir útvarpsstillingu og forgangi.

Sérhver aðgerð hefur forgang og er rofin ef tímaáætlunarmaðurinn fær aðgerð með hærri forgang sem skarast í tíma. Útvarpsaðgerðir með lægri forgang sem ekki er hægt að keyra út frá áætlunarbreytum þeirra munu mistakast og það er undir viðkomandi stafla að reyna þær aftur. Þegar tímaáætlunarmaðurinn keyrir útvarpsaðgerð á virkan hátt úr staflanum, getur staflinn haldið áfram að senda viðbótarútvarpsaðgerðir þar til hann gefur eftir af fúsum og frjálsum vilja, eða þar til tímaáætlunarmaðurinn fær útvarpsaðgerð með hærri forgang og kemur í veg fyrir það.

Bakgrunnsmóttaka
Áætluð móttaka
Áætlað sending

Hver stafli getur beðið útvarpsáætlunarmanninn um að framkvæma allt að tvær útvarpsaðgerðir (bakgrunnsmóttaka og annaðhvort áætlaða móttöku eða áætlaða sendingu) í einu:

Hver aðgerð hefur eftirfarandi færibreytur:

Upphafstími	Vísbending á hvaða tímapunkti í framtíðinni þessi útvarpsrekstur mun standa yfir. Þetta gæti verið „keyrt núna“ eða eitthvað gildi á míkrósekúndum í framtíðinni.
Forgangur	Tala sem gefur til kynna hlutfallslegan forgang aðgerðarinnar. Þegar sjálfgefnar stillingar eru notaðar eru Bluetooth LE útvarpsaðgerðir næstum alltaf í meiri forgangi en Zigbee.
Slip Time	Tími sem hægt er að seinka viðburðinum fram yfir upphafstíma hans og samt vera ásættanlegt fyrir stafla. Þetta getur verið 0, en þá er ekki hægt að sleppa atburðinum.
Viðskiptatími	Áætlaður tími sem það tekur að klára viðskiptin. Sendingarviðburðir hafa yfirleitt mun betur skilgreindan viðskiptatíma, en móttökuatburðir eru oft óþekktir. Þetta er notað til að hjálpa útvarpsáætlunarmanninum að ákvarða hvort hægt sé að keyra viðburð.

Staflan skilgreinir þessar mismunandi færibreytur sem henta aðgerðinni sem verið er að framkvæma. Til dæmisampTil dæmis, Bluetooth-tengingarviðburðir eru oft á dagskrá í framtíðinni og hafa enga leyfða miða, en Zigbee sendingarviðburðir geta oft seinkað lítið magn og stjörnu síðar.

Frá sjónarhóli RAIL Radio Scheduler eru áætlaðar sendingar og áætlaðar móttökur eins. Þær eru báðar einfaldlega aðgerðir sem krefjast notkunar á útvarpinu og er því ekki hægt að framkvæma samtímis. Munurinn er aðeins áberandi á RAIL API lag, þar sem annað hvort TX eða RX API er kallað.

Bakgrunnsmóttaka

Þetta er samfelld móttökuhamur sem ætlað er að trufla með öðrum aðgerðum og fara aftur í eftir að þeim er lokið. Ef Bakgrunnsmóttaka er í meiri forgangi en aðrar aðgerðir munu þær útvarpsaðgerðir ekki tímasettar og ekki keyra. Það er undir staflanum eða umsókninni komið að breyta forgangi eða ávöxtun af fúsum og frjálsum vilja. Sjá kafla 5.1 Dæmiamples með Background Receive, Yield Radio og State Transition til dæmisamples af því hvernig bakgrunnsmóttaka hefur samskipti við áætlaðar aðgerðir.

áætlun móttaka

Þetta er móttaka á framtíðartíma með tiltekinni lengd. Útvarpsáætlunarmaðurinn mun taka tillit til útvarpsskiptatímans þegar hann ákveður hvort aðgerðin verði áætluð eða ekki. Ef það er ekki hægt að tímasetja það þá sendir tímaáætlunarmaðurinn bilunartilvik í kallstaflann. Útvarpsaðgerðin er framlengd sjálfkrafa þar til staflan gefur eftir af fúsum og frjálsum vilja, eða tímaáætlunarmaðurinn fær aðgerð með hærri forgang og truflar hana. Með því að lengja móttökuna getur staflan haldið áfram útvarpsaðgerð sem byggist á kröfum efri stigi siðareglur, til dæmisample sendingu svars byggt á mótteknum gögnum.

Áætlað sending

Þetta er sending á framtíðartíma með lágmarkslengd. Þessi lágmarkslengd getur falið í sér væntanlega framhaldsviðburði, tdampsenda ACK til IEEE 802.15.4 senda. Hins vegar þarf lágmarkstími fyrir þessa aðgerð ekki að innihalda óvænta atburði sem geta lengt tímann umfram lágmarkstímann, t.d.ampskortur vegna CCA bilana í IEEE 802.15.4. Útvarpsáætlunarmaðurinn tekur tillit til útvarpsskiptatímans þegar hann ákveður hvort aðgerðin verði áætluð eða ekki. Ef það er ekki hægt að tímasetja það þá sendir tímaáætlunarmaðurinn bilunartilvik í kallstaflann.

Útvarpsstilling

Hver útvarpsaðgerð er tengd fyrirframskilgreindri útvarpsstillingu sem ákvarðar ástand vélbúnaðarins sem þarf að nota til að framkvæma aðgerðina. Útvarpsstillingarnar halda utan um núverandi stöðu staflans þannig að framtíðarútvarpsaðgerðir noti sömu útvarpsfæribreytur. Útvarpsstillingar geta verið virkar eða sofandi. Ef staflan breytir virkri Radio Config þá gerir RAIL tafarlausa breytingu á vélbúnaðarstillingunum líka, td.ampað skipta um rás. Ef útvarpsstillingin er ekki virk sem stendur mun næsta áætlaða útvarpsaðgerð nota nýju útvarpsstillinguna.

Forgangur

Hver útvarpsaðgerð hefur forgang sem gefur tímaáætlunaraðilanum til kynna hvaða aðgerð ætti að framkvæma ef það er tímaskörun milli margra aðgerða. Tímagerðarmaðurinn lítur á forganginn 0 sem hæsta forgang og 255 sem lægsta forgang. Útvarpsáætlunarmaðurinn mun leyfa verkefninu með hæsta forgang að fá aðgang að efnislegum ra rdware. Með flestum verkefnum er stjórnun aðeins skilað til útvarpsáætlunar þegar því er lokið, en verkefni eins og bakgrunnsmóttaka verða trufluð ef verkefni með hærri forgang verður virkt

Staflarnir hafa hver um sig sjálfgefna forgangsröðun sem byggir á greiningu Silicon Labs á því hvernig best er að vinna saman til að hámarka vinnuferilinn og forðast tengingar sem falla niður fyrir almenna notkun. Sértæk notkunartilvik geta haft mismunandi þarfir. Forgangsröðunin er sem hér segir, frá hæstu til lægstu

Bluetooth LE áætlunarsending
Bluetooth LE áætluð móttaka

Önnur siðareglur Áætlað sending
Önnur siðareglur Bakgrunnsmóttaka

Þessar forgangsröðun getur verið hnekkt eða breytt af forritinu. Það er umsóknar að ákveða við hvaða aðstæður eigi að breyta þeim. Hluti 4.2 802.15.4 RAIL Forgangur og hluti 6.1 Bluetooth-forgangur innihalda frekari upplýsingar um forgangsröðun fyrir tiltekna tilvik þeirra.

Slip Time

Sérhver útvarpsaðgerð verður að hafa „slip time“ eða hámarks upphafstíma, sem þýðir lengsta tíma í framtíðinni þegar hægt er að hefja aðgerðina ef hún getur ekki hafist á umbeðnum upphafstíma. Þetta gerir tímaáætlunarmanninum kleift að vinna í kringum atburði með hærri forgang sem eiga sér stað á sama tíma, eða atburði með hærri forgang sem eru lengri en búist er við. Samskiptareglur kveða almennt á um hver sleðatíminn getur verið, en útvarpsáætlunarmaðurinn er fær um að meðhöndla þetta á grundvelli aðgerða, sem gerir stafla kleift að renna sumum atburðum en ekki öðrum. Almennt séð hefur IEEE02.15.4 lengri sleðatíma og Bluetooth LE hefur lágmarks sleðatíma.

Afrakstur

Þegar röð af útvarpsaðgerðum hefur verið keyrð, getur staflinn haldið áfram að bæta við aðgerðum sem framlengir upphafsaðgerðina þar til staflinn hefur ekkert meira að gera fyrir tiltekna skilaboðaskipti. Stafla verður að gefa eftir nema hann sé að framkvæma bakgrunnsmóttöku. Ef stafli gefur ekki eftir mun hann halda áfram að lengja útvarpsrekstur sinn og útvarpsaðgerðir með lægri forgang munu þá kalla fram bilun aftur í samsvarandi stafla sem bað um þá útvarpsaðgerð. Aðgerð með hærri forgang getur ekki truflað útvarpsaðgerð með lægri forgangi í gangi sem hefur ekki skilað sér. Sjá kafla 5.1 Examples með Background Receive, Yield Radio og State Transition til dæmisamples af aðstæðum þar sem nauðsynlegt er að gefa útvarpið beinlínis eftir.

Að trufla útvarpsaðgerð

Áætluð útvarpsaðgerð getur verið rofin ef aðgerð með hærri forgang stangast á við hana. Þetta gæti gerst við eftirfarandi tvær aðstæður:

Áætluð útvarpsaðgerð tekur lengri tíma en búist var við og samsvarandi stafla skilar sér ekki því útvarpsrekstur með hærri forgang verður að hefja.
Útvarpsaðgerð með hærri forgang hefur nýlega verið áætlað að eiga sér stað í framtíðinni og stangast á við aðgerð með lægri forgang sem þegar hefur verið áætlað

Langvarandi útvarpsrekstur

Ákveðnar langvarandi útvarpsaðgerðir geta haft mikil áhrif á rétta notkun vörunnar. Forritið gæti þurft að samræma þessar aðgerðir á milli samskiptareglur. Ef umsóknin gerir það ekki þá mun forgangsröðun útvarpsáætlunar hafa forgang. Til dæmisampIEEE 802.15.4 orkuskönnun getur krafist þess að útvarpið sé kveikt til að safna nægilegum orkumælingum. Ef forritið samhæfir ekki aðgerðirnar rétt gæti skönnunin rofnað of snemma vegna Bluetooth-aðgerðar með hærri forgang.

Útvarpsáætlun Examples

Allt úramplesar nota Bluetooth LE og Zigbee, en meginreglurnar gilda um aðrar Bluetooth/802.15.4 samsetningar.

Tímaáætlunin byrjar á því að láta móttaka Zigbee bakgrunn með lágum forgangi. Þetta táknar alltaf-á leið sem gæti þurft að taka á móti IEEE 802.15.4 pakka á óþekktum tíma. Bluetooth LE tenging er einnig virk og krefst þess að staflan sé tilbúinn til móttöku á 30 ms fresti. Bluetooth LE staflan gæti tímasett þetta með góðum fyrirvara vegna þess hve tengingin er fyrirsjáanleg.

Forgangsáætlun

Þetta gefur grunn tdampdæma um forgangsröðun mismunandi útvarpsaðgerða.

Zigbee staflan ákveður að hann þurfi að senda pakka. Það gæti gert þetta sem atburður eftir kröfu, sem þýðir að staflinn ákveður að hann vilji senda pakka núna án þess að láta tímaáætlunarmann vita með góðum fyrirvara. Þetta er öfugt við hvernig Bluetooth LE starfar, þar sem áætlaðar aðgerðir eru þekktar með hæfilega löngu fyrirvara. Tímaáætlunarmaðurinn metur að það sé hægt að framkvæma Zigbee TX 1 útvarpsaðgerðina og samt þjóna Bluetooth LE móttökuatburðinum með hærra forgang í framtíðinni. Þannig að tímaáætlunin leyfir sendingaratburðinum að eiga sér stað. Zigbee staflan framkvæmir alla hluta þessarar sendingaraðgerðar (bíður eftir MAC ack) og gefur sig síðan sjálfviljugur. Áætlaður viðskiptatími Zigbee-útvarpssendingarinnar inniheldur EKKI endurtilraunir.

Í þessu frvample, Bluetooth LE er nú þegar áætlað að taka á móti í framtíðinni og Zigbee staflan vill senda. Fyrir fyrstu Zigbee TX 1 útvarpsaðgerðina er nægur tími fyrir Bluetooth LE RX 1 útvarpsaðgerðina svo tímaáætlunin leyfir staflanum að framkvæma aðgerðina. Síðar, þegar Zigbee staflan reynir að tímasetja Zigbee TX 2, ákveður tímaáætlunarmaðurinn að það sé ekki nægur tími fyrir Bluetooth LE RX 2 viðburðinn með mikla forgang. Hins vegar hefur Zigbee staflan gefið til kynna að þessi aðgerð gæti runnið út upphafstíma hennar. Útvarpsáætlunarmaðurinn ákvarðar að miðað við væntanlega lengd Bluetooth LE útvarpsaðgerðarinnar geti Zigbee aðgerðin hafist eftir þann atburð og enn verið innan þess tíma sem Zigbee staflan gefur til kynna.

Ef allt gengur eins og búist var við mun fyrsta tilraun Zigbee-sendingarinnar eiga sér stað án bilana vegna tímasetningar.

Forgangsrof Example

Þetta frvample sýnir aðgerð með hærri forgang sem truflar aðgerð með lægri forgang.

Þetta frvample byrjar á sama hátt og fyrra frvample. Zigbee og Bluetooth LE eru bæði með útvarpsaðgerð sem er áætluð án áreksturs

Síðar ákveður Zigbee staflan að hann vilji senda annan pakka fyrir Zigbee TX 2 viðburðinn. Tímaáætlunin ákveður að það ætti að vera hægt að skipuleggja þennan viðburð og þjónusta Bluetooth LE RX 2 viðburðinn síðar, byggt á þeim tíma sem Zigbee TX 2 viðburðurinn þarf að taka. Hins vegar tekur Zigbee TX 2 atburðurinn lengri tíma en búist var við vegna langrar tilviljunarkenndar bakslags og gefur ekki eftir í tæka tíð. Þetta veldur því að atburðurinn rekast á rad peration með hærri forgang og því truflar Radio Scheduler Zigbee atburðinn og skilar bilun í hærra stigs stafla. Bluetooth LE atvikið á sér stað venjulega og þegar því er lokið víkur það sjálfviljugur fyrir aðgerðum með lægri forgang.

Þegar bilunin berst frá útvarpsáætlunarstjóranum reynir Zigbee staflan strax að reyna aftur MAC skilaboðin. Það tímasetur aðgerðina og felur í sér miðatíma. Á þessum tímapunkti hefur Bluetooth LE staflan forgang yfir útvarpið og því er ekki hægt að hefja aðgerðina ennþá, en tímaáætlunarmaðurinn samþykkir nýju útvarpsaðgerðina. Bluetooth LE staflan klárar áætlaða móttöku sína og gefur útvarpið. Tímaáætlunin kveikir síðan á því að Zigbee sendingaraðgerðin á sér stað vegna þess að hún er enn innan sleðatíma upphaflegu upphafsaðgerðarinnar. Eftir að sendingu er lokið fer tímaáætlunarmaðurinn aftur í bakgrunnsmóttökuaðgerðina.

Aðgerð með hærri forgang sem er framlengd

Þetta frvampLe sýnir hvað gerist þegar aðgerð með hærri forgang tekur lengri tíma en upphaflega var áætlað og veldur því að aðgerð með lægri forgang missir af tækifæri sínu

Í þessu tilviki er Bluetooth LE með áætlunarmóttöku sem nú á sér stað. Zigbee ákveður að senda pakka en það er ekki hægt að keyra hann núna. Tímagerðarmaðurinn samþykkir aðgerðina með þeirri forsendu að Bluetooth LE atburðinum ljúki áður en sleppa tíma Zigbee atburðarins lýkur. Bluetooth LE atburðurinn teygir sig hins vegar lengur vegna þess að viðbótarpakkar eru sendir á milli tækjanna. Bluetooth LE aðgerðin hefur forgang svo Zigbee aðgerðin klárast að lokum. Villa er skilað inn í stafla. Zigbee ákveður að senda pakkann aftur. Aftur, Zigbee staflan gefur til kynna að aðgerðin ætti að hefjast núna en gæti runnið inn í framtíðina. Tímaáætlunin er í miðju að breyta útvarpsstillingunni svo hann getur ekki hafið aðgerðina strax. Þess í stað setur það upphafstíma útvarpsaðgerðarinnar lítið magn og framkvæmir síðan aðgerðina.

Aðgerð með hærri forgang án truflana

Í þessu frvampÚtvarpsáætlunarmaðurinn er í gangi á hnút sem virkar sem Bluetooth LE jaðartæki og sá hnútur hefur fjölda tenginga við mismunandi miðlæg tæki. Það hefur einnig reglubundið auglýsingaljós sem er sent út. Eftirfarandi mynd sýnir tilvik þar sem þessir atburðir eiga sér stað nánast bak við bak og gefa ekki nægan tíma til að skipta aftur yfir í Zigbee útvarpsstillingu. Þess vegna mun það skapa tímabil þar sem Zigbee staflan er
ófær um að senda jafnvel með sleðatímanum.

Zigbee biður tímaáætlunarmann um að skipuleggja útvarpsaðgerð. Jafnvel þó að tímaáætlunarmaðurinn viti að viðburðurinn muni mistakast vegna áætlaðra aðgerða með hærri forgang, samþykkir hann samt áætlaða viðburðinn. Þetta er gert af tveimur ástæðum. Í fyrsta lagi geta aðstæður breyst og hægt er að framkvæma atburðinn. Í öðru lagi gæti staflan sem situr ofan á útvarpsáætluninni reynt að reyna aftur aðgerðina. Ef niðurstaðan af misheppnuðu tímasetningunni var skilað samstundis þá væri ólíklegt að tilraun staflans til að reyna aftur heppnist þar sem enginn tími er liðinn. Þess í stað, með því að setja viðburðinn í biðröð og skila biluninni eftir að miðunartíminn er liðinn, hefur endurtilraun (með eigin miðatíma) meiri möguleika á árangri þar sem hópur komandi útvarpsaðgerða verður öðruvísi.

Móttaka þegar aðgerð með hærri forgang er í gangi

Þetta frvample sýnir hvað gerist þegar Bluetooth LE er virkt og aðgerð með lægri forgang mun taka á móti gögnum.

Í fyrra tilvikinu, þegar IEEE 802.15.4 skilaboð eru send og Bluetooth LE staflan notar útvarpið fyrir virka móttöku mun Zigbee staflan ekki vera á netinu til að taka á móti skilaboðunum. Hins vegar mun Zigbee sendandi skilaboðanna reyna aftur í flestum tilfellum og með afturköllun og öðrum breytingum á tímasetningu mun ekki stangast á við aðra áætlaða Bluetooth móttökuatburði með hærri forgang sem ólíklegt er að rekast á. Zigbee skilaboðin hafa verið móttekin

Annað tilvikið sýnir að ef um er að ræða virka móttöku, gæti Zigbee staflan enn verið rofin og ekki tekið við (eða ACK) skilaboðin. Árangursrík samskipti treysta á endurtekningar á MAC eða hærra lagi til að senda þessi skilaboð aftur og staðfesta að Dynamic Multiprotocol tækið fái skilaboðin.

Þó að það kunni að vera til skoðunar hvort rjúfa ætti virka móttöku eða ekki, er erfitt fyrir tímaritara að taka þá ákvörðun. Almennt séð ætti styrkleiki samskiptareglnanna að gera kleift að taka á móti skilaboðum með góðum árangri, jafnvel þótt truflanir séu

Innleiðing Multiprotocol með 802.15.4-undirstaða stafla

Þessi kafli býður upp á almennar upplýsingar um innleiðingu á 802.15.4-byggðum stafla eins og Zigbee eða Connect sem hluta af fjölsamskiptaforritum. Fyrir upplýsingar um hvernig á að stilla plugins og aðrar upplýsingar sem eru sértækar fyrir tiltekna siðareglur, sjá eina af eftirfarandi umsóknarskýringum:

AN1133: Dynamic Multiprotocol þróun með Bluetooth og Zigbee EmberZNet SDK 6.x og lægri

AN1209: Dynamic Multiprotocol þróun með Bluetooth og Connect

Stuðningur við þráðlausa bókun

Mismunandi þráðlausar samskiptareglur hafa mismunandi eiginleika sem hafa verið nýttar með hönnun Dynamic Multiprotocol. Til dæmisample, Bluetooth Low Energy er mjög ströng og fyrirsjáanleg í áætlun sinni um útvarpsrekstur; auglýsingar og tengingartímabil eiga sér stað á ákveðnum tímum. Aftur á móti er 802.15.4 siðareglur sveigjanlegri í tímasetningu margra skilaboðaviðburða; CSMA (carrier sense multiple access) í IEEE 802.15.4 bætir við tilviljunarkenndum afturköllum þannig að tafir á atburðum eru af stærðargráðunni millisekúndur. Þetta gerir kleift að senda IEEE 802.15.4 skilaboð í kringum Bluetooth Low Energy atburðina og samt vera móttekin á áreiðanlegan hátt

802.15.4 járnbrautarforgangur

802.15.4 samskiptareglur hafa nú þrjár forgangsröðun RAIL.

Nei.	Nafn	Sjálfgefin stilling	Hætta viðmiðun
1	Virkur TX	100	MAC ACK móttekið (eða ekki)
2	Virkur RX	255	Pakka síaður eða MAC ACK sendur
3	Bakgrunnur RX	255	Verkefni með hærri forgang til staðar

Ef Active TX er keyrt verður útvarpinu sleppt á þeim tíma sem samsvarandi MAC staðfesting var móttekin (eða tími kom upp).

Bakgrunnur RX mun skilja útvarpið eftir í móttökustöðu tilbúið til að taka á móti ósamstilltum skilaboðum. Ef virki RX forgangurinn er annar en bakgrunnur RX forgangurinn, mun móttökuforgangurinn hækka í hvert sinn sem samstillingarorð finnast og aðeins lækkað þegar pakkinn er síaður eða lokið og ACK hans er sendur ef óskað var eftir því.

Jafnvægi Forgangsröðun

Eins og útskýrt er í kafla 6.1 Bluetooth forgangsröðun er sjálfgefið Bluetooth forgangssvið varpað inn í RAIL forgangssviðið 16 – 32. Almennt byrjar Bluetooth með lágum forgangi (32) og eykur forganginn á virkan hátt upp í hámark (16) eins og þörf ef skilaboð berast ekki.

Eins og lýst er í fyrri hlutanum notar 802.15.4-undirstaða stafla eins og Zigbee eða Connect sjálfgefna RAIL forgangsgildi 255 fyrir bakgrunn RX, 255 fyrir virka RX og 100 fyrir virka TX.

Sem afleiðing af þessum sjálfgefna RAIL forgangsröðun, í 802.15.4 samskiptareglum-Bluetooth multiprotocol forriti, mun sjálfgefið Bluetooth umferð alltaf hafa forgang fram yfir 802.15.4 samskiptareglur umferð. Þetta er góður kostur fyrir mörg forrit, vegna þess að Bluetooth umferð hefur strangar tímasetningarkröfur, ólíkt 802.15.4 samskiptareglum. Hins vegar, ef Bluetooth umferðarálag er mjög mikið (tdampmeð því að senda mikið af gögnum með mjög litlum tengingarbili), er mögulegt að 802.15.4 samskiptareglur verði algjörlega lokaðir fyrir aðgang að útvarpinu vegna lægri forgangs þess og mjög lítilla glugga tiltæks útvarpstíma sem Bluetooth skilur eftir sig. umferð

Athugið: Eftirfarandi upplýsingar eiga sem stendur aðeins við um EmberZNet Zigbee stafla. Silicon Labs Connect hefur ekki enn þá API sem þarf til að breyta forgangsröðuninni.

Ef þú ert að þróa 802.15.4 byggt kraftmikið fjölsamskiptaforrit, og það er mikilvægt að þessi umferð nái árangri þegar Bluetooth umferð er mjög mikil, geturðu stillt sjálfgefna forgangsröðun eins og sýnt er í töflunni hér að neðan með því að nota eftirfarandi API:

Nei.	Nafn	Sjálfgefin stilling
1	Virkur TX	23
2	Virkur RX	24
3	Bakgrunnur RX	255

Vegna þess að Bluetooth stillir upphaflega RAIL forganginn á 32, gefa þessar 802.15.4 forgangsstillingar 802.15.4 umferð hærri forgang en Bluetooth í upphafi, sem gefur 802.15.4 samskiptareglunum tækifæri til að senda eða taka á móti umferð með góðum árangri, jafnvel í viðurvist mjög mikið álag af Bluetooth umferð. Á hinn bóginn mun Bluetooth auka forgang sinn á kraftmikinn hátt ef það er rekið frá tímaáætlunarkerfinu með 802.15.4 umferð, upp í háan forgang upp á 16. Þannig mun Bluetooth eftir að hafa leyft 802.15.4 siðareglur aðgang að útvarpinu í upphafi taka forgang við síðari endurtilraunir ef þörf krefur.

Þessi nálgun gerir báðum samskiptareglum kleift að skerða notkun þeirra á útvarpinu án þess að önnur geti algjörlega drottnað yfir hinni.

. Innleiðing Multiprotocol með RAIL

Þessi kafli býður upp á frekari upplýsingar um sérkenni RAIL fyrir notendur sem neyta RAIL API beint til að þróa sérsamskiptareglur. Sérstaklega býður það upp á upplýsingar um hvernig á að vinna með RAIL API til að takast á við tiltekin útvarpsáætlunartilvik.

Examples með Background Receive, Yield Radio og State Transition

Grundvallaratriði RAIL Multiprotocol forgangskerfisins eru frekar einföld: útvarpsatburður með hærri forgang (þ.e. minni í fjölda) mun alltaf ræna sérhverjum öðrum útvarpsatburðum með lægri forgang. Hins vegar verður þetta efni flóknara þegar litið er til ástandsbreytinga og API eins og RAIL_StartRx(), sem setja útvarpið í ákveðið ástand í óákveðinn tíma. Þessi hluti veitir nokkrar myndir sem tdamples til að sýna fram á hvernig þessi tímabundnu ástand eru meðhöndluð og hvernig forritalagið getur notað API eins og RAIL_YieldRadio() til að stjórna þeim. Fyrrverandiamples eru sem hér segir:

Ríkisskipti með einni bókun
Ríkisskipti með tveimur bókunum

Ríkisskipti með tveimur bókunum og eintóna vaxandi forgangsröðun

Í þessu frvamples, RAIL_StartTx() er uppspretta TX atburðarins sem truflar bakgrunns RX. Athugið þó að þessi frvamples eiga við um hvaða útvarpsforritaskil nema fyrir RAIL_StartRx(). Með öðrum orðum, fyrrverandiamples eiga við um hvaða forritaskil sem hefja útvarpsviðburð sem er ekki bakgrunnur RX

Þessir fyrrvampLesið sýnir væntanleg hegðun með mörgum samskiptareglum með tilliti til ástandsbreytinga. Til að draga saman:

Í ástandsbreytingu er nýja ástandið meðhöndlað sem ótímabundin framlenging á upphafsatburðinum með sama forgang þar til RAIL_YieldRadio() er kallað.
RX atburðir í bakgrunni verða ekki fyrir áhrifum af RAIL_YieldRadio(). Aðeins RAIL_Idle() getur fjarlægt samskiptareglur varanlega úr RX ástandi í bakgrunni.
Atburður með hærri forgang mun alltaf ræna viðburð með lægri forgang, óháð öðrum API símtölum.

Aðeins RAIL_StartRx() móttökur er hægt að 'snúa aftur til' frá atburði með hærri forgang í gegnum RAIL_YieldRadio() eða RAIL_Idle().
Allir útvarpsatburðir aðrir en RAIL_StartRx() krefjast RAIL_YieldRadio() til að ljúka og halda áfram í næsta atburð.
Símtalið til RAIL_YieldRadio() er ekki hægt að skipta út fyrir RAIL_Idle(). RAIL_Idle() hreinsar út alla atburði fyrir tiltekna samskiptareglu

.Ríkisskipti með einni bókun

Þetta fyrsta fyrrvample skoðar hegðun útvarpsins með einni samskiptareglu (þ.e. þar sem sama AIL_Handle_t er notað fyrir öll útvarpsaðgerðakall). Útvarpið byrjar í RX með upphafssímtali til RAIL_StartRx(), færist síðan yfir í TX með símtali með hærri forgang í RAIL_StartTx(). Það er mikilvægt að hafa í huga að eftir að sendingin er lokið, fer útvarpið yfir í það ástand sem tilgreint er af RAIL_SetTxTransitions(), og það helst í ástandinu endalaust á sama forgangi og rás og TX þar til RAIL_YieldRadio() er kallað. Eftir það fer útvarpið aftur í RX, með upphaflega tilgreinda forgang og rás.

Þörfin á að gefa útvarpið á virkan hátt og þar með RAIL_YieldRadio() API voru nauðsynleg að mestu leyti vegna ACK'ing. Hönnunarhugmyndin er sú, vegna þess að bæði TX og móttekin ACK eru það viewed sem hluti af sömu viðskiptum, ef hnútur sendir og býst við ACK ætti hann að geta bæði skipt yfir í RX og haldið áfram að hlusta á ACK sem hluta af sömu aðgerð (og þar af leiðandi sama forgang) og upprunalega TX. Almennt séð getur RAIL á eigin spýtur ekki vitað hvort ACK sé krafist eða ekki. Þetta getur verið háð öðrum þáttum, eins og pakkainnihaldi eða annarri rökfræði forrita, og því er ekki hægt að ákvarða það einfaldlega með því að athuga hvort ACK'ing hafi verið stillt með RAIL_ConfigAutoAck(). Þess vegna er geðþótta eftir um hvenær útvarpsviðskiptum er lokið. tíkun/stafla.

Ef ACK er ekki krafist, mælir Silicon Labs með því að hringja í RAIL_YieldRadio() sem hluta af meðhöndlun RAIL_EVENT_TX_PACKET_SENT atburðarins. Að gera þetta veldur því að græna línan á myndinni hér að ofan er lágmarkað niður í töf á truflunum. Ef forritið býst við ACK, ætti að hringja í RAIL_YieldRadio() þegar ACK er móttekið eða hefur verið talið að það hafi runnið út.

Ríkisskipti með tveimur bókunum

Þessi atburðarás er svipuð fyrstu atburðarás varðandi ástandsbreytingar eftir TX, en kynnir aðra siðareglur.

Í þessum aðstæðum er mikilvægt að hafa í huga að hægt er að hringja í RAIL_StartRx() hvenær sem er meðan á TX færslunni stendur. Svo lengi sem forgangur þess er minni en eða jafn og forgangur TX, mun RX ekki taka gildi fyrr en forritið kallar á _Yield Radio() á bókun A. Þegar RAIL_StartRx() er kallað á meðan á TX stendur, er RX aðeins bætt við röð viðburða sem á að sinna.

Annað lykilatriði er að þó að RAIL_YieldRadio() á bókun A muni skipta úr TX á bókun A yfir í RX á bókun B, þá þarf RAIL_Idle() á bókun B til að skipta úr RX á bókun B yfir í RX á bókun A. Hugmyndafræðin hér er sú að Bakgrunns RX er í raun ekki hægt að skila, þar sem viðburðurinn er í raun aldrei búinn. Eina leiðin til að hætta er að stöðva Background RX með símtali til RAIL_Idle().

Ríkisskipti með tveimur bókunum og eintóna vaxandi forgangi

Lokasviðsmyndin er næstum eins og sú fyrri, nema símtalið til RAIL_StartRx() á bókun B er í hærri forgangi en símtalið til RAIL_StartTx() á bókun A.

Í þessu tilviki, þar sem forgangur annars RAIL_StartRx() er hærri en forgangur símtalsins til RAIL_StartTx(), er ekki lengur nauðsynlegt að hringja í RAIL_YieldRadio(). Vegna þess að annar RAIL_StartRx() er í hærri forgangi, rænir hann RAIL_StartTx() atburðinum, tekur stjórn á útvarpinu og fjarlægir TX atburðinn úr ríkinu. Hvenær sem er á RX á bókun B er hægt að kalla RAIL_Idle() til að fara aftur í RX á bókun A, alveg eins og í fyrra dæminuample.

Athugaðu hér að þegar forritið kallar á RAIL_Idle() á RX Protocol B, fer forritið ekki aftur í TX Transition of Protocol A. Þess í stað fer það beint í bakgrunns RX, jafnvel þó að forritið hafi aldrei kallað RAIL_Idle() á Protocol A er TX. Fyrir áætlaðar útvarpsaðgerðir (þ.e. allar útvarpsaðgerðir sem hefjast af API öðru en RAIL_StartRx()), þegar útvarpsatburður hefur verið rændur af atburði með hærri forgang, er hann fjarlægður að öllu leyti og verður ekki snúið aftur til síðar. Aðeins Background móttekur, byrjað af RAIL_StartRx(), er hægt að viðhalda í thackground og 'snúa aftur til' með því að hringja í RAIL_YieldRadio() eða RAIL_Idle().

Til að leggja áherslu á muninn á RAIL_YieldRadio() og RAIL_Idle() er mikilvægt að hafa í huga að fyrir öll þessi td.amples, ekki er hægt að skipta út kallinu í RAIL_YieldRadio() fyrir RAIL_Idle(). RAIL_Idle() hreinsar út alla atburði fyrir tiltekna samskiptareglu - bæði bakgrunninn (það er byrjaður af RAIL_StartRx()) og áætlunargerð (það er byrjað af API öðrum en RAIL_StartRx()) aðgerðum. RAIL_Idle() myndi örugglega enn valda því að forritið hættir úr TX umbreytingarástandinu, en það myndi einnig hreinsa út Background RX, sem veldur því að forritið snýr aftur í aðgerðalaus, ekki RX.

Innleiðing Multiprotocol með Bluetooth

Til að fá upplýsingar um hvernig RAIL/Bluetooth ljós/rofi multiprotocol tdample var innleitt og fyrir frekari upplýsingar um þróun fjölsamskiptaforrita með eigin samskiptareglum á RAIL, sjá AN1134: Dynamic Multiprotocol Development with Bluetooth and Proprietary Protocols on RAIL in GSDK v2.x or AN1269 Dynamic Multiprotocol Development with Bluetooth and Proprietary Protocols on RAIL í GSDK v3.x og hærri.

Bluetooth forgangsröðun

Öfugt við Zigbee með statískt skilgreinda forgangsröðun fyrir mismunandi aðgerðagerðir, notar Bluetooth svið og offset nálgun til að úthluta öllum verkefnum á tiltekið svæði forgangsrófsins.

Í þessu frvampBluetooth forgangssviðið, sem sjálft spannar frá 0 til 255, er varpað á takmarkaðan hluta af sameiginlegu RAIL forgangsrýminu

Ólíkt Zigbee hefur Bluetooth miklu strangari tímasetningarkröfur þar sem vantar tiltekinn rauf getur leitt til þess að tenging lýkur. Bluetooth hefur einnig úrval af mismunandi verkefnum eins og (hugsanlega margar) tengingar, auglýsingar, skönnun og reglubundnar auglýsingar með svörum (PAwR) sendingar og móttökur.

Tafla 6.1. Mismunandi forgangsröðun í Bluetooth

1	Tenging	135 til 0	Tengingarviðburði lýkur
2	Upphaf tengingar	55 til 15	Upphafsgluggi lýkur
3	Auglýsing	175 til 127	Auglýsingaviðburði lýkur
4	Skanni	191 til 143	Skanna glugga lýkur
5	PAwR TX	15 til 5	Auglýsandi: PAwR svar rauf Delay Ends Synchronizer: PAwR svar rauf lýkur
6	PAwR RX	20 til 10	Auglýsandi: PAwR svar rifa lýkur samstillingu: PAwR svar rauf Delay endar

Til að takast á við þetta tekur Bluetooth tímaáætlunarkerfið, þar sem forgangsröðun hans er varpað á RAIL útvarpsáætlunina, með í reikninginn eftirfarandi færibreytur fyrir hvert verkefni:

Upphafstími
Lágmarkstími
Hámarkstími

Forgangur

Ef upphafstíminn er færður minnkar heildarhlaupstíminn í sömu röð, það er að slakinn minnkar. Einnig er hægt að stilla forgangsröðun á kraftmikinn hátt.

Tengingar

Tengingar hafa tiltölulega mikinn forgang. Ekki er hægt að færa upphafstíma tengingar.

Forgangurinn eykst á kraftmikinn hátt af Bluetooth tímaáætlunarbúnaðinum því nær sem tengingin kemst eftirlitstímanum og nær hámarksforgangi nálægt því. TX pakki í TX biðröðinni eykur einnig forgang tengingar.

Upphaf tengingar

Upphaf tengingar skannar auglýsingar frá marktæki til að koma á tengingu. Það hefur meiri forgang miðað við skanni til að leyfa öflugri tengingu.

Auglýsingar

Auglýsingar hafa sjálfgefið lægri forgang og hægt er að færa upphafspunkt þeirra. Upphafstími og hámarkstími eru skilgreindir af auglýsingabilinu.

Ef ekki tókst að senda út auglýsingu eykst forgangur auglýsinga hægt og rólega og er endurstillt þegar auglýsing hefur tekist að senda.

Skanni

Sjálfgefið er að þessi verkefni hafi lægsta forgang. Upphafs-, lágmarks- og hámarkstími er skilgreindur af skönnunarbili og gluggastærð. Skönnun getur haldið áfram jafnvel þótt það sé truflað af verkefni með hærri forgang. Ef þetta gerist safnast skannatíminn upp til að tryggja að viðkomandi skannagluggastærð sé náð á hverju skannabili.

Eins og með auglýsingar er forgangurinn aukinn ef ekki var hægt að uppfylla æskilegt skannabil eða gluggastærð áður. Það er endurstillt aftur í upphaflegan forgang þegar skannabili eða gluggastærð hefur verið náð.

Reglubundnar auglýsingar með svörum (PAwR)

Að senda reglubundnar auglýsingar með svörum hafa sjálfgefið hæsta forgang yfir öll önnur Bluetooth verkefni, fylgt eftir með því að fá svör í PAwR til að viðhalda samstillingu í rafrænu hillumerki (ESL) neti.

Forgangur PAwR verkefna er aukinn ef verkáætlunin mistekst tvisvar í röð. Forgangurinn er annaðhvort aukinn um 1/6 hluta af forgangssviðinu, eða að minnsta kosti um einn þar til hámarksforgangi hefur verið náð. Forgangur verkefna er endurstilltur í lágmarki eftir árangursríka tímasetningu. Sama aðferð á við um bæði PAwR auglýsendur og samstillingu í báðar áttir

ExampLeið af Bluetooth tímaáætlunaraðgerð

Þetta frvampLe sýnir hvernig Bluetooth tímaáætlunin mun skipuleggja þrjú tengingarverkefni og eitt auglýsingaverkefni, sem hvert um sig hefur mismunandi forgangsröðun. Í eftirfarandi myndum gefur grái hlutinn til kynna lágmarks keyrslutíma sem verkefni krefst og blái hlutinn gefur til kynna hámarks keyrslutíma sem verkefnið getur notað og, ef sveigjanlegt, svæðið þar sem hægt er að færa verkefnið. Eftirfarandi mynd sýnir í fyrstu uppsetningu

Eins og sýnt er hér að neðan er Conn1 fyrsta verkefnið sem keyrt er þar sem það skarast ekki við neitt verkefni með hærri forgang.

Adv1 skarast við Conn2 með hærri forgang. Adv1 er sveigjanlegt og er því flutt inn eins og sýnt er á eftirfarandi mynd.

Conn2 skarast við hærra forgangsverkefni Conn4. Þar sem Conn2 er ekki sveigjanlegur mistekst tímasetning Conn2.

Conn4 skarast ekki við önnur verkefni, þess vegna er Conn1 end stilltur til að hætta áður en Conn4 byrjar.

Breyta forgangsröðun

“sl_bt_configuration_t” (v3.x)/”gecko_configuration_t” (v2.x) struct skilgreinir sl_bt_stack_config_t struct, sem inniheldur reitinn „bluetooth.linklayer_priorities“ sem er vísbending um forgangsstillingu. Ef bendillinn er NULL þá notar staflinn sjálfgefna forgangsröðun eins og skráð er í kafla 6.1 Bluetooth forgangsröðun hér að ofan sem og þessum hluta.

Ef bendillinn er ekki núll verður hann að vísa til forgangsstillinga eins og skilgreint er hér að neðan:

Færibreyturnar sandman, Cinemax, adv_min, adv_min, cinnamon, conn_max, intimin og intima skilgreina lágmarks- og hámarksforgangsröðun fyrir skönnun, auglýsingar, tengingar og upphafssetningar í sömu röð. Forgangsröðunin mun færast á milli lágmarks- og hámarksmarka eins og lýst er í kafla 6.1.1 Tengingar við 6.1.4 Skanni hér að ofan.

RAIL kortlagningarfæribreytur, rail_mapping_offset og rail_mapping_range, skilgreina hvernig forgangsröðun Bluetooth hlekkjalags er varpað á alþjóðlega RAIL útvarpsáætlunarforgangsröðun. Kortlagningu þessara gilda má sjá í 6.1 Bluetooth forgangsröðun. Sjálfgefið fyrir bæði rail_mapping_offset og rail_mapping_range er 16.

Adv_step og scan step færibreyturnar skilgreina skrefastærðina þegar forgangi skönnunar og auglýsinga er breytt á kraftmikinn hátt. Að lokum skilgreina færibreyturnar pawr_tx_min, pawr_tx_min, pawr_tx_min og pawr_rx_max forgangssvið fyrir Par auglýsanda og TX og RX atburði í samstillingu í hverjum undirviðburði.

IoT safn
www.silabs.com/products

Gæði
www.silabs.com/quality

Stuðningur og samfélag
www.silabs.com/community

Fyrirvari

Silicon Labs ætlar að veita viðskiptavinum nýjustu, nákvæma og ítarlega skjölin um öll jaðartæki og einingar sem eru tiltækar fyrir kerfis- og hugbúnaðarframleiðendur sem nota eða ætla að nota Silicon Labs vörurnar. Einkennisgögn, tiltækar einingar og jaðartæki, minnisstærðir og minnisföng vísa til hvers og eins
tiltekið tæki og „Dæmigert“ færibreytur geta verið mismunandi eftir mismunandi forritum og geta verið mismunandi. Umsókn tdampLesið sem lýst er hér er eingöngu til lýsingar. Silicon Labs áskilur sér rétt til að gera breytingar án frekari fyrirvara á vöruupplýsingum, forskriftum og lýsingum hér, og gefur enga ábyrgð á nákvæmni eða heilleika meðfylgjandi upplýsinga. Án fyrirvara getur Silicon Labs uppfært fastbúnað vörunnar meðan á framleiðsluferlinu stendur af öryggis- eða áreiðanleikaástæðum. Slíkar breytingar munu ekki breyta forskriftum eða frammistöðu vörunnar. Silicon Labs ber enga ábyrgð á afleiðingum notkunar upplýsinganna sem gefnar eru upp í þessu skjali. Þetta skjal felur ekki í sér eða gefur beinlínis leyfi til að hanna eða búa til samþættar rafrásir. Vörurnar eru ekki hannaðar eða heimilaðar til notkunar í neinum FDA Class III tækjum, forritum þar sem FDA formarkaðssamþykki er krafist eða lífsstuðningskerfum án sérstaks skriflegs samþykkis Silicon Labs. „Lífsstuðningskerfi“ er hvers kyns vara eða kerfi sem ætlað er að styðja við eða viðhalda lífi og/eða heilsu, sem, ef það mistekst, má með sanngirni búast við að muni leiða til verulegs líkamstjóns eða dauða. Silicon Labs vörur eru ekki hannaðar eða heimilaðar fyrir hernaðarlega notkun. Silicon Labs vörur skulu undir engum kringumstæðum notuð í gereyðingarvopnum, þar með talið (en ekki takmarkað við) kjarnorku-, sýkla- eða efnavopn, eða eldflaugar sem geta flutt slík vopn. Silicon Labs afsalar sér allri óbeinum og óbeinum ábyrgðum og ber ekki ábyrgð á meiðslum eða skemmdum sem tengjast notkun Silicon Labs vöru í slíkum óviðkomandi forritum. Athugið: Þetta efni gæti innihaldið móðgandi hugtök sem eru nú úrelt. Silicon Labs er að skipta þessum skilmálum út fyrir innifalið tungumál þar sem það er mögulegt. Fyrir frekari upplýsingar, farðu á www.silabs.com/about-us/inclusive-lexicon-project

Upplýsingar um vörumerki
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® og Silicon Labs logo®, Blueridge®, Blueridge Logo®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro lógó og samsetningar þeirra , „orkuvænustu örstýringar í heimi“, Repine Signals®, Disconnect , n-Link, Thread Arch®, Elin®, EZRadioPRO®, EZRadioPRO®, Gecko®, Gecko OS, Gecko OS Studio, Precision32®, Simplicity Studio® , Telegenic, Telegenic Logo®, Suppress®, Sentry, Sentry lógóið og Zentri DMS, Z-Wave® og fleiri eru vörumerki eða skráð vörumerki Silicon Labs. ARM, CORTEX, Cortex-M3 og THUMB eru vörumerki eða skráð vörumerki ARM Holdings. Keli er skráð vörumerki ARM Limited. Wi-Fi er skráð vörumerki Wi-Fi Alliance. Allar aðrar vörur eða vörumerki sem nefnd eru hér eru vörumerki í viðkomandi eign