SILICON LABS UG305 Dynamic Multiprotocol User Guide

تعارف

هي دستاويز بيان ڪري ٿو ته ڪيئن سلڪون ليبز سافٽ ويئر ٺهيل آهي ڪيترن ئي پروٽوڪول ذريعي استعمال ٿيڻ لاءِ هڪ وائرليس چپ تي. متحرڪ ملٽي پروٽوڪول ٽائيم سلائيز ريڊيو ۽ تيزيء سان ترتيبن کي تبديل ڪري ٿو مختلف وائرلیس پروٽوڪول کي فعال ڪرڻ لاء هڪ ئي وقت تي معتبر طور تي هلائڻ لاء.

نوٽ: هن دستاويز ۾ Zigbee جي مخصوص معلومات ورجن 6.10.x ۽ هيٺين تي لاڳو ٿئي ٿي.
مخصوص متحرڪ ملٽي پروٽوڪول لاڳو ڪرڻ تي تفصيل ڏنل ايپليڪيشن نوٽس ۾ مهيا ڪيا ويا آهن:
AN1133: بلوٽوت ۽ Zigbee EmberZNet SDK 6.x ۽ لوئر سان متحرڪ ملٽي پروٽوڪول ڊولپمينٽ
AN1134: GSDK v2.x ۾ ريل تي بلوٽوت ۽ ملڪيت جي پروٽوڪول سان متحرڪ ملٽي پروٽوڪول ترقي
AN1269: GSDK v3.x ۽ اعليٰ ۾ RAIL تي Bluetooth® ۽ Proprietary Protocols سان متحرڪ ملٽي پروٽوڪول ڊولپمينٽ
AN1209: بلوٽوت ۽ ڪنيڪٽ سان متحرڪ ملٽي پروٽوڪول ڊولپمينٽ
AN1265: GSDK v3.x ۾ Bluetooth® ۽ OpenThread سان متحرڪ ملٽي پروٽوڪول ڊولپمينٽ

اصطلاحات

هيٺ ڏنل فهرستن مان ڪجھ اصطلاحن کي مخصوص ڪري ٿو متحرڪ ملٽي پروٽوڪول عمل درآمد لاءِ

ريڊيو ايبسٽرڪشن انٽرفيس پرت (RAIL): عام API جنهن جي ذريعي اعلي سطحي ڪوڊ حاصل ڪري ٿو EFR32 ريڊيو تائين رسائي.

ريڊيو آپريشن: مقرر ڪيل مخصوص عمل. ريڊيو آپريشن ۾ ريڊيو جي ترتيب ۽ ترجيح ٻئي هوندي آهي. هر اسٽيڪ درخواست ڪري سگهي ٿو ته ريڊيو شيڊولر ٻن ريڊيو آپريشنن تائين انجام ڏئي ٿو (پس منظر وصول ۽ يا ته شيڊول وصول يا شيڊول ٿيل

• پس منظر وصول: مسلسل وصول ڪرڻ، مقرر ڪيل عملن ۾ مداخلت ڪرڻ جو ارادو ڪيو ويو، ۽ انهن جي مڪمل ٿيڻ کان پوء واپس آيو.
• مقرر ڪيل وصول: حاصل ڪريو پيڪٽس يا حساب ڪريو RSSI مخصوص وقت ۽ مدت تي. (ڊيولپرز جيڪي RAIL تي ڪم ڪري رهيا آهن، نوٽ ڪريو ته RAIL API جي لحاظ کان، "شيڊول ٿيل وصول" جيئن هن دستاويز ۾ استعمال ڪيو ويو آهي، ڪنهن به وصولي آپريشن ڏانهن اشارو ڪري ٿو، RAIL_StartRx کان سواء، ۽ صرف RAIL_ScheduleRx تائين محدود ناهي.)
• شيڊول ٿيل ٽرانسميt: مختلف منتقلي عملن مان ڪو به هڪ بشمول فوري ٽرانسمٽ، شيڊول (مستقبل) ٽرانسمٽ، يا سي سي اي انحصار ٽرانسمٽ. (ڊيولپرز جيڪي RAIL تي ڪم ڪري رهيا آهن، نوٽ ڪريو ته RAIL API جي لحاظ کان، "Scheduled Transmit" جيئن هن دستاويز ۾ استعمال ڪيو ويو آهي، ڪنهن به ٽرانسمٽ آپريشن ڏانهن اشارو ڪري ٿو، ۽ RAIL_StartScheduledTx جي دائري ۾ محدود ناهي.

Radio config: هارڊويئر جي حالت کي طئي ڪري ٿو جيڪو ريڊيو آپريشن کي انجام ڏيڻ لاء استعمال ڪيو وڃي.

ريڊيو شيڊيولر: RAIL جو حصو جيڪو مختلف پروٽوڪول جي وچ ۾ ثالث ڪري ٿو اهو طئي ڪرڻ لاءِ ته ڪهڙن وٽ ريڊيو تائين رسائي هوندي.

ترجيح: هر اسٽيڪ مان هر آپريشن کي ڊفالٽ ترجيح هوندي آهي. هڪ ايپليڪيشن ڊفالٽ ترجيحات کي تبديل ڪري سگهي ٿي.

ڦلڻ جو وقت: مستقبل ۾ وڌ ۾ وڌ وقت جڏهن آپريشن شروع ٿي سگهي ٿو جيڪڏهن اهو درخواست ٿيل شروعاتي وقت تي شروع نه ٿي سگهي.

حاصل: هڪ اسٽيڪ لازمي طور تي هڪ آپريشن جي آخر ۾ يا عملن جي تسلسل ۾ حاصل ڪرڻ گهرجي، جيستائين اهو پس منظر وصول نه ڪري رهيو آهي. جيستائين اسٽيڪ حاصل نه ٿئي، شيڊيولر نه ڪندو شيڊيولر هيٺين ترجيحي ڪمن کي

RTOS (ريئل ٽائيم آپريٽنگ سسٽم) ڪنيل: آپريٽنگ سسٽم جو حصو جيڪو ٽاسڪ مئنيجمينٽ، ۽ وچ ۾ ڪميونيڪيشن ۽ هم وقت سازي جو ذميوار آهي. اهو عمل مائڪريم OS-5 ڪنيل استعمال ڪري ٿو.

آرڪيٽيڪچر

Dynamic Multiprotocol EFR32 هارڊويئر ۽ RAIL سافٽ ويئر کي ان جي بلڊنگ بلاڪ جي طور تي استعمال ڪري ٿو. Zigbee، بلوٽوٿ، ۽/يا ڪي ٻيا معيار تي ٻڌل يا پراپرائيٽري پروٽوڪول وري ٺاهي سگھجن ٿا انهن غير معياري پرتن جي مٿان، مختلف پروٽوڪول جي وچ ۾ ڪوڊ جي عمل کي منظم ڪرڻ لاءِ مائڪريم استعمال ڪندي. هيٺ ڏنل ڊراگرام سافٽ ويئر ماڊلز جي عام ڍانچي کي بيان ڪري ٿو.

 

ورجن 2.0 سان شروع ٿي، RAIL کي RAIL API ڪالن لاءِ ريڊيو ڪنفيگريشن ھينڊل جي پاس ڪرڻ جي ضرورت آھي. هي تشڪيل مختلف PHY پيٽرولر بيان ڪري ٿو جيڪي اسٽيڪ پاران استعمال ڪيا ويا آهن

Micrium OS هڪ RTOS آهي جيڪو اسٽيڪ ۽ ايپليڪيشن منطق کي سي پي يو جي عمل جي وقت کي حصيداري ڪرڻ جي اجازت ڏئي ٿو.

ريڊيو شيڊيولر هڪ سافٽ ويئر لائبريري آهي جيڪا ذهانت سان ريڊيو آپريشنز کي انجام ڏيڻ لاءِ اسٽيڪ جي درخواستن جو جواب ڏئي ٿي ته جيئن اعتماد کي وڌ کان وڌ ۽ ويڪرائي کي گهٽايو وڃي. RAIL پاران مهيا ڪيل API جيڪي ريڊيو کي شامل نه ڪندا آهن ريڊيو شيڊولر کي بائي پاس.

RAIL ڪور EFR32 هارڊويئر کي ريڊيو شيڊولر جي هدايتن جي جواب ۾ ترتيب ڏئي ٿو.

سنگل Firmware تصوير

Dynamic Multiprotocol هڪ سافٽ ويئر ڊولپر کي اجازت ڏئي ٿو ته هڪ واحد monolithic بائنري ٺاهي جيڪا EFR32 تي لوڊ ڪئي وئي آهي. سافٽ ويئر اپڊيٽ مڪمل بائنري کي اپڊيٽ ڪندي ڪيو ويندو آهي. هي گيڪ اوٽ لوڊر استعمال ڪندي مڪمل ڪيو ويو آهي، جنهن جا تفصيل ڳولي سگهجن ٿا UG266: Silicon Labs Gecko Bootloader User's Guide for GSDK 3.2 ۽ Lower and UG489: Silicon LabsGecko Bootloader User's Guide for GSDK 4.0 and Higher.

آزاد اسٽيڪ آپريشن

Silicon Labs اسٽيڪ اڃا تائين متحرڪ ملٽي پروٽوڪول صورتحال ۾ هڪ ٻئي کان آزاد طور تي ڪم ڪن ٿا. ڪجھ ڊگھي رھندڙ ريڊيو آپريشنز جو اثر ھڪ ٻئي پروٽوڪول جي ويڪرائي ۽ تعميل واري آپريشن تي پوندو. اهو انهن واقعن لاءِ ڪنهن خاص خيال کي طئي ڪرڻ لاءِ درخواست تي منحصر آهي. ڏسو سيڪشن 2. وڌيڪ معلومات لاءِ ريڊيو شيڊيولر.

ريڊيو شيڊيولر

ريڊيو شيڊيولر RAIL (ريڊيو ايبسٽرڪشن انٽرفيس ليئر) جو حصو آھي. RAIL هڪ وجداني، آساني سان حسب ضرورت ريڊيو انٽرفيس پرت ۽ API مهيا ڪري ٿو، جيڪو ملڪيت يا معيار تي ٻڌل وائرليس پروٽوڪول کي سپورٽ ڪري ٿو. ريڊيو شيڊيولر کي ريڊيو آپريشنز جي اجازت ڏيڻ لاءِ ٺاھيو ويو آھي جيڪي شيڊول ۽ ترجيح ڏئي سگھجن ٿيون. هر پروٽوڪول ۾ مختلف ريڊيو آپريشن ٿي سگهي ٿو گهٽ يا وڌيڪ اهم، يا وڌيڪ يا گهٽ وقت حساس، صورتحال جي لحاظ کان. شيڊولر انهن کي حساب ۾ وٺي سگھي ٿو جڏهن تڪرار بابت فيصلا ڪرڻ ۽ انهن جو فيصلو ڪيئن ڪجي

جيستائين توهان RAIL تي ڪسٽم پروٽوڪول سان ايپليڪيشنون ٺاهي رهيا آهيو، اڪثر ريڊيو شيڊولر ڪم پاڻمرادو هيٺيون اسٽيڪ ۽ ريل ڪوڊ ذريعي سنڀاليا ويندا آهن. توهان کي صرف ان جي عام API ذريعي اسٽيڪ استعمال ڪرڻ جي ضرورت آهي.

هڪ اعلي سطح تي، اسٽيڪ ريڊيو آپريشن موڪلي ٿو (مثال طورample a شيڊول وصول يا شيڊول ٽرانسميٽ). ريڊيو آپريشنز آهن
قطار ۾ رکيل ۽ پوءِ خدمت ڪئي وئي مستقبل جي وقت تي انهن جي پيٽرولن جي بنياد تي. جڏهن اهو ريڊيو آپريشن شروع ڪرڻ جو وقت آهي، شيڊولر جانچ ڪري ٿو ته ڇا مقابلي وارو واقعو موجود آهي يا نه ۽ ڇا آپريشن ۾ دير ٿي سگهي ٿي يا نه. جيڪڏهن شيڊيولر واقعي کي نه هلائي سگهي ته اهو نتيجو واپس ڪري ٿو اعلي سطح تي، جيڪو نئين پيٽرولن سان ٻيهر ڪوشش ڪري سگهي ٿو.

هڪ دفعو ريڊيو آپريشن شروع ٿي چڪو آهي، لاڳاپيل اسٽيڪ اڳوڻي آپريشن جي نتيجن جي بنياد تي شيڊولر کي اضافي آپريشن موڪلي سگهي ٿو (مثال طورampهڪ ACK جي انتظار ۾). هر عمل جي آخر ۾ يا عملن جي تسلسل ۾ اسٽيڪ کي لازمي طور تي ريڊيو جو استعمال حاصل ڪرڻ گهرجي.

ريڊيو آپريشن

شيڊولر ۾ هر واقعي کي ريڊيو آپريشنز جي عناصرن ۾ ورهايو ويو آهي، جيڪي ريڊيو ترتيب ۽ ترجيح سان لاڳاپيل آهن.

هر آپريشن کي هڪ ترجيح هوندي آهي ۽ ان ۾ مداخلت ڪئي ويندي آهي جيڪڏهن شيڊولر کي اعلي ترجيحي آپريشن ملي ٿي جيڪا وقت ۾ اوورليپ ٿئي ٿي. هيٺين ترجيحي ريڊيو آپريشنز جيڪي نه هلائي سگھجن ٿيون انهن جي شيڊول جي ماپن جي بنياد تي ناڪام ٿي وينديون، ۽ اھو انھن کي ٻيهر ڪوشش ڪرڻ لاءِ لاڳاپيل اسٽيڪ تي آھي. هڪ دفعو شيڊيولر فعال طور تي اسٽيڪ مان ريڊيو آپريشن هلائيندو آهي، اسٽيڪ اضافي ريڊيو آپريشنز موڪلڻ جاري رکي سگهي ٿو جيستائين اهو رضاڪارانه طور تي حاصل نه ڪري، يا جيستائين شيڊيولر هڪ اعليٰ ترجيحي ريڊيو آپريشن حاصل ڪري ۽ ان کي اڳڀرائي نه ڪري.

• پس منظر وصول
• مقرر ڪيل وصول
• شيڊول ٿيل ٽرانسميشن

هر اسٽيڪ ريڊيو شيڊيولر کي هڪ وقت ۾ ٻه ريڊيو آپريشنز (پس منظر وصول ڪرڻ يا شيڊول ٿيل وصول يا شيڊول ٿيل ٽرانسمٽ) ڪرڻ لاءِ چئي سگهي ٿو:

هر آپريشن هيٺ ڏنل پيراگراف آهن:

شروعاتي وقت	هڪ اشارو مستقبل ۾ ڪهڙي موڙ تي هي ريڊيو آپريشن هلندو. اهو ٿي سگهي ٿو "هاڻي هلائي" يا مستقبل ۾ مائڪرو سيڪنڊن ۾ ڪجهه قدر.
ترجيح	ھڪڙو انگ جيڪو اشارو ڪري ٿو آپريشن جي نسبتي ترجيح. جڏهن ڊفالٽ سيٽنگون استعمال ڪندي، بلوٽوٿ LE ريڊيو آپريشنز تقريبا هميشه Zigbee عملن کان وڌيڪ ترجيح آهن.
ڦلڻ جو وقت	وقت جو هڪ مقدار جيڪو واقعو ان جي شروعاتي وقت کان وڌيڪ دير ٿي سگهي ٿو ۽ اڃا تائين اسٽيڪ کي قبول ڪيو وڃي. اهو ٿي سگهي ٿو 0، جنهن صورت ۾ واقعي کي سلپ نه ٿو ڪري سگهجي.
ٽرانزيڪشن جو وقت	لڳ ڀڳ وقت جي رقم جيڪا وٺندي آهي ٽرانزيڪشن کي مڪمل ڪرڻ ۾. منتقلي واقعن ۾ عام طور تي گهڻو وڌيڪ چڱي طرح بيان ڪيل ٽرانزيڪشن جو وقت هوندو آهي، جڏهن ته وصول ٿيندڙ واقعا اڪثر اڻڄاتل هوندا آهن. هي ريڊيو شيڊولر جي مدد ڪرڻ لاءِ استعمال ڪيو ويندو آهي اهو طئي ڪرڻ لاءِ ته ڇا واقعي کي هلائي سگهجي ٿو.

اسٽيڪ انهن مختلف پيٽرولن کي بيان ڪري ٿو جيڪو آپريشن تي عمل ڪرڻ لاءِ مناسب آهي. مثال طورampلي، بلوٽوٿ ڪنيڪشن جا واقعا اڪثر ڪري مستقبل ۾ شيڊول ڪيا ويندا آهن ۽ ان جي اجازت نه هوندي آهي، جڏهن ته Zigbee ٽرانسمٽ واقعا اڪثر دير سان دير ٿي سگهن ٿا ۽ بعد ۾ اسٽار.

RAIL ريڊيو شيڊيولر جي نقطه نظر کان، شيڊول ٿيل ٽرانسمٽ ۽ شيڊول وصول هڪجهڙا آهن. اهي ٻئي صرف آپريشن آهن جن کي ريڊيو جي استعمال جي ضرورت آهي، ۽ اهڙيء طرح هڪ ئي وقت تي عمل نٿو ڪري سگهجي. فرق صرف RAIL API پرت تي ظاهر ٿئي ٿو، جتي يا ته TX يا RX API سڏيو ويندو آهي.

پس منظر وصول

هي هڪ مسلسل وصولي موڊ آهي جيڪو ٻين عملن جي وچ ۾ مداخلت ڪرڻ جو ارادو ڪيو ويو آهي، ۽ انهن جي مڪمل ٿيڻ کان پوء واپس ڪيو ويو آهي. جيڪڏهن پس منظر وصول ڪرڻ ٻين عملن جي ڀيٽ ۾ وڌيڪ ترجيح آهي، اهي ريڊيو آپريشن شيڊول نه ٿيندا ۽ نه هلندا. اهو ترجيحات کي تبديل ڪرڻ يا رضاڪارانه طور تي حاصل ڪرڻ لاء اسٽيڪ يا ايپليڪيشن تي آهي. ڏسو ايڪشن 5.1 Examples سان گڏ پس منظر وصول ڪرڻ، يئلڊ ريڊيو ۽ اسٽيٽ ٽرانزيڪشن for examples ته ڪيئن پس منظر وصول ڪري ٿو شيڊول ٿيل عملن سان لهه وچڙ ۾.

مقرر ڪيل وصول

هي هڪ مخصوص مدت سان مستقبل جي وقت تي وصول ڪرڻ آهي. ريڊيو شيڊيولر فيصلو ڪرڻ ۾ ريڊيو سوئچنگ جي وقت تي غور ڪندو ته ڇا آپريشن شيڊول ڪيو ويندو يا نه. جيڪڏهن اهو شيڊول نه ٿي سگهي ته پوءِ شيڊولر هڪ ناڪام واقعو ڪالنگ اسٽيڪ ڏانهن موڪلي ٿو. ريڊيو آپريشن خود بخود وڌايو ويندو آهي جيستائين اسٽيڪ رضاڪارانه طور تي حاصل نه ٿئي، يا شيڊولر هڪ اعلي ترجيحي آپريشن حاصل ڪري ۽ ان ۾ مداخلت ڪري. وصولي کي وڌائڻ سان اسٽيڪ کي ريڊيو آپريشن جاري رکڻ جي اجازت ڏئي ٿي جيڪا اعليٰ سطحي پروٽوڪول جي ضرورتن جي بنياد تي، مثال طورampحاصل ڪيل ڊيٽا جي بنياد تي جواب جي منتقلي.

شيڊول ٿيل ٽرانسميشن

هي هڪ منتقلي آهي مستقبل جي وقت ۾ گهٽ ۾ گهٽ مدت سان. ھن گھٽ ۾ گھٽ مدت ۾ شامل ٿي سگھي ٿو متوقع پٺيان ايندڙ واقعا، مثال طورampIEEE 802.15.4 منتقل ڪرڻ لاءِ ACK. بهرحال، هن آپريشن لاءِ گهٽ ۾ گهٽ وقت ۾ غير متوقع واقعا شامل نه ٿيڻ گهرجن جيڪي وقت کي گهٽ ۾ گهٽ مدي کان اڳتي وڌائي سگهن، مثال طورampIEEE 802.15.4 ۾ CCA ناڪامين جي ڪري گهٽتائي. ريڊيو شيڊولر اهو فيصلو ڪرڻ ۾ ريڊيو سوئچنگ جي وقت تي غور ڪري ٿو ته ڇا آپريشن شيڊول ڪيو ويندو يا نه. جيڪڏهن اهو شيڊول نه ٿي سگهي ته پوءِ شيڊولر هڪ ناڪام واقعو ڪالنگ اسٽيڪ ڏانهن موڪلي ٿو.

ريڊيو ترتيب

هر ريڊيو آپريشن اڳواٽ بيان ڪيل ريڊيو ترتيب سان لاڳاپيل آهي جيڪو هارڊويئر جي حالت کي طئي ڪري ٿو جيڪو آپريشن کي انجام ڏيڻ لاء استعمال ڪيو وڃي. ريڊيو ڪنفيگس اسٽيڪ جي موجوده حالت کي باخبر رکي ٿو ته جيئن مستقبل ۾ ريڊيو آپريشن ساڳيا ريڊيو پيٽرولر استعمال ڪندا. ريڊيو ترتيبون فعال يا غير فعال ٿي سگھن ٿيون. جيڪڏهن اسٽيڪ هڪ فعال ريڊيو ڪنفيگريشن کي تبديل ڪري ٿو ته پوءِ RAIL هارڊويئر جي ترتيب ۾ پڻ هڪ فوري تبديلي ڪري ٿي، اڳوڻي لاءِampهڪ چينل تبديل ڪرڻ. جيڪڏهن ريڊيو config في الحال فعال نه آهي ته پوء ايندڙ شيڊول ريڊيو آپريشن نئين ريڊيو ترتيب استعمال ڪندو.

ترجيح

هر ريڊيو آپريشن کي هڪ ترجيح هوندي آهي جيڪا شيڊيولر ڏانهن اشارو ڪري ٿي ته جيڪڏهن ڪيترن ئي عملن جي وچ ۾ وقت جي اوورليپ هجي ته ڪهڙي آپريشن کي عمل ۾ آڻڻ گهرجي. شيڊيولر 0 جي ترجيح کي اعليٰ ترجيح ۽ 255 کي گھٽ ۾ گھٽ ترجيح سمجھي ٿو. ريڊيو شيڊولر ڪم کي اجازت ڏيندو سڀ کان وڌيڪ ترجيح سان جسماني راڊ ويئر تائين رسائي. اڪثر ڪمن سان ڪنٽرول صرف مڪمل ٿيڻ تي ريڊيو شيڊيولر کي واپس ڪيو ويندو آهي، پر پس منظر جي وصولي جھڙي ڪمن ۾ مداخلت ڪئي ويندي ان صورت ۾ جيڪڏهن ڪو ڪم اعليٰ ترجيح سان چالو ٿئي.

هر هڪ اسٽيڪ ۾ ترجيحات جو هڪ ڊفالٽ سيٽ هوندو آهي سلڪون ليبز جي تجزيي جي بنياد تي ته ڊيوٽي چڪر کي وڌائڻ لاءِ بهترين تعاون ڪيئن ڪجي ۽ عام استعمال جي ڪيس لاءِ ڪنيڪشن ختم ٿيڻ کان پاسو ڪجي. مخصوص استعمال جا ڪيس مختلف ضرورتون ٿي سگھي ٿي. ترجيحات ھيٺ ڏنل آھن، اعلي کان گھٽ تائين

1.  بلوٽوٽ لي شيڊول ٽرانسميٽ
2.  بلوٽوت LE شيڊول وصول ڪيو
3.  ٻيا پروٽوڪول شيڊول ٽرانسميٽ
4.  ٻيا پروٽوڪول پس منظر وصول

اهي ترجيحون ختم ٿي سگهن ٿيون يا ايپليڪيشن طرفان تبديل ٿي سگهن ٿيون. اهو فيصلو ڪرڻ لاءِ درخواست تي منحصر آهي ته ڪهڙين حالتن ۾ انهن کي تبديل ڪيو وڃي. سيڪشن 4.2 802.15.4 ريل جي ترجيح ۽ سيڪشن 6.1 بلوٽوٿ ترجيحات ۾ انھن جي مخصوص مثالن لاءِ ترجيحن تي وڌيڪ تفصيل شامل آھن.

ڦلڻ جو وقت

هر ريڊيو آپريشن کي لازمي طور تي "سلپ ٽائيم"، يا وڌ ۾ وڌ شروعاتي وقت هجڻ گهرجي، مطلب ته مستقبل ۾ سڀ کان وڌيڪ وقت جڏهن آپريشن شروع ٿي سگهي ٿو جيڪڏهن اهو درخواست ٿيل شروعاتي وقت تي شروع نه ٿي سگهي. هي شيڊولر کي اجازت ڏئي ٿو ته اعليٰ ترجيحي واقعن جي چوڌاري ڪم ڪن جيڪي هڪ ئي وقت ۾ ٿي رهيا آهن، يا اعليٰ ترجيحي واقعا جيڪي انهن جي متوقع مدت کان وڌي وڃن ٿا. پروٽوڪول عام طور تي ٻڌائي ٿو ته پرچي جو وقت ڇا ٿي سگهي ٿو، پر ريڊيو شيڊولر هن کي هر آپريشن جي بنياد تي سنڀالڻ جي قابل هوندو آهي، هڪ اسٽيڪ کي ڪجهه واقعن کي سلپ ڪرڻ جي اجازت ڏئي ٿو پر ٻين کي نه. عام طور تي، IEEE02.15.4 وٽ گهڻي پرچي جو وقت آهي ۽ بلوٽوت LE وٽ گهٽ ۾ گهٽ سلپ جو وقت آهي.

حاصلات

هڪ دفعو ريڊيو آپريشن جو هڪ سلسلو فعال طور تي هلي رهيو آهي، اسٽيڪ شايد شروعاتي آپريشن کي وڌائڻ لاءِ آپريشنز کي شامل ڪرڻ جاري رکي جيستائين اسٽيڪ کي خاص پيغام جي تبادلي لاءِ وڌيڪ ڪجهه نه ڪيو وڃي. هڪ اسٽيڪ لازمي طور تي حاصل ڪرڻ گهرجي جيستائين اهو پس منظر وصول نه ڪري رهيو آهي. جيڪڏهن هڪ اسٽيڪ حاصل نه ڪندو آهي ته پوءِ اهو پنهنجي ريڊيو آپريشن کي وڌائڻ جاري رکندو، ۽ گهٽ ترجيحي ريڊيو آپريشنز وري ساڳئي اسٽيڪ تي ناڪامي جو سبب بڻجندو جنهن ريڊيو آپريشن جي درخواست ڪئي هئي. هڪ اعلي ترجيح وارو آپريشن هن وقت هلندڙ، گهٽ ترجيحي ريڊيو آپريشن ۾ مداخلت نٿو ڪري سگهي جنهن کي حاصل نه ڪيو ويو آهي. ڏسو سيڪشن 5.1 Examples سان گڏ پس منظر وصول ڪرڻ، يئلڊ ريڊيو ۽ اسٽيٽ ٽرانزيڪشن for exampحالتون جتي واضح طور تي ريڊيو پيدا ڪرڻ ضروري آهي.

ريڊيو آپريشن ۾ مداخلت

هڪ مقرر ڪيل ريڊيو آپريشن ۾ مداخلت ٿي سگهي ٿي جيڪڏهن هڪ اعلي ترجيحي آپريشن ان سان تڪرار ڪري ٿي. اهو ٿي سگهي ٿو هيٺين ٻن حالتن ۾:

1. هڪ شيڊول ٿيل ريڊيو آپريشن توقع کان وڌيڪ وقت وٺندو آهي ۽ لاڳاپيل اسٽيڪ نه ڏيندو آهي اعليٰ ترجيحي ريڊيو آپريشن شروع ٿيڻ گهرجي.
2. هڪ اعلي ترجيحي ريڊيو آپريشن صرف مستقبل ۾ ٿيڻ لاءِ مقرر ڪيو ويو آهي ۽ اڳ ۾ ئي مقرر ڪيل گهٽ ترجيحي آپريشن سان ٽڪراءُ

ڊگھي رھندڙ ريڊيو آپريشن

ڪجھ ڊگھي رھندڙ ريڊيو آپريشنز کي پراڊڪٽ جي صحيح آپريشن تي وڏو اثر پئجي سگھي ٿو. ايپليڪيشن کي شايد ضرورت هجي انهن عملن کي پروٽوڪولن جي وچ ۾ همراه ڪرڻ. جيڪڏهن ايپليڪيشن نه ٿي ته پوءِ ريڊيو شيڊولر جي ترجيحن کي ترجيح ڏني ويندي. مثال طورampلي، هڪ IEEE 802.15.4 انرجي اسڪين گھربل ٿي سگھي ٿو ته ريڊيو تي رھي ڪافي توانائي پڙھڻ گڏ ڪرڻ لاءِ. جيڪڏهن ايپليڪيشن عملن کي صحيح طرح سان ترتيب نه ڏئي ٿي، اسڪين کي وقت کان اڳ مداخلت ڪري سگهجي ٿي ڇو ته اعلي ترجيح بلوٽوت آپريشن جي ڪري.

ريڊيو شيڊيولر Examples

سڀ سابقamples Bluetooth LE ۽ Zigbee استعمال ڪن ٿا، پر اصول ٻين بلوٽوت/802.15.4 مجموعن تي لاڳو ٿين ٿا.

شيڊولر شروع ٿئي ٿو گھٽ ترجيح Zigbee پس منظر حاصل ڪرڻ سان آپريشن. هي نمائندگي ڪري ٿو هميشه تي روٽر جنهن کي اڻڄاتل وقتن تي IEEE 802.15.4 پيڪٽس حاصل ڪرڻ جي ضرورت هجي. هڪ بلوٽوٿ LE ڪنيڪشن پڻ فعال آهي ۽ هر 30 ايم ايس وصول ڪرڻ لاءِ اسٽيڪ کي تيار ڪرڻ جي ضرورت آهي. بلوٽوٿ LE اسٽيڪ شايد اڳ ۾ ئي شيڊول ڪري سگھي ٿو ڪنيڪشن جي قابل ذڪر فطرت جي ڪري.

ترجيحي منصوبه بندي

هي هڪ بنيادي مثال ڏئي ٿوampمختلف ريڊيو آپريشنز جي ترجيحن جو فيصلو.

Zigbee اسٽيڪ فيصلو ڪري ٿو ته ان کي هڪ پيڪٽ موڪلڻ جي ضرورت آهي. اهو ٿي سگهي ٿو اهو هڪ آن ڊيمانڊ ايونٽ جي طور تي، مطلب ته اسٽيڪ فيصلو ڪري ٿو ته اهو شيڊيولر کي اڳ ۾ ئي ڄاڻ ڏيڻ کان سواءِ هاڻي هڪ پيڪيٽ موڪلڻ چاهي ٿو. اهو ان جي ابتڙ آهي ته ڪيئن بلوٽوت LE هلندي آهي، جتي شيڊول ٿيل آپريشنون اڳ ۾ ئي ڄاڻن ٿيون. شيڊيولر اندازو ڪري ٿو ته اهو ممڪن آهي Zigbee TX 1 ريڊيو آپريشن کي انجام ڏيڻ ۽ اڃا تائين خدمت ڪري ٿو اعلي ترجيح بلوٽوت LE استقبال واري واقعي جي مستقبل ۾. تنهن ڪري شيڊولر کي منتقلي واري واقعي جي اجازت ڏئي ٿي. Zigbee اسٽيڪ هن ٽرانسمٽ آپريشن جا سڀ ٽڪرا انجام ڏئي ٿو (ميڪ ايڪ جي انتظار ۾)، ۽ پوءِ رضاڪارانه طور تي حاصل ٿئي ٿو. Zigbee ٽرانسمٽ ريڊيو آپريشن جي تخميني ٽرانزيڪشن وقت ۾ ٻيهر ڪوششون شامل نه آھن.

هن ۾ اڳوڻيample، Bluetooth LE اڳ ۾ ئي مستقبل ۾ حاصل ڪرڻ لاءِ طئي ٿيل آهي ۽ Zigbee اسٽيڪ منتقل ڪرڻ چاهي ٿو. پهرين Zigbee TX 1 ريڊيو آپريشن لاءِ بلوٽوٿ LE RX 1 ريڊيو آپريشن کان اڳ ڪافي وقت آھي تنھنڪري شيڊيولر اسٽيڪ کي آپريشن ڪرڻ جي اجازت ڏئي ٿو. بعد ۾، جڏهن Zigbee اسٽيڪ Zigbee TX 2 کي شيڊول ڪرڻ جي ڪوشش ڪري ٿو، شيڊولر اهو طئي ڪري ٿو ته اعلي ترجيح بلوٽوت LE RX 2 واقعي کان اڳ ڪافي وقت نه آهي. بهرحال، Zigbee اسٽيڪ اشارو ڪيو آهي ته اهو عمل شايد ان جي شروعاتي وقت کي پرچي سگھي ٿو. ريڊيو شيڊيولر اهو طئي ڪري ٿو ته بلوٽوٿ LE ريڊيو آپريشن جي متوقع مدت کي ڏنو ويو Zigbee آپريشن ان واقعي کان پوءِ شروع ٿي سگهي ٿو ۽ اڃا به Zigbee اسٽيڪ پاران ظاهر ڪيل پرچي وقت جي اندر هوندو.

جيڪڏهن سڀ ڪجهه توقع جي مطابق ٿي وڃي، Zigbee ٽرانسميشن آپريشن جي پهرين ڪوشش ٿيندي بغير ڪنهن ناڪامي جي شيڊولنگ جي ڪري.

ترجيحي مداخلت Example

هن اڳوڻيample هڪ اعلي ترجيحي آپريشن کي بيان ڪري ٿو جيڪو گهٽ ترجيح واري عمل ۾ مداخلت ڪري ٿو.

 

 

 

هن اڳوڻيample ساڳئي طرح شروع ٿئي ٿو جيئن اڳئين اڳوڻيample. Zigbee ۽ Bluetooth LE ٻنهي وٽ هڪ ريڊيو آپريشن آهي جيڪو بغير ڪنهن ٽڪراءَ جي شيڊول ڪيو ويو آهي

بعد ۾، Zigbee اسٽيڪ اهو فيصلو ڪري ٿو ته اهو Zigbee TX 2 ايونٽ لاءِ هڪ ٻيو پيڪيٽ موڪلڻ چاهي ٿو. شيڊيولر اهو طئي ڪري ٿو ته اهو ممڪن ٿيڻ گهرجي ته هن واقعي کي شيڊول ڪرڻ ۽ بعد ۾ بلوٽوٿ LE RX 2 ايونٽ جي خدمت ڪرڻ، ان وقت جي بنياد تي جيڪو Zigbee TX 2 واقعو وٺڻ گهرجي. بهرحال، Zigbee TX 2 ايونٽ ڊگهي بي ترتيب واري واپسي جي ڪري توقع کان وڌيڪ وقت وٺندو آهي ۽ وقت ۾ حاصل نٿو ڪري. اهو واقعو هڪ اعليٰ ترجيحي ريڊ پريشن سان ٽڪرائڻ جو سبب بڻجندو آهي، ۽ ان ڪري ريڊيو شيڊيولر Zigbee ايونٽ ۾ مداخلت ڪري ٿو ۽ اعليٰ سطحي اسٽيڪ ۾ ناڪامي واپس ڪري ٿو. بلوٽوٿ LE واقعو عام طور تي ٿئي ٿو ۽ جڏهن اهو مڪمل ٿئي ٿو ته اهو رضاڪارانه طور تي ڪنهن به هيٺين ترجيحي عملن کي حاصل ڪري ٿو.

ريڊيو شيڊولر کان ناڪامي حاصل ڪرڻ تي Zigbee اسٽيڪ فوري طور تي MAC پيغام کي ٻيهر ڪوشش ڪرڻ جي ڪوشش ڪري ٿو. اهو آپريشن کي ترتيب ڏئي ٿو ۽ هڪ پرچي وقت شامل آهي. هن جڳهه تي بلوٽوٿ LE اسٽيڪ کي ريڊيو تي ترجيح ڏني وئي آهي ۽ اهڙيء طرح آپريشن اڃا شروع نه ٿو ڪري سگهجي، پر شيڊولر نئين ريڊيو آپريشن کي قبول ڪري ٿو. بلوٽوٿ LE اسٽيڪ مڪمل ڪري ٿو ان جي مقرر ڪيل وصولي ۽ حاصل ڪري ٿو ريڊيو. شيڊولر وري Zigbee ٽرانسمٽ آپريشن کي شروع ڪري ٿو ڇاڪاڻ ته اهو اڃا تائين شروعاتي شروعاتي آپريشن جي سلپ وقت جي اندر آهي. ٽرانسميشن مڪمل ٿيڻ کان پوءِ شيڊولر پس منظر ڏانهن موٽندو آهي وصولي آپريشن.

اعلي ترجيح وارو آپريشن جيڪو وڌايو ويو آھي

هن اڳوڻيampلي ڏيکاري ٿو ته ڇا ٿئي ٿو جڏهن هڪ اعلي ترجيحي آپريشن اصل ۾ متوقع کان وڌيڪ وقت وٺندو آهي ۽ گهٽ ترجيح واري آپريشن کي ان جو موقعو وڃائڻ جو سبب بڻائيندو آهي

انهي صورت ۾، بلوٽوت LE هڪ شيڊول وصول ڪيو آهي جيڪو هن وقت ٿي رهيو آهي. Zigbee هڪ پيڪٽ موڪلڻ جو فيصلو ڪيو پر اهو هن وقت هلائي نٿو سگهجي. شيڊيولر ان فرض جي تحت آپريشن کي قبول ڪري ٿو ته بلوٽوٿ LE ايونٽ مڪمل ٿيندو زگبي ايونٽ جي سلپ ٽائيم ختم ٿيڻ کان اڳ. بهرحال، بلوٽوت LE ايونٽ ڊگھي وڌندي آهي ان حقيقت جي ڪري ته اضافي پيڪيٽ ڊوائيسز جي وچ ۾ موڪليا ويا آهن. بلوٽوٿ LE آپريشن کي ترجيح ڏني وئي آھي تنھنڪري Zigbee آپريشن آخرڪار سلپ مان نڪرندو آھي. هڪ غلطي اسٽيڪ ڏانهن واپس ڪئي وئي آهي. Zigbee پيڪٽ کي ٻيهر منتقل ڪرڻ جو فيصلو ڪيو. ٻيهر، Zigbee اسٽيڪ اشارو ڪري ٿو ته آپريشن هاڻي شروع ٿيڻ گهرجي پر مستقبل ۾ پرچي سگھي ٿو. شيڊيولر ريڊيو جي ترتيب کي تبديل ڪرڻ جي وچ ۾ آهي، تنهنڪري اهو فوري طور تي آپريشن شروع نٿو ڪري سگهي. ان جي بدران، اهو ريڊيو آپريشن جي شروعاتي وقت کي ٿوري مقدار ۾ سلپ ڪري ٿو ۽ پوء آپريشن کي انجام ڏئي ٿو.

بغير مداخلت جي اعلي ترجيحي آپريشن 

هن ۾ اڳوڻيampلي ريڊيو شيڊيولر هڪ بلوٽوت LE پردي جي طور تي ڪم ڪندڙ نوڊ تي هلندو آهي ۽ اهو نوڊ مختلف مرڪزي ڊوائيسز سان ڪنيڪشن جو تعداد آهي. اهو پڻ هڪ وقتي اشتهارن جو بيڪن آهي جيڪو منتقل ڪيو ويندو آهي. هيٺ ڏنل انگ اکر ڏيکاري ٿو هڪ ڪيس جتي اهي واقعا واقع ٿي رهيا آهن حقيقت ۾ پوئتي موٽڻ ۽ ڪافي وقت جي اجازت نه ڏيو Zigbee ريڊيو ترتيب ڏانهن واپس وڃڻ لاءِ. تنهن ڪري اهو هڪ دور ٺاهيندو جتي Zigbee اسٽيڪ آهي
پرچي وقت جي باوجود منتقل ڪرڻ جي قابل نه.

Zigbee شيڊيولر کان پڇي ٿو ته ٽرانسمٽ ريڊيو آپريشن کي شيڊول ڪرڻ لاءِ. جيتوڻيڪ شيڊولر ڄاڻي ٿو ته واقعي جي ناڪام ٿي ويندي مقرر ڪيل اعلي ترجيحي عملن جي ڪري، اهو اڃا تائين طئي ٿيل واقعي کي قبول ڪري ٿو. اهو ٻن سببن لاء ڪيو ويندو آهي. پهرين، حالتون تبديل ٿي سگهن ٿيون ۽ واقعي تي عمل ڪري سگهجي ٿو. ٻيو، اسٽيڪ ريڊيو شيڊولر جي چوٽي تي ويٺي ٿي سگھي ٿو ڪوشش ڪرڻ جي ڪوشش ڪرڻ جي عمل کي. جيڪڏهن ناڪام شيڊولنگ جو نتيجو فوري طور تي واپس ڪيو ويو ته پوء اسٽيڪ جي ٻيهر ڪوشش ڪرڻ جي ڪوشش ڪامياب ٿيڻ جو امڪان نه هوندو، ڇاڪاڻ ته وقت نه گذريو آهي. ان جي بدران، ايونٽ کي قطار ڪرڻ ۽ سلپ جو وقت ختم ٿيڻ کان پوءِ ناڪامي کي واپس ڪرڻ سان، ٻيهر ڪوشش (پنهنجي سلپ وقت سان) ڪاميابي جو هڪ بهتر موقعو آهي جيئن ايندڙ ريڊيو آپريشنز جو سيٽ مختلف هوندو.

وصول ڪريو جڏهن اعليٰ ترجيحي آپريشن هلندڙ آهي 

هن اڳوڻيample وضاحت ڪري ٿو ته ڇا ٿيندو جڏهن بلوٽوٿ LE فعال هوندو آهي ۽ گهٽ ترجيحي آپريشن ڊيٽا وصول ڪندي.

پهرين صورت ۾، جڏهن هڪ IEEE 802.15.4 پيغام موڪليو ويو آهي ۽ بلوٽوت LE اسٽيڪ ريڊيو کي استعمال ڪري رهيو آهي هڪ فعال وصول ڪرڻ لاءِ Zigbee اسٽيڪ پيغام حاصل ڪرڻ لاءِ آن لائن نه هوندو. جڏهن ته، پيغام جو Zigbee موڪليندڙ اڪثر ڪيسن ۾ ٻيهر ڪوشش ڪندو ۽ بيڪ آف ۽ ٻين وقت جي تبديلين سان تڪرار نه ٿيڻ وارو آهي ٻي اعلي ترجيحي شيڊول ٿيل بلوٽوٿ وصول ٿيندڙ واقعن سان ٽڪرائڻ جو امڪان ناهي. Zigbee پيغام ڪاميابيءَ سان ملي ويو

ٻيو ڪيس ظاهر ڪري ٿو ته، هڪ فعال وصولي جي صورت ۾، Zigbee اسٽيڪ اڃا به رڪاوٽ ٿي سگهي ٿو ۽ پيغام وصول نه ڪيو (يا ACK). ڪامياب ڪميونيڪيشن هن پيغام کي ٻيهر موڪلڻ لاءِ MAC يا اعليٰ پرت تي ٻيهر ڪوششن تي ڀاڙي ٿو ۽ تصديق ڪري ٿو ته ڊائنامڪ ملٽي پروٽوڪول ڊيوائس پيغام وصول ڪري ٿي.

جيتوڻيڪ اتي ويچار ٿي سگھي ٿو ته فعال وصولي ۾ مداخلت ٿيڻ گهرجي يا نه، اهو طئي ڪرڻ لاءِ شيڊيولر لاءِ ڏکيو آهي. عام طور تي پروٽوڪول جي مضبوطي کي پيغامن کي ڪاميابي سان حاصل ڪرڻ جي اجازت ڏيڻ گهرجي جيتوڻيڪ مداخلت سان

802.15.4 بيسڊ اسٽيڪ سان ملٽي پروٽوڪول کي لاڳو ڪرڻ

هي باب هڪ 802.15.4 تي ٻڌل اسٽيڪ لاڳو ڪرڻ بابت عام معلومات پيش ڪري ٿو جهڙوڪ Zigbee يا Connect هڪ ملٽي پروٽوڪول ايپليڪيشنن جي حصي طور. وضاحتن لاءِ ته ڪيئن ترتيب ڏيو plugins ۽ ٻيا تفصيل مخصوص آرٽيڪل پروٽوڪول لاءِ، هيٺ ڏنل ايپليڪيشن نوٽس مان هڪ ڏسو:

• AN1133: بلوٽوت ۽ Zigbee EmberZNet SDK 6.x ۽ لوئر سان متحرڪ ملٽي پروٽوڪول ڊولپمينٽ
•  AN1209: بلوٽوت ۽ ڪنيڪٽ سان متحرڪ ملٽي پروٽوڪول ڊولپمينٽ

وائرليس پروٽوڪول سپورٽ

مختلف وائرليس پروٽوڪول ۾ مختلف خاصيتون آهن جن کي متحرڪ ملٽي پروٽوڪول جي ڊيزائن سان گڏ ڪيو ويو آهي. مثال طورample, Bluetooth گھٽ توانائي ان جي ريڊيو آپريشن جي شيڊول ۾ تمام سخت ۽ اڳڪٿي لائق آھي. اشتهار ۽ ڪنيڪشن جا وقفا مقرر وقتن تي ٿين ٿا. ان جي ابتڙ، هڪ 802.15.4 پروٽوڪول ڪيترن ئي پيغامن جي واقعن جي وقت ۾ وڌيڪ لچڪدار آهي؛ IEEE 802.15.4 ۾ CSMA (ڪيريئر سينس گھڻن رسائي) بي ترتيب واري واپسي کي شامل ڪري ٿو ته جيئن واقعي جي دير مليس سيڪنڊن جي ترتيب تي هجي. هي IEEE 802.15.4 پيغامن کي بلوٽوٿ لو انرجي واقعن جي چوڌاري موڪلڻ جي اجازت ڏئي ٿو ۽ اڃا به معتبر طور تي وصول ڪيو وڃي ٿو.

802.15.4 ريل جي ترجيح

802.15.4 پروٽوڪول هن وقت ٽي ريل ترجيحات آهن.

نه.	نالو	ڊفالٽ سيٽنگ	نڪرڻ جو معيار
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 پروٽوڪول-بلوٽوٿ ملٽي پروٽوڪول ايپليڪيشن ۾، ڊفالٽ بلوٽوٿ ٽريفڪ هميشه 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

ڇاڪاڻ ته بلوٽوت شروعاتي طور تي پنهنجي ريل جي ترجيح کي 32 تي مقرر ڪري ٿو، اهي 802.15.4 ترجيحي سيٽنگون 802.15.4 ٽريفڪ کي شروعاتي طور تي بلوٽوت جي ڀيٽ ۾ وڌيڪ ترجيح ڏين ٿيون، جيڪو 802.15.4 پروٽوڪول کي ٽريفڪ منتقل ڪرڻ يا وصول ڪرڻ جو هڪ موقعو ڏئي ٿو ڪاميابيءَ سان. بلوٽوٽ ٽرئفڪ جو وڏو لوڊ. ٻئي طرف، بلوٽوت پنهنجي ترجيح کي متحرڪ طور تي وڌائيندو جيڪڏهن اهو شيڊولر کان 802.15.4 ٽريفڪ جي ذريعي، 16 جي اعلي ترجيحن تائين ڇڪايو ويندو آهي. اهڙيء طرح 802.15.4 پروٽوڪول کي ريڊيو تائين رسائي جي اجازت ڏيڻ کان پوء، بلوٽوت وٺي ويندي. جيڪڏهن ضروري هجي ته ايندڙ ڪوششن تي ترجيح.

اهو طريقو ٻنهي پروٽوڪولن کي اجازت ڏئي ٿو ته انهن جي ريڊيو جي استعمال تي سمجھوتو ڪرڻ جي بغير هڪ ٻئي تي مڪمل طور تي غالب ٿيڻ جي قابل.

. ريل سان ملٽي پروٽوڪول لاڳو ڪرڻ 

هي باب انهن صارفين لاءِ RAIL جي خاصيتن بابت وڌيڪ معلومات پيش ڪري ٿو جيڪي RAIL API استعمال ڪن ٿا سڌو سنئون پروٽوڪول ٺاهڻ لاءِ. خاص طور تي اهو تفصيل پيش ڪري ٿو ته ڪيئن ڪم ڪجي RAIL APIs سان مخصوص ريڊيو شيڊيولر ڪيسن کي سنڀالڻ لاءِ.

Examples سان گڏ پس منظر وصول ڪرڻ، حاصل ڪيل ريڊيو ۽ رياستي منتقلي

RAIL ملٽي پروٽوڪول ترجيحي نظام جا بنيادي اصول بلڪل سادا آھن: ھڪڙو ريڊيو واقعو اعليٰ ترجيح سان (جيڪو آھي، تعداد ۾ ننڍو) ھميشه ڪنھن ٻئي ريڊيو واقعن کي گھٽ ترجيح سان گڏ ھلائيندو. بهرحال، هي موضوع وڌيڪ پيچيده ٿي ويندو آهي جڏهن رياست جي منتقلي ۽ APIs تي غور ڪيو وڃي جيئن ته RAIL_StartRx()، جيڪو ريڊيو کي هڪ خاص حالت ۾ غير معين وقت تائين رکي ٿو. هي سيڪشن ڪجهه مثال پيش ڪري ٿو هڪ مثالamples اهو ظاهر ڪرڻ لاءِ ته اهي وقت جي غير محدود رياستن کي ڪيئن سنڀاليو وڃي ٿو، ۽ ڪيئن ايپليڪيشن پرت APIs استعمال ڪري سگهي ٿي جهڙوڪ RAIL_YieldRadio() انهن کي ڪنٽرول ڪرڻ لاءِ. سابقampهن ريت آهن:

• هڪ واحد پروٽوڪول سان رياستي منتقلي
• ٻن پروٽوڪول سان رياستي منتقلي
• رياستي منتقلي ٻن پروٽوڪول سان ۽ هڪجهڙائي سان وڌندڙ ترجيحات

انهن ۾ اڳوڻيamples، RAIL_StartTx() TX واقعي جو ذريعو آهي جيڪو پس منظر RX ۾ مداخلت ڪري ٿو. نوٽ، بهرحال، اهي اڳوڻيamples ڪنهن به ريڊيو API تي لاڳو ٿين ٿا سواءِ RAIL_StartRx(). ٻين لفظن ۾، اڳوڻيamples ڪنهن به API تي لاڳو ٿئي ٿو جيڪو ريڊيو ايونٽ شروع ڪري ٿو جيڪو پس منظر RX نه آهي

اهي سابقampرياست جي منتقلي جي حوالي سان متوقع ملٽي پروٽوڪول رويي کي بيان ڪري ٿو. اختصار ڪرڻ:

• رياست جي منتقلي ۾، نئين رياست کي ان ئي ترجيح تي شروعاتي واقعي جي اڻڄاتل واڌ جي طور تي علاج ڪيو ويندو آهي جيستائين RAIL_YieldRadio() سڏيو ويندو آهي.
• پس منظر RX واقعا متاثر نه ٿيا RAIL_YieldRadio(). صرف RAIL_Idle() مستقل طور پروٽوڪول کي پس منظر RX اسٽيٽ مان هٽائي سگھي ٿو.
• ھڪڙو واقعو اعلي ترجيح سان ھميشه ھڪڙي واقعي کي گھٽ ترجيح سان گڏ ڪندو، بغير ڪنھن ٻئي API ڪالن جي.
• RAIL_YieldRadio() يا RAIL_Idle().
• RAIL_StartRx() کان سواءِ سڀني ريڊيو واقعن کي RAIL_YieldRadio() جي ضرورت آهي ته جيئن پوءِ ايندڙ واقعي کي ختم ڪرڻ ۽ اڳتي وڌڻ لاءِ.
• RAIL_YieldRadio() کي ڪال RAIL_Idle() سان تبديل نه ٿي ڪري سگھجي. RAIL_Idle() ڏنل پروٽوڪول لاءِ سڀني واقعن کي صاف ڪري ٿو

.هڪ واحد پروٽوڪول سان رياستي منتقلي

هي پهريون سابقampلي هڪ واحد پروٽوڪول سان ريڊيو جي رويي کي جانچيندو آهي (اهو آهي، جتي ساڳيو AIL_Handle_t استعمال ڪيو ويندو آهي سڀني ريڊيو فنڪشن ڪالن لاء). ريڊيو RX ۾ شروعاتي ڪال سان RAIL_StartRx() تي شروع ٿئي ٿو، پوءِ 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() کي پروٽوڪول A تي ڪال نه ڪري. جڏھن RAIL_StartRx() کي TX دوران سڏيو ويندو آھي، RX صرف شامل ڪيل واقعن جي قطار ۾ شامل ڪيو وڃي.

ٻيو اهم نقطو اهو آهي ته، جيتوڻيڪ RAIL_YieldRadio() پروٽوڪول A تي TX کان پروٽوڪول A تي RX کان پروٽوڪول B تي، هڪ RAIL_Idle() پروٽوڪول B تي RX کان پروٽوڪول B تي RX کان پروٽوڪول A تي منتقل ٿيڻ جي ضرورت آهي. هتي فلسفو اهو آهي ته پس منظر RXs حقيقت ۾ حاصل نه ٿي ڪري سگھجي، ڇو ته واقعي واقعي ڪڏهن به ختم نه ٿيو آهي. نڪرڻ جو واحد رستو آھي پس منظر RX کي ڪال ڪرڻ سان RAIL_Idle().

 ٻن پروٽوڪول سان رياستي منتقلي ۽ هڪجهڙائي سان وڌندڙ ترجيح

آخري منظرنامو تقريباً پوئين هڪ جهڙو آهي، سواءِ RAIL_StartRx() کي پروٽوڪول B تي ڪال، پروٽوڪول A تي RAIL_StartTx() کي ڪال کان وڌيڪ اوليت تي آهي.

انهي صورت ۾، ڇو ته ٻئي RAIL_StartRx() جي ترجيح RAIL_StartTx () جي ڪال جي ترجيح کان وڌيڪ آهي، RAIL_YieldRadio() کي ڪال ڪرڻ جي ضرورت ناهي. ڇاڪاڻ ته ٻيو RAIL_StartRx() هڪ اعليٰ ترجيح تي آهي، اهو RAIL_StartTx() واقعي تي قبضو ڪري ٿو، ريڊيو جو ڪنٽرول وٺڻ ۽ رياست مان TX واقعي کي هٽائڻ. ڪنهن به وقت ان دوران RX پروٽوڪول B تي، RAIL_Idle() کي سڏيو وڃي ٿو RX ڏانهن واپسي لاءِ پروٽوڪول A تي، جيئن اڳئين اڳوڻي ۾ampلي.

هتي نوٽ ڪريو ته جڏهن ايپليڪيشن RAIL_Idle() کي پروٽوڪول B جي RX تي ڪال ڪري ٿي، ته ايپليڪيشن پروٽوڪول A جي TX منتقلي ڏانهن واپس نه ايندي آهي. ان جي بدران، اهو صحيح پس منظر RX ڏانهن وڃي ٿو، جيتوڻيڪ ايپليڪيشن ڪڏهن به پروٽوڪول تي RAIL_Idle() نه سڏيو آهي. A جي TX. شيڊول ٿيل ريڊيو آپريشنز لاءِ (يعني، RAIL_StartRx() کان سواءِ ڪنهن API پاران شروع ڪيل ڪو به ريڊيو آپريشن)، هڪ دفعو ريڊيو ايونٽ هڪ اعليٰ ترجيح واري واقعي کان کسجي ويندو آهي، اهو مڪمل طور تي هٽايو ويندو آهي ۽ بعد ۾ واپس نه ڪيو ويندو. صرف پس منظر وصول ڪري ٿو، RAIL_StartRx () پاران شروع ڪيو ويو، ٺھيل گرائونڊ ۾ برقرار رکي سگھجي ٿو ۽ RAIL_YieldRadio() يا RAIL_Idle() کي ڪال ذريعي 'واپس ڪيو ويو'.

RAIL_YieldRadio() ۽ RAIL_Idle() جي وچ ۾ فرق تي زور ڏيڻ لاءِ اهو نوٽ ڪرڻ ضروري آهي ته، انهن سڀني لاءِ اڳوڻيamples، RAIL_YieldRadio() کي ڪال RAIL_Idle() سان تبديل نه ٿي ڪري سگھجي. RAIL_Idle() ڏنل پروٽوڪول لاءِ سڀني واقعن کي صاف ڪري ٿو - ٻئي پس منظر (جيڪو شروع ڪيو ويو RAIL_StartRx()) ۽ شيڊول ٿيل (يعني RAIL_StartRx()) آپريشنز کان سواءِ APIs پاران شروع ڪيو ويو. RAIL_Idle() واقعي اڃا تائين ايپليڪيشن کي TX جي منتقلي واري حالت مان نڪرڻ جو سبب بڻائيندو، پر اهو پڻ پس منظر RX کي صاف ڪري ڇڏيندو، جنهن جي ڪري ايپليڪيشن کي بيڪار ڏانهن موٽڻ جو سبب بڻائيندو، نه RX.

بلوٽوت سان ملٽي پروٽوڪول کي لاڳو ڪرڻ

تفصيلن لاءِ ته ڪيئن ريل/بلوٽوت لائيٽ/سوئچ ملٽي پروٽوڪول اڳample تي عمل ڪيو ويو، ۽ RAIL تي توهان جي پنهنجي پروٽوڪول سان ملٽي پروٽوڪول ايپليڪيشن ٺاهڻ بابت وڌيڪ معلومات لاءِ، ڏسو AN1134: Dynamic Multiprotocol Development with Bluetooth and Proprietary Protocols in RAIL in GSDK v2.x or AN1269 Dynamic Multiprotocol Development with Bluetooth and Proprietary Proprietary Protocol on Rail. GSDK v3.x ۽ اعلي ۾.

بلوٽوت ترجيحات

جيئن ته مختلف آپريشن جي قسمن لاءِ مستحڪم طور تي بيان ڪيل ترجيحن سان Zigbee جي مخالفت، بلوٽوت استعمال ڪري ٿو رينج ۽ آفسيٽ طريقي سان سڀني ڪمن کي تفويض ڪرڻ لاءِ ترجيحي اسپيڪٽرم جي ڏنل علائقي ۾.

هن ۾ اڳوڻيampبلوٽوت جي ترجيح واري حد، جيڪا پاڻ 0 کان 255 تائين پکڙيل آهي، شيئر ڪيل ريل جي ترجيح واري جاءِ جي محدود حصي تي نقشي ۾ ٺهيل آهي.

Zigbee جي برعڪس، بلوٽوت کي تمام گهڻو سخت وقت جي گهرج آهي جتي ڏنل سلاٽ غائب ٿي سگھي ٿو ڪنيڪشن ختم ٿيڻ جي نتيجي ۾. بلوٽوٿ ۾ پڻ مختلف ڪمن جو هڪ سلسلو آهي جهڙوڪ (امڪاني طور تي گھڻا) ڪنيڪشن، اشتهار، اسڪيننگ، ۽ وقتي اشتهارن سان جواب ڏيڻ (PAwR) ٽرانسميشن ۽ استقبال.

جدول 6.1. بلوٽوت ۾ مختلف ترجيحات

1	ڪنيڪشن	135 کان 0 تائين	ڪنيڪشن واقعي ختم ٿي
2	ڪنيڪشن جي شروعات	55 کان 15 تائين	شروعات ونڊو ختم ٿي
3	اشتهار	175 کان 127 تائين	اشتهاري تقريب ختم ٿي
4	اسڪينر	191 کان 143 تائين	اسڪين ونڊو ختم
5	PAWR TX	15 کان 5 تائين	اشتهار ڏيڻ وارو: PAwR جوابي سلاٽ دير ختم ٿئي ٿو هم وقت سازي: PAwR جوابي سلاٽ ختم ٿي
6	PAWR RX	20 کان 10 تائين	اشتهار ڏيندڙ: PAwR جوابي سلاٽ ختم ٿي ويو هم وقت ساز: PAwR جوابي سلاٽ دير ختم ٿي

هن کي سنڀالڻ لاءِ بلوٽوٿ شيڊولر، جن جي ترجيحن کي RAIL ريڊيو شيڊيولر سان ميپ ڪيو ويو آهي، هر ڪم لاءِ هيٺين پيرا ميٽرن کي حساب ۾ رکي ٿو:

1.  شروعاتي وقت
2.  گھٽ ۾ گھٽ وقت
3.  وڌ ۾ وڌ وقت
4.  ترجيح
   

جيڪڏهن شروعاتي وقت کي منتقل ڪيو وڃي ته مجموعي طور تي هلندڙ وقت گهٽجي ويو آهي، اهو آهي سست گھٽجي ويو آهي. پڻ ترجيحات کي متحرڪ طور تي ترتيب ڏئي سگھجي ٿو.

ڪنيڪشن

ڪنيڪشن هڪ نسبتا اعلي ترجيح آهي. ڪنيڪشن جي شروعاتي وقت کي منتقل نه ٿو ڪري سگھجي.

بلوٽوٿ شيڊولر جي طرفان ترجيحي طور تي وڌي وئي آهي ڪنيڪشن جي نگراني جي وقت جي ويجهو، ۽ وڌ کان وڌ ترجيح ان جي ويجهو پهچي ٿو. TX قطار ۾ هڪ TX پيڪيٽ پڻ ڪنيڪشن جي ترجيح وڌائي ٿو.

ڪنيڪشن جي شروعات

ڪنيڪشن جي شروعات ڪنيڪشن قائم ڪرڻ لاءِ ٽارگيٽ ڊيوائس مان اشتهارن کي اسڪين ڪري ٿو. وڌيڪ مضبوط ڪنيڪشن قائم ڪرڻ جي اجازت ڏيڻ لاءِ اسڪينر جي مقابلي ۾ ان کي اعليٰ ترجيح ڏني وئي آهي.

اشتهارن

ڊفالٽ طور اشتهارن کي گهٽ ترجيح آهي ۽ انهن جي شروعاتي نقطي کي منتقل ڪري سگهجي ٿو. شروعاتي وقت ۽ وڌ ۾ وڌ وقت اشتهارن جي وقفي سان بيان ڪيا ويا آهن.

جيڪڏهن ڪو اشتهار نه موڪليو وڃي ته، اشتهارن جي ترجيح سست رفتاري سان وڌي ويندي آهي ۽ هڪ ڀيرو ڪاميابيءَ سان موڪلڻ کان پوءِ ٻيهر سيٽ ڪيو ويندو آهي.

اسڪينر

ڊفالٽ طور، انهن ڪمن کي تمام گھٽ ترجيح آهي. شروع، گھٽ ۾ گھٽ ۽ وڌ ۾ وڌ وقت اسڪيننگ جي وقفي ۽ ونڊو سائيز جي وضاحت ڪئي وئي آھي. اسڪيننگ جاري رهي سگهي ٿي جيتوڻيڪ هڪ اعلي ترجيحي ڪم جي وچ ۾ مداخلت. جيڪڏهن ائين ٿئي ٿو ته اسڪين جو وقت گڏ ڪيو ويندو آهي انهي کي يقيني بڻائڻ لاءِ ته گهربل اسڪين ونڊو سائيز هر اسڪيننگ وقفي تي پهچي وڃي.

جيئن ته اشتهارن سان ترجيح وڌي ويندي آهي ان صورت ۾ جڏهن گهربل اسڪين وقفو يا ونڊو سائيز اڳ ۾ پورو نه ٿي سگهيو هجي. هڪ ڀيرو اسڪين جي وقفي يا ونڊو جي ماپ پوري ٿيڻ کان پوءِ ان کي واپس ان جي ابتدائي ترجيح تي بحال ڪيو ويندو.

جوابن سان وقتي اشتهار (PAwR) 

جوابن سان گڏ وقتي اشتهار موڪلڻ کي ٻين سڀني بلوٽوٿ ڪمن تي ڊفالٽ جي لحاظ کان اعليٰ ترجيح حاصل آهي، ان کان پوءِ PAwR ۾ جواب حاصل ڪرڻ لاءِ هڪ اليڪٽرانڪ شيلف ليبل (ESL) نيٽ ورڪ ۾ هم وقت سازي کي برقرار رکڻ لاءِ.

هڪ PAwR ٽاسڪ جي ترجيح وڌي ويندي آهي جيڪڏهن ٽاسڪ شيڊيولنگ ​​هڪ قطار ۾ ٻه ڀيرا ناڪام ٿئي ٿي. ترجيح يا ته ترجيحي حد جي 1/6th کان وڌي وئي آھي، يا گھٽ ۾ گھٽ ھڪڙي وڌندي آھي جيستائين وڌ ۾ وڌ ترجيح تي پھچي وڃي. ڪم جي ترجيح کي ڪامياب شيڊول ڪرڻ کان پوءِ گھٽ ۾ گھٽ واپس ڪيو ويندو. ساڳيو طريقو ٻنهي طرفن ۾ PAwR اشتهار ڏيندڙ هڪ هم وقت سازي تي لاڳو ٿئي ٿو

Exampبلوٽوٽ شيڊولر آپريشن جو لي 

هن اڳوڻيample وضاحت ڪري ٿو ته ڪيئن بلوٽوٿ شيڊولر ٽي ڪنيڪشن ٽاسڪ ۽ هڪ اشتهاري ڪم کي شيڊول ڪندو، هر هڪ مختلف ترجيحن تي مشتمل هوندو. هيٺ ڏنل انگن اکرن ۾ سرمائي حصو ڏيکاري ٿو گهٽ ۾ گهٽ رن ٽائم جيڪو ڪم جي ضرورت آهي ۽ نيرو حصو ڏيکاري ٿو وڌ ۾ وڌ رن ٽائم جيڪو ڪم استعمال ڪري سگهي ٿو ۽، جيڪڏهن لچڪدار هجي، اهو علائقو جتي ڪم منتقل ٿي سگهي ٿو. هيٺيون شڪل شروعاتي سيٽ اپ ۾ ڏيکاري ٿو

جيئن هيٺ ڏيکاريل آهي Conn1 هلائڻ لاءِ پهريون ڪم آهي جيئن اهو ڪنهن به اعليٰ ترجيحي ڪم سان اوورليپ نٿو ٿئي.

Adv1 اوورليپ ڪري ٿو اعليٰ ترجيح Conn2 سان. Adv1 لچڪدار آھي ۽ تنھنڪري ھيٺ ڏنل شڪل ۾ بيان ڪيل طور تي منتقل ٿي ويو آھي.

Conn2 اوورليپ ڪري ٿو اعليٰ ترجيحي ڪم سان Conn4. جيئن ته Conn2 لچڪدار نه آهي Conn2 جي شيڊول ناڪام ٿي.

Conn4 ٻين ڪمن سان اوورليپ نٿو ٿئي، تنهن ڪري Conn1 جي آخر ۾ ترتيب ڏني وئي آهي ته Conn4 شروع ٿيڻ کان اڳ بند ٿي وڃي.

Conn4 ٻين ڪمن سان اوورليپ نٿو ٿئي، تنهن ڪري Conn1 جي آخر ۾ ترتيب ڏني وئي آهي ته Conn4 شروع ٿيڻ کان اڳ بند ٿي وڃي.

ترجيحات کي تبديل ڪرڻ

"sl_bt_configuration_t" (v3.x)/"gecko_configuration_t" (v2.x) struct وضاحت ڪري ٿو sl_bt_stack_config_t struct، جنهن ۾ فيلڊ شامل آهي "bluetooth.linklayer_priorities" جيڪو ترجيح جي ترتيب ڏانهن اشارو آهي. جيڪڏهن پوائنٽر NULL آهي ته پوءِ اسٽيڪ ان جي ڊفالٽ ترجيحن کي استعمال ڪري ٿو جيئن سيڪشن 6.1 ۾ ڏنل بلوٽوٿ ترجيحات مٿي ڏنل سيڪشن سان گڏ.

ان صورت ۾ پوائنٽر خالي نه آهي ان کي ترجيحي سيٽنگن جي ھڪڙي جوڙجڪ ڏانھن اشارو ڪرڻ گھرجي جيئن ھيٺ بيان ڪيو ويو آھي:

سينڊمان، سئنيمڪس، 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 بلوٽوت ترجيحات ۾ ڏسي سگھجي ٿو. ريل_ميپنگ_آفسيٽ ۽ ريل_ميپنگ_رينج ٻنهي لاءِ ڊفالٽ 16 آهي.

adv_step ۽ اسڪين قدم پيٽرولر قدم جي سائيز کي بيان ڪن ٿا جڏهن اسڪيننگ ۽ اشتهارن جي ترجيح کي متحرڪ طور تي تبديل ڪيو وڃي. آخرڪار، پيرا ميٽرس pawr_tx_min، pawr_tx_min، pawr_tx_min، ۽ pawr_rx_max Par Advertiser ۽ synchronizer TX ۽ RX واقعن لاءِ ترجيحي حد مقرر ڪن ٿا.

IoT پورٽ فوليو
www.silabs.com/products

ڪيفيت
www.silabs.com/quality

سپورٽ ۽ ڪميونٽي
www.silabs.com/community

رد ڪرڻ

Silicon Labs گراهڪن کي مهيا ڪرڻ جو ارادو رکي ٿو جديد، صحيح، ۽ گہرا دستاويز مهيا ڪرڻ لاءِ موجود سڀني پردي ۽ ماڊلز جي سسٽم ۽ سافٽ ويئر لاڳو ڪندڙن لاءِ استعمال ڪرڻ يا استعمال ڪرڻ جو ارادو Silicon Labs پروڊڪٽس. خاصيت جي ڊيٽا، دستياب ماڊلز ۽ پرديئرز، ميموري سائيز ۽ ميموري ايڊريس هر هڪ ڏانهن اشارو ڪيو
مخصوص ڊوائيس، ۽ "عام" پيٽرولر مهيا ڪري سگھن ٿا ۽ مختلف ايپليڪيشنن ۾ مختلف ٿي سگهن ٿا. درخواست مثالampهتي بيان ڪيل les صرف مثالي مقصدن لاءِ آهن. Silicon Labs هتي موجود پراڊڪٽ جي معلومات، وضاحتن، ۽ وضاحتن ۾ وڌيڪ نوٽيس کانسواءِ تبديليون ڪرڻ جو حق محفوظ رکي ٿي، ۽ شامل ڪيل معلومات جي درستگي يا مڪمل ٿيڻ جي ضمانت نه ڏئي ٿي. اڳواٽ اطلاع جي بغير، سلڪون ليبز حفاظتي يا قابل اعتماد سببن جي ڪري پيداوار جي عمل دوران پيداوار جي فرم ویئر کي اپڊيٽ ڪري سگھي ٿي. اهڙيون تبديليون خاصيتون يا پيداوار جي ڪارڪردگي کي تبديل نه ڪندي. Silicon Labs هن دستاويز ۾ مهيا ڪيل معلومات جي استعمال جي نتيجن جي ذميواري نه هوندي. هي دستاويز ڪنهن به انٽيگريٽيڊ سرڪٽس کي ڊزائين ڪرڻ يا ٺاھڻ لاءِ ڪو به لائسنس ظاهر يا واضح طور تي نٿو ڏئي. پراڊڪٽس ڪنهن به FDA ڪلاس III ڊوائيسز ۾ استعمال ٿيڻ جي لاءِ ٺهيل يا مجاز نه آهن، ايپليڪيشنون جن لاءِ FDA پريم مارڪيٽ جي منظوري گهربل آهي يا لائف سپورٽ سسٽم، بغير سلڪون ليبز جي مخصوص لکيل اجازت کان سواءِ. هڪ ”لائف سپورٽ سسٽم“ ڪنهن به پراڊڪٽ يا سسٽم آهي جنهن جو مقصد زندگي ۽/يا صحت کي سهارو ڏيڻ يا برقرار رکڻ آهي، جيڪو، جيڪڏهن اهو ناڪام ٿئي ٿو، مناسب طور تي اميد رکي سگهجي ٿو ته نتيجي ۾ اهم ذاتي زخم يا موت. Silicon Labs پروڊڪٽس فوجي ايپليڪيشنن لاءِ ٺهيل يا مجاز نه آهن. Silicon Labs مصنوعات ڪنهن به حالت ۾ وڏي تباهي جي هٿيارن ۾ استعمال نه ٿينديون آهن (پر ان تائين محدود ناهي) ايٽمي، حياتياتي يا ڪيميائي هٿيار، يا ميزائل جيڪي اهڙي قسم جي هٿيارن کي پهچائڻ جي قابل آهن. Silicon Labs سڀني ظاهري ۽ تقاضا وارنٽي کي رد ڪري ٿي ۽ اهڙي غير مجاز ايپليڪيشنن ۾ سلڪون ليبز جي پراڊڪٽ جي استعمال سان لاڳاپيل ڪنهن به زخم يا نقصان جي ذميوار يا ذميوار نه هوندي. نوٽ: هي مواد شايد جارحاڻي اصطلاحن تي مشتمل هجي جيڪو هاڻي ختم ٿي چڪو آهي. Silicon Labs انهن اصطلاحن کي تبديل ڪري رهي آهي شامل ٻولي سان جتي ممڪن هجي. وڌيڪ معلومات لاءِ، وڃو www.silabs.com/about-us/inclusive-lexicon-project

ٽريڊ مارڪ ڄاڻ
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® and the Silicon Labs logo®, Blueridge®, Blueridge Logo®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro Logo ۽ ان جا مجموعا , “دنيا جا سڀ کان وڌيڪ توانائي دوست مائڪرو ڪنٽرولرز”, 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, the Sentry logo and Zentri DMS, Z-Wave®، ۽ ٻيا آھن ٽريڊ مارڪ يا رجسٽرڊ ٽريڊمارڪس Silicon Labs جا. ARM، CORTEX، Cortex-M3 ۽ THUMB ARM Holdings جا ٽريڊ مارڪ يا رجسٽرڊ ٽريڊمارڪس آھن. ڪيلي ARM Limited جو هڪ رجسٽرڊ ٽريڊ مارڪ آهي. وائي فائي وائي فائي الائنس جو رجسٽرڊ ٽريڊ مارڪ آھي. هتي ذڪر ڪيل ٻيا سڀئي پروڊڪٽس يا برانڊ جا نالا انهن جي لاڳاپيل هولڊ جا ٽريڊ مارڪ آهن

دستاويز / وسيلا

SILICON LABS UG305 متحرڪ ملٽي پروٽوڪول [pdf] استعمال ڪندڙ ھدايت UG305, UG305 Dynamic Multiprotocol, Dynamic Multiprotocol, Multiprotocol

حوالو

• استعمال ڪندڙ دستي