SILICON LABS UG305 Dynamic Multiprotocol User Guide

SILICON LABS UG305 Dynamic Multiprotocol User Guide

Mga sulod itago

Pasiuna

Kini nga dokumento naghulagway kung giunsa ang software sa Silicon Labs gidisenyo nga gamiton sa daghang mga protocol sa usa ka wireless chip. Ang dinamikong multiprotocol time-slices sa radyo ug paspas nga nag-usab sa mga configuration aron makahimo ang lain-laing wireless nga mga protocol nga makaandar nga kasaligan sa samang higayon.

Nota: Ang impormasyon nga piho sa Zigbee niini nga dokumento magamit sa bersyon 6.10.x ug ubos pa.
Ang mga detalye sa piho nga dinamikong multiprotocol nga pagpatuman gihatag sa mosunod nga mga nota sa aplikasyon:
AN1133: Dynamic Multiprotocol Development nga adunay Bluetooth ug Zigbee EmberZNet SDK 6.x ug Ubos
AN1134: Dynamic Multiprotocol Development nga adunay Bluetooth ug Proprietary Protocol sa RAIL sa GSDK v2.x
AN1269: Dynamic Multiprotocol Development nga adunay Bluetooth® ug Proprietary Protocols sa RAIL sa GSDK v3.x ug Higher
AN1209: Dynamic nga Multiprotocol Development nga adunay Bluetooth ug Sumpaysumpaya
AN1265: Dynamic Multiprotocol Development nga adunay Bluetooth® ug OpenThread sa GSDK v3.x

Terminolohiya

Ang mosunod naglista sa pipila ka terminolohiya nga espesipiko sa dynamic nga multiprotocol nga pagpatuman

Radio Abstraction Interface Layer (RAIL): Ang komon nga API diin ang mas taas nga lebel nga code makakuha og access sa EFR32 radio.

Operasyon sa radyo: Usa ka piho nga aksyon nga gikatakda. Ang usa ka operasyon sa radyo adunay usa ka radio configuration ug usa ka prayoridad. Ang matag stack mahimong mohangyo nga ang radio scheduler mohimo hangtod sa duha ka mga operasyon sa radyo (background makadawat ug bisan sa Scheduled Receive o Scheduled

Pagdawat sa Background: Nagpadayon nga pagdawat, gituyo nga mabalda sa Naka-iskedyul nga mga operasyon, ug ibalik pagkahuman sa ilang pagkompleto.
Naka-iskedyul nga Pagdawat: Dawata ang mga pakete o kuwentaha ang RSSI sa gitakdang oras ug gidugayon. (Mga nag-develop nga nagtrabaho sa RAIL, timan-i nga sa termino sa RAIL API, ang "Naka-iskedyul nga Pagdawat" ingon nga gigamit sa kini nga dokumento nagtumong sa bisan unsang operasyon sa pagdawat, gawas sa RAIL_StartRx, ug dili limitado sa sakup sa RAIL_ScheduleRx.)

Gitakda nga Transmit: Bisan unsa sa lain-laing mga operasyon sa pagpadala lakip na ang dinaliang pagpasa, naka-iskedyul (umaabot) nga pagpadala, o CCAdependent nga pagpadala. (Mga nag-develop nga nagtrabaho sa RAIL, timan-i nga sa termino sa RAIL API, ang "Scheduled Transmit" nga gigamit niini nga dokumento nagtumong sa bisan unsang operasyon sa pagpadala, ug dili limitado sa sakup sa RAIL_StartScheduledTx.

Radio Config: Gitino ang kahimtang sa hardware nga kinahanglan gamiton sa paghimo sa usa ka operasyon sa radyo.

Radio Scheduler: RAIL component nga naghusay tali sa lain-laing mga protocol aron sa pagtino kon kinsa ang adunay access sa radyo.

Prayoridad: Ang matag operasyon gikan sa matag stack adunay default nga prayoridad. Mahimong usbon sa usa ka aplikasyon ang default nga mga prayoridad.

Panahon sa Slip: Ang pinakataas nga oras sa umaabot kung kanus-a masugdan ang operasyon kung dili kini magsugod sa gihangyo nga oras sa pagsugod.

Abot: Ang usa ka stack kinahanglan nga boluntaryo nga mohatag sa katapusan sa usa ka operasyon o han-ay sa mga operasyon, gawas kung kini naghimo sa usa ka background nga nadawat. Hangtud nga ang stack mobunga, ang scheduler dili mag-iskedyul sa ubos nga prayoridad nga mga buluhaton

RTOS (Real Time Operating System) Kernel: Ang bahin sa operating system nga responsable sa pagdumala sa buluhaton, ug intertask nga komunikasyon ug pag-synchronize. Kini nga pagpatuman naggamit sa Micrium OS-5 kernel.

Arkitektura

Gigamit sa Dynamic Multiprotocol ang EFR32 hardware ug ang RAIL software isip mga bloke sa pagtukod niini. Ang Zigbee, Bluetooth, ug/o bisan unsang uban nga gibase sa mga sumbanan o proprietary nga mga protocol mahimo unya nga matukod sa ibabaw sa mga undational layer, gamit ang Micrium aron pagdumala sa pagpatuman sa code tali sa lain-laing mga protocol. Ang mosunod nga diagram naghulagway sa kinatibuk-ang istruktura sa software modules.

Sugod sa bersyon 2.0, gikinahanglan sa RAIL ang pagpasa sa radio configuration handle ngadto sa mga tawag sa RAIL API. Kini nga configuration naghulagway sa lain-laing mga parameter sa PHY nga gigamit sa stack

Ang Micrium OS usa ka RTOS nga nagtugot sa mga stack ug lohika sa aplikasyon nga ipaambit ang oras sa pagpatuman sa CPU.

Ang Radio scheduler usa ka librarya sa software nga maalamong motubag sa mga hangyo sa mga stack aron mahimo ang mga operasyon sa radyo aron mapadako ang kasaligan ug mamenosan ang latency. Ang mga API nga gihatag sa RAIL nga dili moapil sa radyo sa pag-bypass sa Radio scheduler.

Ang RAIL core nag-configure sa EFR32 hardware isip tubag sa mga instruksyon gikan sa radio scheduler.

Usa ka Imahe sa Firmware

Ang Dynamic Multiprotocol nagtugot sa usa ka software developer nga makamugna og usa ka monolithic binary nga gikarga sa usa ka EFR32. Ang mga pag-update sa software gihimo pinaagi sa pag-upgrade sa tibuuk nga binary. Nahimo kini gamit ang Geck otloader, ang mga detalye niini makita sa UG266: Silicon Labs Gecko Bootloader User's Guide para sa GSDK 3.2 ug Lower ug UG489: Silicon LabsGecko Bootloader User's Guide para sa GSDK 4.0 ug Higher.

Independent nga Stack Operation

Ang Silicon Labs stacks naglihok gihapon nga independente sa usag usa sa usa ka Dynamic Multiprotocol nga sitwasyon. Ang pila ka dugay na nga operasyon sa radyo adunay epekto sa latency sa laing protocol ug nagsunod nga operasyon. Anaa sa aplikasyon ang pagtino sa bisan unsang espesyal nga konsiderasyon alang sa kini nga mga panghitabo. Tan-awa ang seksyon 2. Ang Radio Scheduler para sa dugang nga impormasyon.

Ang Radio Scheduler

Ang Radio Scheduler kay usa ka component sa RAIL (Radio Abstraction Interface Layer). Naghatag ang RAIL og usa ka intuitive, dali mapasibo nga radio interface layer ug API, nga nagsuporta sa proprietary o standards-based wireless protocols. Ang Radio Scheduler gidisenyo aron tugotan ang mga operasyon sa radyo nga mahimong ma-iskedyul ug unahon. Ang lainlaing mga operasyon sa radyo sa matag protocol mahimong labi ka hinungdanon, o labi pa o dili kaayo sensitibo sa oras, depende sa sitwasyon. Mahimong tagdon sa scheduler kana sa paghimog mga desisyon bahin sa mga panagbangi ug kung giunsa kini paghusay

Gawas lang kung nag-develop ka og mga aplikasyon nga adunay naandan nga protocol sa RAIL, kadaghanan sa mga function sa scheduler sa radyo awtomatik nga gidumala pinaagi sa nagpahiping stack ug RAIL code. Kinahanglan ra nimo nga gamiton ang stack pinaagi sa normal nga API.

Sa taas nga lebel, ang stack nagpadala usa ka operasyon sa radyo (alang sa exampUsa ka Naka-iskedyul nga Pagdawat o Naka-iskedyul nga Pagpadala). Ang mga operasyon sa radyo mao ang
gipila ug dayon giserbisyohan sa umaabot nga panahon base sa ilang mga parameter. Sa diha nga panahon na sa pagsugod sa operasyon sa radyo ang scheduler magsusi kung adunay usa ka kompetisyon nga panghitabo ug kung ang operasyon mahimong malangan o dili. Kung ang scheduler dili makadagan sa panghitabo ibalik ang resulta sa mas taas nga layer, nga mahimong sulayan pag-usab gamit ang bag-ong mga parameter.

Kung nagsugod na ang operasyon sa radyo, ang katugbang nga stack makapadala sa scheduler og dugang nga mga operasyon base sa mga resulta sa miaging operasyon (alang sa exampNaghulat ako alang sa usa ka ACK). Sa pagtapos sa matag operasyon o han-ay sa mga operasyon ang stack kinahanglan maghatag ug paggamit sa radyo.

Operasyon sa Radyo

Ang matag panghitabo sa scheduler gibahin ngadto sa mga elemento nga gitawag og Radio Operations, nga nalangkit sa radio config ug priority.

Ang matag operasyon adunay prayoridad ug mabalda kung ang scheduler makadawat og mas taas nga prayoridad nga operasyon nga nagsapaw sa oras. Ang mas ubos nga prayoridad nga mga operasyon sa radyo nga dili mapadagan base sa ilang mga parameter sa eskedyul mapakyas, ug anaa na sa tagsa-tagsa ka stack ang pagsulay niini pag-usab. Sa higayon nga ang scheduler aktibo nga nagpadagan sa usa ka operasyon sa radyo gikan sa stack, ang stack mahimo nga magpadayon sa pagpadala sa dugang nga mga operasyon sa radyo hangtud nga kini boluntaryo nga mohatag, o hangtud nga ang scheduler makadawat sa usa ka mas taas nga prayoridad nga operasyon sa radyo ug preempt niini.

Pagdawat sa Background
Naka-iskedyul nga Pagdawat
Naka-iskedyul nga Pagpadala

Ang matag stack makahangyo sa Radio Scheduler sa paghimo og hangtod sa duha ka mga operasyon sa radyo (background makadawat ug bisan sa Scheduled Receive o Scheduled transmit) sa usa ka higayon:

Ang matag operasyon adunay mosunod nga mga parameter:

Panahon sa Pagsugod	Usa ka timailhan kung unsa nga punto sa umaabot nga kini nga operasyon sa radyo modagan. Mahimo kini nga "pagdagan karon" o pila ka kantidad sa mga microsecond sa umaabot.
Prayoridad	Usa ka numero nga nagpaila sa paryente nga prayoridad sa operasyon. Kung gamiton ang default setting, ang mga operasyon sa Bluetooth LE radio halos kanunay nga mas taas nga prayoridad kaysa mga operasyon sa Zigbee.
Panahon sa Slip	Usa ka gidugayon sa panahon nga ang panghitabo mahimong malangan lapas sa oras sa pagsugod niini ug madawat gihapon sa stack. Kini mahimong 0, diin ang panghitabo dili ma-slip.
Panahon sa Transaksyon	Ang gibanabana nga gidugayon sa oras nga gikinahanglan aron makompleto ang transaksyon. Ang pagpadala sa mga panghitabo kasagaran adunay usa ka labi ka maayo nga gitakda nga oras sa transaksyon, samtang ang pagdawat sa mga panghitabo kanunay nga wala mahibal-an. Gigamit kini aron matabangan ang scheduler sa radyo sa pagtino kung ang usa ka kalihokan mahimo bang dagan.

Ang stack naghubit niining lain-laing mga parameter nga angay sa operasyon nga gipatuman. Kay exampDugang pa, ang mga panghitabo sa koneksyon sa Bluetooth kanunay nga gieskedyul sa umaabot ug wala’y gitugotan nga slip, samtang ang Zigbee nagpadala sa mga panghitabo kanunay nga malangan usa ka gamay nga kantidad ug bituon sa ulahi.

Gikan sa panan-aw sa RAIL Radio Scheduler, ang Naka-iskedyul nga pagpadala ug Naka-iskedyul nga pagdawat parehas. Pareho silang mga operasyon nga nanginahanglan paggamit sa radyo, ug sa ingon dili mahimo nga dungan nga ipatuman. Ang kalainan makita lamang sa RAIL API layer, diin ang usa ka TX o RX API gitawag.

Pagdawat sa Background

Kini usa ka padayon nga mode sa pagdawat nga gituyo nga mabalda sa ubang mga operasyon, ug ibalik pagkahuman sa ilang pagkompleto. Kung ang Background Receive mas taas nga prayoridad kaysa sa ubang mga operasyon, ang mga operasyon sa radyo dili ma-chedule ug dili modagan. Anaa sa mga stack o aplikasyon ang pagbag-o sa prayoridad o boluntaryo nga paghatag. Tan-awa ang seksyon 5.1 Examples uban sa Background Receive, Yield Radio ug State Transition alang sa exampbahin sa kung giunsa ang pagdawat sa Background nakig-uban sa mga naka-iskedyul nga operasyon.

cheduled Pagdawat

Kini usa ka pagdawat sa umaabot nga panahon nga adunay piho nga gidugayon. Ang radio scheduler magkonsiderar sa radio switching time sa pagdesisyon kung ang operasyon ieskedyul o dili. Kung dili kini ma-iskedyul unya ang scheduler magpadala usa ka pakyas nga panghitabo sa calling stack. Ang operasyon sa radyo awtomatik nga gipalugway hangtod nga ang stack boluntaryong mohatag, o ang scheduler makadawat sa mas taas nga prayoridad nga operasyon ug makabalda niini. Ang pagpalapad sa pagdawat nagtugot sa stack sa pagpadayon sa usa ka operasyon sa radyo base sa mga kinahanglanon sa mas taas nga lebel nga protocol, alang sa example transmission sa usa ka tubag base sa nadawat data.

Naka-iskedyul nga Pagpadala

Kini usa ka pagpadala sa umaabot nga panahon nga adunay labing gamay nga gidugayon. Kini nga minimum nga gidugayon mahimong maglakip sa gipaabot nga follow-on nga mga panghitabo, alang sa exampusa ka ACK sa usa ka IEEE 802.15.4 transmit. Bisan pa, ang minimum nga oras alang niini nga operasyon dili kinahanglan nga maglakip sa wala damha nga mga panghitabo nga mahimong molugway sa oras lapas sa minimum nga gidugayon, alang sa exampmga kakulangan tungod sa mga kapakyasan sa CCA sa IEEE 802.15.4. Gikonsiderar sa scheduler sa radyo ang oras sa pagbalhin sa radyo sa pagdesisyon kung ieskedyul ba o dili ang operasyon. Kung dili kini ma-iskedyul unya ang scheduler magpadala usa ka pakyas nga panghitabo sa calling stack.

Radio Config

Ang matag operasyon sa radyo nalangkit sa usa ka predefined radio config nga nagtino sa kahimtang sa hardware nga kinahanglang gamiton sa pagbuhat sa operasyon. Ang Radio Configs nagsubay sa kasamtangan nga kahimtang sa stack aron ang umaabot nga mga operasyon sa radyo mogamit sa parehas nga mga parameter sa radyo. Ang Radio Config mahimong aktibo o dili aktibo. Kung ang stack nagbag-o sa usa ka aktibo nga Radio Config unya ang RAIL naghimo usab dayon nga pagbag-o sa pag-configure sa hardware, alang sa exampmag change ug channel. Kung ang radio config dili karon aktibo unya ang sunod nga naka-iskedyul nga operasyon sa radyo mogamit sa bag-ong radio config.

Prayoridad

Ang matag operasyon sa radyo adunay prayoridad nga nagpaila sa scheduler kung unsang operasyon ang kinahanglan ipatuman kung adunay usa ka timing nga nagsapaw taliwala sa daghang mga operasyon. Gitagad sa scheduler ang usa ka prayoridad nga 0 isip pinakataas nga prayoridad ug 255 isip pinakaubos nga prayoridad. Ang radio scheduler motugot sa buluhaton nga adunay pinakataas nga prayoridad sa pag-access sa pisikal nga ra rdware. Uban sa kadaghanan sa mga buluhaton nga kontrol ibalik sa radio scheduler lamang sa pagkahuman, apan ang mga buluhaton sama sa background makadawat mabalda kung ang usa ka buluhaton nga adunay mas taas nga prayoridad mahimong aktibo

Ang matag stack adunay usa ka default set sa mga prayoridad base sa Silicon Labs 'pagtuki kung giunsa ang labing kaayo nga pagtinabangay aron mapadako ang siklo sa katungdanan ug malikayan ang mga nahulog nga koneksyon alang sa usa ka generic nga kaso sa paggamit. Ang piho nga mga kaso sa paggamit mahimong adunay lainlaing mga panginahanglan. Ang mga prayoridad mao ang mosunod, gikan sa pinakataas ngadto sa pinakaubos

Bluetooth LE Naka-iskedyul nga Pagpadala
Bluetooth LE Naka-iskedyul nga Pagdawat
Ubang protocol nga Naka-iskedyul nga Pagpadala
Uban pang protocol nga Pagdawat sa Background

Kini nga mga prayoridad mahimong ma-override o usbon sa aplikasyon. Anaa na sa aplikasyon ang pagdesisyon kung unsa nga mga kahimtang ang magbag-o niini. Ang Seksyon 4.2 802.15.4 Ang Priyoridad sa RAIL ug ang seksyon 6.1 Ang Mga Priyoridad sa Bluetooth adunay daghang mga detalye sa mga prayoridad alang sa ilang piho nga mga higayon.

Panahon sa Slip

Ang matag operasyon sa radyo kinahanglan nga adunay "slip time", o labing taas nga oras sa pagsugod, nagpasabut nga ang kinalayo nga oras sa umaabot kung kanus-a masugdan ang operasyon kung dili kini magsugod sa gihangyo nga oras sa pagsugod. Gitugotan niini ang scheduler sa pagtrabaho sa mas taas nga prayoridad nga mga panghitabo nga nahitabo sa samang higayon, o mas taas nga prayoridad nga mga panghitabo nga molapas sa ilang gipaabot nga gidugayon. Ang protocol sa kasagaran nagdiktar kung unsa ang oras sa pag-slip, apan ang scheduler sa radyo makahimo sa pagdumala niini sa matag-operasyon nga basehan, nga gitugotan ang usa ka stack nga mawala ang pipila ka mga panghitabo apan dili ang uban. Sa kinatibuk-an, ang IEEE02.15.4 adunay mas taas nga slip time ug ang Bluetooth LE adunay gamay nga slip time.

Abot

Sa higayon nga ang usa ka han-ay sa mga operasyon sa radyo aktibo nga gipadagan, ang stack mahimong magpadayon sa pagdugang sa mga operasyon nga nagpalugway sa unang operasyon hangtud nga ang stack wala nay mahimo alang sa partikular nga pagbayloay sa mensahe. Ang usa ka stack kinahanglan nga boluntaryong mohatag gawas kung kini naghimo sa usa ka background nga nadawat. Kung ang usa ka stack dili mohatag unya kini magpadayon sa pagpalapad sa iyang operasyon sa radyo, ug ang ubos nga prayoridad nga mga operasyon sa radyo magpahinabog kapakyasan balik sa katugbang nga stack nga mihangyo sa maong operasyon sa radyo. Ang usa ka mas taas nga prayoridad nga operasyon dili makabalda sa usa ka karon nga nagdagan, ubos nga prayoridad nga operasyon sa radyo nga wala mobunga. Tan-awa ang seksyon 5.1 Examples uban sa Background Receive, Yield Radio ug State Transition alang sa exampgamay sa mga sitwasyon diin ang dayag nga paghatag sa radyo gikinahanglan.

Pagputol sa Operasyon sa Radyo

Ang usa ka naka-iskedyul nga operasyon sa radyo mahimong mabalda kung ang usa ka mas taas nga prayoridad nga operasyon supak niini. Kini mahimong mahitabo sa mosunod nga duha ka mga kahimtang:

Ang usa ka naka-iskedyul nga operasyon sa radyo mas dugay kaysa gipaabut ug ang katugbang nga stack dili makahatag sa mas taas nga prayoridad nga radiooperation kinahanglan magsugod.
Ang usa ka mas taas nga prayoridad nga operasyon sa radyo bag-o lang gikatakda nga mahitabo sa umaabot ug mga panagbangi sa usa ka ubos nga prayoridad nga operasyon nga naka-iskedyul na

Madugay nga mga Operasyon sa Radyo

Ang pila ka dugay na nga mga Operasyon sa Radyo mahimong adunay dako nga epekto sa husto nga operasyon sa produkto. Mahimong kinahanglan nga i-coordinate sa aplikasyon kini nga mga operasyon tali sa mga protocol. Kung ang aplikasyon dili dayon ang mga prayoridad sa scheduler sa radyo ang mag-una. Kay example, usa ka IEEE 802.15.4 energy scan mahimong magkinahanglan nga ang radyo magpabilin aron makakuha og igo nga mga pagbasa sa enerhiya. Kung ang aplikasyon dili husto nga mag-coordinate sa mga operasyon, ang pag-scan mahimong mabalda sa dili pa panahon tungod sa mas taas nga prayoridad nga operasyon sa Bluetooth.

Radio Scheduler Examples

Tanang exampGigamit nila ang Bluetooth LE ug Zigbee, apan ang mga prinsipyo magamit sa ubang Bluetooth/802.15.4 nga kombinasyon.

Nagsugod ang scheduler pinaagi sa pagbaton og ubos nga prayoridad nga Zigbee background nga makadawat og operasyon. Kini nagrepresentar sa usa ka kanunay-on router nga mahimong kinahanglan nga makadawat IEEE 802.15.4 packets sa wala mailhi nga mga panahon. Aktibo usab ang koneksyon sa Bluetooth LE ug nanginahanglan nga ang stack andam nga makadawat matag 30 ms. Ang Bluetooth LE stack mahimong mag-iskedyul niini nga abante tungod sa pagka-redictable sa koneksyon.

Pag-iskedyul sa Prioridad

Naghatag kini usa ka sukaranan nga example sa paghukom sa mga prayoridad sa lain-laing mga operasyon sa radyo.

Ang Zigbee stack nagdesisyon nga kinahanglan kini magpadala usa ka pakete. Mahimo kini nga buhaton ingon usa ka on-demand nga panghitabo, nagpasabut nga ang stack nakahukom nga gusto nga magpadala usa ka pakete karon nga wala ipahibalo ang scheduler nga daan. Sukwahi kini kung giunsa ang pag-operate sa Bluetooth LE, kung diin nahibal-an ang mga naka-iskedyul nga operasyon nga labi ka abante. Gibanabana sa scheduler nga posible nga ipahigayon ang operasyon sa radyo sa Zigbee TX 1 ug magserbisyo gihapon sa mas taas nga prayoridad nga panghitabo sa pagdawat sa Bluetooth LE sa umaabot. Busa gitugotan sa scheduler nga mahitabo ang transmit event. Gibuhat sa Zigbee stack ang tanan nga mga bahin sa kini nga operasyon sa pagpadala (naghulat alang sa usa ka MAC ack), ug dayon boluntaryo nga mohatag. Ang gibanabana nga oras sa transaksyon sa operasyon sa radyo sa pagpadala sa Zigbee DILI naglakip sa mga pagsulay pag-usab.

Niining example, Bluetooth LE naka-iskedyul na nga makadawat sa umaabot ug ang Zigbee stack gusto nga ipadala. Alang sa unang Zigbee TX 1 nga operasyon sa radyo adunay igong panahon sa dili pa ang Bluetooth LE RX 1 nga operasyon sa radyo aron ang scheduler motugot sa stack sa pagbuhat sa operasyon. Sa ulahi, sa dihang ang Zigbee stack mosulay sa pag-iskedyul sa Zigbee TX 2 ang scheduler motino nga walay igong panahon sa dili pa ang high priority nga Bluetooth LE RX 2 nga panghitabo. Bisan pa, ang Zigbee stack nagpakita nga kini nga aksyon mahimo’g mawala ang oras sa pagsugod niini. Gitino sa scheduler sa radyo nga tungod sa gipaabot nga gidugayon sa operasyon sa Bluetooth LE radio ang operasyon sa Zigbee mahimong magsugod human sa maong panghitabo ug anaa gihapon sa sulod sa slip time nga gipakita sa Zigbee stack.

Kung mahitabo ang tanan sama sa gipaabut, ang operasyon sa pagpadala sa Zigbee adunay una nga pagsulay nga mahitabo nga wala’y bisan unsang mga kapakyasan tungod sa pag-iskedyul.

Priority Interruption Example

Kini nga example nag-ilustrar sa usa ka mas taas nga prayoridad nga operasyon nga nakabalda sa usa ka ubos nga prayoridad.

Kini nga example magsugod sa samang paagi sa miaging example. Ang Zigbee ug Bluetooth LE parehong adunay operasyon sa radyo nga naka-iskedyul nga wala’y bisan unsang pagbangga

Sa ulahi, ang Zigbee stack nakahukom nga gusto kini magpadala ug laing pakete para sa Zigbee TX 2 nga panghitabo. Gitino sa scheduler nga mahimong posible ang pag-iskedyul niini nga panghitabo ug pagserbisyo sa Bluetooth LE RX 2 nga panghitabo sa ulahi, base sa pinakataas nga oras nga gikinahanglan sa Zigbee TX 2 nga panghitabo. Bisan pa, ang Zigbee TX 2 nga panghitabo mas dugay kaysa gipaabut tungod sa usa ka taas nga random nga backoff ug dili makahatag sa oras. Kini ang hinungdan sa panghitabo nga makabangga sa usa ka mas taas nga priority rad peration, ug busa ang Radio Scheduler mobalda sa Zigbee nga panghitabo ug mibalik sa usa ka kapakyasan sa mas taas nga lebel nga stack. Ang panghitabo sa Bluetooth LE kasagarang mahitabo ug kung makompleto na kini boluntaryong muhatag sa bisan unsang mas ubos nga prayoridad nga operasyon.

Sa pagkadawat sa kapakyasan gikan sa radio scheduler ang Zigbee stack misulay dayon sa pagsulay sa MAC nga mensahe. Nag-iskedyul kini sa operasyon ug naglakip sa oras sa pag-slip. Niini nga punto ang Bluetooth LE stack adunay prayoridad sa radyo ug sa ingon ang operasyon dili pa masugdan, apan ang scheduler midawat sa bag-ong operasyon sa radyo. Ang Bluetooth LE stack mokompleto sa iyang nakaeskedyul nga pagdawat ug mohatag sa radyo. Ang scheduler unya mag-trigger sa Zigbee transmit operation nga mahitabo tungod kay anaa pa kini sa slip time sa unang pagsugod nga operasyon. Human makompleto ang pagpadala ang scheduler mobalik sa background nga makadawat sa operasyon.

Mas Taas nga Priyoridad nga Operasyon nga Gipalugway

Kini nga exampGipakita kung unsa ang mahitabo kung ang usa ka mas taas nga prayoridad nga operasyon mas dugay kaysa sa orihinal nga gipaabut ug hinungdan sa usa ka ubos nga prayoridad nga operasyon nga mawad-an sa oportunidad niini

Sa kini nga kaso, ang Bluetooth LE adunay Naka-iskedyul nga pagdawat nga karon nahitabo. Nakahukom si Zigbee nga magpadala usa ka pakete apan dili kini magamit karon. Gidawat sa scheduler ang operasyon ubos sa pangagpas nga ang Bluetooth LE event makompleto sa dili pa matapos ang slip time sa Zigbee event. Bisan pa, ang panghitabo sa Bluetooth LE mas dugay tungod sa kamatuoran nga ang dugang nga mga pakete gipadala taliwala sa mga aparato. Ang operasyon sa Bluetooth LE adunay prayoridad aron ang operasyon sa Zigbee sa kadugayan mahurot. Usa ka sayup ang gibalik sa stack. Nakahukom si Zigbee nga ipadala pag-usab ang pakete. Sa makausa pa, ang Zigbee stack nagpaila nga ang operasyon kinahanglan magsugod karon apan mahimong mawala sa umaabot. Ang scheduler anaa sa tunga-tunga sa pag-usab sa radio config aron dili kini makasugod dayon sa operasyon. Hinunoa, gi-slip niini ang oras sa pagsugod sa operasyon sa radyo sa gamay nga kantidad ug dayon ipatuman ang operasyon.

Mas Taas nga Priyoridad nga Operasyon nga Walay Paglunga

Niining exampAng radio scheduler nagdagan sa usa ka node nga naglihok isip Bluetooth LE peripheral ug kana nga node adunay daghang mga koneksyon sa lain-laing mga sentral nga mga himan. Kini usab adunay usa ka periodic advertising beacon nga gipasa. Ang mosunod nga numero nagpakita sa usa ka kaso diin kini nga mga panghitabo nahitabo halos back-to-back ug wala magtugot ug igong panahon sa pagbalik ngadto sa Zigbee radio config. Busa maghimo kini usa ka yugto kung diin ang Zigbee stack
dili maka-transmit bisan sa oras sa pag-slip.

Gihangyo ni Zigbee ang scheduler nga mag-iskedyul og operasyon sa pagpasa sa radyo. Bisan kung nahibal-an sa scheduler nga mapakyas ang kalihokan tungod sa gitakda nga mas taas nga prayoridad nga mga operasyon, gidawat gihapon niini ang gikatakda nga kalihokan. Gihimo kini tungod sa duha ka rason. Una, ang mga kahimtang mahimong mausab ug ang panghitabo mahimong ipatuman. Ikaduha, ang stack nga naglingkod sa ibabaw sa radio scheduler mahimong mosulay pag-usab sa aksyon. Kung ang resulta sa napakyas nga pag-iskedyul gibalik dayon nan ang pagsulay sa stack sa pagsulay pag-usab dili tingali molampos tungod kay wala’y oras nga milabay. Hinuon, pinaagi sa pagpila sa panghitabo ug pagbalik sa kapakyasan pagkahuman sa oras sa pag-slip, ang pagsulay pag-usab (nga adunay kaugalingon nga oras sa pag-slip) adunay mas maayo nga higayon nga magmalampuson tungod kay lahi ang set sa umaabot nga operasyon sa radyo.

Pagdawat Kung Nagdagan ang Mas Taas nga Priyoridad nga Operasyon

Kini nga exampGi-ilustrar sa le kung unsa ang mahitabo kung ang Bluetooth LE aktibo ug usa ka ubos nga prayoridad nga operasyon ang makadawat og data.

Sa unang kaso, kung ang IEEE 802.15.4 nga mensahe gipadala ug ang Bluetooth LE stack naggamit sa radyo alang sa aktibong pagdawat sa Zigbee stack dili online aron makadawat sa mensahe. Bisan pa, ang nagpadala sa Zigbee sa mensahe mosulay pag-usab sa kadaghanan nga mga kaso ug uban ang mga pag-atras ug uban pang mga pagbag-o sa oras dili magkasumpaki sa lain nga mas taas nga prayoridad nga naka-iskedyul nga Bluetooth makadawat mga panghitabo nga dili tingali magbangga. Ang mensahe sa Zigbee malampuson nga nadawat

Ang ikaduha nga kaso nagpakita nga, sa kaso sa usa ka aktibo nga pagdawat, ang Zigbee stack mahimo gihapon nga mabalda ug dili makadawat (o ACK) sa mensahe. Ang malampuson nga komunikasyon nagsalig sa pagsulay pag-usab sa MAC o mas taas nga layer aron ipadala kini nga mensahe pag-usab ug pamatud-an nga ang Dynamic Multiprotocol device nakadawat sa mensahe.

Bisan kung adunay mga konsiderasyon kung kinahanglan ba o dili ang aktibo nga pagdawat mabalda, lisud alang sa tig-iskedyul sa paghimo niana nga determinasyon. Sa kinatibuk-an ang kalig-on sa mga protocol kinahanglan magtugot alang sa mga mensahe nga malampuson nga madawat bisan kung adunay pagkabalda

Pag-implementar sa Multiprotocol nga adunay 802.15.4-Based Stack

Kini nga kapitulo nagtanyag sa kinatibuk-ang impormasyon mahitungod sa pagpatuman sa 802.15.4-based stack sama sa Zigbee o Connect isip kabahin sa usa ka multiprotocol nga aplikasyon. Alang sa mga detalye kung giunsa ang pag-configure plugins ug uban pang mga detalye nga espesipiko sa rticular protocol, tan-awa ang usa sa mosunod nga mga nota sa aplikasyon:

AN1133: Dynamic Multiprotocol Development nga adunay Bluetooth ug Zigbee EmberZNet SDK 6.x ug Ubos

AN1209: Dynamic nga Multiprotocol Development nga adunay Bluetooth ug Sumpaysumpaya

Suporta sa Wireless Protocol

Ang lainlaing mga wireless protocol adunay lainlaing mga kinaiya nga gigamit sa disenyo sa Dynamic Multiprotocol. Kay example, Bluetooth Low Energy estrikto kaayo ug matag-an sa iyang eskedyul sa mga operasyon sa radyo; advertisement ug koneksyon agwat mahitabo sa gitakda nga mga panahon. Sa kasukwahi, ang usa ka 802.15.4 protocol mas flexible sa panahon sa daghang mga panghitabo sa mensahe; Ang CSMA (carrier sense multiple access) sa IEEE 802.15.4 nagdugang ug random backoffs aron ang mga paglangan sa panghitabo anaa sa han-ay sa milliseconds. Kini nagtugot sa IEEE 802.15.4 nga mga mensahe nga ipadala sa palibot sa Bluetooth Low Energy nga mga panghitabo ug sa gihapon masaligan nga madawat.

802.15.4 RAIL Priyoridad

Ang 802.15.4 nga mga protocol sa pagkakaron adunay tulo ka prayoridad sa RAIL.

Dili.	Ngalan	Default nga Setting	Exit Criterion
1	Aktibo nga TX	100	Nadawat ang MAC ACK (o wala)
2	Aktibo nga RX	255	Packet filtered o MAC ACK gipadala
3	Background RX	255	Buluhaton nga adunay mas taas nga Priyoridad karon

Kung ang usa ka Active TX mapatuman ang radyo ipagawas sa panahon nga ang katugbang nga MAC acknowledgement nadawat (o usa ka timeout ang nahitabo).

Ang background RX magbilin sa radyo sa makadawat nga estado nga andam sa pagdawat sa mga asynchronous nga mensahe. Kung ang aktibo nga RX priority lahi sa background nga RX priority, ang makadawat nga priority ipataas sa matag higayon nga ang usa ka sync nga pulong mamatikdan ug ipaubos lamang sa higayon nga kana nga packet masala o makompleto ug ang ACK niini ipadala kung ang usa gihangyo.

Pagbalanse sa mga Priyoridad

Sama sa gipatin-aw sa seksyon 6.1 Bluetooth Priorities, sa default ang Bluetooth priority range gimapa ngadto sa RAIL priority range 16 – 32. Sa kinatibuk-an, ang Bluetooth nagsugod gamit ang ubos nga priority (32) ug dinamikong nagdugang sa priority hangtod sa maximum (16) ingon gikinahanglan kung ang mga mensahe dili molampos.

Sama sa gihulagway sa miaging seksyon, ang 802.15.4-based stack sama sa Zigbee o Connect naggamit sa default RAIL priority values nga 255 para sa background RX, 255 para sa active RX, ug 100 para sa active TX.

Isip resulta niining mga default RAIL priorities, sa usa ka 802.15.4 protocol-Bluetooth multiprotocol nga aplikasyon, pinaagi sa default Bluetooth traffic ang kanunay mag-una sa 802.15.4 protocol traffic. Kini usa ka maayong pagpili alang sa daghang mga aplikasyon, tungod kay ang trapiko sa Bluetooth adunay higpit nga mga kinahanglanon sa oras, dili sama sa mga protocol sa 802.15.4. Bisan pa, kung ang pagkarga sa trapiko sa Bluetooth taas kaayo (alang sa example, pagpadala og daghang data gamit ang gamay kaayo nga agwat sa koneksyon), posible nga ang trapiko sa 802.15.4 protocol nga bug-os nga ma-block gikan sa pag-access sa radyo tungod sa ubos nga prayoridad niini ug ang gamay kaayo nga mga bintana sa magamit nga oras sa radyo nga gibilin sa Bluetooth. trapiko

Nota: Ang mosunod nga impormasyon sa pagkakaron magamit lamang sa EmberZNet Zigbee stack. Ang Silicon Labs Connect wala pa ang API nga gikinahanglan aron mabag-o ang mga prayoridad.

Kung nag-develop ka ug 802.15.4-based dynamic multiprotocol nga aplikasyon, ug importante nga molampos kana nga trapiko sa presensya sa taas kaayo nga load nga trapiko sa Bluetooth, mahimo nimong i-adjust ang default priorities sama sa gipakita sa table sa ubos gamit ang mosunod nga API:

Dili.	Ngalan	Default nga Setting
1	Aktibo nga TX	23
2	Aktibo nga RX	24
3	Background RX	255

Tungod kay ang Bluetooth sa sinugdanan nagtakda sa iyang RAIL priority ngadto sa 32, kini nga 802.15.4 priority settings naghatag sa 802.15.4 nga trapiko nga mas taas nga prayoridad kay sa Bluetooth sa sinugdanan, nga naghatag sa 802.15.4 protocol og kahigayunan sa pagpadala o pagdawat sa trapiko nga malampuson bisan sa presensya sa usa ka kaayo. taas nga load sa trapiko sa Bluetooth. Sa laing bahin, ang Bluetooth dinamikong mopataas sa iyang prayoridad kon kini mabanggaan gikan sa scheduler sa th 802.15.4 nga trapiko, ngadto sa taas nga prayoridad sa 16. Busa human sa pagtugot sa 802.15.4 protocol access sa radyo sa sinugdanan, ang Bluetooth mokuha. prayoridad sa sunod nga pagsulay pag-usab kon gikinahanglan.

Kini nga pamaagi nagtugot sa duha ka protocol sa pagkompromiso sa ilang paggamit sa radyo nga walay usa nga makahimo sa hingpit nga pagdominar sa lain.

. Pagpatuman sa Multiprotocol uban sa RAIL

Kini nga kapitulo nagtanyag og dugang nga impormasyon mahitungod sa mga partikularidad sa RAIL alang sa mga tiggamit nga direktang mogamit sa RAIL API aron makahimo og proprietary nga mga protocol. Sa partikular nagtanyag kini mga detalye kung giunsa ang pagtrabaho kauban ang mga RAIL API aron madumala ang piho nga mga kaso sa scheduler sa radyo.

Examples uban sa Background Receive, Yield Radio ug State Transition

Ang mga sukaranan sa RAIL Multiprotocol priority system medyo prangka: ang usa ka panghitabo sa radyo nga adunay mas taas nga prayoridad (sa ato pa, gamay ang gidaghanon) kanunay nga mag-agaw sa bisan unsang ubang mga panghitabo sa radyo nga adunay gamay nga prayoridad. Bisan pa, kini nga hilisgutan mahimong labi ka komplikado kung gikonsiderar ang mga transisyon sa estado ug mga API sama sa RAIL_StartRx(), nga nagbutang sa radyo sa usa ka piho nga kahimtang sa usa ka dili tino nga gidugayon sa oras. Kini nga seksyon naghatag pipila ka mga ilustrasyon sa usa ka examples aron ipakita kung giunsa pagdumala ang mga estado nga wala’y limitasyon sa oras, ug kung giunsa magamit sa layer sa aplikasyon ang mga API sama sa RAIL_YieldRadio () aron makontrol kini. Ang examples mao ang mosunod:

Mga Transisyon sa Estado nga adunay Usa ka Protokol
Mga Transisyon sa Estado nga adunay Duha ka Protokol
Mga Transisyon sa Estado nga adunay Duha ka Protokol ug Monotonically Nagdugang nga mga Priyoridad

Sa mga examples, RAIL_StartTx() mao ang tinubdan sa TX nga panghitabo nga makabalda sa background RX. Hinumdomi, bisan pa, nga kini nga mga exampang mga magamit sa bisan unsang radio API gawas sa RAIL_StartRx(). Sa laing pagkasulti, ang exampang mga magamit sa bisan unsang API nga nagsugod sa usa ka panghitabo sa radyo nga dili background RX

Kini nga mga exampnga naghulagway sa gipaabot nga multiprotocol nga kinaiya mahitungod sa mga pagbalhin sa estado. Sa pag-summarize:

Sa usa ka transisyon sa estado, ang bag-ong estado giisip nga usa ka dili tino nga extension sa gigikanan nga panghitabo sa parehas nga prayoridad hangtod nga gitawag ang RAIL_YieldRadio ().

Ang mga panghitabo sa background RX dili apektado sa RAIL_YieldRadio(). RAIL_Idle() ra ang permanenteng makatangtang sa usa ka protocol gikan sa background nga RX state.
Ang usa ka panghitabo nga adunay mas taas nga prayoridad kanunay nga mag-agaw sa usa ka panghitabo nga adunay ubos nga prayoridad, bisan unsa pa ang ubang mga tawag sa API.
Ang RAIL_StartRx() ra ang makadawat mahimong 'ibalik sa' gikan sa mas taas nga priority nga panghitabo pinaagi sa RAIL_YieldRadio() o RAIL_Idle().

Ang tanan nga mga panghitabo sa radyo gawas sa RAIL_StartRx() nanginahanglan RAIL_YieldRadio() aron matapos ug mouswag sa sunod nga panghitabo.
Ang tawag sa RAIL_YieldRadio() dili mapulihan sa RAIL_Idle(). Ang RAIL_Idle() nagwagtang sa tanang panghitabo alang sa gihatag nga protocol

.Mga Transisyon sa Estado nga adunay Usa ka Protokol

Kaning una nga exampGisusi sa le ang pamatasan sa radyo nga adunay usa ka protocol (nga mao, kung diin ang parehas nga AIL_Handle_t gigamit alang sa tanan nga mga tawag sa function sa radyo). Ang radyo magsugod sa RX nga adunay inisyal nga tawag sa RAIL_StartRx(), unya mobalhin sa TX nga adunay mas taas nga priority nga tawag sa RAIL_StartTx(). Mahinungdanon nga timan-an nga pagkahuman mahuman ang pagpadala, ang mga transisyon sa radyo sa estado nga gitakda sa RAIL_SetTxTransitions (), ug kini magpabilin sa estado hangtod sa hangtod sa parehas nga prayoridad ug channel sama sa TX hangtod gitawag ang RAIL_YieldRadio (). Pagkahuman niana, ang radyo mobalik sa RX, nga adunay una nga gipiho nga prayoridad ug channel.

Ang panginahanglan sa aktibong paghatag sa radyo, ug busa ang RAIL_YieldRadio() API kay gikinahanglan tungod sa ACK'ing. Ang pilosopiya sa disenyo mao kana, tungod kay ang usa ka TX ug usa ka nadawat nga ACK mao viewed isip bahin sa parehas nga transaksyon, kung ang usa ka node nagpadala ug nagpaabut sa usa ka ACK kinahanglan kini nga pareho nga pagbalhin sa RX ug magpadayon sa pagpaminaw sa ACK ingon bahin sa parehas nga operasyon (ug busa parehas nga prayoridad) ingon ang orihinal nga TX. Sa kinatibuk-an, bisan pa, ang RAIL sa iyang kaugalingon dili mahibal-an kung gikinahanglan o dili ang ACK. Mahimong magdepende kini sa ubang mga hinungdan, sama sa mga sulud sa pakete, o uban pang lohika sa aplikasyon, ug busa dili yano nga matino pinaagi sa pagsusi kung ang ACK'ing na-configure ba sa RAIL_ConfigAutoAck(). tication/stack.

Sa kaso nga dili gikinahanglan ang ACK, girekomenda sa Silicon Labs ang pagtawag sa RAIL_YieldRadio() isip kabahin sa pagdumala sa RAIL_EVENT_TX_PACKET_SENT nga panghitabo. Ang pagbuhat niini hinungdan nga ang berde nga linya sa ibabaw nga numero maminusan hangtod sa interrupt latency nga oras. Kung ang aplikasyon nagpaabut sa usa ka ACK, ang RAIL_YieldRadio() kinahanglan nga tawagan kung ang ACK madawat o giisip nga wala na.

Mga Transisyon sa Estado nga adunay Duha ka Protokol

Kini nga senaryo susama sa unang senaryo mahitungod sa mga transisyon sa estado human sa TX, apan nagpaila sa laing protocol.

Niini nga sitwasyon, importante nga matikdan nga ang RAIL_StartRx() mahimong tawgon bisan unsang orasa atol sa transaksyon sa TX. Hangtud nga ang prayoridad niini ubos pa o katumbas sa prayoridad sa TX, ang RX dili ma-epekto hangtud nga ang aplikasyon motawag sa _Yield Radio() sa Protocol A. Kung ang RAIL_StartRx() gitawag sa panahon sa TX, ang RX kay gidugang sa pila sa mga panghitabo nga dumalahon.

Ang laing importanteng punto mao nga, bisan tuod ang RAIL_YieldRadio() sa Protocol A mobalhin gikan sa TX sa Protocol A ngadto sa RX sa Protocol B, ang RAIL_Idle() sa Protocol B gikinahanglan nga mobalhin gikan sa RX sa Protocol B ngadto sa RX sa Protocol A. Ang pilosopiya dinhi mao nga ang mga Background RX dili gyud mahatag, tungod kay ang panghitabo dili gyud matapos. Ang bugtong paagi sa paggawas mao ang pagpahunong sa Background RX sa usa ka tawag sa RAIL_Idle().

Mga Transisyon sa Estado nga adunay Duha ka Protocol ug Monotonically Increasing Priority

Ang kataposang senaryo halos parehas sa nauna, gawas sa tawag sa RAIL_StartRx() sa Protocol B kay mas taas nga prayoridad kay sa tawag sa RAIL_StartTx() sa Protocol A.

Niini nga kaso, tungod kay ang prayoridad sa ikaduha nga RAIL_StartRx() mas taas kay sa prayoridad sa tawag sa RAIL_StartTx(), ang tawag sa RAIL_YieldRadio() dili na kinahanglan. Tungod kay ang ikaduha nga RAIL_StartRx() naa sa mas taas nga prayoridad, kini nag-ilog sa RAIL_StartTx() nga panghitabo, nagkontrolar sa radyo ug nagtangtang sa TX nga panghitabo gikan sa estado. Bisan unsang orasa sa RX sa Protocol B, ang RAIL_Idle() mahimong tawagan aron mobalik sa RX sa Protocol A, sama sa miaging ex.ample.

Timan-i dinhi, nga kung ang aplikasyon nagtawag sa RAIL_Idle() sa Protocol B's RX, ang aplikasyon dili mobalik sa TX Transition sa Protocol A. Hinunoa, kini moadto mismo sa background nga RX, bisan kung ang aplikasyon wala gayud gitawag nga RAIL_Idle() sa Protocol TX ni A. Alang sa Naka-iskedyul nga mga operasyon sa radyo (nga mao, bisan unsang operasyon sa radyo nga gisugdan sa usa ka API gawas sa RAIL_StartRx()), sa higayon nga ang usa ka panghitabo sa radyo makuha sa usa ka mas taas nga prayoridad nga panghitabo, kini hingpit nga tangtangon ug dili na ibalik sa ulahi. Ang Background ra ang makadawat, gisugdan sa RAIL_StartRx(), mahimong mamentinar sa thackground ug 'ibalik sa' pinaagi sa tawag sa RAIL_YieldRadio() o RAIL_Idle().

Aron mahatagan og gibug-aton ang kalainan tali sa RAIL_YieldRadio() ug RAIL_Idle() importante nga timan-an nga, alang sa tanan niini nga examples, ang tawag sa RAIL_YieldRadio() dili mapulihan sa RAIL_Idle(). Ang RAIL_Idle() nagwagtang sa tanang panghitabo alang sa gihatag nga protocol - ang Background (nga mao, gisugdan sa RAIL_StartRx()) ug Scheduled (nga mao, gisugdan sa mga API gawas sa RAIL_StartRx()) nga mga operasyon. Ang RAIL_Idle() makahimo gihapon sa aplikasyon sa paggawas gikan sa TX transition state, apan kini usab magwagtang sa Background RX, hinungdan nga ang aplikasyon mobalik sa idle, dili RX.

Pagpatuman sa Multiprotocol nga adunay Bluetooth

Para sa mga detalye kung giunsa ang RAIL/Bluetooth nga suga/switch multiprotocol example gipatuman, ug alang sa dugang nga impormasyon sa pagpalambo sa usa ka multiprotocol nga aplikasyon uban sa imong kaugalingong protocol sa RAIL, tan-awa ang AN1134: Dynamic Multiprotocol Development uban sa Bluetooth ug Proprietary Protocols sa RAIL sa GSDK v2.x o AN1269 Dynamic Multiprotocol Development uban sa Bluetooth ug Proprietary Protocols sa RAIL sa GSDK v3.x ug Higher.

Mga Priyoridad sa Bluetooth

Sukwahi sa Zigbee nga adunay estatikong gihubit nga mga prayoridad alang sa lain-laing mga matang sa operasyon, ang Bluetooth naggamit sa usa ka range ug offset nga pamaagi aron sa pag-assign sa tanang mga buluhaton sa usa ka gihatag nga lugar sa priority spectrum.

Niining exampAng Bluetooth priority range, nga mismo nagsangkad gikan sa 0 hangtod 255, gimapa sa limitado nga bahin sa gipaambit nga RAIL priority space.

Dili sama sa Zigbee, ang Bluetooth adunay mas estrikto nga mga kinahanglanon sa timing diin ang pagkawala sa gihatag nga slot mahimong moresulta sa pagtapos sa koneksyon. Usab ang Bluetooth adunay lain-laing mga buluhaton sama sa (potensyal nga daghang) koneksyon, advertisement, scanning, ug Periodic Advertising with Responses (PAwR) transmissions ug receptions.

Talaan 6.1. Nagkalainlain nga mga Priyoridad sa Bluetooth

1	Koneksyon	135 hangtod 0	Natapos ang Hitabo sa Koneksyon
2	Pagsugod sa Koneksyon	55 hangtod 15	Natapos ang Window sa Pagsugod
3	Advertisement	175 hangtod 127	Natapos ang Hitabo sa Advertisement
4	Scanner	191 hangtod 143	Natapos ang Scan Window
5	PAwR TX	15 hangtod 5	Advertiser: PAwR Response Slot Delay Ends Synchronizer: PAwR Response Slot Ends
6	PAwR RX	20 hangtod 10	Advertiser: Ang PAwR Response Slot Ends Synchronizer: PAwR Response Slot Delay Ends

Aron madumala kini ang Bluetooth scheduler, kansang mga prayoridad gimapa sa RAIL radio scheduler, gikonsiderar ang mosunod nga mga parameter alang sa matag buluhaton:

Panahon sa Pagsugod
Minimum nga oras
Maximum nga oras
Prayoridad

Kung ang oras sa pagsugod gibalhin ang kinatibuk-ang oras sa pagdagan maminusan, kana ang paghinay nga pagkunhod. Usab ang mga prayoridad mahimong dinamikong ipasibo.

Mga koneksyon

Ang mga koneksyon adunay medyo taas nga prayoridad. Ang oras sa pagsugod sa usa ka koneksyon dili mabalhin.

Ang prayoridad mao ang dinamikong gidugangan sa Bluetooth scheduler sa mas duol sa koneksyon makuha sa supervision timeout, ug pagkab-ot sa pinakataas nga prayoridad nga duol niini. Usa ka TX packet sa TX queue usab nagdugang sa prayoridad sa usa ka koneksyon.

Pagsugod sa Koneksyon

Ang pagsugod sa koneksyon nag-scan sa mga paanunsiyo gikan sa target nga aparato aron magtukod usa ka koneksyon. Kini adunay mas taas nga prayoridad kumpara sa usa ka scanner aron tugotan ang mas lig-on nga pagtukod sa koneksyon.

Mga paanunsiyo

Ang mga paanunsiyo sa default adunay gamay nga prayoridad ug ang ilang pagsugod nga punto mahimong mabalhin. Ang oras sa pagsugod ug Maximum nga oras gihubit sa agwat sa ad.

Kung ang usa ka paanunsiyo dili mapadala, ang prayoridad sa mga paanunsyo hinayhinay nga motaas ug i-reset pagbalik sa higayon nga ang usa ka paanunsyo malampuson nga gipadala.

Scanner

Sa kasagaran, kini nga mga buluhaton adunay labing ubos nga prayoridad. Ang pagsugod, minimum ug maximum nga oras gihubit pinaagi sa agwat sa pag-scan ug gidak-on sa bintana. Ang pag-scan mahimong magpadayon bisan kung mabalda sa usa ka mas taas nga prayoridad nga buluhaton. Kung mahitabo kini ang oras sa pag-scan matipon aron masiguro nga ang gitinguha nga gidak-on sa bintana sa pag-scan maabot sa matag agwat sa pag-scan.

Sama sa mga paanunsiyo ang prayoridad madugangan kung ang gitinguha nga agwat sa pag-scan o gidak-on sa bintana dili maabut kaniadto. I-reset kini balik sa inisyal nga prayoridad sa higayon nga ang scan interval o gidak-on sa bintana nahimamat.

Periodic Advertising with Responses (PAwR)

Ang pagpadala sa Periodic Advertising nga adunay mga Tubag adunay pinakataas nga prayoridad pinaagi sa default sa tanan nga uban pang mga buluhaton sa Bluetooth, gisundan sa pagdawat mga tubag sa PAwR aron mapadayon ang pag-synchronize sa usa ka network sa electronic shelf label (ESL).

Ang usa ka prayoridad sa buluhaton sa PAwR madugangan kung ang pag-iskedyul sa buluhaton mapakyas kaduha sa usa ka laray. Ang priority madugangan ug 1/6th sa priority range, o labing menos usa hangtod maabot ang maximum priority. Ang prayoridad sa buluhaton gi-reset balik sa minimum pagkahuman sa malampuson nga pag-iskedyul. Ang sama nga pamaagi magamit sa PAwR advertiser ug synchronizer sa duha ka direksyon

Example sa Bluetooth Scheduler Operation

Kini nga exampGiilustrar niini kon sa unsang paagi ang Bluetooth scheduler mag-iskedyul ug tulo ka buluhaton sa koneksyon ug usa ka buluhaton sa pag-advertise, ang matag usa adunay lain-laing mga prayoridad. Sa mosunod nga mga numero ang gray nga bahin nagpaila sa minimum nga runtime nga gikinahanglan sa usa ka buluhaton ug ang asul nga bahin nagpaila sa pinakataas nga runtime nga magamit sa buluhaton ug, kon flexible, ang rehiyon diin ang buluhaton mahimong ibalhin. Ang mosunod nga numero nagpakita sa inisyal nga setup

Sama sa gipakita sa ubos ang Conn1 mao ang una nga buluhaton nga gipadagan tungod kay wala kini nagsapaw sa bisan unsang mas taas nga prayoridad nga buluhaton.

Ang Adv1 nagsapaw sa mas taas nga prayoridad nga Conn2. Ang Adv1 kay flexible ug busa gibalhin ingon sa gihulagway sa mosunod nga numero.

Ang Conn2 nagsapaw sa mas taas nga prayoridad nga buluhaton Conn4. Ingon nga ang Conn2 dili flexible ang pag-iskedyul sa Conn2 napakyas.

Ang Conn4 dili magsapaw sa ubang mga buluhaton, busa ang katapusan sa Conn1 gipasibo aron mohunong sa dili pa magsugod ang Conn4.

Pag-usab sa mga Priyoridad

Ang "sl_bt_configuration_t" (v3.x)/"gecko_configuration_t" (v2.x) struct naghubit sa sl_bt_stack_config_t struct, nga naglangkob sa field "bluetooth.linklayer_priorities" nga usa ka pointer sa priority configuration. Kung ang pointer NULL nan ang stack naggamit sa mga default nga prayoridad sama sa gilista sa seksyon 6.1 Bluetooth Priorities sa ibabaw ingon man kini nga seksyon.

Kung ang pointer dili null kinahanglan nga itudlo kini sa usa ka istruktura sa mga setting sa prayoridad nga gipasabut sa ubos:

Ang mga parametro nga sandman, Cinemax, adv_min, adv_min, cinnamon, conn_max, intimin ug intima naghubit sa minimum ug maximum nga mga prayoridad alang sa pag-scan, advertisement, koneksyon, ug initiation matag usa. Ang mga prayoridad molihok tali sa min ug max nga mga utlanan sama sa gihulagway sa mga seksyon 6.1.1 Koneksyon sa 6.1.4 Scanner sa ibabaw.

Ang RAIL mapping parameters, rail_mapping_offset ug rail_mapping_range, naghubit kung giunsa ang mga prayoridad sa Bluetooth link layer gimapa ngadto sa global RAIL radio scheduler priorities. Ang pagmapa niini nga mga bili makita sa 6.1 Bluetooth Priorities. Ang default para sa rail_mapping_offset ug rail_mapping_range kay 16.

Ang adv_step ug scan nga mga parametro sa lakang naghubit sa gidak-on sa lakang kung ang prayoridad sa pag-scan ug pag-anunsiyo mausab sa dinamikong paagi. Sa kataposan, ang mga parameter nga pawr_tx_min, pawr_tx_min, pawr_tx_min, ug pawr_rx_max naghubit sa priority range para sa Par advertiser ug synchronizer TX ug RX nga mga panghitabo sa matag subevent.

IoT Portfolio
www.silabs.com/products

Kalidad
www.silabs.com/quality

Suporta ug Komunidad
www.silabs.com/community

Disclaimer

Gitinguha sa Silicon Labs nga mahatagan ang mga kostumer sa labing bag-o, tukma, ug lawom nga dokumentasyon sa tanan nga mga peripheral ug module nga magamit alang sa mga tigpatuman sa sistema ug software nga naggamit o nagtinguha nga gamiton ang mga produkto sa Silicon Labs. Ang datos sa pag-ila, anaa nga mga module ug peripheral, mga gidak-on sa memorya ug mga address sa memorya nagtumong sa matag usa
espesipikong device, ug "Typical" nga mga parameter nga gihatag mahimo ug magkalainlain sa lainlaing mga aplikasyon. Aplikasyon exampAng mga gihulagway dinhi alang lamang sa mga katuyoan sa paghulagway. Ang Silicon Labs adunay katungod sa paghimo sa mga pagbag-o nga wala’y dugang nga pahibalo sa impormasyon sa produkto, mga detalye, ug mga paghulagway dinhi, ug wala maghatag mga garantiya sa katukma o pagkakompleto sa gilakip nga kasayuran. Kung walay una nga pahibalo, ang Silicon Labs mahimong mag-update sa firmware sa produkto sa panahon sa proseso sa paghimo alang sa seguridad o kasaligan nga mga hinungdan. Ang ingon nga mga pagbag-o dili magbag-o sa mga detalye o ang pasundayag sa produkto. Ang Silicon Labs walay tulubagon sa mga sangputanan sa paggamit sa impormasyon nga gihatag niini nga dokumento. Kini nga dokumento wala magpasabot o dayag nga paghatag og bisan unsang lisensya sa pagdesinyo o paghimo sa bisan unsang integrated circuits. Ang mga produkto wala gidesinyo o gitugutan nga gamiton sulod sa bisan unsang FDA Class III device, mga aplikasyon diin gikinahanglan ang pag-apruba sa premarket sa FDA o Life Support Systems nga walay espesipikong sinulat nga pagtugot sa Silicon Labs. Ang "Sistema sa Pagsuporta sa Kinabuhi" mao ang bisan unsang produkto o sistema nga gituyo aron suportahan o mapadayon ang kinabuhi ug/o kahimsog, nga, kung kini mapakyas, makatarunganon nga gilauman nga moresulta sa daghang personal nga kadaot o kamatayon. Ang mga produkto sa Silicon Labs wala gidesinyo o gitugutan alang sa mga aplikasyon sa militar. Ang mga produkto sa Silicon Labs sa bisan unsang kahimtang dili magamit sa mga hinagiban sa dinaghang paglaglag lakip (apan dili limitado sa) nukleyar, biolohikal o kemikal nga mga hinagiban, o mga misil nga makahimo sa paghatud sa ingon nga mga hinagiban. Gisalikway sa Silicon Labs ang tanan nga gipahayag ug gipasabut nga mga garantiya ug dili responsable o manubag sa bisan unsang mga kadaot o kadaot nga may kalabotan sa paggamit sa usa ka produkto sa Silicon Labs sa ingon nga dili awtorisado nga mga aplikasyon. Mubo nga sulat: Kini nga sulod mahimong adunay mga makapasakit nga terminolohiya nga dili na magamit. Ang Silicon Labs nag-ilis niini nga mga termino sa inklusibo nga pinulongan kung mahimo. Para sa dugang nga impormasyon, bisitaha ang www.silabs.com/about-us/inclusive-lexicon-project

Impormasyon sa Trademark
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® ug ang Silicon Labs logo®, Blueridge®, Blueridge Logo®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro logo ug mga kombinasyon niini , "ang labing kusog nga micro controllers sa kalibutan", Repine Signals®, Disconnect , n-Link, Thread Arch®, Elin®, EZRadioPRO®, EZRadioPRO®, Tuko®, Gecko OS, Gecko OS Studio, Precision32®, Simplicity Studio® , Telegenic, ang Telegenic Logo®, Suppress® , Sentry, ang Sentry logo ug Zentri DMS, Z-Wave®, ug uban pa kay mga marka sa pamatigayon o rehistradong tatak sa Silicon Labs. Ang ARM, CORTEX, Cortex-M3 ug THUMB maoy mga marka sa pamatigayon o rehistradong marka sa pamatigayon sa ARM Holdings. Ang Keli usa ka rehistradong marka sa pamatigayon sa ARM Limited. Ang Wi-Fi kay rehistrado nga marka sa Wi-Fi Alliance. Ang tanan nga uban pang mga produkto o mga ngalan sa tatak nga gihisgutan dinhi mga marka sa pamatigayon sa ilang tagsa-tagsa nga gihuptan