SILICON LABS UG305 Dynamic Multiprotocol ការណែនាំអ្នកប្រើប្រាស់

សេចក្តីផ្តើម

ឯកសារនេះពិពណ៌នាអំពីរបៀបដែលកម្មវិធី Silicon Labs ត្រូវបានរចនាឡើងដើម្បីប្រើដោយពិធីការជាច្រើននៅលើបន្ទះឈីបឥតខ្សែតែមួយ។ ពេលវេលាពហុប្រូតូកូលថាមវន្ត កាត់វិទ្យុ និងផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធយ៉ាងឆាប់រហ័ស ដើម្បីបើកដំណើរការពិធីការឥតខ្សែផ្សេងៗគ្នា ដើម្បីដំណើរការប្រកបដោយភាពជឿជាក់ក្នុងពេលតែមួយ។

ចំណាំ៖ ព័ត៌មានជាក់លាក់ Zigbee នៅក្នុងឯកសារនេះអនុវត្តចំពោះកំណែ 6.10.x និងទាបជាងនេះ។
ព័ត៌មានលម្អិតអំពីការអនុវត្តពហុប្រូតូកូលថាមវន្តជាក់លាក់ត្រូវបានផ្តល់ជូននៅក្នុងកំណត់ចំណាំកម្មវិធីខាងក្រោម៖
AN1133៖ ការអភិវឌ្ឍន៍ពហុប្រូតូកូលថាមវន្តជាមួយប៊្លូធូស និង Zigbee EmberZNet SDK 6.x និងទាបជាង
AN1134៖ ការអភិវឌ្ឍន៍ពហុប្រូតូកូលថាមវន្តជាមួយប៊្លូធូស និងពិធីការកម្មសិទ្ធិលើផ្លូវដែកក្នុង GSDK v2.x
AN1269៖ ការអភិវឌ្ឍន៍ពហុប្រូតូកូលថាមវន្តជាមួយBluetooth® និងពិធីការកម្មសិទ្ធិលើផ្លូវដែកក្នុង GSDK v3.x និងខ្ពស់ជាងនេះ។
AN1209៖ ការអភិវឌ្ឍន៍ពហុប្រូតូកូលថាមវន្តជាមួយប៊្លូធូស និងភ្ជាប់
AN1265៖ ការអភិវឌ្ឍន៍ពហុប្រូតូកូលថាមវន្តជាមួយBluetooth® និង OpenThread ក្នុង GSDK v3.x

វាក្យសព្ទ

ខាងក្រោមនេះរាយនាមពាក្យមួយចំនួនជាក់លាក់ចំពោះការអនុវត្តពហុប្រូតូកូលថាមវន្ត

ស្រទាប់ចំណុចប្រទាក់វិទ្យុ Abstraction (RAIL)៖ API ទូទៅដែលលេខកូដកម្រិតខ្ពស់ទទួលបានសិទ្ធិចូលប្រើវិទ្យុ EFR32 ។

ប្រតិបត្តិការវិទ្យុ៖ សកម្មភាពជាក់លាក់ដែលត្រូវកំណត់ពេល។ ប្រតិបត្តិការវិទ្យុមានទាំងការកំណត់រចនាសម្ព័ន្ធវិទ្យុ និងអាទិភាព។ ជង់នីមួយៗអាចស្នើសុំឱ្យកម្មវិធីកំណត់ពេលវិទ្យុធ្វើប្រតិបត្តិការវិទ្យុរហូតដល់ពីរ (ការទទួលផ្ទៃខាងក្រោយ និងទាំងការទទួលតាមកាលវិភាគ ឬកាលវិភាគ

• ផ្ទៃខាងក្រោយទទួល៖ ទទួលជាបន្តបន្ទាប់ មានបំណងត្រូវបានរំខានដោយប្រតិបត្តិការដែលបានគ្រោងទុក ហើយត្រឡប់ទៅក្រោយការបញ្ចប់របស់ពួកគេ។
• ការទទួលតាមកាលវិភាគ៖ ទទួលកញ្ចប់ព័ត៌មាន ឬគណនា RSSI តាមពេលវេលា និងរយៈពេលជាក់លាក់។ (អ្នកអភិវឌ្ឍន៍ដែលធ្វើការលើ RAIL សូមចំណាំថានៅក្នុងលក្ខខណ្ឌនៃ RAIL API "Scheduled Receive" ដូចដែលបានប្រើក្នុងឯកសារនេះសំដៅទៅលើប្រតិបត្តិការទទួលណាមួយ ក្រៅពី RAIL_StartRx ហើយមិនត្រឹមតែត្រូវបានកំណត់ក្នុងវិសាលភាពចំពោះ RAIL_ScheduleRx ប៉ុណ្ណោះទេ)។
• Transmi ដែលបានកំណត់ពេលt៖ រាល់ប្រតិបត្តិការបញ្ជូនផ្សេងៗ រួមទាំងការបញ្ជូនភ្លាមៗ ការបញ្ជូនតាមកាលវិភាគ (អនាគត) ឬការបញ្ជូនតាម CCAdependent។ (អ្នកអភិវឌ្ឍន៍ដែលធ្វើការលើ RAIL សូមចំណាំថានៅក្នុងលក្ខខណ្ឌនៃ RAIL API "ការបញ្ជូនតាមកាលវិភាគ" ដូចដែលបានប្រើក្នុងឯកសារនេះសំដៅទៅលើប្រតិបត្តិការបញ្ជូនណាមួយ និងមិនត្រូវបានកំណត់ក្នុងវិសាលភាពចំពោះ RAIL_StartScheduledTx ទេ។

Radio Config៖ កំណត់ស្ថានភាពនៃផ្នែករឹងដែលត្រូវតែប្រើដើម្បីដំណើរការវិទ្យុ។

កម្មវិធីកំណត់ពេលវិទ្យុ៖ សមាសធាតុ RAIL ដែលធ្វើអាជ្ញាកណ្តាលរវាងពិធីការផ្សេងៗគ្នាដើម្បីកំណត់ថាតើមួយណានឹងមានសិទ្ធិចូលប្រើវិទ្យុ។

អាទិភាព៖ ប្រតិបត្តិការនីមួយៗពីជង់នីមួយៗមានអាទិភាពលំនាំដើម។ កម្មវិធីអាចផ្លាស់ប្តូរអាទិភាពលំនាំដើម។

ពេលវេលារអិល៖ ពេលវេលាអតិបរមានាពេលអនាគត នៅពេលប្រតិបត្តិការអាចត្រូវបានចាប់ផ្តើមប្រសិនបើវាមិនអាចចាប់ផ្តើមនៅពេលចាប់ផ្តើមដែលបានស្នើសុំ។

ទិន្នផល៖ ជង់ត្រូវតែស្ម័គ្រចិត្តនៅចុងបញ្ចប់នៃប្រតិបត្តិការ ឬលំដាប់នៃប្រតិបត្តិការ លុះត្រាតែវាដំណើរការការទទួលផ្ទៃខាងក្រោយ។ រហូតទាល់តែជង់ផ្តល់ទិន្នផល អ្នកកំណត់ពេលនឹងមិនកំណត់ពេលភារកិច្ចអាទិភាពទាបជាងនេះទេ។

RTOS (ប្រព័ន្ធប្រតិបត្តិការពេលវេលាពិត) ខឺណែល។៖ ផ្នែកនៃប្រព័ន្ធប្រតិបត្តិការដែលទទួលខុសត្រូវលើការគ្រប់គ្រងភារកិច្ច និងការទំនាក់ទំនងអន្តរកិច្ចការ និងការធ្វើសមកាលកម្ម។ ការអនុវត្តនេះប្រើខឺណែល Micrium OS-5 ។

ស្ថាបត្យកម្ម

Dynamic Multiprotocol ប្រើផ្នែករឹង EFR32 និងកម្មវិធី RAIL ជាប្លុកសំណង់របស់វា។ Zigbee, ប៊្លូធូស និង/ឬពិធីការដែលមានមូលដ្ឋានលើស្តង់ដារ ឬកម្មសិទ្ធិផ្សេងទៀតអាចត្រូវបានបង្កើតឡើងនៅលើកំពូលនៃស្រទាប់ដែលមិនអាចកំណត់បាន ដោយប្រើ Micrium ដើម្បីគ្រប់គ្រងការប្រតិបត្តិនៃកូដរវាងពិធីការផ្សេងៗ។ ដ្យាក្រាមខាងក្រោមបង្ហាញពីរចនាសម្ព័ន្ធទូទៅនៃម៉ូឌុលកម្មវិធី។

 

ចាប់ផ្តើមជាមួយនឹងកំណែ 2.0, RAIL តម្រូវឱ្យឆ្លងកាត់ចំណុចទាញកំណត់រចនាសម្ព័ន្ធវិទ្យុទៅការហៅ RAIL API ។ ការកំណត់រចនាសម្ព័ន្ធនេះពិពណ៌នាអំពីប៉ារ៉ាម៉ែត្រ PHY ផ្សេងៗដែលត្រូវបានប្រើដោយជង់

Micrium OS គឺជា RTOS ដែលអនុញ្ញាតឱ្យជង់ និងតក្កវិជ្ជាកម្មវិធីចែករំលែកពេលវេលាដំណើរការស៊ីភីយូ។

កម្មវិធីកំណត់ពេលវិទ្យុគឺជាបណ្ណាល័យកម្មវិធីដែលឆ្លើយតបយ៉ាងឆ្លាតវៃនូវសំណើដោយជង់ ដើម្បីអនុវត្តប្រតិបត្តិការវិទ្យុ ដើម្បីបង្កើនភាពជឿជាក់ និងកាត់បន្ថយភាពយឺតយ៉ាវ។ API ផ្តល់ដោយ RAIL ដែលមិនភ្ជាប់វិទ្យុរំលងកម្មវិធីកំណត់ពេលវិទ្យុ។

ស្នូល RAIL កំណត់រចនាសម្ព័ន្ធផ្នែករឹង EFR32 ក្នុងការឆ្លើយតបទៅនឹងការណែនាំពីកម្មវិធីកំណត់ពេលវិទ្យុ។

រូបភាពកម្មវិធីបង្កប់តែមួយ

Dynamic Multiprotocol អនុញ្ញាតឱ្យអ្នកបង្កើតកម្មវិធីបង្កើតប្រព័ន្ធគោលពីរ monolithic តែមួយដែលត្រូវបានផ្ទុកនៅលើ EFR32 ។ ការអាប់ដេតកម្មវិធីត្រូវបានធ្វើដោយការអាប់ដេតប្រព័ន្ធគោលពីរទាំងមូល។ នេះត្រូវបានសម្រេចដោយប្រើ Geck otloader ព័ត៌មានលម្អិតដែលអាចត្រូវបានរកឃើញនៅក្នុង UG266: Silicon Labs Gecko Bootloader User's Guide សម្រាប់ GSDK 3.2 និងទាបជាង និង UG489: Silicon LabsGecko Bootloader User's Guide សម្រាប់ GSDK 4.0 និងខ្ពស់ជាងនេះ។

ប្រតិបត្តិការជង់ឯករាជ្យ

ជង់ Silicon Labs នៅតែដំណើរការដោយឯករាជ្យពីគ្នាទៅវិញទៅមកនៅក្នុងស្ថានភាព Dynamic Multiprotocol។ ប្រតិបត្តិការ​វិទ្យុ​ដែល​មាន​រយៈពេល​យូរ​ជាក់លាក់​នឹង​ជះឥទ្ធិពល​លើ​ភាព​យឺតយ៉ាវ​របស់​ពិធីការ​មួយ​ផ្សេង​ទៀត និង​ប្រតិបត្តិការ​ដែល​អនុលោម​តាម។ វាអាស្រ័យលើកម្មវិធីដើម្បីកំណត់ការពិចារណាពិសេសណាមួយសម្រាប់ព្រឹត្តិការណ៍ទាំងនេះ។ សូមមើលផ្នែកទី 2. កម្មវិធីកំណត់ពេលវិទ្យុ សម្រាប់ព័ត៌មានបន្ថែម។

កម្មវិធីកំណត់ពេលវិទ្យុ

Radio Scheduler គឺជាធាតុផ្សំនៃ RAIL (Radio Abstraction Interface Layer)។ RAIL ផ្តល់នូវស្រទាប់ចំណុចប្រទាក់វិទ្យុដែលអាចប្ដូរតាមបំណងបានយ៉ាងងាយស្រួល និងអាចប្ដូរតាមបំណងបាន ដែលគាំទ្រពិធីការឥតខ្សែដែលមានមូលដ្ឋានលើកម្មសិទ្ធិ ឬស្តង់ដារ។ កម្មវិធីកំណត់ពេលវិទ្យុត្រូវបានរចនាឡើងដើម្បីអនុញ្ញាតឱ្យមានប្រតិបត្តិការវិទ្យុដែលអាចត្រូវបានកំណត់ពេល និងកំណត់អាទិភាព។ ប្រតិបត្តិការវិទ្យុផ្សេងៗគ្នានៅក្នុងពិធីការនីមួយៗអាចមានសារៈសំខាន់ច្រើន ឬតិច ឬពេលវេលាច្រើន ឬតិចអាស្រ័យលើស្ថានភាព។ អ្នករៀបចំកាលវិភាគអាចពិចារណារឿងទាំងនោះនៅពេលធ្វើការសម្រេចចិត្តអំពីជម្លោះ និងរបៀបវិនិច្ឆ័យពួកគេ។

លុះត្រាតែអ្នកកំពុងបង្កើតកម្មវិធីដោយប្រើពិធីការផ្ទាល់ខ្លួននៅលើ RAIL មុខងារកម្មវិធីកំណត់ពេលវិទ្យុភាគច្រើនត្រូវបានគ្រប់គ្រងដោយស្វ័យប្រវត្តិដោយកូដមូលដ្ឋាន និង RAIL ។ អ្នកគ្រាន់តែត្រូវប្រើជង់តាមរយៈ API ធម្មតារបស់វា។

នៅកម្រិតខ្ពស់ជង់បញ្ជូនប្រតិបត្តិការវិទ្យុ (សម្រាប់ឧample a ការទទួលតាមកាលវិភាគ ឬការបញ្ជូនតាមកាលវិភាគ)។ ប្រតិបត្តិការវិទ្យុគឺ
បានដាក់ជាជួរ ហើយបន្ទាប់មកផ្តល់សេវានៅពេលអនាគត ដោយផ្អែកលើប៉ារ៉ាម៉ែត្ររបស់ពួកគេ។ នៅពេលដែលវាដល់ពេលចាប់ផ្តើមប្រតិបត្តិការវិទ្យុ អ្នកកំណត់ពេលពិនិត្យមើលថាតើមានព្រឹត្តិការណ៍ប្រកួតប្រជែងមានឬអត់ ហើយថាតើប្រតិបត្តិការអាចត្រូវបានពន្យារពេលឬអត់។ ប្រសិនបើអ្នកកំណត់ពេលមិនអាចដំណើរការព្រឹត្តិការណ៍នោះ វាត្រឡប់លទ្ធផលទៅស្រទាប់ខ្ពស់ជាង ដែលអាចព្យាយាមម្តងទៀតជាមួយនឹងប៉ារ៉ាម៉ែត្រថ្មី។

នៅពេលដែលប្រតិបត្តិការវិទ្យុបានចាប់ផ្តើម ជង់ដែលត្រូវគ្នាអាចបញ្ជូនប្រតិបត្តិការបន្ថែមរបស់កម្មវិធីកំណត់ពេលដោយផ្អែកលើលទ្ធផលនៃប្រតិបត្តិការពីមុន (សម្រាប់ឧ។ampឡេកំពុងរង់ចាំ ACK) ។ នៅចុងបញ្ចប់នៃប្រតិបត្តិការនីមួយៗ ឬលំដាប់នៃប្រតិបត្តិការ ជង់ត្រូវតែផ្តល់នូវការប្រើប្រាស់វិទ្យុ។

ប្រតិបត្តិការវិទ្យុ

ព្រឹត្តិការណ៍នីមួយៗនៅក្នុងកម្មវិធីកំណត់ពេលត្រូវបានបំបែកទៅជាធាតុដែលហៅថា ប្រតិបត្តិការវិទ្យុ ដែលត្រូវបានផ្សារភ្ជាប់ជាមួយនឹងការកំណត់រចនាសម្ព័ន្ធវិទ្យុ និងអាទិភាពមួយ។

រាល់ប្រតិបត្តិការមានអាទិភាព ហើយត្រូវបានរំខាន ប្រសិនបើអ្នកកំណត់ពេលទទួលបានប្រតិបត្តិការដែលមានអាទិភាពខ្ពស់ជាង ដែលត្រួតលើគ្នាទាន់ពេលវេលា។ ប្រតិបត្តិការវិទ្យុអាទិភាពទាបដែលមិនអាចដំណើរការបានដោយផ្អែកលើប៉ារ៉ាម៉ែត្រកាលវិភាគរបស់ពួកគេនឹងបរាជ័យ ហើយវាអាស្រ័យលើជង់រៀងៗខ្លួនដើម្បីព្យាយាមម្តងទៀត។ នៅពេលដែលកម្មវិធីកំណត់ពេលវេលាដំណើរការប្រតិបត្តិការវិទ្យុពីជង់យ៉ាងសកម្ម ជង់អាចបន្តបញ្ជូនប្រតិបត្តិការវិទ្យុបន្ថែមរហូតដល់វាផ្តល់លទ្ធផលដោយស្ម័គ្រចិត្ត ឬរហូតដល់អ្នកកំណត់ពេលទទួលបានប្រតិបត្តិការវិទ្យុដែលមានអាទិភាពខ្ពស់ជាង ហើយកក់ទុកមុន។

• ផ្ទៃខាងក្រោយទទួល
• ការទទួលតាមកាលវិភាគ
• ការបញ្ជូនតាមកាលវិភាគ

ជង់នីមួយៗអាចសួរកម្មវិធីកំណត់ពេលវិទ្យុឱ្យធ្វើប្រតិបត្តិការវិទ្យុរហូតដល់ពីរ (ការទទួលផ្ទៃខាងក្រោយ និងទាំងការទទួលតាមកាលវិភាគ ឬការបញ្ជូនតាមកាលវិភាគ) ក្នុងពេលតែមួយ៖

ប្រតិបត្តិការនីមួយៗមានប៉ារ៉ាម៉ែត្រដូចខាងក្រោមៈ

ពេលវេលាចាប់ផ្តើម	ការ​ចង្អុល​បង្ហាញ​នៅ​ចំណុច​ណា​នៅ​ពេល​អនាគត​ប្រតិបត្តិការ​វិទ្យុ​នេះ​នឹង​ដំណើរការ។ នេះអាចត្រូវបាន "ដំណើរការឥឡូវនេះ" ឬតម្លៃមួយចំនួនគិតជាមីក្រូវិនាទីនាពេលអនាគត។
អាទិភាព	លេខដែលបង្ហាញពីអាទិភាពទាក់ទងនៃប្រតិបត្តិការ។ នៅពេលប្រើការកំណត់លំនាំដើម ប្រតិបត្តិការវិទ្យុ Bluetooth LE តែងតែមានអាទិភាពខ្ពស់ជាងប្រតិបត្តិការ Zigbee ។
ពេលវេលារអិល	ចំនួនពេលវេលាដែលព្រឹត្តិការណ៍អាចត្រូវបានពន្យារពេលលើសពីពេលវេលាចាប់ផ្តើមរបស់វា ហើយនៅតែអាចទទួលយកបានចំពោះជង់។ នេះអាចជា 0 ក្នុងករណីនេះ ព្រឹត្តិការណ៍មិនអាចរំលងបានទេ។
ពេលវេលាប្រតិបត្តិការ	ចំនួនពេលវេលាប្រហាក់ប្រហែលដែលវាត្រូវការដើម្បីបញ្ចប់ប្រតិបត្តិការ។ ព្រឹត្តិការណ៍បញ្ជូនជាធម្មតាមានពេលវេលាប្រតិបត្តិការដែលបានកំណត់ឱ្យបានល្អជាងនេះ ខណៈដែលព្រឹត្តិការណ៍ទទួលច្រើនតែមិនស្គាល់។ វា​ត្រូវ​បាន​ប្រើ​ដើម្បី​ជួយ​កម្មវិធី​កំណត់​ពេល​វិទ្យុ​កំណត់​ថា​តើ​ព្រឹត្តិការណ៍​មួយ​អាច​ត្រូវ​បាន​ដំណើរការ​ឬ​អត់។

ជង់កំណត់ប៉ារ៉ាម៉ែត្រផ្សេងៗទាំងនេះសមស្របទៅនឹងប្រតិបត្តិការដែលកំពុងដំណើរការ។ សម្រាប់អតីតample, ព្រឹត្តិការណ៍នៃការតភ្ជាប់ប៊្លូធូសជាញឹកញាប់ត្រូវបានកំណត់ពេលនាពេលអនាគត ហើយមិនមានការអនុញ្ញាតទេ ចំណែកព្រឹត្តិការណ៍បញ្ជូន Zigbee ជាញឹកញាប់អាចត្រូវបានពន្យារពេលក្នុងចំនួនតិចតួច ហើយដាក់ផ្កាយនៅពេលក្រោយ។

តាមទស្សនៈរបស់អ្នករៀបចំកម្មវិធីវិទ្យុ RAIL ការបញ្ជូនតាមកាលវិភាគ និងការទទួលតាមកាលវិភាគគឺដូចគ្នាបេះបិទ។ ពួកវាទាំងពីរជាប្រតិបត្តិការសាមញ្ញដែលទាមទារការប្រើប្រាស់វិទ្យុ ហើយដូច្នេះមិនអាចប្រតិបត្តិក្នុងពេលដំណាលគ្នាបានទេ។ ifference គឺជាក់ស្តែងតែនៅស្រទាប់ RAIL API ដែលទាំង TX ឬ RX API ត្រូវបានហៅ។

ផ្ទៃខាងក្រោយទទួល

នេះគឺជារបៀបទទួលបន្តដែលមានបំណងត្រូវបានរំខានដោយប្រតិបត្តិការផ្សេងទៀត ហើយត្រឡប់ទៅក្រោយការបញ្ចប់របស់ពួកគេ។ ប្រសិនបើ Background Receive មានអាទិភាពខ្ពស់ជាងប្រតិបត្តិការផ្សេងទៀត ប្រតិបត្តិការវិទ្យុទាំងនោះនឹងមិនត្រូវបានកំណត់ពេលទេ ហើយនឹងមិនដំណើរការទេ។ វាអាស្រ័យលើជង់ ឬកម្មវិធីដើម្បីផ្លាស់ប្តូរអាទិភាព ឬទិន្នផលដោយស្ម័គ្រចិត្ត។ សូមមើលផ្នែក 5.1 ឧamples ជាមួយ Background Receive, Yield Radio និង State Transition សម្រាប់ examples ពីរបៀបដែលផ្ទៃខាងក្រោយទទួលអន្តរកម្មជាមួយប្រតិបត្តិការដែលបានគ្រោងទុក។

បានកំណត់ពេលទទួល

នេះគឺជាការទទួលនៅពេលអនាគតជាមួយនឹងរយៈពេលជាក់លាក់។ កម្មវិធីកំណត់ពេលវិទ្យុនឹងគិតគូរអំពីពេលវេលាប្តូរវិទ្យុក្នុងការសម្រេចចិត្តថាតើប្រតិបត្តិការនឹងត្រូវកំណត់ពេលឬអត់។ ប្រសិនបើវាមិនអាចកំណត់ពេលបានទេ នោះអ្នកកំណត់ពេលបញ្ជូនព្រឹត្តិការណ៍បរាជ័យទៅជង់ការហៅទូរសព្ទ។ ប្រតិបត្តិការ​វិទ្យុ​ត្រូវ​បាន​ពង្រីក​ដោយ​ស្វ័យ​ប្រវត្តិ​រហូត​ដល់​ជង់​ផ្តល់​ផល​ដោយ​ស្ម័គ្រ​ចិត្ត ឬ​អ្នក​កំណត់​ពេល​ទទួល​បាន​ប្រតិបត្តិការ​អាទិភាព​ខ្ពស់​ជាង​នេះ ហើយ​រំខាន​វា។ ការពង្រីកការទទួលអនុញ្ញាតឱ្យជង់បន្តប្រតិបត្តិការវិទ្យុដោយផ្អែកលើតម្រូវការនៃពិធីការកម្រិតខ្ពស់សម្រាប់ឧample ការបញ្ជូនការឆ្លើយតបដោយផ្អែកលើទិន្នន័យដែលទទួលបាន។

ការបញ្ជូនតាមកាលវិភាគ

នេះ​ជា​ការ​បញ្ជូន​នៅ​ពេល​អនាគត​ដែល​មាន​រយៈពេល​អប្បបរមា។ រយៈពេលអប្បបរមានេះអាចរាប់បញ្ចូលព្រឹត្តិការណ៍បន្ទាប់ដែលរំពឹងទុកសម្រាប់ឧampប្រើ ACK ទៅការបញ្ជូន IEEE 802.15.4 ។ ទោះជាយ៉ាងណាក៏ដោយ ពេលវេលាអប្បបរមាសម្រាប់ប្រតិបត្តិការនេះមិនត្រូវរួមបញ្ចូលព្រឹត្តិការណ៍ដែលមិនរំពឹងទុកដែលអាចពន្យាពេលលើសពីរយៈពេលអប្បបរមាសម្រាប់ឧ។ampការខ្វះខាតដោយសារតែការបរាជ័យ CCA នៅក្នុង IEEE 802.15.4 ។ កម្មវិធីកំណត់ពេលវិទ្យុគិតពិចារណាអំពីពេលវេលាប្តូរវិទ្យុក្នុងការសម្រេចចិត្តថាតើប្រតិបត្តិការនឹងត្រូវកំណត់ពេលឬអត់។ ប្រសិនបើវាមិនអាចកំណត់ពេលបានទេ នោះអ្នកកំណត់ពេលបញ្ជូនព្រឹត្តិការណ៍បរាជ័យទៅជង់ការហៅទូរសព្ទ។

ការកំណត់រចនាសម្ព័ន្ធវិទ្យុ

ប្រតិបត្តិការវិទ្យុនីមួយៗត្រូវបានភ្ជាប់ជាមួយការកំណត់រចនាសម្ព័ន្ធវិទ្យុដែលបានកំណត់ជាមុនដែលកំណត់ស្ថានភាពនៃផ្នែករឹងដែលត្រូវតែប្រើដើម្បីអនុវត្តប្រតិបត្តិការ។ ការកំណត់រចនាសម្ព័ន្ធវិទ្យុរក្សាដាននៃស្ថានភាពបច្ចុប្បន្នរបស់ជង់ ដូច្នេះប្រតិបត្តិការវិទ្យុនាពេលអនាគតនឹងប្រើប៉ារ៉ាម៉ែត្រវិទ្យុដូចគ្នា។ ការកំណត់រចនាសម្ព័ន្ធវិទ្យុអាចសកម្ម ឬនៅស្ងៀម។ ប្រសិនបើជង់ផ្លាស់ប្តូរ Radio Config សកម្មនោះ RAIL ធ្វើការផ្លាស់ប្តូរភ្លាមៗចំពោះការកំណត់រចនាសម្ព័ន្ធផ្នែករឹងផងដែរ សម្រាប់ឧ.ampផ្លាស់ប្តូរឆានែល។ ប្រសិនបើការកំណត់រចនាសម្ព័ន្ធវិទ្យុបច្ចុប្បន្នមិនដំណើរការទេ នោះប្រតិបត្តិការវិទ្យុដែលបានកំណត់ពេលបន្ទាប់នឹងប្រើការកំណត់រចនាសម្ព័ន្ធវិទ្យុថ្មី។

អាទិភាព

ប្រតិបត្តិការវិទ្យុនីមួយៗមានអាទិភាពដែលបង្ហាញទៅកាន់អ្នកកំណត់ពេលថាប្រតិបត្តិការណាមួយគួរតែត្រូវបានប្រតិបត្តិ ប្រសិនបើមានពេលវេលាត្រួតគ្នារវាងប្រតិបត្តិការច្រើន។ កម្មវិធីកំណត់ពេលចាត់ទុកអាទិភាព 0 ជាអាទិភាពខ្ពស់បំផុត និង 255 ជាអាទិភាពទាបបំផុត។ កម្មវិធីកំណត់ពេលវិទ្យុនឹងអនុញ្ញាតឱ្យកិច្ចការដែលមានអាទិភាពខ្ពស់បំផុតដើម្បីចូលប្រើ ra rdware រាងកាយ។ ជាមួយនឹងការគ្រប់គ្រងកិច្ចការភាគច្រើនត្រូវបានបញ្ជូនត្រឡប់ទៅកម្មវិធីកំណត់ពេលវិទ្យុតែនៅពេលបញ្ចប់ប៉ុណ្ណោះ ប៉ុន្តែកិច្ចការដូចជាការទទួលផ្ទៃខាងក្រោយនឹងត្រូវបានរំខានក្នុងករណីដែលកិច្ចការដែលមានអាទិភាពខ្ពស់ជាងនេះក្លាយជាសកម្ម

ជង់នីមួយៗមានការកំណត់លំនាំដើមនៃអាទិភាពដោយផ្អែកលើការវិភាគរបស់ Silicon Labs អំពីរបៀបដែលល្អបំផុតក្នុងការសហការដើម្បីបង្កើនវដ្តកាតព្វកិច្ច និងជៀសវាងការតភ្ជាប់ដែលធ្លាក់ចុះសម្រាប់ករណីប្រើប្រាស់ទូទៅ។ ករណីប្រើប្រាស់ជាក់លាក់អាចមានតម្រូវការខុសៗគ្នា។ អាទិភាពមានដូចខាងក្រោម ពីខ្ពស់បំផុតទៅទាបបំផុត។

1.  ការបញ្ជូនតាមកាលវិភាគប៊្លូធូស LE
2.  ប៊្លូធូស LE បានកំណត់ពេលទទួល
3.  ការបញ្ជូនតាមកាលវិភាគផ្សេងទៀត។
4.  ពិធីការផ្សេងទៀតផ្ទៃខាងក្រោយទទួល

អាទិភាពទាំងនេះអាចត្រូវបានបដិសេធ ឬផ្លាស់ប្តូរដោយកម្មវិធី។ វាអាស្រ័យលើកម្មវិធីក្នុងការសម្រេចចិត្តក្នុងកាលៈទេសៈណាដែលត្រូវផ្លាស់ប្តូរពួកគេ។ ផ្នែកទី 4.2 802.15.4 អាទិភាពផ្លូវដែក និងផ្នែក 6.1 អាទិភាពប៊្លូធូសមានព័ត៌មានលម្អិតបន្ថែមអំពីអាទិភាពសម្រាប់ករណីជាក់លាក់របស់ពួកគេ។

ពេលវេលារអិល

រាល់ប្រតិបត្តិការវិទ្យុត្រូវតែមាន "ពេលវេលារអិល" ឬពេលវេលាចាប់ផ្តើមអតិបរមា មានន័យថាជាពេលវេលាដ៏ឆ្ងាយបំផុតនាពេលអនាគត នៅពេលប្រតិបត្តិការអាចត្រូវបានចាប់ផ្តើមប្រសិនបើវាមិនអាចចាប់ផ្តើមនៅពេលចាប់ផ្តើមដែលបានស្នើសុំ។ នេះអនុញ្ញាតឱ្យអ្នកកំណត់ពេលធ្វើការជុំវិញព្រឹត្តិការណ៍ដែលមានអាទិភាពខ្ពស់ដែលកំពុងកើតឡើងក្នុងពេលតែមួយ ឬព្រឹត្តិការណ៍អាទិភាពខ្ពស់ជាងដែលលើសពីរយៈពេលរំពឹងទុករបស់ពួកគេ។ ពិធីការជាទូទៅកំណត់ថាពេលវេលារអិលអាចជាអ្វី ប៉ុន្តែកម្មវិធីកំណត់ពេលវិទ្យុមានសមត្ថភាពក្នុងការដោះស្រាយវានៅលើមូលដ្ឋានប្រតិបត្តិការនីមួយៗ ដែលអនុញ្ញាតឱ្យជង់ដើម្បីរអិលព្រឹត្តិការណ៍មួយចំនួន ប៉ុន្តែមិនមែនកម្មវិធីផ្សេងទៀតទេ។ ជាទូទៅ IEEE02.15.4 មានពេលរអិលយូរជាង ហើយ Bluetooth LE មានពេលរអិលតិចបំផុត។

ទិន្នផល

នៅពេលដែលលំដាប់នៃប្រតិបត្តិការវិទ្យុកំពុងដំណើរការយ៉ាងសកម្ម ជង់អាចបន្តបន្ថែមប្រតិបត្តិការដែលពង្រីកប្រតិបត្តិការដំបូងរហូតដល់ជង់មិនមានអ្វីត្រូវធ្វើទៀតទេសម្រាប់ការប្តូរសារជាក់លាក់។ ជង់ត្រូវតែផ្តល់លទ្ធផលដោយឯកឯង លុះត្រាតែវាដំណើរការការទទួលផ្ទៃខាងក្រោយ។ ប្រសិនបើជង់មួយមិនផ្តល់លទ្ធផលទេ នោះវានឹងបន្តពង្រីកប្រតិបត្តិការវិទ្យុរបស់វា ហើយប្រតិបត្តិការវិទ្យុដែលមានអាទិភាពទាបជាងនេះនឹងបង្កឱ្យមានការបរាជ័យត្រឡប់ទៅជង់ដែលត្រូវគ្នាដែលបានស្នើសុំប្រតិបត្តិការវិទ្យុនោះ។ ប្រតិបត្តិការដែលមានអាទិភាពខ្ពស់មិនអាចរំខានដល់ប្រតិបត្តិការវិទ្យុដែលមានអាទិភាពទាបដែលកំពុងដំណើរការបច្ចុប្បន្ន ដែលមិនទាន់ផ្តល់លទ្ធផល។ សូមមើលផ្នែក 5.1 ឧamples ជាមួយ Background Receive, Yield Radio និង State Transition សម្រាប់ examples នៃស្ថានភាពដែលការបញ្ជូនវិទ្យុច្បាស់លាស់គឺចាំបាច់។

រំខានប្រតិបត្តិការវិទ្យុ

ប្រតិបត្តិការវិទ្យុដែលបានកំណត់ពេលអាចនឹងត្រូវបានរំខាន ប្រសិនបើប្រតិបត្តិការអាទិភាពខ្ពស់ជាងនេះប៉ះទង្គិចជាមួយវា។ វាអាចកើតឡើងក្នុងកាលៈទេសៈពីរខាងក្រោម៖

1. ប្រតិបត្តិការវិទ្យុដែលបានកំណត់ពេលត្រូវចំណាយពេលយូរជាងការរំពឹងទុក ហើយជង់ដែលត្រូវគ្នាមិនច្រានចោលទេ ដែលប្រតិបត្តិការវិទ្យុអាទិភាពខ្ពស់ត្រូវតែចាប់ផ្តើម។
2. ប្រតិបត្តិការវិទ្យុដែលមានអាទិភាពខ្ពស់ជាងទើបតែត្រូវបានកំណត់ពេលនឹងកើតឡើងនាពេលអនាគត ហើយការប៉ះទង្គិចជាមួយប្រតិបត្តិការអាទិភាពទាបជាងដែលបានកំណត់ពេលរួចហើយ

ប្រតិបត្តិការវិទ្យុយូរអង្វែង

ប្រតិបត្តិការវិទ្យុដែលមានអាយុកាលយូរមួយចំនួនអាចមានឥទ្ធិពលខ្លាំងលើប្រតិបត្តិការត្រឹមត្រូវនៃផលិតផល។ កម្មវិធីអាចត្រូវការសម្របសម្រួលប្រតិបត្តិការទាំងនេះរវាងពិធីការ។ ប្រសិនបើកម្មវិធីមិនដំណើរការ នោះអាទិភាពកម្មវិធីកំណត់ពេលវិទ្យុនឹងមានអាទិភាព។ សម្រាប់អតីតample ការស្កែនថាមពល IEEE 802.15.4 អាចតម្រូវឱ្យវិទ្យុបន្តដើម្បីប្រមូលការអានថាមពលគ្រប់គ្រាន់។ ប្រសិនបើ​កម្មវិធី​មិន​សម្របសម្រួល​ប្រតិបត្តិការ​ឱ្យ​បាន​ត្រឹមត្រូវ ការ​ស្កេន​អាច​ត្រូវ​បាន​រំខាន​មុន​ពេល​កំណត់ ដោយសារ​ប្រតិបត្តិការ​ប៊្លូធូស​មាន​អាទិភាព​ខ្ពស់។

កម្មវិធីកំណត់ពេលវិទ្យុ Examples

ទាំងអស់អតីតamples ប្រើ Bluetooth LE និង Zigbee ប៉ុន្តែគោលការណ៍អនុវត្តចំពោះបន្សំ Bluetooth/802.15.4 ផ្សេងទៀត។

កម្មវិធីកំណត់ពេលចាប់ផ្តើមដោយការមានប្រតិបត្តិការទទួលផ្ទៃខាងក្រោយ Zigbee អាទិភាពទាប។ នេះតំណាងឱ្យរ៉ោតទ័របើកជានិច្ច ដែលប្រហែលជាត្រូវការទទួលកញ្ចប់ព័ត៌មាន IEEE 802.15.4 នៅពេលមិនស្គាល់។ ការភ្ជាប់ប៊្លូធូស LE ក៏សកម្មផងដែរ ហើយតម្រូវឱ្យជង់រួចរាល់ដើម្បីទទួលរាល់ 30 ms។ ជង់ប៊្លូធូស LE អាចកំណត់ពេលវាបានល្អជាមុន ដោយសារលក្ខណៈដែលអាចកំណត់បាននៃការតភ្ជាប់។

កាលវិភាគអាទិភាព

នេះ​ផ្តល់​នូវ​អតីត​មូលដ្ឋានample នៃការវិនិច្ឆ័យអាទិភាពនៃប្រតិបត្តិការវិទ្យុផ្សេងៗគ្នា។

ជង់ Zigbee សម្រេចថាវាត្រូវការផ្ញើកញ្ចប់ព័ត៌មាន។ វាអាចធ្វើវាជាព្រឹត្តិការណ៍តាមតម្រូវការ មានន័យថាជង់សម្រេចចិត្តថាវាចង់ផ្ញើកញ្ចប់ព័ត៌មានឥឡូវនេះដោយមិនជូនដំណឹងដល់អ្នករៀបចំកាលវិភាគជាមុន។ នេះគឺផ្ទុយទៅនឹងរបៀបដែលប៊្លូធូស LE ដំណើរការ ដែលប្រតិបត្តិការដែលបានកំណត់ពេលត្រូវបានគេដឹងជាមុន។ អ្នកកំណត់ពេលវាយតម្លៃថាវាអាចទៅរួចក្នុងប្រតិបត្តិការវិទ្យុ Zigbee TX 1 ហើយនៅតែបម្រើព្រឹត្តិការណ៍ទទួល Bluetooth LE អាទិភាពខ្ពស់ជាងនេះនាពេលអនាគត។ ដូច្នេះកម្មវិធីកំណត់ពេលអនុញ្ញាតឱ្យព្រឹត្តិការណ៍បញ្ជូនកើតឡើង។ ជង់ Zigbee អនុវត្តរាល់បំណែកនៃប្រតិបត្តិការបញ្ជូននេះ (រង់ចាំ MAC ack) ហើយបន្ទាប់មកផ្តល់លទ្ធផលដោយស្ម័គ្រចិត្ត។ ពេលវេលាប្រតិបត្តិការប៉ាន់ស្មាននៃប្រតិបត្តិការវិទ្យុបញ្ជូន Zigbee មិនរួមបញ្ចូលការព្យាយាមម្តងទៀតទេ។

នៅក្នុងនេះ អតីតampដូច្នេះ ប៊្លូធូស LE ត្រូវបានកំណត់ពេលរួចជាស្រេចក្នុងការទទួលនាពេលអនាគត ហើយជង់ Zigbee ចង់បញ្ជូន។ សម្រាប់ប្រតិបត្តិការវិទ្យុ Zigbee TX 1 ដំបូងមានពេលគ្រប់គ្រាន់មុនពេលប្រតិបត្តិការវិទ្យុ Bluetooth LE RX 1 ដូច្នេះកម្មវិធីកំណត់ពេលអនុញ្ញាតឱ្យជង់ធ្វើប្រតិបត្តិការ។ ក្រោយមក នៅពេលដែលជង់ Zigbee ព្យាយាមកំណត់ពេល Zigbee TX 2 កម្មវិធីកំណត់ពេលកំណត់ថាមិនមានពេលវេលាគ្រប់គ្រាន់មុនពេលព្រឹត្តិការណ៍ Bluetooth LE RX 2 អាទិភាពខ្ពស់។ ទោះយ៉ាងណាក៏ដោយ ជង់ Zigbee បានបង្ហាញថាសកម្មភាពនេះអាចរំលងពេលវេលាចាប់ផ្តើមរបស់វា។ កម្មវិធីកំណត់ពេលវិទ្យុកំណត់ថាបានផ្តល់ឱ្យរយៈពេលដែលរំពឹងទុកនៃប្រតិបត្តិការវិទ្យុ Bluetooth LE ប្រតិបត្តិការ Zigbee អាចចាប់ផ្តើមបន្ទាប់ពីព្រឹត្តិការណ៍នោះ ហើយនៅតែស្ថិតក្នុងរយៈពេលរអិលដែលបង្ហាញដោយជង់ Zigbee ។

ប្រសិនបើអ្វីៗដំណើរការដូចការរំពឹងទុក ប្រតិបត្តិការបញ្ជូន Zigbee នឹងមានការប៉ុនប៉ងលើកដំបូងរបស់វាកើតឡើងដោយមិនមានការបរាជ័យណាមួយដោយសារការកំណត់កាលវិភាគ។

ការរំខានអាទិភាព Example

អតីតample បង្ហាញពីប្រតិបត្តិការដែលមានអាទិភាពខ្ពស់ដែលរំខានដល់អាទិភាពទាបជាងមួយ។

 

 

 

អតីតample ចាប់ផ្តើមតាមរបៀបដូចគ្នានឹងអតីតពីមុនampលេ Zigbee និង Bluetooth LE ទាំងពីរមានប្រតិបត្តិការវិទ្យុដែលត្រូវបានកំណត់ពេលដោយគ្មានការប៉ះទង្គិចណាមួយឡើយ។

ក្រោយមកជង់ Zigbee សម្រេចចិត្តថាខ្លួនចង់ផ្ញើកញ្ចប់ព័ត៌មានផ្សេងទៀតសម្រាប់ព្រឹត្តិការណ៍ Zigbee TX 2 ។ កម្មវិធីកំណត់ពេលកំណត់ថា វាគួរតែអាចកំណត់ពេលព្រឹត្តិការណ៍នេះ និងផ្តល់សេវាកម្មដល់ព្រឹត្តិការណ៍ Bluetooth LE RX 2 នៅពេលក្រោយ ដោយផ្អែកលើពេលវេលាដែលព្រឹត្តិការណ៍ Zigbee TX 2 ត្រូវតែធ្វើឡើង។ ទោះជាយ៉ាងណាក៏ដោយ ព្រឹត្តិការណ៍ Zigbee TX 2 ចំណាយពេលយូរជាងការរំពឹងទុក ដោយសារការត្រលប់មកវិញដោយចៃដន្យយូរហើយមិនផ្តល់លទ្ធផលទាន់ពេល។ នេះបណ្តាលឱ្យព្រឹត្តិការណ៍ប៉ះទង្គិចគ្នាជាមួយនឹង rad peration អាទិភាពខ្ពស់ជាង ហើយដូច្នេះ Radio Scheduler រំខានព្រឹត្តិការណ៍ Zigbee ហើយត្រឡប់ការបរាជ័យទៅជង់កម្រិតខ្ពស់។ ព្រឹត្តិការណ៍ប៊្លូធូស LE របស់ Th កើតឡើងជាធម្មតា ហើយនៅពេលដែលវាត្រូវបានបញ្ចប់ វានឹងផ្តល់លទ្ធផលដោយស្ម័គ្រចិត្តចំពោះប្រតិបត្តិការដែលមានអាទិភាពទាបជាងណាមួយ។

នៅពេលទទួលបានការបរាជ័យពីកម្មវិធីកំណត់ពេលវិទ្យុ ជង់ Zigbee ភ្លាមៗព្យាយាមព្យាយាមសារ MAC ម្តងទៀត។ វាកំណត់ពេលប្រតិបត្តិការ និងរួមបញ្ចូលពេលវេលារអិល។ នៅពេលនេះ ជង់ប៊្លូធូស LE មានអាទិភាពលើវិទ្យុ ហើយដូច្នេះប្រតិបត្តិការមិនអាចចាប់ផ្តើមនៅឡើយទេ ប៉ុន្តែអ្នកកំណត់ពេលទទួលយកប្រតិបត្តិការវិទ្យុថ្មី។ ជង់ប៊្លូធូស LE បញ្ចប់ការទទួលតាមកាលវិភាគរបស់វា ហើយផ្តល់លទ្ធផលវិទ្យុ។ បន្ទាប់មកកម្មវិធីកំណត់ពេលធ្វើឱ្យប្រតិបត្តិការបញ្ជូន Zigbee កើតឡើង ព្រោះវានៅតែស្ថិតក្នុងចន្លោះពេលនៃការចាប់ផ្តើមប្រតិបត្តិការដំបូង។ បន្ទាប់ពីការបញ្ជូនបានបញ្ចប់ កម្មវិធីកំណត់ពេលត្រឡប់ទៅប្រតិបត្តិការទទួលផ្ទៃខាងក្រោយវិញ។

ប្រតិបត្តិការអាទិភាពខ្ពស់ដែលត្រូវបានពង្រីក

អតីតample បង្ហាញពីអ្វីដែលកើតឡើងនៅពេលដែលប្រតិបត្តិការអាទិភាពខ្ពស់ត្រូវចំណាយពេលយូរជាងការរំពឹងទុកដំបូង ហើយបណ្តាលឱ្យប្រតិបត្តិការដែលមានអាទិភាពទាបបាត់បង់ឱកាសរបស់វា។

ក្នុងករណីនេះ ប៊្លូធូស LE មានការទទួលតាមកាលវិភាគដែលកំពុងតែប្រព្រឹត្តទៅ។ Zigbee សម្រេច​ចិត្ត​ផ្ញើ​កញ្ចប់​ព័ត៌មាន ប៉ុន្តែ​វា​មិន​អាច​ដំណើរការ​បាន​ទេ​ឥឡូវ​នេះ។ កម្មវិធីកំណត់ពេលទទួលយកប្រតិបត្តិការក្រោមការសន្មត់ថាព្រឹត្តិការណ៍ Bluetooth LE នឹងបញ្ចប់មុនពេលចុងបញ្ចប់នៃពេលវេលារអិលនៃព្រឹត្តិការណ៍ Zigbee ។ ទោះជាយ៉ាងណាក៏ដោយ ព្រឹត្តិការណ៍ Bluetooth LE អូសបន្លាយយូរជាងនេះ ដោយសារតែកញ្ចប់ព័ត៌មានបន្ថែមត្រូវបានផ្ញើរវាងឧបករណ៍។ ប្រតិបត្តិការប៊្លូធូស LE មានអាទិភាព ដូច្នេះប្រតិបត្តិការ Zigbee នៅទីបំផុតនឹងអស់ការរអិល។ កំហុសមួយត្រូវបានត្រលប់ទៅជង់វិញ។ Zigbee សម្រេចចិត្តបញ្ជូនកញ្ចប់ព័ត៌មានឡើងវិញ។ ជាថ្មីម្តងទៀត ជង់ Zigbee បង្ហាញថាប្រតិបត្តិការគួរតែចាប់ផ្តើមឥឡូវនេះ ប៉ុន្តែអាចនឹងធ្លាក់ចុះទៅអនាគត។ កម្មវិធីកំណត់ពេលកំពុងស្ថិតនៅចំកណ្តាលនៃការផ្លាស់ប្តូរការកំណត់រចនាសម្ព័ន្ធវិទ្យុ ដូច្នេះវាមិនអាចចាប់ផ្តើមប្រតិបត្តិការភ្លាមៗបានទេ។ ផ្ទុយទៅវិញ វាធ្វើឱ្យពេលវេលាចាប់ផ្តើមប្រតិបត្តិការវិទ្យុក្នុងចំនួនតិចតួច ហើយបន្ទាប់មកប្រតិបត្តិប្រតិបត្តិការ។

ប្រតិបត្តិការអាទិភាពខ្ពស់ដោយគ្មានការរំខាន 

នៅក្នុងនេះ អតីតample កម្មវិធីកំណត់ពេលវិទ្យុកំពុងដំណើរការលើថ្នាំងដែលដើរតួជាឧបករណ៍ភ្ជាប់ប៊្លូធូស LE ហើយថ្នាំងនោះមានការតភ្ជាប់មួយចំនួនទៅកាន់ឧបករណ៍កណ្តាលផ្សេងៗគ្នា។ វាក៏មានកម្មវិធីផ្សាយពាណិជ្ជកម្មតាមកាលកំណត់ដែលត្រូវបានបញ្ជូនផងដែរ។ តួរលេខខាងក្រោមបង្ហាញពីករណីដែលព្រឹត្តិការណ៍ទាំងនេះកំពុងកើតឡើងស្ទើរតែត្រលប់មកវិញ និងមិនអនុញ្ញាតឱ្យមានពេលវេលាគ្រប់គ្រាន់ដើម្បីប្តូរត្រលប់ទៅការកំណត់វិទ្យុ Zigbee វិញ។ ដូច្នេះវានឹងបង្កើតរយៈពេលមួយដែលជង់ Zigbee គឺ
មិន​អាច​បញ្ជូន​បាន​សូម្បី​តែ​ពេល​វេលា​រអិល​។

Zigbee សួរអ្នកកំណត់ពេលកំណត់ពេលប្រតិបត្តិការវិទ្យុ។ ទោះបីជាអ្នកកំណត់ពេលដឹងថាព្រឹត្តិការណ៍នឹងបរាជ័យដោយសារតែប្រតិបត្តិការដែលមានអាទិភាពខ្ពស់ជាងមុនដែលបានកំណត់ពេលវានៅតែទទួលយកព្រឹត្តិការណ៍ដែលបានកំណត់ពេល។ នេះត្រូវបានធ្វើសម្រាប់ហេតុផលពីរ។ ទីមួយ កាលៈទេសៈអាចផ្លាស់ប្តូរ ហើយព្រឹត្តិការណ៍អាចត្រូវបានប្រតិបត្តិ។ ទីពីរ ជង់ដែលអង្គុយនៅលើកំពូលនៃកម្មវិធីកំណត់ពេលវិទ្យុអាចព្យាយាមសាកល្បងសកម្មភាពម្តងទៀត។ ប្រសិនបើលទ្ធផលនៃការកំណត់ពេលបរាជ័យត្រូវបានបញ្ជូនមកវិញភ្លាមៗ នោះការព្យាយាមរបស់ជង់ដើម្បីព្យាយាមម្តងទៀតទំនងជាមិនជោគជ័យទេព្រោះគ្មានពេលវេលាកន្លងផុតទៅ។ ជំនួសមកវិញ ដោយការតម្រង់ជួរព្រឹត្តិការណ៍ និងត្រឡប់ការបរាជ័យវិញបន្ទាប់ពីពេលវេលារអិលបានផុតកំណត់ ការព្យាយាមម្តងទៀត (ជាមួយនឹងពេលវេលារអិលរបស់វាផ្ទាល់) មានឱកាសជោគជ័យប្រសើរជាងមុន ដោយសារសំណុំនៃប្រតិបត្តិការវិទ្យុនាពេលខាងមុខនឹងខុសគ្នា។

ទទួលនៅពេលដែលប្រតិបត្តិការអាទិភាពខ្ពស់ជាងកំពុងដំណើរការ 

អតីតample បង្ហាញពីអ្វីដែលកើតឡើងនៅពេលដែលប៊្លូធូស LE សកម្ម ហើយប្រតិបត្តិការដែលមានអាទិភាពទាបជាងនេះនឹងត្រូវបានទទួលទិន្នន័យ។

ក្នុងករណីដំបូង នៅពេលដែលសារ IEEE 802.15.4 ត្រូវបានផ្ញើ ហើយជង់ប៊្លូធូស LE កំពុងប្រើប្រាស់វិទ្យុសម្រាប់ការទទួលសកម្ម ជង់ Zigbee នឹងមិនមានអ៊ីនធឺណិតដើម្បីទទួលសារនោះទេ។ ទោះជាយ៉ាងណាក៏ដោយ អ្នកផ្ញើ Zigbee នៃសារនឹងព្យាយាមម្តងទៀតក្នុងករណីភាគច្រើន ហើយជាមួយនឹងការថយក្រោយ និងការផ្លាស់ប្តូរពេលវេលាផ្សេងទៀតនឹងមិនមានបញ្ហាជាមួយនឹងអាទិភាពខ្ពស់ផ្សេងទៀតដែលបានកំណត់ពេល ប៊្លូធូស ទទួលបានព្រឹត្តិការណ៍ដែលទំនងជាមិនប៉ះទង្គិចគ្នានោះទេ។ សារ Zigbee ត្រូវបានទទួលដោយជោគជ័យ

ករណីទីពីរបង្ហាញថា ក្នុងករណីទទួលសកម្ម ជង់ Zigbee អាចនៅតែត្រូវបានរំខាន និងមិនទទួលបាន (ឬ ACK) សារ។ ការទំនាក់ទំនងជោគជ័យពឹងផ្អែកលើការព្យាយាមម្តងទៀតនៅ MAC ឬស្រទាប់ខ្ពស់ជាងនេះ ដើម្បីផ្ញើសារនេះម្តងទៀត ហើយផ្ទៀងផ្ទាត់ថាឧបករណ៍ Dynamic Multiprotocol ទទួលបានសារ។

ខណៈពេលដែលអាចមានការពិចារណាថាតើការទទួលសកម្មគួរត្រូវបានរំខាន ឬអត់នោះ វាជាការលំបាកសម្រាប់អ្នករៀបចំកាលវិភាគដើម្បីធ្វើការសម្រេចចិត្តនោះ។ ជាទូទៅ ភាពរឹងមាំនៃពិធីការគួរតែអនុញ្ញាតឱ្យសារត្រូវបានទទួលដោយជោគជ័យ ទោះបីជាមានការរំខានក៏ដោយ។

ការអនុវត្ត Multiprotocol ជាមួយ 802.15.4-Based Stack

ជំពូកនេះផ្តល់នូវព័ត៌មានទូទៅអំពីការអនុវត្តជង់ដែលមានមូលដ្ឋានលើ 802.15.4 ដូចជា Zigbee ឬ Connect ជាផ្នែកនៃកម្មវិធីពហុប្រូតូកូល។ សម្រាប់ព័ត៌មានលម្អិតអំពីរបៀបកំណត់ plugins និងព័ត៌មានលម្អិតផ្សេងទៀតដែលជាក់លាក់ចំពោះពិធីការ rticular សូមមើលកំណត់ចំណាំកម្មវិធីមួយខាងក្រោម៖

• AN1133៖ ការអភិវឌ្ឍន៍ពហុប្រូតូកូលថាមវន្តជាមួយប៊្លូធូស និង Zigbee EmberZNet SDK 6.x និងទាបជាង
•  AN1209៖ ការអភិវឌ្ឍន៍ពហុប្រូតូកូលថាមវន្តជាមួយប៊្លូធូស និងភ្ជាប់

ការគាំទ្រពិធីការឥតខ្សែ

ពិធីការឥតខ្សែផ្សេងគ្នាមានលក្ខណៈខុសៗគ្នាដែលត្រូវបានប្រើប្រាស់ជាមួយនឹងការរចនានៃ Dynamic Multiprotocol។ សម្រាប់អតីតample, ប៊្លូធូសថាមពលទាបគឺមានភាពតឹងរ៉ឹង និងអាចព្យាករណ៍បាននៅក្នុងកាលវិភាគនៃប្រតិបត្តិការវិទ្យុរបស់វា។ ចន្លោះពេលផ្សាយពាណិជ្ជកម្ម និងការតភ្ជាប់កើតឡើងនៅពេលវេលាកំណត់។ ផ្ទុយទៅវិញ ពិធីការ 802.15.4 មានភាពបត់បែនជាងមុនក្នុងការកំណត់ពេលវេលានៃព្រឹត្តិការណ៍សារជាច្រើន។ CSMA (ការចូលប្រើច្រើននៃក្រុមហ៊ុនដឹកជញ្ជូន) នៅក្នុង IEEE 802.15.4 បន្ថែមការថយក្រោយដោយចៃដន្យ ដូច្នេះការពន្យារពេលព្រឹត្តិការណ៍គឺស្ថិតនៅលើលំដាប់នៃមិល្លីវិនាទី។ វាអនុញ្ញាតឱ្យសារ IEEE 802.15.4 ត្រូវបានផ្ញើជុំវិញព្រឹត្តិការណ៍ Bluetooth Low Energy ហើយនៅតែទទួលបានដោយភាពជឿជាក់

802.15.4 អាទិភាពផ្លូវដែក

ពិធីការ 802.15.4 បច្ចុប្បន្នមានអាទិភាព RAIL បី។

ទេ	ឈ្មោះ	ការកំណត់លំនាំដើម	លក្ខណៈវិនិច្ឆ័យចាកចេញ
1	TX សកម្ម	100	MAC ACK បានទទួល (ឬអត់)
2	RX សកម្ម	255	កញ្ចប់ត្រូវបានត្រង ឬ MAC ACK បានផ្ញើ
3	ផ្ទៃខាងក្រោយ RX	255	កិច្ចការដែលមានអាទិភាពខ្ពស់ជាងនេះ។

ប្រសិនបើ Active TX ត្រូវបានប្រតិបត្តិ វិទ្យុនឹងត្រូវបានចេញផ្សាយនៅពេលដែលការទទួលស្គាល់ MAC ដែលត្រូវគ្នាត្រូវបានទទួល (ឬអស់ពេលបានកើតឡើង)។

ផ្ទៃខាងក្រោយ RX នឹងចាកចេញពីវិទ្យុនៅក្នុងស្ថានភាពទទួល ត្រៀមខ្លួនជាស្រេចដើម្បីទទួលសារអសមកាល។ ប្រសិនបើអាទិភាព RX សកម្មខុសពីអាទិភាព RX ផ្ទៃខាងក្រោយ នោះអាទិភាពទទួលនឹងត្រូវបានលើកឡើងនៅពេលណាដែលពាក្យធ្វើសមកាលកម្មត្រូវបានរកឃើញ ហើយគ្រាន់តែបន្ទាបនៅពេលដែលកញ្ចប់ព័ត៌មាននោះត្រូវបានត្រង ឬបញ្ចប់ ហើយ ACK របស់វាត្រូវបានផ្ញើប្រសិនបើមានសំណើមួយ។

តុល្យភាពអាទិភាព

ដូចដែលបានពន្យល់នៅក្នុងផ្នែក 6.1 អាទិភាពប៊្លូធូស តាមលំនាំដើម ជួរអាទិភាពប៊្លូធូសត្រូវបានគូសវាសទៅក្នុងជួរអាទិភាព RAIL 16 – 32។ ជាទូទៅ ប៊្លូធូសចាប់ផ្តើមដោយប្រើអាទិភាពទាប (32) ហើយបង្កើនអាទិភាពយ៉ាងសកម្មរហូតដល់អតិបរមា (16) ជា ត្រូវការប្រសិនបើសារមិនជោគជ័យ។

ដូចដែលបានពិពណ៌នានៅក្នុងផ្នែកមុន ជង់ដែលមានមូលដ្ឋានលើ 802.15.4 ដូចជា Zigbee ឬ Connect ប្រើតម្លៃអាទិភាព RAIL លំនាំដើមនៃ 255 សម្រាប់ផ្ទៃខាងក្រោយ RX, 255 សម្រាប់ RX សកម្ម និង 100 សម្រាប់ TX សកម្ម។

ជាលទ្ធផលនៃអាទិភាព RAIL លំនាំដើមទាំងនេះ នៅក្នុងកម្មវិធី 802.15.4 protocol-Bluetooth multiprotocol តាមលំនាំដើម ចរាចរណ៍ប៊្លូធូសនឹងតែងតែមានអាទិភាពលើចរាចរណ៍ពិធីការ 802.15.4។ នេះគឺជាជម្រើសដ៏ល្អសម្រាប់កម្មវិធីជាច្រើន ពីព្រោះចរាចរណ៍ប៊្លូធូសមានតម្រូវការពេលវេលាតឹងរ៉ឹង មិនដូចពិធីការ 802.15.4 ទេ។ ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើការផ្ទុកចរាចរណ៍ប៊្លូធូសខ្ពស់ខ្លាំង (សម្រាប់ឧample ការផ្ញើទិន្នន័យជាច្រើនដោយប្រើចន្លោះពេលតភ្ជាប់តូចបំផុត) វាអាចទៅរួចសម្រាប់ចរាចរពិធីការ 802.15.4 ដែលត្រូវបានរារាំងទាំងស្រុងពីការចូលប្រើវិទ្យុ ដោយសារអាទិភាពរបស់វាទាប និងបង្អួចតូចបំផុតនៃពេលវេលាវិទ្យុដែលនៅសេសសល់ដោយប៊្លូធូស។ ចរាចរណ៍

ចំណាំ៖ ព័ត៌មានខាងក្រោមបច្ចុប្បន្នអាចអនុវត្តបានតែចំពោះជង់ EmberZNet Zigbee ប៉ុណ្ណោះ។ Silicon Labs Connect មិនទាន់មាន API ដែលត្រូវការដើម្បីផ្លាស់ប្តូរអាទិភាពនោះទេ។

ប្រសិនបើអ្នកកំពុងបង្កើតកម្មវិធីពហុប្រូតូកូលថាមវន្តដែលមានមូលដ្ឋានលើ 802.15.4 ហើយវាមានសារៈសំខាន់សម្រាប់ចរាចរនោះដើម្បីជោគជ័យក្នុងវត្តមាននៃចរាចរណ៍ប៊្លូធូសដែលមានផ្ទុកខ្ពស់ អ្នកអាចកែតម្រូវអាទិភាពលំនាំដើមដូចបង្ហាញក្នុងតារាងខាងក្រោមដោយប្រើ API ខាងក្រោម៖

ទេ	ឈ្មោះ	ការកំណត់លំនាំដើម
1	TX សកម្ម	23
2	RX សកម្ម	24
3	ផ្ទៃខាងក្រោយ RX	255

ដោយសារតែប៊្លូធូសដំបូងកំណត់អាទិភាព RAIL របស់វាដល់ 32 ការកំណត់អាទិភាព 802.15.4 ទាំងនេះផ្តល់ឱ្យចរាចរណ៍ 802.15.4 អាទិភាពខ្ពស់ជាងប៊្លូធូសដំបូង ដែលផ្តល់ឱ្យពិធីការ 802.15.4 នូវឱកាសក្នុងការបញ្ជូន ឬទទួលចរាចរណ៍ដោយជោគជ័យ សូម្បីតែនៅក្នុងវត្តមានរបស់ ការផ្ទុកខ្ពស់នៃចរាចរណ៍ប៊្លូធូស។ ម្យ៉ាងវិញទៀត ប៊្លូធូសនឹងបង្កើនអាទិភាពរបស់វាជាលក្ខណៈថាមវន្ត ប្រសិនបើវាត្រូវបានរារាំងពីកម្មវិធីកំណត់ពេលដោយចរាចរណ៍ 802.15.4 រហូតដល់អាទិភាពខ្ពស់ 16។ ដូច្នេះបន្ទាប់ពីអនុញ្ញាតឱ្យពិធីការ 802.15.4 ចូលប្រើវិទ្យុដំបូង ប៊្លូធូសនឹងប្រើប្រាស់ អាទិភាពលើការព្យាយាមបន្តបន្ទាប់ប្រសិនបើចាំបាច់។

វិធីសាស្រ្តនេះអនុញ្ញាតឱ្យពិធីការទាំងពីរធ្វើការសម្របសម្រួលលើការប្រើប្រាស់វិទ្យុរបស់ពួកគេ ដោយគ្មាននរណាម្នាក់អាចគ្រប់គ្រងបានទាំងស្រុងលើមួយផ្សេងទៀត។

. ការអនុវត្ត Multiprotocol ជាមួយ RAIL 

ជំពូកនេះផ្តល់ព័ត៌មានបន្ថែមអំពីលក្ខណៈពិសេសរបស់ RAIL សម្រាប់អ្នកប្រើប្រាស់ដែលប្រើប្រាស់ RAIL API ដោយផ្ទាល់ដើម្បីបង្កើតពិធីការដែលមានកម្មសិទ្ធិ។ ជាពិសេសវាផ្តល់នូវព័ត៌មានលម្អិតអំពីរបៀបធ្វើការជាមួយ RAIL APIs ដើម្បីដោះស្រាយករណីកម្មវិធីកំណត់ពេលវិទ្យុជាក់លាក់។

Examples ជាមួយ Background Receive, Yield Radio និង State Transition

មូលដ្ឋានគ្រឹះនៃប្រព័ន្ធអាទិភាព RAIL Multiprotocol គឺត្រង់ដោយស្មើភាព៖ ព្រឹត្តិការណ៍វិទ្យុដែលមានអាទិភាពខ្ពស់ជាង (ពោលគឺចំនួនតូចជាង) នឹងតែងតែដណ្តើមយកព្រឹត្តិការណ៍វិទ្យុផ្សេងទៀតដែលមានអាទិភាពទាបជាង។ ទោះយ៉ាងណាក៏ដោយ ប្រធានបទនេះកាន់តែស្មុគស្មាញនៅពេលពិចារណាលើការផ្លាស់ប្តូររដ្ឋ និង APIs ដូចជា RAIL_StartRx() ដែលដាក់វិទ្យុទៅក្នុងស្ថានភាពជាក់លាក់មួយក្នុងរយៈពេលមិនកំណត់។ ផ្នែក​នេះ​ផ្ដល់​នូវ​ការ​បង្ហាញ​ខ្លះ​អំពី​អតីតamples ដើម្បីបង្ហាញពីរបៀបដែលស្ថានភាពគ្មានដែនកំណត់ទាំងនេះត្រូវបានគ្រប់គ្រង និងរបៀបដែលស្រទាប់កម្មវិធីអាចប្រើ APIs ដូចជា RAIL_YieldRadio() ដើម្បីគ្រប់គ្រងពួកវា។ អតីតamples មានដូចខាងក្រោម:

• ការផ្លាស់ប្តូររដ្ឋជាមួយនឹងពិធីសារតែមួយ
• ការផ្លាស់ប្តូររដ្ឋជាមួយនឹងពិធីការពីរ
• ការផ្លាស់ប្តូររដ្ឋជាមួយនឹងពិធីការពីរ និងបង្កើនអាទិភាពឯកត្តកម្ម

នៅក្នុងទាំងនេះ examples, RAIL_StartTx() គឺជាប្រភពនៃព្រឹត្តិការណ៍ TX ដែលរំខានដល់ផ្ទៃខាងក្រោយ RX ។ ចំណាំ, ទោះជាយ៉ាងណា, ថាទាំងនេះ examples អាចអនុវត្តបានចំពោះ API វិទ្យុណាមួយ លើកលែងតែ RAIL_StartRx()។ នៅក្នុងពាក្យផ្សេងទៀត, អតីតamples អាចអនុវត្តបានចំពោះ API ណាមួយដែលចាប់ផ្តើមព្រឹត្តិការណ៍វិទ្យុដែលមិនមែនជា RX ផ្ទៃខាងក្រោយ

ទាំងនេះ អតីតamples បង្ហាញពីឥរិយាបថពហុប្រូតូកូលដែលរំពឹងទុកទាក់ទងនឹងការផ្លាស់ប្តូររដ្ឋ។ សង្ខេប:

• នៅក្នុងការផ្លាស់ប្តូររដ្ឋ រដ្ឋថ្មីត្រូវបានចាត់ទុកជាផ្នែកបន្ថែមមិនកំណត់នៃព្រឹត្តិការណ៍ដើមនៅអាទិភាពដូចគ្នានោះ រហូតដល់ RAIL_YieldRadio() ត្រូវបានហៅ។
• ព្រឹត្តិការណ៍ RX ផ្ទៃខាងក្រោយមិនត្រូវបានប៉ះពាល់ដោយ RAIL_YieldRadio() ទេ។ មានតែ RAIL_Idle() ប៉ុណ្ណោះដែលអាចលុបពិធីការចេញពីស្ថានភាព RX ផ្ទៃខាងក្រោយជាអចិន្ត្រៃយ៍។
• ព្រឹត្តិការណ៍ដែលមានអាទិភាពខ្ពស់ជាងនឹងតែងតែដណ្តើមយកព្រឹត្តិការណ៍ដែលមានអាទិភាពទាប ដោយមិនគិតពីការហៅ API ផ្សេងទៀតឡើយ។
• មានតែការទទួល RAIL_StartRx() ប៉ុណ្ណោះដែលអាច 'ត្រឡប់ទៅកាន់' ពីព្រឹត្តិការណ៍ដែលមានអាទិភាពខ្ពស់ជាងតាមរយៈ RAIL_YieldRadio() ឬ RAIL_Idle()។
• ព្រឹត្តិការណ៍វិទ្យុទាំងអស់ក្រៅពី RAIL_StartRx() ទាមទារ RAIL_YieldRadio() ដើម្បីបញ្ចប់ និងដំណើរការទៅព្រឹត្តិការណ៍បន្ទាប់។
• ការហៅទៅកាន់ RAIL_YieldRadio() មិនអាចជំនួសដោយ RAIL_Idle() បានទេ។ RAIL_Idle() ជម្រះព្រឹត្តិការណ៍ទាំងអស់សម្រាប់ពិធីការដែលបានផ្តល់ឱ្យ

.ការផ្លាស់ប្តូររដ្ឋជាមួយនឹងពិធីសារតែមួយ

នេះអតីតample ពិនិត្យឥរិយាបថរបស់វិទ្យុដោយប្រើពិធីការតែមួយ (នោះគឺជាកន្លែងដែល AIL_Handle_t ដូចគ្នាត្រូវបានប្រើសម្រាប់ការហៅមុខងារវិទ្យុទាំងអស់)។ វិទ្យុចាប់ផ្តើមនៅក្នុង RX ជាមួយនឹងការហៅដំបូងទៅកាន់ RAIL_StartRx() បន្ទាប់មកផ្លាស់ទីទៅ TX ជាមួយនឹងការហៅអាទិភាពខ្ពស់ទៅ RAIL_StartTx() ។ វាជាការសំខាន់ក្នុងការកត់សម្គាល់ថាបន្ទាប់ពីការបញ្ជូនត្រូវបានធ្វើរួច ការផ្លាស់ប្តូរវិទ្យុទៅរដ្ឋដែលបានបញ្ជាក់ដោយ RAIL_SetTxTransitions() ហើយវាស្ថិតនៅក្នុងរដ្ឋដោយគ្មានកំណត់នៅអាទិភាពដូចគ្នា និងឆានែល TX រហូតដល់ RAIL_YieldRadio() ត្រូវបានហៅ។ បន្ទាប់ពីនោះ វិទ្យុត្រឡប់ទៅ RX វិញ ដោយមានអាទិភាព និងប៉ុស្តិ៍ដែលបានបញ្ជាក់ដំបូង។

តម្រូវការក្នុងការផ្តល់ទិន្នផលវិទ្យុយ៉ាងសកម្ម ហើយដូច្នេះ RAIL_YieldRadio() API គឺចាំបាច់ភាគច្រើនដោយសារតែ ACK'ing ។ ទស្សនវិជ្ជានៃការរចនាគឺថាព្រោះទាំង TX និង ACK ដែលទទួលបានគឺ viewed ជាផ្នែកមួយនៃប្រតិបត្តិការដូចគ្នា ប្រសិនបើថ្នាំងបញ្ជូន និងរំពឹងថា ACK វាគួរតែអាចផ្លាស់ប្តូរទាំងពីរទៅ RX និងបន្តស្តាប់ ACK ដែលជាផ្នែកមួយនៃប្រតិបត្តិការដូចគ្នា (ហើយដូច្នេះអាទិភាពដូចគ្នា) ដូច TX ដើម។ ទោះជាយ៉ាងណាក៏ដោយជាទូទៅ RAIL ដោយខ្លួនឯងមិនអាចដឹងថាតើត្រូវការ ACK ឬអត់នោះទេ។ វាអាចអាស្រ័យលើកត្តាផ្សេងទៀត ដូចជាមាតិកាកញ្ចប់ព័ត៌មាន ឬតក្កវិជ្ជាកម្មវិធីផ្សេងទៀត ហើយដូច្នេះមិនអាចកំណត់ដោយសាមញ្ញដោយពិនិត្យមើលថាតើ ACK'ing ត្រូវបានកំណត់រចនាសម្ព័ន្ធជាមួយ RAIL_ConfigAutoAck()។ ដូច្នេះហើយ ការសម្រេចចិត្តនៅពេលប្រតិបត្តិការវិទ្យុត្រូវបានបញ្ចប់។ ការចាត់តាំង/ជង់។

ក្នុងករណីដែល ACK មិនត្រូវបានទាមទារនោះ Silicon Labs ណែនាំឱ្យហៅទៅ RAIL_YieldRadio() ជាផ្នែកមួយនៃការដោះស្រាយព្រឹត្តិការណ៍ RAIL_EVENT_TX_PACKET_SENT ។ ការ​ធ្វើ​បែប​នេះ​ធ្វើ​ឱ្យ​បន្ទាត់​ពណ៌​បៃតង​ក្នុង​រូប​ខាង​លើ​ត្រូវ​បាន​បង្រួម​អប្បបរមា​រហូត​ដល់​ពេល​វេលា​ដែល​រំខាន។ ប្រសិនបើកម្មវិធីរំពឹងថានឹងមាន ACK នោះ RAIL_YieldRadio() គួរតែត្រូវបានហៅនៅពេលដែល ACK ត្រូវបានទទួល ឬត្រូវបានចាត់ទុកថាអស់ពេលហើយ។

ការផ្លាស់ប្តូររដ្ឋជាមួយនឹងពិធីការពីរ

សេណារីយ៉ូនេះស្រដៀងនឹងសេណារីយ៉ូដំបូងដែលទាក់ទងនឹងការផ្លាស់ប្តូររដ្ឋបន្ទាប់ពី TX ប៉ុន្តែណែនាំពិធីការមួយផ្សេងទៀត។

ក្នុងស្ថានភាពនេះ វាជារឿងសំខាន់ក្នុងការកត់សម្គាល់ថា RAIL_StartRx() អាចត្រូវបានហៅនៅពេលណាមួយក្នុងអំឡុងពេលប្រតិបត្តិការ TX ។ ដរាបណាអាទិភាពរបស់វាតិចជាង ឬស្មើនឹងអាទិភាពនៃ TX នោះ RX នឹងមិនចូលជាធរមានទេ រហូតទាល់តែកម្មវិធីហៅ _Yield Radio() នៅលើ Protocol A។ នៅពេលដែល RAIL_StartRx() ត្រូវបានហៅកំឡុងពេល TX RX គឺគ្រាន់តែ បានបន្ថែមទៅជួរនៃព្រឹត្តិការណ៍ដែលត្រូវដោះស្រាយ។

ចំណុចសំខាន់មួយទៀតគឺថា ទោះបីជា RAIL_YieldRadio() នៅលើ Protocol A នឹងផ្លាស់ប្តូរពី TX នៅលើ Protocol A ទៅ RX នៅលើ Protocol B ក៏ដោយ RAIL_Idle() នៅលើ Protocol B គឺត្រូវបានទាមទារដើម្បីផ្លាស់ប្តូរពី RX នៅលើ Protocol B ទៅ RX នៅលើ Protocol A។ ទស្សនវិជ្ជានៅទីនេះគឺថា Background RXs ពិតជាមិនអាចផ្តល់លទ្ធផលបានទេ ចាប់តាំងពីព្រឹត្តិការណ៍នេះពិតជាមិនដែលបញ្ចប់។ មធ្យោបាយតែមួយគត់ដើម្បីចេញគឺត្រូវបញ្ឈប់ Background RX ដោយការហៅទៅកាន់ RAIL_Idle()។

 ការផ្លាស់ប្តូររដ្ឋជាមួយនឹងពិធីការពីរ និងអាទិភាពបង្កើន monotonically

សេណារីយ៉ូចុងក្រោយគឺស្ទើរតែដូចគ្នាទៅនឹងករណីមុន លើកលែងតែការហៅទៅកាន់ RAIL_StartRx() នៅលើពិធីការ B មានអាទិភាពខ្ពស់ជាងការហៅទៅកាន់ RAIL_StartTx() នៅលើពិធីការ A។

ក្នុងករណីនេះ ដោយសារអាទិភាពនៃ RAIL_StartRx() ទីពីរគឺខ្ពស់ជាងអាទិភាពនៃការហៅទៅកាន់ RAIL_StartTx() ការហៅទៅកាន់ RAIL_YieldRadio() គឺមិនចាំបាច់ទៀតទេ។ ដោយសារតែ RAIL_StartRx() ទីពីរមានអាទិភាពខ្ពស់ជាង វាដណ្តើមយកព្រឹត្តិការណ៍ RAIL_StartTx() ដោយគ្រប់គ្រងវិទ្យុ និងដកព្រឹត្តិការណ៍ TX ចេញពីស្ថានភាព។ នៅពេលណាមួយក្នុងអំឡុងពេលនោះ RX នៅលើពិធីការ B, RAIL_Idle() អាចត្រូវបានហៅឱ្យត្រឡប់ទៅ RX នៅលើពិធីការ A ដូចនៅក្នុងអតីតពីមុនampលេ

សូមចំណាំនៅទីនេះថានៅពេលដែលកម្មវិធីហៅទៅ RAIL_Idle() នៅលើ RX របស់ Protocol B កម្មវិធីមិនត្រលប់ទៅ TX Transition នៃ Protocol A ទេ។ ផ្ទុយទៅវិញ វាទៅខាងស្ដាំ RX ផ្ទៃខាងក្រោយ ទោះបីជាកម្មវិធីមិនដែលហៅថា RAIL_Idle() នៅលើ Protocol A's TX ។ សម្រាប់ប្រតិបត្តិការវិទ្យុដែលបានកំណត់ពេល (នោះគឺប្រតិបត្តិការវិទ្យុណាមួយដែលចាប់ផ្តើមដោយ API ផ្សេងក្រៅពី RAIL_StartRx()) នៅពេលដែលព្រឹត្តិការណ៍វិទ្យុមួយត្រូវបានដណ្តើមយកដោយព្រឹត្តិការណ៍ដែលមានអាទិភាពខ្ពស់ វាត្រូវបានដកចេញទាំងស្រុង ហើយនឹងមិនត្រលប់ទៅពេលក្រោយទេ។ មានតែការទទួលផ្ទៃខាងក្រោយប៉ុណ្ណោះ ដែលចាប់ផ្តើមដោយ RAIL_StartRx() អាចត្រូវបានរក្សានៅក្នុង thackground និង 'ត្រឡប់ទៅ' តាមរយៈការហៅទៅកាន់ RAIL_YieldRadio() ឬ RAIL_Idle()។

ដើម្បីបញ្ជាក់ពីភាពខុសគ្នារវាង RAIL_YieldRadio() និង RAIL_Idle() វាជាការសំខាន់ក្នុងការកត់សម្គាល់ថា សម្រាប់អតីតទាំងអស់នេះamples, ការហៅទៅកាន់ RAIL_YieldRadio() មិនអាចជំនួសដោយ RAIL_Idle() បានទេ។ RAIL_Idle() ជម្រះព្រឹត្តិការណ៍ទាំងអស់សម្រាប់ពិធីការដែលបានផ្តល់ឱ្យ – ទាំងផ្ទៃខាងក្រោយ (ដែលបានចាប់ផ្តើមដោយ RAIL_StartRx()) និងកាលវិភាគ (នោះគឺចាប់ផ្តើមដោយ APIs ផ្សេងពីប្រតិបត្តិការ RAIL_StartRx()) ។ RAIL_Idle() ពិតជានឹងធ្វើឱ្យកម្មវិធីចេញពីស្ថានភាពផ្លាស់ប្តូរ TX ប៉ុន្តែវាក៏នឹងលុប Background RX ផងដែរ ដែលបណ្តាលឱ្យកម្មវិធីត្រឡប់ទៅទំនេរ មិនមែន RX ទេ។

ការអនុវត្ត Multiprotocol ជាមួយប៊្លូធូស

សម្រាប់ព័ត៌មានលម្អិតអំពីរបៀបដែល RAIL/Bluetooth light/switch multiprotocol example ត្រូវបានអនុវត្ត ហើយសម្រាប់ព័ត៌មានបន្ថែមស្តីពីការបង្កើតកម្មវិធីពហុប្រូតូកូលជាមួយនឹងពិធីការផ្ទាល់ខ្លួនរបស់អ្នកនៅលើ RAIL សូមមើល AN1134: ការអភិវឌ្ឍន៍ពហុប្រូតូកូលថាមវន្តជាមួយប៊្លូធូស និងពិធីការកម្មសិទ្ធិនៅលើ RAIL នៅក្នុង GSDK v2.x ឬ AN1269 ការអភិវឌ្ឍន៍ពហុប្រូតូកូលថាមវន្តជាមួយប៊្លូធូស និងពិធីការកម្មសិទ្ធិលើ។ នៅក្នុង GSDK v3.x និងខ្ពស់ជាងនេះ។

អាទិភាពប៊្លូធូស

ផ្ទុយពី Zigbee ដែលមានអាទិភាពដែលបានកំណត់ជាស្ថាបត្យកម្មសម្រាប់ប្រភេទប្រតិបត្តិការផ្សេងៗគ្នា ប៊្លូធូសប្រើជួរ និងវិធីអុហ្វសិតដើម្បីចាត់ចែងកិច្ចការទាំងអស់ទៅតំបន់ដែលបានផ្តល់ឱ្យនៃវិសាលគមអាទិភាព។

នៅក្នុងនេះ អតីតample ជួរអាទិភាពប៊្លូធូស ដែលខ្លួនវាលាតសន្ធឹងពី 0 ដល់ 255 ត្រូវបានគូសផែនទីទៅផ្នែកដែលមានកំណត់នៃទំហំអាទិភាព RAIL ដែលបានចែករំលែក

មិនដូច Zigbee ទេ ប៊្លូធូសមានតម្រូវការកំណត់ពេលវេលាដ៏តឹងរ៉ឹងជាងនេះ ដែលការបាត់រន្ធដោតដែលបានផ្តល់ឱ្យអាចបណ្តាលឱ្យមានការបិទការតភ្ជាប់។ ប៊្លូធូសក៏មានមុខងារផ្សេងៗគ្នាដូចជា ការតភ្ជាប់ (មានសក្តានុពលច្រើន) ការផ្សាយពាណិជ្ជកម្ម ការស្កេន និងការផ្សាយពាណិជ្ជកម្មតាមកាលកំណត់ជាមួយនឹងការឆ្លើយតប (PAwR) ការបញ្ជូន និងការទទួល។

តារាង 6.1 ។ អាទិភាពផ្សេងៗគ្នានៅក្នុងប៊្លូធូស

1	ការតភ្ជាប់	២៩ ដល់ ៣៨	ព្រឹត្តិការណ៍នៃការតភ្ជាប់បញ្ចប់
2	ការចាប់ផ្តើមការតភ្ជាប់	២៩ ដល់ ៣៨	ការចាប់ផ្តើមបញ្ចប់បង្អួច
3	ការផ្សាយពាណិជ្ជកម្ម	២៩ ដល់ ៣៨	ព្រឹត្តិការណ៍ផ្សាយពាណិជ្ជកម្មបញ្ចប់
4	ម៉ាស៊ីនស្កេន	២៩ ដល់ ៣៨	ស្កេនបញ្ចប់បង្អួច
5	PawR TX	២៩ ដល់ ៣៨	អ្នកផ្សាយពាណិជ្ជកម្ម៖ PAwR Response Slot Delay Ends Synchronizer: PAwR Response Slots បញ្ចប់
6	PawR RX	២៩ ដល់ ៣៨	អ្នកផ្សាយពាណិជ្ជកម្ម៖ PAwR Response Slot Ends Synchronizer: PAwR Response Slot Delays បញ្ចប់

ដើម្បីដោះស្រាយវា កម្មវិធីកំណត់ពេលប៊្លូធូស ដែលអាទិភាពរបស់វាត្រូវបានគូសផែនទីទៅនឹងកម្មវិធីកំណត់ពេលវិទ្យុ RAIL គិតគូរពីប៉ារ៉ាម៉ែត្រខាងក្រោមសម្រាប់កិច្ចការនីមួយៗ៖

1.  ពេលវេលាចាប់ផ្តើម
2.  ពេលវេលាអប្បបរមា
3.  ពេលវេលាអតិបរមា
4.  អាទិភាព
   

ប្រសិនបើពេលវេលាចាប់ផ្តើមត្រូវបានផ្លាស់ទី ពេលវេលាដំណើរការសរុបត្រូវបានកាត់បន្ថយរៀងៗខ្លួន នោះគឺជាភាពយឺតយ៉ាវត្រូវបានកាត់បន្ថយ។ អាទិភាពអាចត្រូវបានកែតម្រូវដោយថាមវន្តផងដែរ។

ការតភ្ជាប់

ការតភ្ជាប់មានអាទិភាពខ្ពស់។ ពេលវេលាចាប់ផ្តើមនៃការតភ្ជាប់មិនអាចផ្លាស់ទីបានទេ។

អាទិភាពត្រូវបានបង្កើនដោយថាមវន្តដោយកម្មវិធីកំណត់ពេលប៊្លូធូស ការតភ្ជាប់កាន់តែជិតដល់ពេលអស់ពេលនៃការគ្រប់គ្រង ហើយឈានដល់អាទិភាពអតិបរមានៅជិតវា។ កញ្ចប់ TX ក្នុងជួរ TX ក៏បង្កើនអាទិភាពនៃការតភ្ជាប់ផងដែរ។

ការចាប់ផ្តើមការតភ្ជាប់

ការចាប់ផ្តើមការតភ្ជាប់ស្កេនការផ្សាយពាណិជ្ជកម្មពីឧបករណ៍គោលដៅដើម្បីបង្កើតការតភ្ជាប់។ វាមានអាទិភាពខ្ពស់ជាងបើធៀបនឹងម៉ាស៊ីនស្កេន ដើម្បីអនុញ្ញាតឱ្យមានការតភ្ជាប់កាន់តែរឹងមាំ។

ការផ្សាយពាណិជ្ជកម្ម

ការផ្សាយពាណិជ្ជកម្មតាមលំនាំដើមមានអាទិភាពទាបជាង ហើយចំណុចចាប់ផ្តើមរបស់វាអាចផ្លាស់ទីបាន។ ពេលវេលាចាប់ផ្តើម និងពេលវេលាអតិបរមាត្រូវបានកំណត់ដោយចន្លោះពេលផ្សាយពាណិជ្ជកម្ម។

ប្រសិនបើការផ្សាយពាណិជ្ជកម្មមិនអាចផ្ញើចេញបានទេ អាទិភាពនៃការផ្សាយពាណិជ្ជកម្មកើនឡើងយឺតៗ ហើយត្រូវបានកំណត់ឡើងវិញនៅពេលដែលការផ្សាយពាណិជ្ជកម្មត្រូវបានផ្ញើដោយជោគជ័យ។

ម៉ាស៊ីនស្កេន

តាមលំនាំដើម កិច្ចការទាំងនេះមានអាទិភាពទាបបំផុត។ ចាប់ផ្តើម ពេលវេលាអប្បបរមា និងអតិបរមាត្រូវបានកំណត់ដោយចន្លោះពេលស្កេន និងទំហំបង្អួច។ ការស្កេនអាចបន្តសូម្បីតែនៅពេលមានការរំខានដោយកិច្ចការដែលមានអាទិភាពខ្ពស់ជាង។ ប្រសិនបើរឿងនេះកើតឡើង ពេលវេលាស្កេនត្រូវបានប្រមូលផ្តុំ ដើម្បីប្រាកដថាទំហំបង្អួចស្កេនដែលចង់បានត្រូវបានឈានដល់នៅចន្លោះពេលស្កេននីមួយៗ។

ដូចគ្នានឹងការផ្សាយពាណិជ្ជកម្មដែរ អាទិភាពត្រូវបានបង្កើនក្នុងករណីដែលចន្លោះពេលស្កេនដែលចង់បាន ឬទំហំបង្អួចមិនអាចបំពេញបានពីមុន។ វាត្រូវបានកំណត់ឡើងវិញទៅអាទិភាពដំបូងរបស់វា នៅពេលដែលចន្លោះពេលស្កេន ឬទំហំបង្អួចត្រូវបានបំពេញ។

ការផ្សាយពាណិជ្ជកម្មតាមកាលកំណត់ជាមួយនឹងការឆ្លើយតប (PAwR) 

ការផ្ញើការផ្សាយពាណិជ្ជកម្មតាមកាលកំណត់ជាមួយនឹងការឆ្លើយតបមានអាទិភាពខ្ពស់បំផុតតាមលំនាំដើមលើកិច្ចការប៊្លូធូសផ្សេងទៀតទាំងអស់ បន្ទាប់មកដោយការទទួលការឆ្លើយតបនៅក្នុង PAwR ដើម្បីរក្សាការធ្វើសមកាលកម្មនៅក្នុងបណ្តាញស្លាកធ្នើអេឡិចត្រូនិច (ESL) ។

អាទិភាពកិច្ចការ PAwR ត្រូវបានបង្កើន ប្រសិនបើការកំណត់ពេលភារកិច្ចបរាជ័យពីរដងក្នុងមួយជួរ។ អាទិភាពត្រូវបានកើនឡើងដោយ 1/6 នៃជួរអាទិភាព ឬយ៉ាងហោចណាស់ដោយមួយរហូតដល់អាទិភាពអតិបរមាត្រូវបានឈានដល់។ អាទិភាពកិច្ចការត្រូវបានកំណត់ឡើងវិញទៅអប្បបរមា បន្ទាប់ពីការកំណត់ពេលជោគជ័យ។ នីតិវិធីដូចគ្នាអនុវត្តចំពោះអ្នកផ្សាយពាណិជ្ជកម្ម PAwR ទាំងពីរអ្នកធ្វើសមកាលកម្មក្នុងទិសដៅទាំងពីរ

Example នៃប្រតិបត្តិការកម្មវិធីកំណត់ពេលប៊្លូធូស 

អតីតample បង្ហាញពីរបៀបដែលកម្មវិធីកំណត់ពេលប៊្លូធូសនឹងកំណត់ពេលភារកិច្ចតភ្ជាប់ចំនួនបី និងកិច្ចការផ្សាយពាណិជ្ជកម្មមួយ ដែលនីមួយៗមានអាទិភាពខុសៗគ្នា។ នៅក្នុងតួរលេខខាងក្រោម ផ្នែកពណ៌ប្រផេះបង្ហាញពីរយៈពេលដំណើរការអប្បបរមាដែលកិច្ចការទាមទារ ហើយផ្នែកពណ៌ខៀវបង្ហាញពីរយៈពេលរត់អតិបរមាដែលកិច្ចការអាចប្រើ ហើយប្រសិនបើអាចបត់បែនបាន តំបន់ដែលកិច្ចការអាចត្រូវបានផ្លាស់ទី។ រូបខាងក្រោមបង្ហាញក្នុងការរៀបចំដំបូង

ដូចដែលបានបង្ហាញខាងក្រោម Conn1 គឺជាកិច្ចការដំបូងដែលត្រូវដំណើរការព្រោះវាមិនត្រួតលើគ្នាជាមួយនឹងកិច្ចការដែលមានអាទិភាពខ្ពស់ជាងនេះទេ។

Adv1 ត្រួតលើគ្នាជាមួយអាទិភាពខ្ពស់ជាង Conn2. Adv1 គឺអាចបត់បែនបាន ដូច្នេះហើយត្រូវបានផ្លាស់ប្តូរដូចដែលបានបង្ហាញក្នុងរូបខាងក្រោម។

Conn2 ត្រួតលើគ្នាជាមួយកិច្ចការអាទិភាពខ្ពស់ជាង Conn4. ដោយសារ Conn2 មិនអាចបត់បែនបាន ការកំណត់ពេល Conn2 បរាជ័យ។

Conn4 មិនត្រួតលើគ្នាជាមួយកិច្ចការផ្សេងទៀតទេ ដូច្នេះ Conn1 end ត្រូវបានកែតម្រូវដើម្បីបញ្ឈប់មុនពេល Conn4 ចាប់ផ្តើម។

Conn4 មិនត្រួតលើគ្នាជាមួយកិច្ចការផ្សេងទៀតទេ ដូច្នេះ Conn1 end ត្រូវបានកែតម្រូវដើម្បីបញ្ឈប់មុនពេល Conn4 ចាប់ផ្តើម។

ការកែប្រែអាទិភាព

រចនាសម្ព័ន្ធ “sl_bt_configuration_t” (v3.x)/”gecko_configuration_t” (v2.x) កំណត់រចនាសម្ព័ន្ធ sl_bt_stack_config_t ដែលមានវាល “bluetooth.linklayer_priorities” ដែលជាចង្អុលទៅការកំណត់រចនាសម្ព័ន្ធអាទិភាព។ ប្រសិនបើទ្រនិចគឺ NULL នោះជង់ប្រើអាទិភាពលំនាំដើមរបស់វាដូចដែលបានរាយក្នុងផ្នែក 6.1 អាទិភាពប៊្លូធូសខាងលើ ក៏ដូចជាផ្នែកនេះ។

ក្នុងករណីដែលទ្រនិចមិនចាត់ទុកជាមោឃៈ វាត្រូវតែចង្អុលទៅរចនាសម្ព័ន្ធនៃការកំណត់អាទិភាពដូចដែលបានកំណត់ខាងក្រោម៖

ប៉ារ៉ាម៉ែត្រ sandman, Cinemax, adv_min, adv_min, cinnamon, conn_max, intimin និង intima កំណត់អាទិភាពអប្បបរមា និងអតិបរមាសម្រាប់ការស្កេន ការផ្សាយពាណិជ្ជកម្ម ការតភ្ជាប់ និងការចាប់ផ្តើមរៀងៗខ្លួន។ អាទិភាពនឹងផ្លាស់ទីរវាងព្រំដែនអប្បបរមា និងអតិបរមា ដូចដែលបានពិពណ៌នានៅក្នុងផ្នែក 6.1.1 ការតភ្ជាប់ទៅ 6.1.4 ម៉ាស៊ីនស្កេនខាងលើ។

ប៉ារ៉ាម៉ែត្រផែនទី RAIL, rail_mapping_offset និង rail_mapping_range កំណត់ពីរបៀបដែលអាទិភាពស្រទាប់តំណប៊្លូធូសត្រូវបានគូសផែនទីទៅនឹងអាទិភាពកម្មវិធីកំណត់ពេលវិទ្យុ RAIL សកល។ ការគូសផែនទីនៃតម្លៃទាំងនេះអាចមើលឃើញនៅក្នុង 6.1 អាទិភាពប៊្លូធូស។ លំនាំដើមសម្រាប់ទាំង rail_mapping_offset និង rail_mapping_range គឺ 16 ។

ប៉ារ៉ាម៉ែត្រជំហាន adv_step និងស្កេនកំណត់ទំហំជំហាននៅពេលដែលអាទិភាពនៃការស្កេន និងការផ្សាយពាណិជ្ជកម្មត្រូវបានផ្លាស់ប្តូរថាមវន្ត។ ជាចុងក្រោយ ប៉ារ៉ាម៉ែត្រ pawr_tx_min, pawr_tx_min, pawr_tx_min, និង pawr_rx_max កំណត់ជួរអាទិភាពសម្រាប់អ្នកផ្សាយពាណិជ្ជកម្ម និងកម្មវិធីធ្វើសមកាលកម្ម TX និង RX នៅក្នុងព្រឹត្តិការណ៍រងនីមួយៗ។

ផលប័ត្រ IoT
www.silabs.com/products

គុណភាព
www.silabs.com/quality

ការគាំទ្រ និងសហគមន៍
www.silabs.com/community

ការបដិសេធ

Silicon Labs មានបំណងផ្តល់ជូនអតិថិជននូវឯកសារចុងក្រោយបំផុត ត្រឹមត្រូវ និងស៊ីជម្រៅនៃគ្រឿងកុំព្យូទ័រ និងម៉ូឌុលទាំងអស់ដែលមានសម្រាប់អ្នកអនុវត្តប្រព័ន្ធ និងកម្មវិធីដែលប្រើប្រាស់ ឬមានបំណងប្រើប្រាស់ផលិតផល Silicon Labs ។ ទិន្នន័យលក្ខណៈ ម៉ូឌុលដែលមាន និងគ្រឿងកុំព្យូទ័រ ទំហំអង្គចងចាំ និងអាសយដ្ឋានអង្គចងចាំ សំដៅលើនីមួយៗ
ឧបករណ៍ជាក់លាក់ និងប៉ារ៉ាម៉ែត្រ "ធម្មតា" ដែលបានផ្តល់អាច និងធ្វើខុសគ្នានៅក្នុងកម្មវិធីផ្សេងៗ។ កម្មវិធី ឧamples ដែលបានពិពណ៌នានៅទីនេះគឺសម្រាប់គោលបំណងបង្ហាញតែប៉ុណ្ណោះ។ Silicon Labs រក្សាសិទ្ធិដើម្បីធ្វើការផ្លាស់ប្តូរដោយមិនមានការជូនដំណឹងបន្ថែមចំពោះព័ត៌មានផលិតផល លក្ខណៈបច្ចេកទេស និងការពិពណ៌នានៅទីនេះ ហើយមិនផ្តល់ការធានាចំពោះភាពត្រឹមត្រូវ ឬពេញលេញនៃព័ត៌មានដែលបានរួមបញ្ចូលនោះទេ។ ដោយគ្មានការជូនដំណឹងជាមុន Silicon Labs អាចធ្វើបច្ចុប្បន្នភាពកម្មវិធីបង្កប់ផលិតផលក្នុងអំឡុងពេលដំណើរការផលិតសម្រាប់ហេតុផលសុវត្ថិភាព ឬភាពជឿជាក់។ ការផ្លាស់ប្តូរបែបនេះនឹងមិនផ្លាស់ប្តូរលក្ខណៈបច្ចេកទេស ឬដំណើរការរបស់ផលិតផលនោះទេ។ Silicon Labs នឹងមិនទទួលខុសត្រូវចំពោះផលវិបាកនៃការប្រើប្រាស់ព័ត៌មានដែលបានផ្គត់ផ្គង់នៅក្នុងឯកសារនេះទេ។ ឯកសារនេះមិនបញ្ជាក់ ឬផ្តល់អាជ្ញាប័ណ្ណច្បាស់លាស់ណាមួយក្នុងការរចនា ឬបង្កើតសៀគ្វីរួមបញ្ចូលគ្នាណាមួយឡើយ។ ផលិតផលមិនត្រូវបានរចនាឡើង ឬត្រូវបានអនុញ្ញាតឱ្យប្រើប្រាស់នៅក្នុងឧបករណ៍ FDA Class III ណាមួយឡើយ កម្មវិធីដែលតម្រូវឱ្យមានការយល់ព្រមពីទីផ្សារមុនរបស់ FDA ឬប្រព័ន្ធជំនួយជីវិត ដោយគ្មានការយល់ព្រមជាលាយលក្ខណ៍អក្សរជាក់លាក់ពី Silicon Labs ។ “ប្រព័ន្ធទ្រទ្រង់ជីវិត” គឺជាផលិតផល ឬប្រព័ន្ធណាមួយដែលមានបំណងគាំទ្រ ឬទ្រទ្រង់ជីវិត និង/ឬសុខភាព ដែលប្រសិនបើវាបរាជ័យ វាអាចត្រូវបានគេរំពឹងថានឹងបណ្តាលឱ្យមានរបួស ឬស្លាប់យ៉ាងធ្ងន់ធ្ងរ។ ផលិតផល Silicon Labs មិនត្រូវបានរចនាឡើង ឬអនុញ្ញាតសម្រាប់កម្មវិធីយោធាទេ។ ផលិតផល Silicon Labs មិនត្រូវស្ថិតក្រោមកាលៈទេសៈណាក៏ដោយ ដែលត្រូវបានប្រើប្រាស់ក្នុងអាវុធប្រល័យលោក រួមទាំង (ប៉ុន្តែមិនកំណត់ចំពោះ) អាវុធនុយក្លេអ៊ែរ អាវុធជីវសាស្ត្រ ឬគីមី ឬមីស៊ីលដែលមានសមត្ថភាពបញ្ជូនអាវុធបែបនេះឡើយ។ Silicon Labs បដិសេធរាល់ការធានាច្បាស់លាស់ និងបង្កប់ន័យ ហើយនឹងមិនទទួលខុសត្រូវ ឬទទួលខុសត្រូវចំពោះការរងរបួស ឬការខូចខាតដែលទាក់ទងនឹងការប្រើប្រាស់ផលិតផល Silicon Labs នៅក្នុងកម្មវិធីដែលគ្មានការអនុញ្ញាតបែបនេះឡើយ។ ចំណាំ៖ ខ្លឹមសារនេះអាចមានពាក្យប្រមាថមើលងាយ ដែលឥឡូវលែងប្រើហើយ។ Silicon Labs កំពុងជំនួសពាក្យទាំងនេះជាមួយនឹងភាសារួមបញ្ចូលនៅពេលណាដែលអាចធ្វើទៅបាន។ សម្រាប់ព័ត៌មានបន្ថែម សូមចូលទៅកាន់គេហទំព័រ www.silabs.com/about-us/inclusive-lexicon-project

ព័ត៌មានពាណិជ្ជសញ្ញា
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® និងនិមិត្តសញ្ញា Silicon Labs®, Blueridge®, Blueridge Logo®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro និងបន្សំរបស់វា។ "ឧបករណ៍បញ្ជាខ្នាតតូចដែលងាយស្រួលប្រើបំផុតរបស់ពិភពលោក", Repine Signals®, Disconnect, n-Link, Thread Arch®, Elin®, EZRadioPRO®, EZRadioPRO®, Gecko®, Gecko OS, Gecko OS Studio, Precision32®, Simplicity Studio® , Telegenic, the Telegenic Logo®, Suppress®, Sentry, និមិត្តសញ្ញា Sentry និង Zentri DMS, Z-Wave® និងផ្សេងទៀតគឺជាពាណិជ្ជសញ្ញា ឬពាណិជ្ជសញ្ញាដែលបានចុះបញ្ជីរបស់ Silicon Labs។ ARM, CORTEX, Cortex-M3 និង THUMB គឺជាពាណិជ្ជសញ្ញា ឬពាណិជ្ជសញ្ញាដែលបានចុះបញ្ជីរបស់ ARM Holdings ។ Keli គឺជាពាណិជ្ជសញ្ញាចុះបញ្ជីរបស់ ARM Limited ។ Wi-Fi គឺជាពាណិជ្ជសញ្ញាដែលបានចុះបញ្ជីរបស់ Wi-Fi Alliance។ ផលិតផល ឬម៉ាកយីហោផ្សេងទៀតទាំងអស់ដែលបានលើកឡើងនៅទីនេះ គឺជាពាណិជ្ជសញ្ញានៃការកាន់កាប់រៀងៗខ្លួន

ឯកសារ/ធនធាន

SILICON LABS UG305 Dynamic Multiprotocol [pdf] ការណែនាំអ្នកប្រើប្រាស់ UG305, UG305 Dynamic Multiprotocol, Dynamic Multiprotocol, Multiprotocol

ឯកសារយោង

• សៀវភៅណែនាំអ្នកប្រើប្រាស់