Mwongozo wa Mtumiaji wa SILICON LABS UG305 Dynamic Multiprotocol

Mwongozo wa Mtumiaji wa SILICON LABS UG305 Dynamic Multiprotocol

Yaliyomo kujificha

Utangulizi

Hati hii inaeleza jinsi programu ya Silicon Labs imeundwa kutumiwa na itifaki nyingi kwenye chipu moja isiyotumia waya. Itifaki nyingi zinazobadilika hukata redio na kubadilisha usanidi kwa haraka ili kuwezesha itifaki mbalimbali zisizotumia waya kufanya kazi kwa kutegemewa kwa wakati mmoja.

Kumbuka: Maelezo mahususi ya Zigbee katika hati hii yanatumika kwa toleo la 6.10.x na la chini zaidi.
Maelezo kuhusu utekelezaji mahususi wa itifaki nyingi unaobadilika yametolewa katika maelezo yafuatayo ya programu:
AN1133: Ukuzaji wa Itifaki nyingi za Nguvu kwa Bluetooth na Zigbee EmberZNet SDK 6.x na Chini
AN1134: Ukuzaji wa Itifaki nyingi za Nguvu kwa Bluetooth na Itifaki za Umiliki kwenye RAIL katika GSDK v2.x
AN1269: Ukuzaji wa Itifaki nyingi Inayobadilika kwa kutumia Bluetooth® na Itifaki za Umiliki kwenye RAIL katika GSDK v3.x na Juu
AN1209: Ukuzaji wa Itifaki nyingi za Nguvu na Bluetooth na Unganisha
AN1265: Ukuzaji wa Itifaki nyingi za Nguvu kwa kutumia Bluetooth® na OpenThread katika GSDK v3.x

Istilahi

Ifuatayo inaorodhesha baadhi ya istilahi mahususi kwa utekelezaji thabiti wa itifaki nyingi

Tabaka la Kiolesura cha Kuondoa Redio (RAIL): API ya kawaida ambayo kwayo msimbo wa kiwango cha juu hupata ufikiaji wa redio ya EFR32.

Uendeshaji wa Redio: Hatua mahususi itakayoratibiwa. Uendeshaji wa redio una usanidi wa redio na kipaumbele. Kila mrundikano unaweza kuomba kwamba kipanga ratiba cha redio kifanye hadi shughuli mbili za redio (kupokea usuli na ama Kupokea Kwa Ratiba au Kumeratibiwa

Usuli Pokea: Upokezi unaoendelea, unaokusudiwa kukatizwa na shughuli Zilizoratibiwa, na kurejeshwa baada ya kukamilika kwake.

Iliyoratibiwa Kupokea: Pokea pakiti au ukokotoe RSSI kwa wakati na muda maalum. (Watengenezaji wanaofanya kazi kwenye RAIL, kumbuka kuwa kulingana na RAIL API, "Mapokezi Yaliyoratibiwa" kama yalivyotumiwa katika hati hii inarejelea utendakazi wowote wa upokezi, isipokuwa RAIL_StartRx, na haizuiliwi tu katika upeo wa RAIL_ScheduleRx.)
Transmi iliyopangwat: Usambazaji wowote kati ya anuwai ya usambazaji ikijumuisha upitishaji wa papo hapo, usambazaji ulioratibiwa (wa siku zijazo), au usambazaji tegemezi wa CCA. (Watengenezaji wanaofanya kazi kwenye RAIL, kumbuka kuwa kulingana na RAIL API, "Usambazaji Ulioratibiwa" kama inavyotumika katika hati hii inarejelea utumaji wowote wa utumaji, na hauzuiliwi katika upeo wa RAIL_StartScheduledTx.

Radio Config: Hubainisha hali ya maunzi ambayo lazima yatumike kutekeleza utendakazi wa redio.

Mratibu wa Redio: Sehemu ya RAIL ambayo hupatanisha kati ya itifaki tofauti ili kubainisha ni ipi itaweza kufikia redio.

Kipaumbele: Kila operesheni kutoka kwa kila rafu ina kipaumbele chaguomsingi. Programu inaweza kubadilisha vipaumbele chaguomsingi.

Muda wa Kuteleza: Muda wa juu zaidi katika siku zijazo wakati operesheni inaweza kuanza ikiwa haiwezi kuanza wakati ulioombwa wa kuanza.

Mazao: Rafu lazima itoe mavuno kwa hiari mwishoni mwa operesheni au mfuatano wa shughuli, isipokuwa ikiwa inatekeleza upokeaji wa usuli. Hadi rafu itokee, kipanga ratiba hakitaratibu majukumu yaliyopewa kipaumbele

RTOS (Mfumo wa Uendeshaji wa Wakati Halisi) Kernel: Sehemu ya mfumo wa uendeshaji ambayo inawajibika kwa usimamizi wa kazi, na mawasiliano kati ya kazi na usawazishaji. Utekelezaji huu hutumia kernel ya Micrium OS-5.

Usanifu

Dynamic Multiprotocol hutumia maunzi ya EFR32 na programu ya RAIL kama vizuizi vyake vya ujenzi. Zigbee, Bluetooth, na/au itifaki zozote za msingi au wamiliki zinaweza kujengwa juu ya tabaka zisizo na masharti, kwa kutumia Micrium kudhibiti utekelezaji wa nambari kati ya itifaki tofauti. Mchoro ufuatao unaonyesha muundo wa jumla wa moduli za programu.

Kuanzia na toleo la 2.0, RAIL inahitaji upitishaji wa mpini wa usanidi wa redio kwa simu za RAIL API. Mipangilio hii inafafanua vigezo mbalimbali vya PHY vinavyotumiwa na rafu

Micrium OS ni RTOS ambayo inaruhusu rafu na mantiki ya programu kushiriki wakati wa utekelezaji wa CPU.

Kipanga ratiba cha Redio ni maktaba ya programu ambayo hujibu kwa akili maombi ya rafu kutekeleza shughuli za redio ili kuongeza kutegemewa na kupunguza muda wa kusubiri. API zinazotolewa na RAIL ambazo hazishiriki redio kukwepa kipanga ratiba cha Redio.

Msingi wa RAIL husanidi maunzi ya EFR32 kwa kujibu maagizo kutoka kwa kipanga ratiba cha redio.

Picha ya Firmware Moja

Dynamic Multiprotocol huruhusu msanidi programu kutengeneza jozi moja ya monolithic ambayo imepakiwa kwenye EFR32. Masasisho ya programu hufanywa kwa kuboresha mfumo wote wa binary. Hii inakamilishwa kwa kutumia kifaa cha kupakia kifaa cha Geck, maelezo ambayo yanaweza kupatikana katika UG266: Mwongozo wa Mtumiaji wa Gecko Bootloader ya Silicon Labs kwa GSDK 3.2 na Chini na UG489: Mwongozo wa Mtumiaji wa Silicon LabsGecko Bootloader kwa GSDK 4.0 na Juu.

Operesheni ya Stack ya Kujitegemea

Rafu za Silicon Labs bado zinafanya kazi bila ya nyingine katika hali ya Itifaki nyingi ya Nguvu. Uendeshaji fulani wa redio wa muda mrefu utakuwa na athari kwenye muda wa kusubiri wa itifaki nyingine na utendakazi unaotii. Ni juu ya maombi kuamua mazingatio yoyote maalum kwa hafla hizi. Tazama sehemu ya 2. Mratibu wa Redio kwa habari zaidi.

Mratibu wa Redio

Ratiba ya Redio ni sehemu ya RAIL (Tabaka la Kiolesura cha Kuondoa Redio). RAIL hutoa safu angavu, inayoweza kubinafsishwa kwa urahisi na API, ambayo inaauni itifaki zisizo na waya zinazomilikiwa au kulingana na viwango. Kiratibu cha Redio kimeundwa ili kuruhusu utendakazi wa redio ambao unaweza kuratibiwa na kupewa kipaumbele. Uendeshaji tofauti wa redio katika kila itifaki inaweza kuwa muhimu zaidi au chini, au nyeti zaidi ya wakati au kidogo, kulingana na hali. Mpangaji ratiba anaweza kuzingatia hayo wakati wa kufanya maamuzi kuhusu migogoro na jinsi ya kuisuluhisha

Isipokuwa unatengeneza programu kwa kutumia itifaki maalum kwenye RAIL, utendakazi mwingi wa kipanga ratiba cha redio hushughulikiwa kiotomatiki kwa msururu wa msingi na msimbo wa RAIL. Unahitaji tu kutumia stack kupitia API yake ya kawaida.

Kwa kiwango cha juu, stack hutuma operesheni ya redio (kwa mfanoample Mapokezi Yaliyoratibiwa au Usambazaji Ulioratibiwa). Shughuli za redio ni
zimewekwa kwenye foleni na kisha kuhudumiwa wakati ujao kulingana na vigezo vyao. Wakati wa kuanza utendakazi wa redio ukifika kipanga ratiba hukagua ikiwa tukio shindani lipo au la na kama operesheni inaweza kucheleweshwa au la. Ikiwa kipanga ratiba hakiwezi kuendesha tukio, kinarudisha matokeo kwenye safu ya juu, ambayo inaweza kujaribu tena na vigezo vipya.

Mara tu operesheni ya redio imeanza, safu inayolingana inaweza kutuma shughuli za ziada za kipanga ratiba kulingana na matokeo ya operesheni ya awali (kwa mfano.ampnasubiri ACK). Mwishoni mwa kila oparesheni au mfuatano wa utendakazi lazima stack itoe matumizi ya redio.

Uendeshaji wa Redio

Kila tukio katika kiratibu limegawanywa katika vipengele vinavyoitwa Uendeshaji wa Redio, ambavyo vinahusishwa na usanidi wa redio na kipaumbele.

Kila operesheni ina kipaumbele na inakatizwa ikiwa kipanga ratiba kinapokea utendakazi wa kipaumbele cha juu unaopishana kwa wakati. Operesheni za redio zilizopewa kipaumbele cha chini ambazo haziwezi kuendeshwa kulingana na vigezo vya ratiba zitashindwa, na ni juu ya mrundikano husika kuzijaribu tena. Punde tu kipanga ratiba kinapotekeleza utendakazi wa redio kutoka kwa rafu, rundo hilo linaweza kuendelea kutuma utendakazi wa ziada wa redio hadi litoe kwa hiari, au hadi kipanga ratiba kipokee utendakazi wa redio uliopewa kipaumbele zaidi na kuutangulia.

Usuli Pokea
Iliyoratibiwa Kupokea
Usambazaji Uliopangwa

Kila rafu inaweza kuuliza Kiratibu cha Redio kutekeleza hadi utendakazi mbili za redio (kupokea kwa usuli na ama Kupokea Kwa Ratiba au Usambazaji Ulioratibiwa) kwa wakati mmoja:

Kila operesheni ina vigezo vifuatavyo:

Wakati wa Kuanza	Dalili ni wakati gani katika siku zijazo operesheni hii ya redio itaendeshwa. Hii inaweza "kuendeshwa sasa hivi" au thamani fulani katika sekunde ndogo katika siku zijazo.
Kipaumbele	Nambari inayoonyesha kipaumbele cha jamaa cha operesheni. Wakati wa kutumia mipangilio chaguo-msingi, utendakazi wa redio ya Bluetooth LE ni karibu kila mara kipaumbele cha juu kuliko shughuli za Zigbee.
Muda wa Kuteleza	Muda ambao tukio linaweza kucheleweshwa zaidi ya wakati wake wa kuanza na bado likubalike kwenye rafu. Hii inaweza kuwa 0, katika hali ambayo tukio haliwezi kuteleza.
Muda wa Muamala	Muda unaokadiriwa kwamba inachukua kukamilisha muamala. Matukio ya kusambaza kwa kawaida huwa na muda uliofafanuliwa vyema zaidi wa muamala, ilhali matukio ya kupokea mara nyingi hayajulikani. Hii inatumika kusaidia kipanga ratiba cha redio kubaini kama tukio linaweza kuendeshwa.

Rafu inafafanua vigezo hivi mbalimbali vinavyofaa kwa operesheni inayotekelezwa. Kwa mfanoampna, matukio ya muunganisho wa Bluetooth yamepangwa katika siku zijazo na hayana hati inayoruhusiwa, ilhali matukio ya utumaji wa Zigbee mara nyingi yanaweza kucheleweshwa kwa kiasi kidogo na kuweka nyota baadaye.

Kwa mtazamo wa Kiratibu cha Redio ya RAIL, Usambazaji Ulioratibiwa na Upokeaji Ulioratibiwa ni sawa. Zote ni shughuli zinazohitaji matumizi ya redio, na kwa hivyo haziwezi kutekelezwa kwa wakati mmoja. Upendeleo unaonekana tu kwenye safu ya RAIL API, ambapo API ya TX au RX inaitwa.

Usuli Pokea

Hii ni hali ya kupokea inayoendelea ambayo inakusudiwa kukatizwa na shughuli zingine, na kurejeshwa baada ya kukamilika kwake. Ikiwa Upokeaji wa Mandharinyuma ni kipaumbele cha juu kuliko shughuli zingine, shughuli hizo za redio hazitasimamiwa na hazitaendeshwa. Ni juu ya rafu au programu kubadilisha kipaumbele au mavuno kwa hiari. Tazama sehemu ya 5.1 Kutamples yenye Mandharinyuma Pokea, Redio ya Mazao na Mpito wa Jimbo kwa mfanoampmaelezo ya jinsi upokeaji wa Mandharinyuma huingiliana na shughuli Zilizoratibiwa.

tumeled Pokea

Hii ni pokezi katika wakati ujao na muda uliobainishwa. Kipanga ratiba cha redio kitazingatia muda wa kubadili redio katika kuamua kama operesheni itaratibiwa au la. Ikiwa haiwezi kuratibiwa basi kipanga ratiba hutuma tukio la kutofaulu kwa rafu ya kupiga simu. Uendeshaji wa redio hupanuliwa kiotomatiki hadi rafu itoe mavuno kwa hiari, au kipanga ratiba kipokee utendakazi wa kipaumbele cha juu na kuukatiza. Kupanua upokeaji huruhusu rafu kuendelea na utendakazi wa redio kulingana na mahitaji ya itifaki ya kiwango cha juu, kwa mfanoample uwasilishaji wa jibu kulingana na data iliyopokelewa.

Usambazaji Uliopangwa

Hiki ni kisambazaji katika wakati ujao chenye muda wa chini zaidi. Muda huu wa chini unaweza kujumuisha matukio ya ufuatiliaji yanayotarajiwa, kwa mfanoampna ACK kwa upitishaji wa IEEE 802.15.4. Hata hivyo, muda wa chini zaidi wa operesheni hii si lazima ujumuishe matukio yasiyotarajiwa ambayo yanaweza kuongeza muda zaidi ya muda wa chini zaidi, kwa ex.ampupungufu kutokana na kushindwa kwa CCA katika IEEE 802.15.4. Kipanga ratiba cha redio huzingatia muda wa kubadili redio katika kuamua kama operesheni itaratibiwa au la. Ikiwa haiwezi kuratibiwa basi kipanga ratiba hutuma tukio la kutofaulu kwa rafu ya kupiga simu.

Usanidi wa Redio

Kila operesheni ya redio inahusishwa na usanidi wa redio uliotanguliwa ambao huamua hali ya vifaa ambavyo lazima vitumike kufanya operesheni. Redio Configs hufuatilia hali ya sasa ya rafu ili utendakazi wa redio wa siku zijazo utumie vigezo sawa vya redio. Mipangilio ya Redio inaweza kuwa hai au tulivu. Ikiwa rafu itabadilisha Usanidi unaotumika wa Redio basi RAIL hufanya mabadiliko ya haraka kwenye usanidi wa maunzi pia, kwa mfano.ampna kubadilisha chaneli. Ikiwa usanidi wa redio haufanyiki kwa sasa basi utendakazi unaofuata ulioratibiwa wa redio utatumia usanidi mpya wa redio.

Kipaumbele

Kila operesheni ya redio ina kipaumbele ambacho huonyesha kwa kipanga ratiba ni operesheni gani inapaswa kutekelezwa ikiwa kuna mwingiliano wa muda kati ya shughuli nyingi. Kipanga ratiba huchukulia kipaumbele cha 0 kama kipaumbele cha juu zaidi na 255 kama kipaumbele cha chini zaidi. Kipanga ratiba cha redio kitaruhusu kazi kwa kipaumbele cha juu zaidi kufikia ra rdware halisi. Udhibiti wa majukumu mengi hurejeshwa kwa kipanga ratiba cha redio tu baada ya kukamilika, lakini kazi kama vile upokeaji wa chinichini zitakatizwa ikiwa kazi yenye kipaumbele cha juu itatumika.

Rafu kila moja ina seti chaguomsingi ya vipaumbele kulingana na uchanganuzi wa Silicon Labs wa jinsi bora ya kushirikiana ili kuongeza mzunguko wa wajibu na kuepuka miunganisho iliyopungua kwa kesi ya matumizi ya jumla. Kesi maalum za utumiaji zinaweza kuwa na mahitaji tofauti. Vipaumbele ni kama ifuatavyo, kutoka juu hadi chini

Usambazaji Ulioratibiwa wa Bluetooth LE
Bluetooth LE Imeratibiwa Kupokea

Usambazaji Ulioratibiwa wa itifaki
Itifaki Nyingine Mandharinyuma Pokea

Vipaumbele hivi vinaweza kubatilishwa au kubadilishwa na programu. Ni juu ya maombi kuamua chini ya hali gani ya kuzibadilisha. Sehemu ya 4.2 802.15.4 Kipaumbele cha RAIL na sehemu ya 6.1 Vipaumbele vya Bluetooth vina maelezo zaidi kuhusu vipaumbele vya matukio yao mahususi.

Muda wa Kuteleza

Kila utendakazi wa redio lazima uwe na "muda wa kuteleza", au muda wa juu zaidi wa kuanza, kumaanisha wakati wa mbali zaidi katika siku zijazo wakati operesheni inaweza kuanza ikiwa haiwezi kuanza wakati ulioombwa wa kuanza. Hili huruhusu kipanga ratiba kufanyia kazi matukio ya kipaumbele cha juu zaidi yanayotokea kwa wakati mmoja, au matukio ya kipaumbele cha juu ambayo yanazidi muda unaotarajiwa. Itifaki kwa ujumla huelekeza muda wa kuteleza unaweza kuwa nini, lakini kipanga ratiba cha redio kinaweza kushughulikia hili kwa kila operesheni, kuruhusu mrundikano kuteleza baadhi ya matukio lakini si mengine. Kwa ujumla, IEEE02.15.4 ina muda mrefu zaidi wa kuteleza na Bluetooth LE ina muda mdogo wa kuteleza.

Mazao

Mara tu mfuatano wa utendakazi wa redio unapotekelezwa, rundo hilo linaweza kuendelea kuongeza shughuli zinazopanua utendakazi wa awali hadi mkusanyiko usiwe na la kufanya kwa ubadilishanaji mahususi wa ujumbe. Rafu lazima itoe mavuno kwa hiari isipokuwa inatekeleza upokeaji wa usuli. Ikiwa mrundikano hautokei basi itaendelea kupanua utendakazi wake wa redio, na utendakazi wa redio uliopewa kipaumbele cha chini utasababisha kutofaulu kurudi kwenye safu inayolingana iliyoomba utendakazi wa redio. Uendeshaji wa kipaumbele cha juu hauwezi kukatiza utendakazi wa redio unaoendeshwa kwa sasa, na wa kipaumbele cha chini ambao haujazaa matunda. Tazama sehemu ya 5.1 Kutamples yenye Mandharinyuma Pokea, Redio ya Mazao na Mpito wa Jimbo kwa mfanoampkidogo ya hali ambapo kutoa redio kwa uwazi ni muhimu.

Kukatiza Uendeshaji wa Redio

Uendeshaji wa redio ulioratibiwa unaweza kukatizwa ikiwa operesheni ya kipaumbele cha juu itakinzana nayo. Hii inaweza kutokea katika hali mbili zifuatazo:

Uendeshaji wa redio ulioratibiwa huchukua muda mrefu kuliko inavyotarajiwa na mrundikano unaolingana hautoi utendakazi wa redio uliopewa kipaumbele lazima uanze.
Operesheni ya redio yenye kipaumbele cha juu zaidi imeratibiwa kutokea katika siku zijazo na migongano na operesheni ya kipaumbele cha chini ambayo tayari imeratibiwa.

Uendeshaji wa Redio wa Muda Mrefu

Uendeshaji fulani wa Redio wa muda mrefu unaweza kuwa na athari kubwa kwa utendakazi sahihi wa bidhaa. Huenda programu ikahitaji kuratibu shughuli hizi kati ya itifaki. Ikiwa programu haifanyi kazi basi vipaumbele vya kipanga ratiba vitatanguliwa. Kwa mfanoample, uchanganuzi wa nishati wa IEEE 802.15.4 unaweza kuhitaji redio ibakie ili kukusanya usomaji wa nishati ya kutosha. Ikiwa programu haitaratibu utendakazi ipasavyo, utafutaji unaweza kukatizwa mapema kutokana na utendakazi wa Bluetooth uliopewa kipaumbele zaidi.

Mratibu wa Redio Exampchini

All zamaniamptunatumia Bluetooth LE na Zigbee, lakini kanuni zinatumika kwa michanganyiko mingine ya Bluetooth/802.15.4.

Kipanga ratiba huanza kwa kuwa na shughuli ya upokeaji wa chinichini ya Zigbee. Hii inawakilisha kipanga njia kinachowashwa kila mara ambacho kinaweza kuhitaji kupokea pakiti za IEEE 802.15.4 kwa nyakati zisizojulikana. Muunganisho wa Bluetooth LE pia unatumika na unahitaji rafu kuwa tayari kupokea kila 30 ms. Rafu ya Bluetooth LE inaweza kuratibu hii mapema kwa sababu ya hali ya kubadilika ya muunganisho.

Upangaji Kipaumbele

Hii inatoa ex ya msingiample ya kuamua vipaumbele vya shughuli mbalimbali za redio.

Rafu ya Zigbee itaamua kwamba inahitaji kutuma pakiti. Huenda ikafanya hivi kama tukio linapohitajika, kumaanisha kwamba rafu itaamua kuwa inataka kutuma pakiti sasa bila kumfahamisha kipanga ratiba mapema. Hii ni tofauti na jinsi Bluetooth LE inavyofanya kazi, ambapo shughuli zilizoratibiwa zinajulikana mapema sana. Kipanga ratiba kinatathmini kuwa inawezekana kutekeleza utendakazi wa redio ya Zigbee TX 1 na bado kuhudumia tukio la upokeaji wa Bluetooth LE lililopewa kipaumbele katika siku zijazo. Kwa hivyo kipanga ratiba huruhusu tukio la kusambaza kutokea. Mkusanyiko wa Zigbee hufanya vipande vyote vya operesheni hii ya kusambaza (kusubiri ack ya MAC), na kisha hutoa mavuno kwa hiari. Makadirio ya muda wa muamala wa operesheni ya redio ya Zigbee HAIJUMUI majaribio tena.

Katika hii example, Bluetooth LE tayari imeratibiwa kupokea katika siku zijazo na rafu ya Zigbee inataka kusambaza. Kwa operesheni ya kwanza ya redio ya Zigbee TX 1 kuna muda wa kutosha kabla ya utendakazi wa redio ya Bluetooth LE RX 1 ili kipanga ratiba kiruhusu mrundikano kufanya operesheni. Baadaye, mrundikano wa Zigbee unapojaribu kuratibu Zigbee TX 2 kipanga ratiba hubaini kuwa hakuna muda wa kutosha kabla ya tukio la kipaumbele cha Bluetooth LE RX 2. Hata hivyo, rundo la Zigbee limedokeza kuwa huenda hatua hii ikapita wakati wake wa kuanza. Kipanga ratiba cha redio huamua kwamba kutokana na muda unaotarajiwa wa utendakazi wa redio ya Bluetooth LE, operesheni ya Zigbee inaweza kuanza baada ya tukio hilo na bado iwe ndani ya muda wa kuteleza ulioonyeshwa na mrundikano wa Zigbee.

Iwapo yote yatafanyika kama inavyotarajiwa, operesheni ya usambazaji wa Zigbee itakuwa na jaribio lake la kwanza kutokea bila hitilafu yoyote kutokana na kuratibiwa.

Kukatizwa kwa Kipaumbele Example

Ex huyuample huonyesha operesheni ya kipaumbele cha juu ikikatiza iliyopewa kipaumbele cha chini.

Ex huyuample huanza kwa njia sawa na ile ya zamaniample. Zigbee na Bluetooth LE zote zina utendakazi wa redio ambao umeratibiwa bila mgongano wowote

Baadaye, mrundikano wa Zigbee unaamua kuwa unataka kutuma pakiti nyingine kwa ajili ya tukio la Zigbee TX 2. Kiratibu huamua kuwa inafaa kuratibu tukio hili na kuhudumia tukio la Bluetooth LE RX 2 baadaye, kulingana na muda wa kawaida ambao tukio la Zigbee TX 2 lazima lichukue. Walakini, tukio la Zigbee TX 2 huchukua muda mrefu kuliko ilivyotarajiwa kwa sababu ya kurudi nyuma kwa muda mrefu na haitoi matunda kwa wakati. Hii husababisha tukio kugongana na msururu wa rad uliopewa kipaumbele zaidi, na kwa hivyo Mratibu wa Redio hukatiza tukio la Zigbee na kurudisha kutofaulu kwa safu ya kiwango cha juu. Tukio la Bluetooth LE hutokea kawaida na linapokamilika hujitolea kwa shughuli zozote za kipaumbele cha chini.

Baada ya kupokea hitilafu kutoka kwa kipanga ratiba cha redio, rundo la Zigbee hujaribu kujaribu tena ujumbe wa MAC. Inapanga operesheni na inajumuisha wakati wa kuteleza. Kwa wakati huu rafu ya Bluetooth LE ina kipaumbele juu ya redio na kwa hivyo operesheni haiwezi kuanza, lakini kipanga ratiba kinakubali utendakazi mpya wa redio. Rafu ya Bluetooth LE hukamilisha upokeaji wake ulioratibiwa na kutoa redio. Kipanga ratiba kisha huanzisha operesheni ya usambazaji wa Zigbee kutokea kwa sababu bado iko ndani ya muda wa kuteleza wa operesheni ya mwanzo ya kuanza. Baada ya utumaji kukamilika, kipanga ratiba kinarudi kwenye usuli wa uendeshaji wa upokeaji.

Operesheni ya Kipaumbele cha Juu ambayo Imepanuliwa

Ex huyuample huonyesha kinachotokea wakati utendakazi wa kipaumbele cha juu unachukua muda mrefu kuliko ilivyotarajiwa na kusababisha utendakazi wa kipaumbele cha chini kukosa fursa yake.

Katika hali hii, Bluetooth LE ina upokezi Ulioratibiwa ambao unafanyika kwa sasa. Zigbee anaamua kutuma pakiti lakini haiwezi kuendeshwa kwa sasa. Kipanga ratiba kinakubali utendakazi kwa kudhania kuwa tukio la Bluetooth LE litakamilika kabla ya mwisho wa muda wa kuteleza wa tukio la Zigbee. Hata hivyo, tukio la Bluetooth LE linaongeza muda mrefu kutokana na ukweli kwamba pakiti za ziada zinatumwa kati ya vifaa. Operesheni ya Bluetooth LE ina kipaumbele kwa hivyo operesheni ya Zigbee inaisha. Hitilafu imerejeshwa kwenye rafu. Zigbee anaamua kusambaza tena pakiti. Tena, rundo la Zigbee linaonyesha operesheni inapaswa kuanza sasa lakini inaweza kuteleza katika siku zijazo. Kipanga ratiba kiko katikati ya kubadilisha usanidi wa redio kwa hivyo haiwezi kuanza operesheni mara moja. Badala yake, inateleza wakati wa kuanza kwa redio kwa kiasi kidogo na kisha kutekeleza operesheni.

Uendeshaji Kipaumbele cha Juu Bila Kukatizwa

Katika hii exampna kipanga ratiba cha redio kinafanya kazi kwenye nodi inayofanya kazi kama pembeni ya Bluetooth LE na nodi hiyo ina miunganisho kadhaa kwa vifaa tofauti vya kati. Pia ina taa ya mara kwa mara ya utangazaji ambayo hupitishwa. Kielelezo kifuatacho kinaonyesha kisa ambapo matukio haya yanatokea kwa karibu na hairuhusu muda wa kutosha kurudi kwenye usanidi wa redio ya Zigbee. Kwa hivyo itaunda kipindi ambapo safu ya Zigbee iko
haiwezi kusambaza hata kwa wakati wa kuteleza.

Zigbee anauliza mpanga ratiba kupanga utendakazi wa kusambaza redio. Ingawa mratibu anajua kuwa tukio litashindwa kwa sababu ya utendakazi wa kipaumbele cha juu ulioratibiwa, bado inakubali tukio lililoratibiwa. Hii inafanywa kwa sababu mbili. Kwanza, hali zinaweza kubadilika na tukio linaweza kutekelezwa. Pili, rundo lililokaa juu ya kipanga ratiba cha redio linaweza kujaribu kujaribu tena kitendo. Ikiwa matokeo ya upangaji ulioshindwa yangerejeshwa mara moja basi jaribio la mrundikano wa kujaribu tena halitawezekana kufaulu kwa kuwa hakuna muda umepita. Badala yake, kwa kupanga tukio kwenye foleni na kurudisha kushindwa baada ya muda wa kuteleza kuisha, kujaribu tena (pamoja na wakati wake wa kuteleza) kuna nafasi nzuri ya kufaulu kwani seti ya oparesheni zijazo za redio zitakuwa tofauti.

Pokea Wakati Operesheni ya Kipaumbele Zaidi Inapoendeshwa

Ex huyuample huonyesha kile kinachotokea wakati Bluetooth LE inatumika na operesheni ya kipaumbele cha chini itakuwa inapokea data.

Katika hali ya kwanza, wakati ujumbe wa IEEE 802.15.4 unatumwa na rafu ya Bluetooth LE ikitumia redio kupokea amilifu, rundo la Zigbee halitakuwa mtandaoni ili kupokea ujumbe. Hata hivyo, mtumaji wa Zigbee wa ujumbe atajaribu tena katika hali nyingi na kwa kurudi nyuma na mabadiliko mengine ya wakati hayatakinzana na kipaumbele kingine cha juu kilichoratibiwa kupokea matukio ambayo hayawezi kugongana. Ujumbe wa Zigbee umepokelewa

Kesi ya pili inaonyesha kwamba, katika kesi ya kupokea amilifu, rundo la Zigbee bado linaweza kukatizwa na lisipokee (au ACK) ujumbe. Mawasiliano yenye mafanikio yanategemea majaribio tena kwenye MAC au safu ya juu zaidi kutuma ujumbe huu tena na kuthibitisha kuwa kifaa cha Dynamic Multiprotocol kinapokea ujumbe.

Ingawa kunaweza kuwa na mambo ya kuzingatia iwapo upokeaji amilifu unapaswa kukatizwa au la, ni vigumu kwa mratibu kufanya uamuzi huo. Kwa ujumla uimara wa itifaki unapaswa kuruhusu ujumbe kupokelewa kwa mafanikio hata kwa kukatizwa

Utekelezaji wa Itifaki nyingi na Rafu yenye Msingi wa 802.15.4

Sura hii inatoa maelezo ya jumla kuhusu utekelezaji wa rafu ya 802.15.4 kama vile Zigbee au Unganisha kama sehemu ya programu nyingi za protocol. Kwa maelezo ya jinsi ya kusanidi plugins na maelezo mengine mahususi kwa itifaki maalum, angalia mojawapo ya maelezo yafuatayo ya programu:

AN1133: Ukuzaji wa Itifaki nyingi za Nguvu kwa Bluetooth na Zigbee EmberZNet SDK 6.x na Chini

AN1209: Ukuzaji wa Itifaki nyingi za Nguvu na Bluetooth na Unganisha

Usaidizi wa Itifaki ya Waya

Itifaki tofauti zisizo na waya zina sifa tofauti ambazo zimesaidiwa na muundo wa Dynamic Multiprotocol. Kwa mfanoample, Bluetooth Low Energy ni kali sana na inatabirika katika ratiba yake ya utendakazi wa redio; matangazo na vipindi vya uunganisho hutokea kwa nyakati zilizowekwa. Kinyume chake, itifaki ya 802.15.4 inaweza kunyumbulika zaidi katika muda wa matukio mengi ya ujumbe; CSMA (mtoa huduma anahisi ufikiaji mwingi) katika IEEE 802.15.4 huongeza kurudi nyuma nasibu ili ucheleweshaji wa tukio uwe kwa mpangilio wa milisekunde. Hii inaruhusu ujumbe wa IEEE 802.15.4 kutumwa karibu na matukio ya Bluetooth Low Energy na bado upokewe kwa njia ya kuaminika.

802.15.4 RELI Kipaumbele

802.15.4 itifaki kwa sasa zina vipaumbele vitatu vya RAIL.

Hapana.	Jina	Mpangilio Chaguomsingi	Toka kwa Kigezo
1	TX inayotumika	100	MAC ACK imepokea (au la)
2	RX inayotumika	255	Pakiti imechujwa au MAC ACK imetumwa
3	Asili ya RX	255	Jukumu lililo na Kipaumbele cha juu zaidi

Iwapo Active TX itatekelezwa redio itatolewa wakati uthibitisho unaolingana wa MAC ulipopokelewa (au kuisha kwa muda kulitokea).

Usuli RX itaacha redio katika hali ya kupokea tayari kupokea ujumbe usiolingana. Ikiwa kipaumbele amilifu cha RX ni tofauti na kipaumbele cha usuli wa RX, kipaumbele cha upokezi kitainuliwa wakati wowote neno la usawazishaji litatambuliwa na kushushwa mara tu pakiti hiyo inapochujwa au kukamilika na ACK yake kutumwa ikiwa moja iliombwa.

Kusawazisha Vipaumbele

Kama ilivyoelezwa katika sehemu ya 6.1 ya Vipaumbele vya Bluetooth, kwa chaguo-msingi masafa ya kipaumbele ya Bluetooth yamepangwa katika safu ya kipaumbele ya RAIL 16 - 32. Kwa ujumla, Bluetooth huanza kwa kutumia kipaumbele cha chini (32) na huongeza kipaumbele hadi kiwango cha juu (16) kama ilivyoelezwa. inahitajika ikiwa ujumbe haufaulu.

Kama ilivyoelezwa katika sehemu iliyotangulia, rafu ya 802.15.4 kama vile Zigbee au Connect hutumia thamani chaguomsingi za RAIL za 255 kwa RX ya usuli, 255 kwa RX inayotumika, na 100 kwa TX inayotumika.

Kutokana na vipaumbele hivi chaguo-msingi vya RAIL, katika 802.15.4 protocol-Bluetooth multiprotocol maombi, kwa chaguo-msingi trafiki ya Bluetooth itachukua kipaumbele zaidi ya 802.15.4 trafiki ya itifaki. Hili ni chaguo zuri kwa programu nyingi, kwa sababu trafiki ya Bluetooth ina mahitaji magumu ya muda, tofauti na itifaki 802.15.4. Walakini, ikiwa mzigo wa trafiki wa Bluetooth ni wa juu sana (kwa mfanoample, kutuma data nyingi kwa kutumia muda mdogo sana wa uunganisho), inawezekana kwa trafiki ya itifaki ya 802.15.4 kuzuiwa kabisa kutoka kwa ufikiaji wa redio kwa sababu ya kipaumbele chake cha chini na madirisha madogo sana ya muda wa redio unaopatikana ulioachwa na Bluetooth. trafiki

Kumbuka: Taarifa ifuatayo kwa sasa inatumika tu kwa rafu ya EmberZNet Zigbee. Silicon Labs Connect bado haina API inayohitajika ili kubadilisha vipaumbele.

Iwapo unatengeneza programu ya protocol yenye nguvu ya msingi wa 802.15.4, na ni muhimu kwa trafiki hiyo kufaulu kukiwa na trafiki ya juu sana ya Bluetooth, unaweza kurekebisha vipaumbele chaguo-msingi kama inavyoonyeshwa kwenye jedwali lililo hapa chini kwa kutumia API ifuatayo:

Hapana.	Jina	Mpangilio Chaguomsingi
1	TX inayotumika	23
2	RX inayotumika	24
3	Asili ya RX	255

Kwa sababu Bluetooth hapo awali iliweka kipaumbele chake cha RAIL kuwa 32, mipangilio hii ya kipaumbele ya 802.15.4 inaipa trafiki 802.15.4 kipaumbele cha juu kuliko Bluetooth hapo awali, ambayo huipa itifaki ya 802.15.4 nafasi ya kusambaza au kupokea trafiki kwa mafanikio hata kukiwa na trafiki nyingi. mzigo mkubwa wa trafiki ya Bluetooth. Kwa upande mwingine, Bluetooth itaongeza kipaumbele chake ikiwa itasukumwa kutoka kwa kipanga ratiba na trafiki ya 802.15.4, hadi kipaumbele cha juu cha 16. Kwa hivyo baada ya kuruhusu ufikiaji wa itifaki ya 802.15.4 kwenye redio mwanzoni, Bluetooth itachukua kipaumbele kwa majaribio yanayofuata ikiwa ni lazima.

Mbinu hii inaruhusu itifaki zote mbili kuathiri matumizi yao ya redio bila moja kuwa na uwezo wa kutawala juu ya nyingine kabisa.

. Utekelezaji wa Multiprotocol na RAIL

Sura hii inatoa maelezo zaidi kuhusu maalum ya RAIL kwa watumiaji wanaotumia RAIL API moja kwa moja ili kuunda itifaki za umiliki. Hasa inatoa maelezo juu ya jinsi ya kufanya kazi na API za RAIL kushughulikia kesi maalum za kupanga redio.

Examples na Upokeaji wa Mandharinyuma, Redio ya Mazao na Mpito wa Jimbo

Misingi ya mfumo wa kipaumbele wa RAIL Multiprotocol ni moja kwa moja: tukio la redio lenye kipaumbele cha juu (yaani, ndogo kwa idadi) daima litanyakua matukio mengine yoyote ya redio kwa kipaumbele cha chini. Hata hivyo, mada hii inakuwa ngumu zaidi wakati wa kuzingatia mabadiliko ya hali na API kama vile RAIL_StartRx(), ambayo huweka redio katika hali fulani kwa muda usiojulikana. Sehemu hii inatoa baadhi ya vielelezo exampili kuonyesha jinsi hali hizi zisizo na kikomo zinashughulikiwa, na jinsi safu ya programu inaweza kutumia API kama vile RAIL_YieldRadio() kuzidhibiti. Examples ni kama ifuatavyo:

Mabadiliko ya Jimbo kwa Itifaki Moja
Mabadiliko ya Jimbo na Itifaki Mbili

Mabadiliko ya Jimbo yenye Itifaki Mbili na Vipaumbele Vinavyoongezeka Kimoja

Katika haya examples, RAIL_StartTx() ndio chanzo cha tukio la TX ambalo linakatiza usuli wa RX. Kumbuka, hata hivyo, kwamba hawa wa zamaniamples zinatumika kwa API yoyote ya redio isipokuwa RAIL_StartRx(). Kwa maneno mengine, examples zinatumika kwa API yoyote inayoanzisha tukio la redio ambalo sio usuli wa RX

Hawa wa zamaniampinaonyesha tabia zinazotarajiwa za protokali nyingi kuhusiana na mabadiliko ya serikali. Kwa muhtasari:

Katika mpito wa hali, hali mpya inachukuliwa kama kiendelezi kisichojulikana cha tukio la asili kwa kipaumbele sawa hadi RAIL_YieldRadio() iitwe.
Matukio ya usuli wa RX hayaathiriwi na RAIL_YieldRadio(). RAIL_Idle() pekee ndiyo inayoweza kuondoa kabisa itifaki kutoka kwa hali ya usuli ya RX.
Tukio lililo na kipaumbele cha juu daima litanyakua tukio lenye kipaumbele cha chini, bila kujali simu zingine zozote za API.

RAIL_StartRx() inapokea pekee ndiyo inaweza 'kurudishwa kwa' kutoka kwa tukio la kipaumbele cha juu kupitia RAIL_YieldRadio() au RAIL_Idle().
Matukio yote ya redio isipokuwa RAIL_StartRx() yanahitaji RAIL_YieldRadio() ili kumalizika na kuendelea hadi tukio linalofuata.
Simu kwa RAIL_YieldRadio() haiwezi kubadilishwa na RAIL_Idle(). RAIL_Idle() hufuta matukio yote ya itifaki iliyotolewa

.Mabadiliko ya Jimbo kwa Itifaki Moja

Ex wa kwanza huyuample huchunguza tabia ya redio kwa itifaki moja (yaani, ambapo AIL_Handle_t sawa inatumika kwa simu zote za utendaji wa redio). Redio huanza kwa RX kwa simu ya kwanza kwa RAIL_StartRx(), kisha inahamia TX na wito wa kipaumbele cha juu hadi RAIL_StartTx(). Ni muhimu kutambua kwamba baada ya uhamisho kufanywa, mabadiliko ya redio hadi hali iliyotajwa na RAIL_SetTxTransitions (), na inakaa katika hali kwa muda usiojulikana kwa kipaumbele sawa na chaneli kama TX hadi RAIL_YieldRadio() inaitwa. Baada ya hapo, redio inarudi kwa RX, ikiwa na kipaumbele maalum na chaneli.

Haja ya kutoa redio kikamilifu, na kwa hivyo RAIL_YieldRadio() API ilikuwa muhimu kwa sababu ya ACK'ing. Falsafa ya muundo ni kwamba, kwa sababu TX na ACK iliyopokelewa ni viewed kama sehemu ya muamala sawa, ikiwa nodi itasambaza na kutarajia ACK inapaswa kuwa na uwezo wa kubadilisha hadi RX na kuendelea kusikiliza ACK kama sehemu ya operesheni sawa (na kwa hivyo kipaumbele sawa) kama TX asili. Kwa ujumla, hata hivyo, RAIL peke yake haiwezi kujua kama ACK inahitajika au la. Hii inaweza kutegemea mambo mengine, kama vile yaliyomo kwenye pakiti, au mantiki nyingine ya programu, na kwa hivyo haiwezi kuamuliwa tu kwa kuangalia kama ACK'ing imesanidiwa na RAIL_ConfigAutoAck(). Kwa hivyo, busara kuhusu wakati shughuli ya redio imekamilika imesalia. tikiti/rundo.

Ikiwa ACK haihitajiki, Silicon Labs inapendekeza upige simu RAIL_YieldRadio() kama sehemu ya kushughulikia tukio la RAIL_EVENT_TX_PACKET_SENT. Kufanya hivi husababisha mstari wa kijani kibichi katika takwimu iliyo hapo juu kupunguzwa hadi muda wa kusubiri wa kukatiza. Ikiwa programu inatarajia ACK, RAIL_YieldRadio() inafaa kupiga simu ACK inapopokelewa au inachukuliwa kuwa muda umeisha.

Mabadiliko ya Jimbo na Itifaki Mbili

Hali hii ni sawa na hali ya kwanza kuhusu mabadiliko ya serikali baada ya TX, lakini inaleta itifaki nyingine.

Katika hali hii, ni muhimu kutambua kwamba RAIL_StartRx() inaweza kuitwa wakati wowote wakati wa shughuli ya TX. Maadamu kipaumbele chake ni kidogo kuliko au sawa na kipaumbele cha TX, RX haitatumika hadi ombi lipige simu kwa _Yield Radio() kwenye Itifaki A. Wakati RAIL_StartRx() inapoitwa wakati wa TX, RX inaitwa tu. imeongezwa kwenye foleni ya matukio ya kushughulikiwa.

Jambo lingine muhimu ni kwamba, ingawa RAIL_YieldRadio() kwenye Itifaki A itabadilika kutoka TX hadi Itifaki A hadi RX kwenye Itifaki B, RAIL_Idle() kwenye Itifaki B inahitajika ili kuhama kutoka RX kwenye Itifaki B hadi RX kwenye Itifaki A. Falsafa hapa ni kwamba RX za Usuli haziwezi kutolewa, kwani tukio halijaisha kabisa. Njia pekee ya kutoka ni kusimamisha RX ya Mandharinyuma kwa kupiga simu kwa RAIL_Idle().

Mabadiliko ya Jimbo yenye Itifaki Mbili na Kipaumbele Kinachoongezeka Kimoja

Hali ya mwisho inakaribia kufanana na ile ya awali, isipokuwa simu kwa RAIL_StartRx() kwenye Itifaki B iko katika kipaumbele cha juu kuliko wito kwa RAIL_StartTx() kwenye Itifaki A.

Katika hali hii, kwa kuwa kipaumbele cha RAIL_StartRx() ya pili ni cha juu kuliko kipaumbele cha simu kwa RAIL_StartTx(), simu kwa RAIL_YieldRadio() haihitajiki tena. Kwa sababu RAIL_StartRx() ya pili iko katika kipaumbele cha juu, inachukua tukio la RAIL_StartTx(), kuchukua udhibiti wa redio na kuondoa tukio la TX kutoka kwa jimbo. Wakati wowote wakati huo RX kwenye Itifaki B, RAIL_Idle() inaweza kuitwa ili kurudi kwenye RX kwenye Itifaki A, kama tu ilivyokuwa katika toleo lililopita.ample.

Kumbuka hapa, kwamba wakati programu inaita RAIL_Idle() kwenye Itifaki B's RX, programu hairudii kwa Mpito wa TX wa Itifaki A. Badala yake, inaenda kulia chinichini RX, ingawa programu haikuita RAIL_Idle() kwenye Itifaki. A ni TX. Kwa utendakazi wa redio ulioratibiwa (yaani, utendakazi wowote wa redio ulioanzishwa na API isipokuwa RAIL_StartRx()), mara tukio la redio linapochukuliwa na tukio la kipaumbele cha juu, huondolewa kabisa na halitarejeshwa baadaye. Mandharinyuma Pekee inapokea, iliyoanzishwa na RAIL_StartRx(), inaweza kudumishwa katika thackground na 'kurejeshwa kwa' kupitia simu kwa RAIL_YieldRadio() au RAIL_Idle().

Ili kusisitiza tofauti kati ya RAIL_YieldRadio() na RAIL_Idle() ni muhimu kutambua kwamba, kwa haya yote ya zamani.amples, simu kwa RAIL_YieldRadio() haiwezi kubadilishwa na RAIL_Idle(). RAIL_Idle() hufuta matukio yote ya itifaki iliyotolewa - Mandharinyuma (yaani, iliyoanzishwa na RAIL_StartRx()) na Iliyoratibiwa (yaani, iliyoanzishwa na API isipokuwa RAIL_StartRx()) shughuli. RAIL_Idle() bado ingesababisha programu kuondoka katika hali ya mpito ya TX, lakini pia ingeondoa Mandharinyuma ya RX, na kusababisha programu kurudi bila kufanya kitu, si RX.

Utekelezaji wa Multiprotocol na Bluetooth

Kwa maelezo kuhusu jinsi RAIL/Bluetooth mwanga/switch multiprotocol example ilitekelezwa, na kwa maelezo zaidi juu ya kuunda programu nyingi za protocol na itifaki yako mwenyewe kwenye RAIL, angalia AN1134: Ukuzaji wa Itifaki nyingi zinazobadilika zenye Bluetooth na Itifaki za Umiliki kwenye RAIL katika GSDK v2.x au AN1269 Dynamic Multiprotocol Development kwa Bluetooth na Itifaki za Umiliki kwenye RAIL. katika GSDK v3.x na Juu.

Vipaumbele vya Bluetooth

Kinyume na Zigbee iliyo na vipaumbele vilivyobainishwa kulingana na takwimu kwa aina tofauti za uendeshaji, Bluetooth hutumia mbinu mbalimbali na kukabiliana ili kugawa kazi zote kwa eneo fulani la wigo wa kipaumbele.

Katika hii example safu ya kipaumbele ya Bluetooth, ambayo yenyewe huanzia 0 hadi 255, imechorwa kwa sehemu ndogo ya nafasi ya kipaumbele ya RAIL iliyoshirikiwa.

Tofauti na Zigbee, Bluetooth ina mahitaji magumu zaidi ya kuweka wakati ambapo kukosa nafasi fulani kunaweza kusababisha muunganisho kukatizwa. Pia Bluetooth ina anuwai ya kazi tofauti kama vile miunganisho (inawezekana nyingi), tangazo, kuchanganua, na utumaji na mapokezi ya Utangazaji wa Mara kwa Mara kwa Majibu (PAwR).

Jedwali 6.1. Vipaumbele Tofauti katika Bluetooth

1	Muunganisho	135 hadi 0	Tukio la Muunganisho Linaisha
2	Uanzishaji wa Muunganisho	55 hadi 15	Dirisha la Kuanzishwa Linaisha
3	Tangazo	175 hadi 127	Tukio la Tangazo Limekwisha
4	Kichanganuzi	191 hadi 143	Dirisha la Kuchanganua Limeisha
5	PAWR TX	15 hadi 5	Mtangazaji: Nafasi ya Kuchelewa kwa Majibu ya PAwR Inaisha Kilandanishi: Nafasi ya Majibu ya PAwR Inaisha
6	PAWR RX	20 hadi 10	Mtangazaji: Nafasi ya Majibu ya PAwR Inaisha Kilandanishi: Ucheleweshaji wa Nafasi ya Majibu ya PAwR Inaisha

Ili kushughulikia hili kipanga ratiba cha Bluetooth, ambacho vipaumbele vyake vimepangwa kwa kipanga ratiba cha redio cha RAIL, huzingatia vigezo vifuatavyo kwa kila kazi:

Wakati wa Kuanza
Muda wa chini
Muda wa juu zaidi

Kipaumbele

Ikiwa muda wa kuanza umesogezwa jumla ya muda wa kukimbia umepunguzwa mtawalia, hiyo ni kwamba ulegevu umepunguzwa. Pia vipaumbele vinaweza kubadilishwa kwa nguvu.

Viunganishi

Viunganisho vina kipaumbele cha juu kiasi. Muda wa kuanza kwa muunganisho hauwezi kuhamishwa.

Kipaumbele kinaongezwa kwa nguvu na kipanga ratiba cha Bluetooth kadiri muunganisho unavyokaribia muda wa kuisha kwa usimamizi, na kufikia kipaumbele cha juu karibu nayo. Pakiti ya TX kwenye foleni ya TX pia huongeza kipaumbele cha muunganisho.

Uanzishaji wa Muunganisho

Uanzishaji wa muunganisho huchanganua matangazo kutoka kwa kifaa lengwa ili kuanzisha muunganisho. Ina kipaumbele cha juu ikilinganishwa na kichanganuzi ili kuruhusu uanzishaji wa muunganisho thabiti zaidi.

Matangazo

Matangazo kwa chaguomsingi yana kipaumbele cha chini na mahali pa kuanzia inaweza kuhamishwa. Muda wa kuanza na Muda wa juu zaidi hufafanuliwa na muda wa matangazo.

Ikiwa tangazo halikuweza kutumwa, kipaumbele cha matangazo huongezeka polepole na hurejeshwa baada ya tangazo kutumwa kwa mafanikio.

Kichanganuzi

Kwa chaguo-msingi, majukumu haya yana kipaumbele cha chini zaidi. Wakati wa kuanza, wa chini na wa juu zaidi hufafanuliwa na muda wa skanning na saizi ya dirisha. Uchanganuzi unaweza kuendelea hata unapokatizwa na kazi ya kipaumbele cha juu. Hili likitokea, muda wa kuchanganua utakusanywa ili kuhakikisha kuwa ukubwa wa dirisha unaohitajika wa kutambaza umefikiwa katika kila muda wa kuchanganua.

Kama ilivyo kwa matangazo, kipaumbele kinaongezwa ikiwa muda unaotaka wa skanning au saizi ya dirisha haikuweza kufikiwa hapo awali. Inarejeshwa kwa kipaumbele chake cha kwanza mara baada ya muda wa skanning au ukubwa wa dirisha kufikiwa.

Matangazo ya Mara kwa Mara yenye Majibu (PAwR)

Kutuma Matangazo ya Mara kwa Mara kwa Majibu kuna kipaumbele cha juu zaidi kwa chaguo-msingi juu ya kazi zingine zote za Bluetooth, ikifuatiwa na kupokea majibu katika PAwR ili kudumisha usawazishaji katika mtandao wa lebo ya rafu ya kielektroniki (ESL).

Kipaumbele cha kazi ya PAwR kinaongezwa ikiwa upangaji wa kazi haufaulu mara mbili mfululizo. Kipaumbele kinaweza kuongezwa kwa 1/6 ya safu ya kipaumbele, au angalau kwa moja hadi kipaumbele cha juu kifikiwe. Kipaumbele cha kazi kinarejeshwa hadi kiwango cha chini zaidi baada ya kuratibu kufanikiwa. Utaratibu huo unatumika kwa mtangazaji wa PAwR kilandanishi katika pande zote mbili

Example ya Uendeshaji wa Kiratibu wa Bluetooth

Ex huyuample huonyesha jinsi kipanga ratiba cha Bluetooth kitaratibu kazi tatu za muunganisho na kazi moja ya tangazo, kila moja ikiwa na vipaumbele tofauti. Katika takwimu zifuatazo sehemu ya kijivu inaonyesha muda wa chini zaidi wa kukimbia ambao kazi inahitaji na sehemu ya bluu inaonyesha muda wa juu wa kukimbia ambao kazi inaweza kutumia na, ikiwa ni rahisi, eneo ambalo kazi inaweza kuhamishwa. Kielelezo kifuatacho kinaonyesha katika usanidi wa awali

Kama inavyoonyeshwa hapa chini Conn1 ndio kazi ya kwanza kufanya kwani haiingiliani na kazi yoyote ya kipaumbele cha juu.

Adv1 inapishana na kipaumbele cha juu Conn2. Adv1 inaweza kunyumbulika na kwa hivyo inasogezwa ndani kama inavyoonyeshwa kwenye takwimu ifuatayo.

Conn2 inaingiliana na jukumu la kipaumbele cha juu Conn4. Kwa vile Conn2 haiwezi kubadilika upangaji wa Conn2 haufaulu.

Conn4 haiingiliani na kazi zingine, kwa hivyo mwisho wa Conn1 hurekebishwa ili kusimama kabla ya Conn4 kuanza.

Kurekebisha Vipaumbele

Muundo wa "sl_bt_configuration_t" (v3.x)/"gecko_configuration_t" (v2.x) unafafanua muundo wa sl_bt_stack_config_t, ambao una sehemu ya "bluetooth.linklayer_priorities" ambayo ni kielekezi cha usanidi wa kipaumbele. Ikiwa kielekezi ni NULL basi rafu hutumia vipaumbele vyake chaguomsingi kama ilivyoorodheshwa katika sehemu ya 6.1 Vipaumbele vya Bluetooth hapo juu pamoja na sehemu hii.

Ikiwa pointer sio batili lazima ielekeze kwa muundo wa mipangilio ya kipaumbele kama inavyofafanuliwa hapa chini:

Vigezo sandman, Cinemax, adv_min, adv_min, mdalasini, conn_max, intimin na intima hufafanua vipaumbele vya chini na vya juu zaidi vya kuchanganua, tangazo, miunganisho, na uanzilishi mtawalia. Vipaumbele vitasonga kati ya mipaka ya chini na ya juu kama ilivyofafanuliwa katika sehemu ya 6.1.1 Viunganisho hadi 6.1.4 Kichanganuzi hapo juu.

Vigezo vya ramani ya RAIL, rail_mapping_offset na rail_mapping_range, hufafanua jinsi vipaumbele vya safu ya kiungo cha Bluetooth vinawekwa kwenye vipaumbele vya kipanga ratiba vya redio ya RAIL. Uchoraji wa thamani hizi unaweza kuonekana katika Vipaumbele vya 6.1 vya Bluetooth. Chaguomsingi kwa rail_mapping_offset na rail_mapping_range ni 16.

Vigezo vya hatua ya adv_step na scan hufafanua ukubwa wa hatua wakati kipaumbele cha utambazaji na utangazaji kinabadilishwa kwa nguvu. Hatimaye, vigezo pawr_tx_min, pawr_tx_min, pawr_tx_min, na pawr_rx_max hufafanua masafa ya kipaumbele kwa mtangazaji wa Par na kisawazisha matukio ya TX na RX katika kila tukio.

Kwingineko ya IoT
www.silabs.com/products

Ubora
www.silabs.com/quality

Usaidizi na Jumuiya
www.silabs.com/jumuiya

Kanusho

Silicon Labs inakusudia kuwapa wateja hati mpya zaidi, sahihi na za kina za vifaa vya pembeni na moduli zote zinazopatikana kwa watekelezaji wa mfumo na programu wanaotumia au wanaokusudia kutumia bidhaa za Silicon Labs. Data ya tabia, moduli zinazopatikana na vifaa vya pembeni, ukubwa wa kumbukumbu na anwani za kumbukumbu hurejelea kila moja
kifaa maalum, na vigezo vya "Kawaida" vilivyotolewa vinaweza na kutofautiana katika programu tofauti. Maombi kwa mfanoampvilivyofafanuliwa hapa ni kwa madhumuni ya kielelezo pekee. Silicon Labs inahifadhi haki ya kufanya mabadiliko bila taarifa zaidi kwa maelezo ya bidhaa, vipimo, na maelezo humu, na haitoi hakikisho kuhusu usahihi au ukamilifu wa maelezo yaliyojumuishwa. Bila arifa ya awali, Maabara ya Silicon yanaweza kusasisha programu dhibiti ya bidhaa wakati wa mchakato wa utengenezaji kwa sababu za usalama au za kutegemewa. Mabadiliko kama haya hayatabadilisha vipimo au utendaji wa bidhaa. Maabara ya Silicon hayatakuwa na dhima kwa matokeo ya matumizi ya habari iliyotolewa katika hati hii. Hati hii haimaanishi au kutoa leseni yoyote ya kubuni au kutengeneza saketi zilizounganishwa. Bidhaa hazijaundwa au kuidhinishwa kutumika ndani ya vifaa vyovyote vya FDA Class III, maombi ambayo kibali cha soko la awali cha FDA kinahitajika au Mifumo ya Usaidizi wa Maisha bila idhini mahususi iliyoandikwa ya Silicon Labs. "Mfumo wa Usaidizi wa Maisha" ni bidhaa au mfumo wowote unaokusudiwa kusaidia au kudumisha maisha na/au afya, ambayo, ikiwa itashindwa, inaweza kutarajiwa kusababisha majeraha makubwa ya kibinafsi au kifo. Bidhaa za Silicon Labs hazijaundwa au kuidhinishwa kwa matumizi ya kijeshi. Bidhaa za Silicon Labs hazitatumika kwa hali yoyote katika silaha za maangamizi makubwa ikijumuisha (lakini sio tu) silaha za nyuklia, kibayolojia au kemikali, au makombora yanayoweza kutoa silaha kama hizo. Silicon Labs inakanusha dhamana zote za wazi na zilizodokezwa na haitawajibika au kuwajibika kwa majeraha au uharibifu wowote unaohusiana na matumizi ya bidhaa ya Silicon Labs katika programu zisizoidhinishwa. Kumbuka: Maudhui haya yanaweza kuwa na istilahi za kuudhi ambazo sasa hazitumiki. Silicon Labs inabadilisha maneno haya kwa lugha-jumuishi inapowezekana. Kwa habari zaidi, tembelea www.silabs.com/about-us/inclusive-lexicon-project

Taarifa za Alama ya Biashara
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® na nembo ya Silicon Labs®, Blueridge®, Blueridge Logo®, EFM®, EFM32®, EFR, Ember®, Energy Micro, nembo ya Energy Micro na michanganyiko yake. , “vidhibiti vidogo vilivyo rafiki zaidi duniani”, Repine Signals®, Disconnect , n-Link, Thread Arch®, Elin®, EZRadioPRO®, EZRadioPRO®, Gecko®, Gecko OS, Gecko OS Studio, Precision32®, Simplicity Studio® , Telegenic, Telegenic Logo®, Suppress® , Sentry, nembo ya Sentry na Zentri DMS, Z-Wave®, na nyinginezo ni chapa za biashara au chapa za biashara zilizosajiliwa za Silicon Labs. ARM, CORTEX, Cortex-M3 na THUMB ni alama za biashara au alama za biashara zilizosajiliwa za ARM Holdings. Keli ni chapa ya biashara iliyosajiliwa ya ARM Limited. Wi-Fi ni chapa ya biashara iliyosajiliwa ya Muungano wa Wi-Fi. Bidhaa zingine zote au majina ya chapa yaliyotajwa hapa ni alama za biashara zinazomilikiwa