SILICON LABS UG305 Dynamic Multiprotocol User Guide

Pambuka

Dokumen iki nerangake carane piranti lunak Silicon Labs dirancang kanggo digunakake dening sawetara protokol ing chip nirkabel siji. Multiprotocol dinamis ngiris wektu radio lan ngganti konfigurasi kanthi cepet kanggo ngaktifake protokol nirkabel sing beda-beda supaya bisa digunakake kanthi andal ing wektu sing padha.

Cathetan: Informasi khusus Zigbee ing dokumen iki ditrapake kanggo versi 6.10.x lan ngisor.
Rincian babagan implementasi multiprotokol dinamis tartamtu diwenehake ing cathetan aplikasi ing ngisor iki:
AN1133: Pangembangan Multiprotokol Dinamis nganggo Bluetooth lan Zigbee EmberZNet SDK 6.x lan Ngisor
AN1134: Pangembangan Multiprotokol Dinamis kanthi Bluetooth lan Protokol Proprietary ing RAIL ing GSDK v2.x
AN1269: Pangembangan Multiprotokol Dinamis kanthi Bluetooth® lan Protokol Kepemilikan ing RAIL ing GSDK v3.x lan luwih dhuwur
AN1209: Pangembangan Multiprotokol Dinamis kanthi Bluetooth lan Sambungake
AN1265: Pangembangan Multiprotokol Dinamis nganggo Bluetooth® lan OpenThread ing GSDK v3.x

Terminologi

Ing ngisor iki dhaptar sawetara terminologi khusus kanggo implementasi multiprotocol dinamis

Lapisan Antarmuka Abstraksi Radio (RAIL): API umum sing kode tingkat sing luwih dhuwur entuk akses menyang radio EFR32.

Operasi Radio: A tumindak tartamtu kanggo dijadwal. Operasi radio nduweni konfigurasi radio lan prioritas. Saben tumpukan bisa njaluk supaya panjadwal radio nindakake nganti rong operasi radio (latar mburi nampa lan salah siji Dijadwal Nampa utawa Dijadwal.

• Latar mburi Nampa: Nampa terus-terusan, dimaksudaké kanggo diselani dening operasi Jadwal, lan bali menyang sawise completion.
• Dijadwal Nampa: Nampa paket utawa ngetung RSSI ing wektu lan durasi tartamtu. (Pengembang nggarap RAIL, elinga yen ing babagan API RAIL, "Nampa Terjadwal" sing digunakake ing dokumen iki nuduhake operasi nampa apa wae, kajaba RAIL_StartRx, lan ora mung winates ing ruang lingkup RAIL_ScheduleRx.)
• Jadwal Transmit: Sembarang salah siji saka macem-macem operasi ngirim kalebu ngirim langsung, dijadwal (masa depan) ngirim, utawa CCAdependent ngirim. (Pengembang nggarap RAIL, elinga yen ing babagan API RAIL, "Transmit Terjadwal" sing digunakake ing dokumen iki nuduhake operasi ngirim apa wae, lan ora diwatesi ing ruang lingkup RAIL_StartScheduledTx.

Radio Config: Nemtokake kahanan hardware sing kudu digunakake kanggo nindakake operasi radio.

Panjadwal Radio: komponen RAIL sing arbitrates antarane protokol beda kanggo nemtokake kang bakal duwe akses kanggo radio.

Prioritas: Saben operasi saka saben tumpukan nduweni prioritas gawan. Aplikasi bisa ngganti prioritas standar.

Wektu Slip: Wektu maksimum ing mangsa nalika operasi bisa diwiwiti yen ora bisa miwiti ing wektu wiwitan dijaluk.

ngasilaken: A tumpukan kudu tanpo pekso ngasilaken ing mburi operasi utawa urutan operasi, kajaba iku nindakake latar mburi nampa. Nganti tumpukan ngasilake, panjadwal ora bakal nggawe jadwal tugas prioritas sing luwih murah

RTOS (Real Time Operating System) Kernel: Bagéyan saka sistem operasi sing tanggung jawab kanggo manajemen tugas, lan komunikasi intertask lan sinkronisasi. Implementasi iki nggunakake kernel Micrium OS-5.

Arsitektur

Dynamic Multiprotocol nggunakake hardware EFR32 lan piranti lunak RAIL minangka blok bangunan. Zigbee, Bluetooth, lan/utawa protokol basis standar utawa kepemilikan liyane banjur bisa dibangun ing ndhuwur lapisan undasional kasebut, nggunakake Micrium kanggo ngatur eksekusi kode ing antarane protokol sing beda-beda. Diagram ing ngisor iki nggambarake struktur umum modul piranti lunak.

 

Diwiwiti karo versi 2.0, RAIL mbutuhake liwat gagang konfigurasi radio kanggo telpon API RAIL. Konfigurasi iki nggambarake macem-macem parameter PHY sing digunakake dening tumpukan

Micrium OS minangka RTOS sing ngidini tumpukan lan logika aplikasi nuduhake wektu eksekusi CPU.

Penjadwal Radio minangka perpustakaan piranti lunak sing kanthi cerdas mangsuli panjalukan saka tumpukan kanggo nindakake operasi radio kanggo ngoptimalake linuwih lan nyilikake latensi. API diwenehake dening RAIL sing ora melu radio ngliwati panjadwal Radio.

Inti RAIL ngatur hardware EFR32 kanggo nanggepi instruksi saka panjadwal radio.

Gambar Firmware Tunggal

Dynamic Multiprotocol ngidini pangembang piranti lunak ngasilake binar monolitik tunggal sing dimuat ing EFR32. Nganyari piranti lunak ditindakake kanthi nganyarke kabeh binar. Iki wis rampung nggunakake Geck otloader, rincian sing bisa ditemokaké ing UG266: Silicon Labs Gecko Bootloader Pandhuan Pangguna kanggo GSDK 3.2 lan Lower lan UG489: Silicon LabsGecko Bootloader Pandhuan pangguna kanggo GSDK 4.0 lan luwih dhuwur.

Operasi Tumpukan Independen

Tumpukan Silicon Labs isih bisa digunakake kanthi mandiri ing kahanan Multiprotocol Dinamis. Operasi radio sing umur dawa tartamtu bakal duwe pengaruh marang latensi protokol liyane lan operasi sing tundhuk. Iku nganti aplikasi kanggo nemtokake pertimbangan khusus kanggo acara kasebut. Waca bagean 2. Radio Scheduler kanggo informasi luwih lengkap.

Penjadwal Radio

Radio Scheduler minangka komponèn saka RAIL (Radio Abstraction Interface Layer). RAIL nyedhiyakake lapisan antarmuka radio lan API sing intuisi lan gampang disesuaikan, sing ndhukung protokol nirkabel adhedhasar utawa standar. Penjadwal Radio dirancang kanggo ngidini operasi radio sing bisa dijadwal lan diprioritasake. Operasi radio sing beda-beda ing saben protokol bisa uga kurang penting, utawa luwih utawa kurang sensitif wektu, gumantung saka kahanan. Penjadwal bisa nimbang-nimbang nalika nggawe keputusan babagan konflik lan cara ngadili

Kajaba sampeyan ngembangake aplikasi kanthi protokol khusus ing RAIL, umume fungsi panjadwal radio ditangani kanthi otomatis kanthi dhasar tumpukan lan kode RAIL. Sampeyan mung kudu nggunakake tumpukan liwat API normal sawijining.

Ing tingkat dhuwur, tumpukan ngirim operasi radio (kanggo example a Dijadwal Nampa utawa Dijadwal Kirim). Operasi radio yaiku
antrian banjur dilayani ing mangsa ngarep adhedhasar paramèteré. Nalika wektu kanggo miwiti operasi radio, panjadwal mriksa apa ana acara saingan lan apa operasi bisa ditundha utawa ora. Yen panjadwal ora bisa mbukak acara bakal ngasilake asil menyang lapisan sing luwih dhuwur, sing bisa nyoba maneh nganggo paramèter anyar.

Sawise operasi radio diwiwiti, tumpukan sing cocog bisa ngirim operasi tambahan panjadwal adhedhasar asil operasi sadurunge (kanggo ex.ampngenteni ACK). Ing pungkasan saben operasi utawa urutan operasi, tumpukan kudu nggunakake radio.

Operasi Radio

Saben acara ing panjadwal dipérang dadi unsur sing disebut Operasi Radio, sing digandhengake karo konfigurasi radio lan prioritas.

Saben operasi duwe prioritas lan diselani yen panjadwal nampa operasi prioritas luwih sing tumpang tindih ing wektu. Operasi radio prioritas sing luwih murah sing ora bisa ditindakake adhedhasar paramèter jadwal bakal gagal, lan gumantung saka tumpukan kanggo nyoba maneh. Sawise panjadwal aktif mbukak operasi radio saka tumpukan, tumpukan bisa terus ngirim operasi radio tambahan nganti tanpo pekso, utawa nganti panjadwal nampa operasi radio prioritas luwih lan preempts.

• Latar mburi Nampa
• Dijadwal Nampa
• Transmisi sing dijadwalake

Saben tumpukan bisa njaluk Penjadwal Radio nindakake nganti rong operasi radio (latar mburi nampa lan salah siji Dijadwal Nampa utawa Dijadwal ngirim) ing wektu:

Saben operasi nduweni paramèter ing ngisor iki:

Wektu Mulai	Pratondo ing titik apa ing mangsa operasi radio iki bakal mbukak. Iki bisa uga "mlaku saiki" utawa sawetara nilai ing mikrodetik ing mangsa ngarep.
Prioritas	Nomer sing nuduhake prioritas relatif saka operasi. Nalika nggunakake setelan gawan, operasi radio Bluetooth LE meh tansah dadi prioritas sing luwih dhuwur tinimbang operasi Zigbee.
Wektu Slip	Jumlah wektu sing acara bisa telat ngluwihi wektu wiwitan lan isih bisa ditrima kanggo tumpukan. Iki bisa uga 0, lan acara kasebut ora bisa diluncurake.
Wektu Transaksi	Jumlah kira-kira wektu sing dibutuhake kanggo ngrampungake transaksi. Acara ngirim biasane duwe wektu transaksi sing luwih jelas, dene acara nampa asring ora dingerteni. Iki digunakake kanggo mbantu panjadwal radio nemtokake manawa acara bisa ditindakake.

Tumpukan kasebut nemtokake macem-macem paramèter sing cocog karo operasi sing ditindakake. Kanggo example, acara sambungan Bluetooth aroften dijadwal ing mangsa lan wis ora slip diijini, déné Zigbee ngirim acara asring bisa telat jumlah cilik lan lintang mengko.

Saka perspektif saka RAIL Radio Scheduler, Jadwal ngirim lan Dijadwal nampa identik. Loro-lorone mung operasi sing mbutuhake radio, mula ora bisa dieksekusi bebarengan. Bedane mung katon ing lapisan API RAIL, ing ngendi TX utawa RX API diarani.

Latar mburi Nampa

Iki minangka mode nampa terus-terusan sing dimaksudake kanggo diselani dening operasi liyane, lan bali menyang sawise rampung. Yen Background Receive luwih prioritas tinimbang operasi liyane, operasi radio kasebut ora bakal dicekel lan ora bakal mlaku. Terserah tumpukan utawa aplikasi kanggo ngganti prioritas utawa ngasilake kanthi sukarela. Waca bagean 5.1 Examples karo Background Nampa, Ngasilake Radio lan Transisi Negara kanggo examples carane Background nampa sesambungan karo operasi Dijadwal.

cheduled Nampa

Iki minangka panampa ing mangsa ngarep kanthi durasi sing ditemtokake. Panjadwal radio bakal nimbang wektu ngoper radio kanggo nemtokake manawa operasi bakal dijadwalake. Yen ora bisa dijadwal, panjadwal ngirim acara gagal menyang tumpukan panggilan. Operasi radio kanthi otomatis ditambah nganti tumpukan kanthi sukarela ngasilake, utawa panjadwal nampa operasi prioritas sing luwih dhuwur lan ngganggu. Ngluwihi nampa ngidini tumpukan kanggo terus operasi radio adhedhasar syarat protokol tingkat sing luwih dhuwur, kanggo Example transmisi respon adhedhasar data ditampa.

Transmisi sing dijadwalake

Iki minangka transmisi ing wektu sing bakal teka kanthi durasi minimal. Durasi minimal iki bisa kalebu acara tindakake sing dikarepake, contoneample lan ACK menyang IEEE 802.15.4 ngirimaken. Nanging, wektu minimal kanggo operasi iki ora kudu kalebu acara sing ora dikarepke sing bisa ngluwihi wektu ngluwihi durasi minimal, kanggo ex.amplackoffs amarga gagal CCA ing IEEE 802.15.4. Panjadwal radio nimbang wektu ngoper radio kanggo nemtokake manawa operasi bakal dijadwal utawa ora. Yen ora bisa dijadwal, panjadwal ngirim acara gagal menyang tumpukan panggilan.

Konfigurasi Radio

Saben operasi radio digandhengake karo konfigurasi radio sing wis ditemtokake sing nemtokake kahanan hardware sing kudu digunakake kanggo nindakake operasi kasebut. Radio Configs nglacak status tumpukan saiki supaya operasi radio ing mangsa ngarep bakal nggunakake paramèter radio sing padha. Konfigurasi Radio bisa uga aktif utawa ora aktif. Yen tumpukan ngganti Konfigurasi Radio sing aktif banjur RAIL nggawe owah-owahan langsung menyang konfigurasi hardware uga, kanggo example ngganti saluran. Yen konfigurasi radio saiki ora aktif, operasi radio sing dijadwal sabanjure bakal nggunakake konfigurasi radio anyar.

Prioritas

Saben operasi radio nduweni prioritas sing nuduhake menyang panjadwal operasi sing kudu ditindakake yen ana tumpang tindih wektu ing antarane sawetara operasi. Penjadwal nganggep prioritas 0 minangka prioritas paling dhuwur lan 255 minangka prioritas paling murah. Panjadwal radio bakal ngidini tugas karo prioritas paling kanggo ngakses ra rdware fisik. Kanthi umume kontrol tugas bali menyang panjadwal radio mung sawise rampung, nanging tugas kaya latar mburi ditampa bakal diselani yen tugas kanthi prioritas luwih aktif aktif.

Tumpukan kasebut duwe prioritas standar adhedhasar analisis Silicon Labs babagan cara kerja sama paling apik kanggo nggedhekake siklus tugas lan ngindhari sambungan sing mandheg kanggo kasus panggunaan umum. Kasus panggunaan tartamtu bisa uga duwe kabutuhan sing beda. Prioritas kaya ing ngisor iki, saka sing paling dhuwur nganti paling ngisor

1.  Bluetooth LE Dijadwal Transmit
2.  Bluetooth LE Dijadwal Nampa
3.  Protokol liyane Jadwal Transmit
4.  Latar mburi protokol liyane Nampa

Prioritas kasebut bisa diganti utawa diganti dening aplikasi. Iku nganti aplikasi kanggo mutusaké ing kahanan apa kanggo ngganti. Bagean 4.2 802.15.4 Prioritas RAIL lan bagean 6.1 Prioritas Bluetooth ngemot rincian liyane babagan prioritas kanggo kedadeyan tartamtu.

Wektu Slip

Saben operasi radio kudu "slip wektu", utawa wektu wiwitan maksimum, tegese wektu paling adoh ing mangsa nalika operasi bisa diwiwiti yen ora bisa miwiti ing wektu wiwitan dijaluk. Iki ngidini panjadwal kanggo nggarap acara prioritas sing luwih dhuwur sing kedadeyan ing wektu sing padha, utawa acara prioritas sing luwih dhuwur sing ngluwihi durasi sing dikarepake. Protokol umume ndhikte apa wektu slip, nanging panjadwal radio bisa nangani iki kanthi basis saben operasi, saéngga tumpukan bisa mlebu sawetara acara nanging ora liya. Umumé, IEEE02.15.4 duwe wektu slip luwih dawa lan Bluetooth LE duwe wektu slip minimal.

ngasilaken

Sawise urutan operasi radio aktif lagi mlaku, tumpukan bisa terus nambah operasi ndawakake operasi awal nganti tumpukan wis ora ana apa-apa maneh kanggo ijol-ijolan pesen tartamtu. A tumpukan mustluntarily ngasilake kajaba nindakake latar mburi nampa. Yen tumpukan ora ngasilake, banjur bakal terus ngluwihi operasi radio, lan operasi radio prioritas sing luwih murah banjur bakal nyebabake kegagalan bali menyang tumpukan sing cocog sing njaluk operasi radio kasebut. Operasi prioritas sing luwih dhuwur ora bisa ngganggu operasi radio prioritas sing luwih murah sing lagi mlaku lan durung ngasilake. Waca bagean 5.1 Examples karo Background Nampa, Ngasilake Radio lan Transisi Negara kanggo examples saka kahanan ngendi eksplisit ngasilake radio perlu.

Ngganggu Operasi Radio

Operasi radio sing dijadwalake bisa diganggu yen operasi sing luwih prioritas bertentangan karo operasi kasebut. Iki bisa kedadeyan ing rong kahanan ing ngisor iki:

1. Operasi radio sing dijadwal luwih suwe tinimbang sing diarepake lan tumpukan sing cocog ora ngasilake operasi radio prioritas sing luwih dhuwur kudu diwiwiti.
2. Operasi radio prioritas sing luwih dhuwur wis dijadwalake bakal kedadeyan ing mangsa ngarep lan konflik karo operasi prioritas sing luwih murah sing wis dijadwalake

Operasi Radio Langgeng

Operasi Radio sing umure dawa tartamtu bisa nduwe pengaruh gedhe kanggo operasi sing bener saka produk kasebut. Aplikasi bisa uga kudu koordinasi operasi kasebut ing antarane protokol. Yen aplikasi kasebut ora, prioritas panjadwal radio bakal diutamakake. Kanggo examplan, IEEE 802.15.4 energi scan bisa mbutuhake radio tetep ing kanggo klumpukne wacan energi cekap. Yen aplikasi ora koordinasi operasi kanthi bener, pindai bisa diganggu sadurunge amarga operasi Bluetooth sing luwih prioritas.

Penjadwal Radio Examples

Kabeh mantanamples nggunakake Bluetooth LE lan Zigbee, nanging prinsip aplikasi kanggo Bluetooth liyane / 802.15.4 kombinasi.

Panjadwal diwiwiti kanthi duwe latar mburi Zigbee prioritas sing kurang nampa operasi. Iki nggantosi dalan tansah-on sing bisa uga kudu nampa IEEE 802.15.4 paket ing wektu ora dingerteni. Sambungan Bluetooth LE uga aktif lan mbutuhake tumpukan siap nampa saben 30 ms. Tumpukan Bluetooth LE bisa uga nggawe jadwal iki luwih dhisik amarga sifat sambungan sing bisa diowahi.

Jadwal Prioritas

Iki nyedhiyakake ex dhasarample saka ngadili prioritas saka operasi radio beda.

Tumpukan Zigbee mutusake yen kudu ngirim paket. Iki bisa ditindakake minangka acara sing dikarepake, tegese tumpukan mutusake yen pengin ngirim paket saiki tanpa menehi informasi luwih dhisik marang panjadwal. Iki beda karo cara Bluetooth LE ngoperasikake, ing ngendi operasi sing dijadwalake bisa dingerteni sadurunge. Penjadwal ngevaluasi manawa bisa nindakake operasi radio Zigbee TX 1 lan isih nglayani acara resepsi Bluetooth LE prioritas sing luwih dhuwur ing mangsa ngarep. Dadi panjadwal ngidini acara ngirim kedadeyan. Tumpukan Zigbee nindakake kabeh bagean saka operasi ngirim iki (nunggu MAC ack), lan banjur tanpo pekso. Perkiraan wektu transaksi saka operasi radio transmisi Zigbee ora kalebu nyoba maneh.

Ing mantan ikiample, Bluetooth LE wis dijadwal kanggo nampa ing mangsa lan tumpukan Zigbee pengin ngirim. Kanggo operasi radio Zigbee TX 1 pisanan ana cukup wektu sadurunge operasi radio Bluetooth LE RX 1 supaya panjadwal ngidini tumpukan kanggo nindakake operasi. Mengko, nalika tumpukan Zigbee nyoba gawe jadwal Zigbee TX 2 panjadwal nemtokake wektu ora cukup sadurunge acara Bluetooth LE RX 2 prioritas dhuwur. Nanging, tumpukan Zigbee wis nunjukake yen tumindak iki bisa nyebabake wektu wiwitan. Panjadwal radio nemtokake manawa diwenehi wektu samesthine operasi radio Bluetooth LE, operasi Zigbee bisa diwiwiti sawise acara kasebut lan isih ana ing wektu slip sing dituduhake dening tumpukan Zigbee.

Yen kabeh dadi kaya samesthine, operasi ngirim Zigbee bakal nyoba pisanan tanpa gagal amarga jadwal.

Prioritas Interupsi Example

Mantan ikiample nggambaraké operasi prioritas luwih interrupting siji prioritas ngisor.

 

 

 

Mantan ikiample diwiwiti kanthi cara sing padha karo mantan sadurungeample. Zigbee lan Bluetooth LE loro-lorone duwe operasi radio sing dijadwalake tanpa tabrakan

Mengko, tumpukan Zigbee mutusake arep ngirim paket liyane kanggo acara Zigbee TX 2. Penjadwal nemtokake manawa bisa gawe jadwal acara iki lan nglayani acara Bluetooth LE RX 2 mengko, adhedhasar wektu paling sethithik sing kudu ditindakake acara Zigbee TX 2. Nanging, acara Zigbee TX 2 njupuk luwih saka samesthine amarga backoff acak dawa lan ora ngasilaken ing wektu. Iki nyebabake acara tabrakan karo prioritas rad peration luwih, lan Radio Scheduler interrupts acara Zigbee lan bali Gagal kanggo tumpukan tingkat sing luwih dhuwur. Acara Bluetooth LE biasane kedadeyan lan yen wis rampung, kanthi sukarela ngasilake operasi prioritas sing luwih murah.

Sawise nampa kegagalan saka panjadwal radio, tumpukan Zigbee langsung nyoba maneh pesen MAC. Jadwal operasi lan kalebu wektu slip. Ing titik iki tumpukan Bluetooth LE duwe prioritas liwat radio lan kanthi mangkono operasi durung bisa diwiwiti, nanging panjadwal nampa operasi radio anyar. Tumpukan Bluetooth LE ngrampungake nampa sing dijadwalake lan ngasilake radio. Penjadwal banjur micu operasi transmisi Zigbee amarga isih ana ing wektu slip saka operasi wiwitan wiwitan. Sawise ngirim lengkap panjadwal bali menyang latar mburi nampa operasi.

Operasi prioritas sing luwih dhuwur sing ditambahi

Mantan ikiample nuduhake apa sing kedadeyan nalika operasi prioritas sing luwih dhuwur luwih suwe tinimbang sing diantisipasi lan nyebabake operasi prioritas sing luwih murah ilang kesempatan kasebut

Ing kasus iki, Bluetooth LE duwe nampa Jadwal sing lagi ditindakake. Zigbee mutusake ngirim paket nanging ora bisa mbukak saiki. Penjadwal nampa operasi miturut asumsi yen acara Bluetooth LE bakal rampung sadurunge pungkasan wektu slip acara Zigbee. Nanging, acara Bluetooth LE luwih suwe amarga kasunyatan manawa paket tambahan dikirim ing antarane piranti kasebut. Operasi Bluetooth LE nduweni prioritas supaya operasi Zigbee pungkasane ora ana slip. Ana kesalahan bali menyang tumpukan. Zigbee mutusake kanggo ngirim maneh paket kasebut. Maneh, tumpukan Zigbee nuduhake operasi kudu diwiwiti saiki nanging bisa uga mlebu ing mangsa ngarep. Penjadwal ana ing tengah-tengah ngganti konfigurasi radio supaya ora bisa langsung miwiti operasi. Nanging, iki nyuda wektu wiwitan operasi radio kanthi jumlah cilik lan banjur nindakake operasi kasebut.

Operasi Prioritas Luwih Tanpa Gangguan 

Ing mantan ikiample panjadwal radio mlaku ing simpul tumindak minangka periferal Bluetooth LE lan simpul kasebut nduweni sawetara sambungan menyang piranti tengah sing beda. Uga duwe beacon iklan periodik sing ditularake. Tokoh ing ngisor iki nuduhake cilik ngendi acara iki kedadean sakbenere bali-kanggo-mburi lan ora ngidini kanggo cukup wektu kanggo ngalih bali menyang config radio Zigbee. Mulane bakal nggawe wektu ing ngendi tumpukan Zigbee
ora bisa ngirim sanajan karo wektu slip.

Zigbee nyuwun panjadwal kanggo gawe jadwal operasi radio ngirim. Sanajan panjadwal ngerti yen acara kasebut bakal gagal amarga dijadwalake operasi prioritas sing luwih dhuwur, nanging tetep nampa acara sing dijadwalake. Iki ditindakake kanthi rong alasan. Kaping pisanan, kahanan bisa owah lan acara kasebut bisa ditindakake. Kapindho, tumpukan sing lungguh ing ndhuwur panjadwal radio bisa nyoba maneh tumindak kasebut. Yen asil saka jadwal gagal bali langsung banjur nyoba tumpukan kanggo nyoba maneh bakal ora bakal kasil amarga ora ana wektu liwati. Nanging, kanthi ngantri acara kasebut lan mbalekake kegagalan sawise wektu slip wis kadaluwarsa, nyoba maneh (kanthi wektu slip dhewe) duwe kasempatan luwih sukses amarga set operasi radio sing bakal teka bakal beda.

Nampa Nalika Operasi Prioritas sing luwih dhuwur lagi mlaku 

Mantan ikiample nggambarake apa sing kedadeyan nalika Bluetooth LE aktif lan operasi prioritas sing luwih murah bakal nampa data.

Ing kasus sing sepisanan, nalika pesen IEEE 802.15.4 dikirim lan tumpukan Bluetooth LE nggunakake radio kanggo nampa aktif, tumpukan Zigbee ora bakal online kanggo nampa pesen kasebut. Nanging, pangirim pesen Zigbee bakal nyoba maneh ing pirang-pirang kasus lan kanthi mundur lan owah-owahan wektu liyane ora bakal konflik karo prioritas liyane sing dijadwalake Bluetooth nampa acara sing ora mungkin tabrakan. Pesen Zigbee ditampa kanthi sukses

Kasus kapindho nuduhake yen, ing kasus nampa aktif, tumpukan Zigbee isih bisa diselani lan ora nampa (utawa ACK) pesen. Komunikasi sing sukses gumantung ing nyoba maneh ing MAC utawa lapisan sing luwih dhuwur kanggo ngirim pesen iki maneh lan verifikasi piranti Dynamic Multiprotocol nampa pesen kasebut.

Nalika ana uga pertimbangan kanggo nampa aktif utawa ora kudu diselani, iku angel kanggo penjadwal kanggo nggawe tekad kasebut. Umumé, kekokohan protokol kudu ngidini pesen bisa ditampa kanthi sukses sanajan ana gangguan

Ngleksanakake Multiprotocol karo 802.15.4-Based Stack

Bab iki nawakake informasi umum babagan ngleksanakake tumpukan basis 802.15.4 kayata Zigbee utawa Connect minangka bagéan saka aplikasi multiprotocol. Kanggo spesifik babagan carane ngatur plugins lan rincian liyane khusus kanggo protokol rticular, deleng salah sawijining cathetan aplikasi ing ngisor iki:

• AN1133: Pangembangan Multiprotokol Dinamis nganggo Bluetooth lan Zigbee EmberZNet SDK 6.x lan Ngisor
•  AN1209: Pangembangan Multiprotokol Dinamis kanthi Bluetooth lan Sambungake

Dhukungan Protokol Nirkabel

Protokol nirkabel sing beda-beda nduweni karakteristik sing beda-beda sing wis dimanfaatake kanthi desain Dynamic Multiprotocol. Kanggo exampNanging, Bluetooth Low Energy banget ketat lan katebak ing jadwal sawijining operasi radio; iklan lan interval sambungan dumadi ing wektu sing disetel. Ing kontras, protokol 802.15.4 luwih fleksibel ing wektu akeh acara pesen; CSMA (pangertèn operator kaping akses) ing IEEE 802.15.4 nambah backoffs acak supaya wektu tundha acara ing urutan milliseconds. Iki ngidini pesen IEEE 802.15.4 dikirim ing sekitar acara Bluetooth Low Energy lan isih bisa ditampa kanthi dipercaya

802.15.4 Prioritas RAIL

Protokol 802.15.4 saiki duwe telung prioritas RAIL.

Ora.	jeneng	Setelan Default	Kriteria metu
1	Aktif TX	100	MAC ACK ditampa (utawa ora)
2	RX aktif	255	Paket disaring utawa MAC ACK dikirim
3	Latar mburi RX	255	Tugas kanthi prioritas sing luwih dhuwur saiki

Yen TX Aktif dieksekusi, radio bakal dirilis nalika pangakuan MAC sing cocog ditampa (utawa ana wektu entek).

Latar mburi RX bakal ninggalake radio ing nampa negara siap kanggo nampa pesen bedo. Yen prioritas RX aktif beda karo prioritas RX latar mburi, prioritas nampa bakal diunggahake nalika tembung sinkronisasi dideteksi lan mung diturunake yen paket kasebut disaring utawa rampung lan ACK dikirim yen dijaluk.

Prioritas Balancing

Kaya sing diterangake ing bagean 6.1 Prioritas Bluetooth, kanthi gawan, sawetara prioritas Bluetooth dipetakan menyang kisaran prioritas RAIL 16 - 32. Umumé, Bluetooth wiwit nggunakake prioritas kurang (32) lan kanthi dinamis nambah prioritas nganti maksimal (16) minangka dibutuhake yen pesen ora kasil.

Kaya sing diterangake ing bagean sadurunge, tumpukan basis 802.15.4 kayata Zigbee utawa Connect nggunakake nilai prioritas RAIL standar 255 kanggo RX latar mburi, 255 kanggo RX aktif, lan 100 kanggo TX aktif.

Minangka asil saka prioritas RAIL standar iki, ing 802.15.4 protokol-Bluetooth multiprotocol aplikasi, minangka standar lalu lintas Bluetooth bakal tansah njupuk prioritas liwat 802.15.4 lalu lintas protokol. Iki minangka pilihan sing apik kanggo akeh aplikasi, amarga lalu lintas Bluetooth nduweni syarat wektu sing ketat, ora kaya protokol 802.15.4. Nanging, yen beban lalu lintas Bluetooth dhuwur banget (kanggo exampNanging, ngirim akeh data nggunakake interval sambungan cilik banget), bisa uga lalu lintas protokol 802.15.4 bisa diblokir saka akses menyang radio amarga prioritas sing luwih murah lan jendhela wektu radio sing kasedhiya ditinggalake dening Bluetooth. lalu lintas

Cathetan: Informasi ing ngisor iki saiki mung ditrapake kanggo tumpukan EmberZNet Zigbee. Silicon Labs Connect durung duwe API sing dibutuhake kanggo ngganti prioritas.

Yen sampeyan ngembangaken aplikasi multiprotocol dinamis basis 802.15.4, lan iku penting kanggo lalu lintas sukses ing ngarsane lalu lintas Bluetooth mbukak dhuwur banget, sampeyan bisa nyetel prioritas gawan minangka ditampilake ing tabel ing ngisor iki nggunakake API:

Ora.	jeneng	Setelan Default
1	Aktif TX	23
2	RX aktif	24
3	Latar mburi RX	255

Amarga Bluetooth wiwitane nyetel prioritas RAIL dadi 32, setelan prioritas 802.15.4 iki menehi prioritas lalu lintas 802.15.4 luwih dhuwur tinimbang Bluetooth ing wiwitan, sing menehi protokol 802.15.4 kesempatan kanggo ngirim utawa nampa lalu lintas kanthi sukses sanajan ana lalu lintas Bluetooth sing akeh banget. Ing tangan liyane, Bluetooth bakal mbosenke nambah prioritas yen bumped saka panjadwal dening th 802.15.4 lalu lintas, nganti prioritas dhuwur 16. Mangkono sawise ngidini akses protokol 802.15.4 kanggo radio wiwitane, Bluetooth bakal njupuk. prioritas ing nyoba maneh sakteruse yen perlu.

Pendekatan iki ngidini loro protokol bisa kompromi babagan panggunaan radio tanpa siji bisa dominasi kanthi lengkap.

. Implementasi Multiprotocol karo RAIL 

Bab iki nawakake informasi luwih lengkap babagan kekhususan RAIL kanggo pangguna sing nggunakake API RAIL langsung kanggo ngembangake protokol kepemilikan. Utamane menehi katrangan babagan cara nggarap API RAIL kanggo nangani kasus panjadwal radio tartamtu.

Examples karo Background Nampa, Ngasilake Radio lan Transisi Negara

Dasar sistem prioritas RAIL Multiprotocol cukup prasaja: acara radio kanthi prioritas sing luwih dhuwur (yaiku, jumlah sing luwih cilik) mesthi bakal ngrebut acara radio liyane kanthi prioritas sing luwih murah. Nanging, topik iki dadi luwih rumit nalika nimbang transisi negara lan API kayata RAIL_StartRx (), kang sijine radio menyang negara tartamtu kanggo wektu indefinite. Bagian iki nyedhiyakake sawetara ilustrasi mantanamples kanggo nduduhake carane negara iki wektu-unbound ditangani, lan carane lapisan aplikasi bisa nggunakake API kayata RAIL_YieldRadio () kanggo kontrol. mantanamples minangka nderek:

• Transisi Negara kanthi Protokol Tunggal
• Transisi Negara karo Loro Protokol
• Transisi Negara kanthi Loro Protokol lan Prioritas Nambah Monoton

Ing mantan ikiamples, RAIL_StartTx () punika sumber acara TX sing interrupts RX latar mburi. Elinga, Nanging, sing ex ikiamples ditrapake kanggo sembarang API radio kajaba RAIL_StartRx (). Ing tembung liyane, mantanamples ditrapake kanggo API sembarang sing miwiti acara radio sing ora RX latar mburi

Iki mantanamples nggambarake prilaku multiprotocol samesthine karo gati kanggo transisi negara. Kanggo ngringkes:

• Ing transisi negara, negara anyar dianggep minangka extension indefinite saka acara asal ing prioritas padha nganti RAIL_YieldRadio () disebut.
• Acara RX latar mburi ora kena pengaruh RAIL_YieldRadio (). Mung RAIL_Idle () permanen bisa mbusak protokol saka negara RX latar mburi.
• Acara kanthi prioritas sing luwih dhuwur bakal tansah ngrebut acara kanthi prioritas sing luwih murah, preduli saka telpon API liyane.
• Mung RAIL_StartRx () nampa bisa 'bali menyang' saka acara prioritas luwih liwat RAIL_YieldRadio () utawa RAIL_Idle ().
• Kabeh acara radio saliyane RAIL_StartRx () mbutuhake RAIL_YieldRadio () kanggo mungkasi lan maju menyang acara sabanjure.
• Telpon kanggo RAIL_YieldRadio () ora bisa diganti karo RAIL_Idle (). RAIL_Idle () mbusak kabeh acara kanggo protokol sing diwenehake

.Transisi Negara kanthi Protokol Tunggal

Iki mantan pertamaample mriksa prilaku radio karo protokol siji (yaiku, ing ngendi AIL_Handle_t padha digunakake kanggo kabeh telpon fungsi radio). Radio diwiwiti ing RX karo telpon dhisikan kanggo RAIL_StartRx (), banjur pindhah menyang TX karo telpon prioritas luwih kanggo RAIL_StartTx (). Iku penting kanggo Wigati sing sawise ngirim wis rampung, transisi radio kanggo negara kasebut dening RAIL_SetTxTransitions (), lan tetep ing negara moho ing prioritas padha lan saluran minangka TX nganti RAIL_YieldRadio () disebut. Sawise iku, radio bali menyang RX, kanthi prioritas lan saluran sing wis ditemtokake.

Perlu kanggo aktif ngasilake radio, lan kanthi mangkono RAIL_YieldRadio () API perlu umumé amarga ACK'ing. Filosofi desain iku, amarga loro TX lan ACK ditampa viewed minangka bagéan saka transaksi padha, yen simpul ngirim lan ngarepake ACK kudu loro transisi kanggo RX lan terus ngrungokake ACK minangka bagéan saka operasi padha (lan mulane padha prioritas) minangka TX asli. Umumé, RAIL dhewe ora bisa ngerti apa ACK dibutuhake utawa ora. Iki bisa gumantung ing faktor liyane, kayata isi paket, utawa logika aplikasi liyane, lan ora bisa mung ditemtokake dening mriksa apa ACK'ing wis diatur karo RAIL_ConfigAutoAck ().Mulane, discretion nalika transaksi radio wis rampung. tication / tumpukan.

Yen ACK ora dibutuhake, Silicon Labs nyaranake nelpon RAIL_YieldRadio () minangka bagéan saka nangani acara RAIL_EVENT_TX_PACKET_SENT. Mengkono iki njalari garis ijo ing tokoh ndhuwur bakal nyilikake mudhun kanggo wektu latensi interupsi. Yen aplikasi nyana ACK, RAIL_YieldRadio () kudu disebut nalika ACK ditampa utawa wis dianggep wektu metu.

Transisi Negara karo Loro Protokol

Skenario iki padha karo skenario pisanan babagan transisi negara sawise TX, nanging ngenalake protokol liyane.

Ing kahanan iki, iku penting kanggo Wigati sing RAIL_StartRx () bisa disebut ing sembarang wektu sak transaksi TX. Anggere prioritas kurang saka utawa padha karo prioritas saka TX, RX ora bakal teka menyang efek nganti aplikasi nelpon _Ngasilke Radio () ing Protocol A. Nalika RAIL_StartRx () disebut sak TX, RX mung. ditambahake menyang antrian acara sing bakal ditangani.

Titik penting liyane yaiku, sanajan RAIL_YieldRadio () ing Protokol A bakal transisi saka TX ing Protokol A menyang RX ing Protokol B, RAIL_Idle () ing Protokol B dibutuhake kanggo transisi saka RX ing Protokol B menyang RX ing Protokol A. Filosofi ing kene yaiku Background RXs ora bisa diasilake, amarga acara kasebut durung rampung. Cara mung kanggo metu iku kanggo mungkasi Background RX karo telpon kanggo RAIL_Idle ().

 Transisi Negara kanthi Loro Protokol lan Prioritas Nambah Monoton

Skenario pungkasan meh padha karo sing sadurunge, kajaba telpon menyang RAIL_StartRx () ing Protokol B luwih prioritas tinimbang telpon menyang RAIL_StartTx () ing Protokol A.

Ing kasus iki, wiwit prioritas saka RAIL_StartRx kapindho () luwih saka prioritas telpon kanggo RAIL_StartTx (), telpon kanggo RAIL_YieldRadio () ora perlu maneh. Amarga RAIL_StartRx kaloro () ing prioritas sing luwih, usurp RAIL_StartTx () acara, njupuk kontrol radio lan njabut acara TX saka negara. Sawayah-wayah sajrone RX ing Protokol B, RAIL_Idle () bisa diarani bali menyang RX ing Protokol A, kaya ing mantan sadurunge.ample.

Wigati kene, yen aplikasi nelpon RAIL_Idle () ing Protocol B kang RX, aplikasi ora bali menyang TX Transisi saka Protocol A. Nanging, iku nengen menyang RX latar mburi, sanajan aplikasi ora tau disebut RAIL_Idle () Protocol. A kang TX. Kanggo operasi radio Jadwal (yaiku, operasi radio apa wae sing diwiwiti dening API liyane saka RAIL_StartRx ()), yen acara radio direbut dening acara prioritas sing luwih dhuwur, bakal dibusak kabeh lan ora bakal dibalekake maneh. Mung Background ditampa, diwiwiti dening RAIL_StartRx (), bisa maintained ing thackground lan 'bali menyang' liwat telpon kanggo RAIL_YieldRadio () utawa RAIL_Idle ().

Kanggo nandheske prabédan antarane RAIL_YieldRadio () lan RAIL_Idle () iku penting kanggo Wigati sing, kanggo kabeh ex ikiamples, telpon kanggo RAIL_YieldRadio () ora bisa diganti karo RAIL_Idle (). RAIL_Idle () mbusak kabeh acara kanggo protokol diwenehi - loro Background (yaiku, diwiwiti dening RAIL_StartRx ()) lan Dijadwal (yaiku, diwiwiti dening API liyane saka RAIL_StartRx ()) operasi. RAIL_Idle () pancen isih bakal nyebabake aplikasi metu saka negara transisi TX, nanging uga bakal mbusak Background RX, nyebabake aplikasi kasebut bali menyang nganggur, ora RX.

Implementasi Multiprotocol karo Bluetooth

Kanggo rincian carane RAIL / lampu Bluetooth / ngalih multiprotocol example dileksanakake, lan kanggo informasi luwih lengkap babagan ngembangaken aplikasi multiprotocol karo protokol dhewe ing RAIL, ndeleng AN1134: Dynamic Multiprotocol Development karo Bluetooth lan Protokol Proprietary ing RAIL ing GSDK v2.x utawa AN1269 Dynamic Multiprotocol Development karo Bluetooth lan Protokol Proprietary ing RAIL ing GSDK v3.x lan luwih dhuwur.

Prioritas Bluetooth

Beda karo Zigbee kanthi prioritas sing ditetepake sacara statis kanggo macem-macem jinis operasi, Bluetooth nggunakake sawetara lan pendekatan offset kanggo nemtokake kabeh tugas menyang area tartamtu saka spektrum prioritas.

Ing mantan ikiampJangkoan prioritas Bluetooth, sing wiwit saka 0 nganti 255, dipetakan menyang bagean winates saka ruang prioritas RAIL sing dienggo bareng.

Ora kaya Zigbee, Bluetooth nduweni syarat wektu sing luwih kenceng yen ora ana slot tartamtu bisa nyebabake sambungan mandheg. Uga Bluetooth nduweni macem-macem tugas kaya (potensi akeh) sambungan, iklan, pemindaian, lan Transmisi lan resepsi Iklan Berkala kanthi Respons (PAwR).

Tabel 6.1. Prioritas beda ing Bluetooth

1	Sambungan	135 nganti 0	Sambungan Acara Ends
2	Wiwitan Sambungan	55 nganti 15	Window wiwitan Ends
3	Iklan	175 nganti 127	Acara Iklan Ends
4	Scanner	191 nganti 143	Pindai Window Ends
5	PAwR TX	15 nganti 5	Pengiklan: Tundha Slot Respons PAwR Ends Sinkronisasi: Slot Response PAwR Ends
6	PAwR RX	20 nganti 10	Pengiklan: Slot Respons PAwR Ends Sinkronisasi: Tundha Slot Respons PAwR Ends

Kanggo nangani iki, panjadwal Bluetooth, sing prioritas dipetakan menyang panjadwal radio RAIL, njupuk parameter ing ngisor iki kanggo saben tugas:

1.  Wektu Mulai
2.  wektu minimal
3.  Wektu maksimal
4.  Prioritas
   

Yen wektu wiwitan dipindhah total wektu mlaku suda mungguh, sing slack suda. Uga prioritas bisa diatur kanthi dinamis.

Sambungan

Sambungan duwe prioritas sing relatif dhuwur. Wektu wiwitan sambungan ora bisa dipindhah.

Prioritas tambah kanthi dinamis dening panjadwal Bluetooth, luwih cedhak sambungan kasebut menyang wektu entek pengawasan, lan tekan prioritas maksimal sing cedhak. Paket TX ing antrian TX uga nambah prioritas sambungan.

Wiwitan Sambungan

Inisiasi sambungan mindai iklan saka piranti target kanggo nggawe sambungan. Nduwe prioritas sing luwih dhuwur tinimbang scanner kanggo ngidini panyiapan sambungan sing luwih kuat.

Iklan

Iklan minangka standar duwe prioritas sing luwih murah lan titik wiwitane bisa dipindhah. Wektu wiwitan lan wektu maksimal ditetepake kanthi interval pariwara.

Yen pariwara ora bisa dikirim, prioritas pariwara mundhak alon-alon lan direset maneh sawise pariwara kasil dikirim.

Scanner

Kanthi gawan, tugas kasebut nduweni prioritas paling murah. Wiwiti, wektu minimal lan maksimum ditetepake dening interval mindhai lan ukuran jendhela. Pindai bisa terus sanajan diselani karo tugas prioritas sing luwih dhuwur. Yen kedadeyan kasebut, wektu pindai diklumpukake kanggo mesthekake ukuran jendhela pindai sing dikarepake tekan ing saben interval mindhai.

Kaya pariwara, prioritas ditambahake yen interval pindai sing dikarepake utawa ukuran jendhela ora bisa ditemokake sadurunge. Iki direset bali menyang prioritas dhisikan sawise interval pindai utawa ukuran jendhela wis ketemu.

Iklan Berkala kanthi Tanggapan (PAwR) 

Ngirim Pariwara Berkala kanthi Tanggapan nduweni prioritas paling dhuwur minangka standar saka kabeh tugas Bluetooth liyane, banjur nampa respon ing PAwR kanggo njaga sinkronisasi ing jaringan label rak elektronik (ESL).

Prioritas tugas PAwR tambah yen jadwal tugas gagal kaping pindho saurutan. Prioritas ditambahake 1/6 saka kisaran prioritas, utawa paling sethithik siji nganti prioritas maksimal wis tekan. Prioritas tugas direset maneh menyang minimal sawise jadwal sukses. Prosedur sing padha ditrapake kanggo pengiklan PAwR lan sinkronisasi ing loro arah

ExampOperasi Penjadwal Bluetooth 

Mantan ikiample nggambarake carane panjadwal Bluetooth bakal gawe jadwal telung tugas sambungan lan siji tugas iklan, saben nyekeli prioritas beda. Ing tokoh ing ngisor iki, bagean abu-abu nuduhake wektu kerja minimal sing dibutuhake lan bagean biru nuduhake wektu kerja maksimal sing bisa digunakake lan, yen fleksibel, wilayah sing bisa dipindhah. Tokoh ing ngisor iki nuduhake ing persiyapan awal

Kaya sing ditampilake ing ngisor iki, Conn1 minangka tugas pertama sing ditindakake amarga ora tumpang tindih karo tugas prioritas sing luwih dhuwur.

Adv1 tumpang tindih karo prioritas sing luwih dhuwur Conn2. Adv1 fleksibel lan mulane bakal dipindhah kaya sing digambarake ing gambar ing ngisor iki.

Conn2 tumpang tindih karo tugas prioritas luwih Conn4. Minangka Conn2 ora fleksibel jadwal Conn2 gagal.

Conn4 ora tumpang tindih karo tugas liyane, mulane Conn1 end disetel kanggo mungkasi sadurunge Conn4 diwiwiti.

Conn4 ora tumpang tindih karo tugas liyane, mulane Conn1 end disetel kanggo mungkasi sadurunge Conn4 diwiwiti.

Ngowahi Prioritas

"sl_bt_configuration_t" (v3.x) / "gecko_configuration_t" (v2.x) struct nemtokake sl_bt_stack_config_t struct, kang ngemot lapangan "bluetooth.linklayer_priorities" sing pointer kanggo konfigurasi prioritas. Yen pointer NULL banjur tumpukan nggunakake prioritas gawan minangka kadhaptar ing bagean 6.1 Bluetooth Prioritas ndhuwur uga bagean iki.

Yen pointer ora null, kudu nuding menyang struct setelan prioritas kaya sing ditegesake ing ngisor iki:

Parameter sandman, Cinemax, adv_min, adv_min, kayu manis, conn_max, intimin lan intima nemtokake prioritas minimal lan maksimum kanggo mindhai, iklan, sambungan, lan inisiasi. Prioritas bakal pindhah antarane wates min lan max minangka diterangake ing bagean 6.1.1 Sambungan kanggo 6.1.4 Scanner ndhuwur.

Parameter pemetaan RAIL, rail_mapping_offset lan rail_mapping_range, nemtokake cara prioritas lapisan link Bluetooth dipetakan menyang prioritas panjadwal radio RAIL global. Pemetaan nilai kasebut bisa dideleng ing 6.1 Prioritas Bluetooth. Standar kanggo rail_mapping_offset lan rail_mapping_range yaiku 16.

Parameter langkah adv_step lan pindai nemtokake ukuran langkah nalika prioritas pemindaian lan pariwara diganti kanthi dinamis. Pungkasan, paramèter pawr_tx_min, pawr_tx_min, pawr_tx_min, lan pawr_rx_max nemtokake sawetara prioritas kanggo pariwara Par lan sinkronisasi acara TX lan RX ing saben subevent.

Portofolio IoT
www.silabs.com/products

Kualitas
www.silabs.com/quality

Dhukungan & Komunitas
www.silabs.com/community

Penafian

Silicon Labs arep menehi dokumentasi paling anyar, akurat, lan jero kanggo kabeh periferal lan modul sing kasedhiya kanggo para pelaksana sistem lan piranti lunak sing nggunakake utawa arep nggunakake produk Silicon Labs. Data karakterisasi, modul lan periferal sing kasedhiya, ukuran memori lan alamat memori nuduhake saben
piranti tartamtu, lan "Khas" paramèter kasedhiya bisa lan beda-beda ing aplikasi beda. Aplikasi exampsing diterangake ing kene mung kanggo ilustrasi. Silicon Labs nduweni hak kanggo nggawe owahan tanpa kabar luwih lengkap babagan informasi produk, spesifikasi, lan katrangan ing kene, lan ora menehi jaminan babagan akurasi utawa kelengkapan informasi sing kalebu. Tanpa kabar sadurunge, Silicon Labs bisa nganyari perangkat kukuh produk sajrone proses manufaktur amarga alasan keamanan utawa linuwih. Owah-owahan kasebut ora bakal ngowahi spesifikasi utawa kinerja produk. Silicon Labs ora duwe tanggung jawab kanggo akibat saka panggunaan informasi sing diwenehake ing dokumen iki. Dokumen iki ora nyatakake utawa kanthi tegas menehi lisensi kanggo ngrancang utawa nggawe sirkuit terpadu. Produk kasebut ora dirancang utawa diidini digunakake ing piranti Kelas III FDA, aplikasi sing dibutuhake persetujuan premarket FDA utawa Sistem Dhukungan Urip tanpa idin tinulis khusus saka Silicon Labs. "Sistem Dhukungan Urip" yaiku produk utawa sistem sing dimaksudake kanggo ndhukung utawa nylametake urip lan/utawa kesehatan, sing, yen gagal, bisa uga bisa nyebabake ciloko utawa pati pribadi sing signifikan. Produk Silicon Labs ora dirancang utawa sah kanggo aplikasi militer. Produk Silicon Labs ora bakal digunakake ing gaman pemusnah massal kalebu (nanging ora winates ing) senjata nuklir, biologi utawa kimia, utawa misil sing bisa ngirim senjata kasebut. Silicon Labs nolak kabeh jaminan sing nyata lan diwenehake lan ora tanggung jawab utawa tanggung jawab kanggo ciloko utawa kerusakan sing ana gandhengane karo panggunaan produk Silicon Labs ing aplikasi sing ora sah kasebut. Cathetan: Isi iki bisa uga ngemot terminologi nyerang sing saiki wis lungse. Silicon Labs ngganti istilah kasebut nganggo basa inklusif yen bisa. Kanggo informasi luwih lengkap, bukak www.silabs.com/about-us/inclusive-lexicon-project

Informasi merek dagang
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® lan logo Silicon Labs®, Blueridge®, Blueridge Logo®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro logo lan kombinasi kasebut , "Pengontrol mikro paling ramah energi ing donya", Repine Signals®, Putus sambungan, n-Link, Thread Arch®, Elin®, EZRadioPRO®, EZRadioPRO®, Gecko®, Gecko OS, Gecko OS Studio, Precision32®, Simplicity Studio® , Telegenic, Telegenic Logo®, Suppress® , Sentry, logo Sentry lan Zentri DMS, Z-Wave®, lan liya-liyane iku merek dagang utawa merek dagang kadhaptar saka Silicon Labs. ARM, CORTEX, Cortex-M3 lan THUMB iku merek dagang utawa merek dagang kadhaptar saka ARM Holdings. Keli minangka merek dagang kadhaptar saka ARM Limited. Wi-Fi minangka merek dagang kadhaptar saka Wi-Fi Alliance. Kabeh produk utawa jeneng merek liyane sing kasebut ing kene minangka merek dagang sing ditahan

Dokumen / Sumber Daya

SILICON LABS UG305 Dynamic Multiprotocol [pdf] Pandhuan pangguna UG305, UG305 Dynamic Multiprotocol, Dynamic Multiprotocol, Multiprotocol

Referensi

• Manual pangguna