د سیلیکون لابراتوار UG305 متحرک ملټي پروتوکول کارونکي لارښود

پیژندنه

دا سند تشریح کوي چې څنګه د سیلیکون لابراتوار سافټویر ډیزاین شوی ترڅو د ډیری پروتوکولونو لخوا په یو واحد بې سیم چپ کې وکارول شي. متحرک ملټي پروتوکول وخت رادیو ټوټه کوي او په ګړندۍ توګه ترتیبونه بدلوي ترڅو مختلف بې سیم پروتوکولونه وړ کړي ترڅو په ورته وخت کې د اعتبار وړ کار وکړي.

نوټ: په دې سند کې د Zigbee مشخص معلومات په 6.10.x او ښکته نسخه کې پلي کیږي.
د ځانګړي متحرک ملټي پروتوکول پلي کولو توضیحات په لاندې غوښتنلیک یادداشتونو کې چمتو شوي:
AN1133: د بلوتوټ او Zigbee EmberZNet SDK 6.x او ښکته سره متحرک ملټي پروتوکول پراختیا
AN1134: په GSDK v2.x کې په RAIL کې د بلوتوټ او ملکیت پروتوکولونو سره متحرک ملټي پروتوکول پراختیا
AN1269: په GSDK v3.x او لوړو کې په RAIL کې د بلوتوټ® او ملکیت پروتوکولونو سره متحرک ملټي پروتوکول پراختیا
AN1209: د بلوتوټ او نښلولو سره متحرک ملټي پروتوکول پراختیا
AN1265: په GSDK v3.x کې د بلوتوټ® او OpenThread سره متحرک ملټي پروتوکول پراختیا

اصطلاحات

لاندې د متحرک ملټي پروتوکول پلي کولو لپاره ځانګړي اصطلاحات لیست کوي

د راډیو خلاصون انٹرفیس پرت (RAIL): عام API چې له لارې یې د لوړې کچې کوډ د EFR32 راډیو ته لاسرسی ترلاسه کوي.

د راډیو عملیات: یو ځانګړی عمل چې ټاکل شوی وي. د راډیو عملیات دواړه د راډیو ترتیب او لومړیتوب لري. هر سټیک کولی شي غوښتنه وکړي چې د راډیو شیډولر تر دوه راډیو عملیات ترسره کړي (د شالید ترلاسه کول او یا هم مهالویش ترلاسه کول یا مهالویش شوي

• پس منظر ترلاسه کول: پرله پسې ترلاسه کول، چې موخه یې د مهالویش عملیاتونو کې خنډ دی، او د بشپړیدو وروسته بیرته راستنیدل.
• مهالویش ترلاسه کول: پاکټونه ترلاسه کړئ یا په ټاکل شوي وخت او موده کې RSSI محاسبه کړئ. (پرمختلونکي په RAIL کې کار کوي، په یاد ولرئ چې د RAIL API په شرایطو کې، "شیډول شوي ترلاسه کول" لکه څنګه چې په دې سند کې کارول شوي د RAIL_StartRx پرته، د ترلاسه کولو عملیاتو ته اشاره کوي، او یوازې د RAIL_ScheduleRx په ساحه کې محدود ندي.)
• مهالویش شوی ټرانسمیt: د لیږد مختلف عملیاتو څخه هر یو د فوري لیږد ، مهالویش (راتلونکي) لیږد ، یا CCA انحصاري لیږد په شمول. (پرمختلونکي چې په RAIL کې کار کوي، په یاد ولرئ چې د RAIL API په شرایطو کې، "شیډول شوي لیږد" لکه څنګه چې په دې سند کې کارول کیږي، د لیږد هر ډول عملیاتو ته اشاره کوي، او د RAIL_StartScheduledTx په ساحه کې محدود ندي.

Radio config: د هارډویر حالت ټاکي چې باید د راډیو عملیاتو ترسره کولو لپاره وکارول شي.

د راډیو مهالویش: د RAIL برخه چې د مختلفو پروتوکولونو ترمنځ منځګړیتوب کوي ترڅو معلومه کړي چې کوم به راډیو ته لاسرسی ولري.

لومړیتوب: د هر سټیک څخه هر عملیات یو ډیفالټ لومړیتوب لري. یو غوښتنلیک کولی شي ډیفالټ لومړیتوبونه بدل کړي.

د سلیپ وخت: په راتلونکي کې اعظمي وخت کله چې عملیات پیل شي که چیرې دا په غوښتل شوي پیل وخت کې پیل نشي.

حاصل: یو سټیک باید په داوطلبانه ډول د عملیاتو یا د عملیاتو ترتیب په پای کې ترلاسه کړي ، پرته لدې چې دا د شالید ترلاسه کولو ترسره کوي. تر هغه چې د سټیک حاصلات نه وي، مهالویش کونکی به د ټیټ لومړیتوب دندې مهالویش نه کوي

RTOS (ریښتیني وخت عملیاتي سیسټم) کرنل: د عملیاتي سیسټم برخه چې د دندې مدیریت، او د اړیکو د اړیکو او همغږي کولو مسولیت لري. دا تطبیق د مایکریوم OS-5 کرنل کاروي.

معمارۍ

ډینامیک ملټي پروتوکول د EFR32 هارډویر او د ریل سافټویر د ودانۍ بلاکونو په توګه کاروي. Zigbee، بلوتوث، او/یا کوم بل معیارونو پر بنسټ یا د ملکیت پروتوکولونه بیا د مختلف پروتوکولونو تر مینځ د کوډ اجرا کولو اداره کولو لپاره د مایکریوم په کارولو سره د غیر ملي پرتونو په سر کې رامینځته کیدی شي. لاندې انځور د سافټویر ماډلونو عمومي جوړښت څرګندوي.

 

د 2.0 نسخه سره پیل، RAIL اړتیا لري چې د RAIL API کالونو ته د راډیو کنفیګریشن هینډل انتقال کړي. دا ترتیب د PHY مختلف پیرامیټونه تشریح کوي چې د سټیک لخوا کارول کیږي

مایکریم OS یو RTOS دی چې سټیکس او غوښتنلیک منطق ته اجازه ورکوي د CPU اجرا کولو وخت شریک کړي.

د راډیو شیډولر د سافټویر کتابتون دی چې په هوښیارۍ سره د سټیکس لخوا غوښتنو ته ځواب ورکوي ترڅو د اعتبار اعظمي کولو او ځنډ کمولو لپاره د راډیو عملیات ترسره کړي. APIs د RAIL لخوا چمتو شوي چې د راډیو مهالویش له لارې راډیو سره ښکیل نه دي.

د ریل کور د EFR32 هارډویر د راډیو شیډولر لارښوونو په ځواب کې تنظیموي.

د واحد فرم ویئر انځور

متحرک ملټي پروتوکول د سافټویر پراختیا کونکي ته اجازه ورکوي چې یو واحد واحد بائنری تولید کړي چې په EFR32 کې بار شوی وي. د سافټویر تازه معلومات د ټول بائنری په لوړولو سره ترسره کیږي. دا د جیک اوټلوډر په کارولو سره سرته رسیدلی ، چې توضیحات یې په UG266 کې موندل کیدی شي: د GSDK 3.2 او ښکته او UG489 لپاره د سیلیکون لابراتوار ګیکو بوټلوډر کارونکي لارښود: د GSDK 4.0 او لوړ لپاره د سیلیکون لیبس جیکو بوټلوډر کارونکي لارښود.

خپلواک سټک عملیات

د سیلیکون لابراتوار سټیکونه لاهم په متحرک ملټي پروتوکول حالت کې له یو بل څخه په خپلواک ډول کار کوي. د راډیو ځینې اوږدمهاله عملیات به د بل پروتوکول په ځنډ او موافق عملیاتو اغیزه ولري. دا په غوښتنلیک پورې اړه لري چې د دې پیښو لپاره کوم ځانګړي نظرونه وټاکي. د نورو معلوماتو لپاره د راډیو مهالویش 2 برخه وګورئ.

د راډیو مهالویش

د راډیو شیډولر د RAIL (د راډیو خلاصون انٹرفیس پرت) برخه ده. RAIL یو هوښیار، په اسانۍ سره د دودیز وړ راډیو انٹرفیس پرت او API چمتو کوي، کوم چې د ملکیت یا معیارونو پر بنسټ د بې سیم پروتوکولونو ملاتړ کوي. د راډیو شیډولر د دې لپاره ډیزاین شوی چې د راډیو عملیاتو لپاره اجازه ورکړي چې مهالویش او لومړیتوب ورکول کیدی شي. په هر پروتوکول کې د راډیو مختلف عملیات ممکن د وضعیت په پام کې نیولو سره ډیر یا لږ مهم وي یا ډیر یا لږ وخت حساس وي. مهالویش کونکی کولی شي دا په پام کې ونیسي کله چې د شخړو په اړه پریکړې وکړي او څنګه یې قضاوت وکړي

پرته لدې چې تاسو په RAIL کې د دودیز پروتوکول سره غوښتنلیکونه رامینځته کوئ ، د راډیو شیډولر ډیری دندې د لاندې سټیک او ریل کوډ لخوا په اوتومات ډول اداره کیږي. تاسو یوازې د دې عادي API له لارې سټیک کارولو ته اړتیا لرئ.

په لوړه کچه، سټیک د راډیو عملیات لیږي (د مثال لپارهampد مهالویش ترلاسه کول یا د لیږد مهال ویش). د راډیو عملیات دي
قطار شوي او بیا په راتلونکي وخت کې د دوی د پیرامیټونو پراساس خدمت کیږي. کله چې دا د راډیو عملیات پیل کولو وخت وي مهالویش دا معاینه کوي چې ایا سیالي کونکي پیښه شتون لري یا نه او ایا عملیات ځنډول کیدی شي یا نه. که مهالویش ونشي کولی پیښه پرمخ بوځي نو دا پایله لوړې پرت ته راګرځي ، کوم چې ممکن د نوي پیرامیټونو سره بیا هڅه وکړي.

یوځل چې د راډیو عملیات پیل شي ، اړونده سټیک کولی شي د تیرو عملیاتو پایلو پراساس مهالویش کونکي اضافي عملیات واستوي (د مثال لپارهampد ACK په تمه). د هر عملیات یا د عملیاتو ترتیب په پای کې سټیک باید د راډیو کارول ترلاسه کړي.

د راډیو عملیات

په مهالویش کې هره پیښه د راډیو عملیاتو په نوم عناصرو ویشل شوې ، کوم چې د راډیو ترتیب او لومړیتوب سره تړاو لري.

هر عملیات یو لومړیتوب لري او مداخله کیږي که چیرې مهالویش د لوړ لومړیتوب عملیات ترلاسه کړي چې په وخت سره تیریږي. د ټیټ لومړیتوب راډیو عملیات چې د دوی د مهالویش پیرامیټونو پراساس نشي پرمخ وړل کیدی ناکام شي ، او دا د اړوند سټیک پورې اړه لري چې دوی بیا هڅه وکړي. یوځل چې مهالویش کونکی په فعاله توګه د سټیک څخه راډیو عملیات پرمخ وړي ، سټیک کولی شي اضافي راډیو عملیاتو لیږلو ته دوام ورکړي تر هغه چې دا په خپله خوښه لاسته راوړي ، یا تر هغه چې مهالویش د لوړ لومړیتوب راډیو عملیات ترلاسه کړي او مخکې یې پریمپټ کړي.

• پس منظر ترلاسه کول
• مهالویش ترلاسه کول
• د لیږد مهال ویش

هر سټیک کولی شي د راډیو مهالویش کونکي څخه وغواړي چې په یو وخت کې تر دوه پورې راډیو عملیات ترسره کړي (د شالید ترلاسه کول او یا د مهالویش ترلاسه کول یا مهالویش شوي لیږد):

هر عملیات لاندې پیرامیټونه لري:

د پیل وخت	یوه نښه په راتلونکي کې په کوم وخت کې د دې راډیو عملیات به پرمخ ځي. دا کیدی شي "اوس چلول" یا په راتلونکي کې په مایکرو ثانیو کې یو څه ارزښت وي.
لومړیتوب	هغه شمیره چې د عملیاتو نسبي لومړیتوب په ګوته کوي. کله چې ډیفالټ ترتیبات وکاروئ ، د بلوتوټ LE راډیو عملیات نږدې تل د زیګبي عملیاتو په پرتله لوړ لومړیتوب لري.
د سلیپ وخت	د وخت اندازه چې پیښه د خپل پیل وخت څخه وروسته ځنډول کیدی شي او لاهم د سټیک لپاره د منلو وړ وي. دا کیدای شي 0 وي، په دې حالت کې پیښه نشي ایستل کیدی.
د راکړې ورکړې وخت	د وخت نږدې اندازه چې دا د لیږد بشپړولو لپاره اخلي. د لیږد پیښې معمولا د لیږد ډیر ښه تعریف شوي وخت لري، پداسې حال کې چې پیښې ترلاسه کوي ډیری وختونه نامعلوم وي. دا د دې لپاره کارول کیږي چې د راډیو مهالویش کونکي سره مرسته وکړي معلومه کړي چې ایا پیښه پرمخ وړل کیدی شي.

سټیک دا مختلف پیرامیټونه تعریفوي چې د عملیاتو اجرا کولو لپاره مناسب دي. د مثال لپارهample، د بلوتوث پیوستون پیښې په راتلونکي کې ډیری وختونه ټاکل کیږي او هیڅ اجازه نه لري، پداسې حال کې چې د Zigbee لیږد پیښې ډیری وختونه یو څه ځنډول کیدی شي او وروسته ستوري شي.

د RAIL راډیو د مهالویش له نظره، مهالویش شوي لیږد او مهالویش ترلاسه کول یو شان دي. دا دواړه ساده عملیات دي چې د راډیو کارولو ته اړتیا لري، او پدې توګه په یو وخت کې نشي اجرا کیدی. تفاوت یوازې د RAIL API پرت کې څرګند دی ، چیرې چې یا TX یا RX API ویل کیږي.

پس منظر ترلاسه کول

دا یو دوامداره ترلاسه کولو حالت دی چې موخه یې د نورو عملیاتو لخوا مداخله ده، او د بشپړیدو وروسته بیرته راستنیدل. که د پس منظر ترلاسه کول د نورو عملیاتو په پرتله لوړ لومړیتوب وي، د دې راډیو عملیات به نه ټاکل کیږي او نه به چلیږي. دا د سټیکس یا غوښتنلیک پورې اړه لري چې لومړیتوب بدل کړي یا په خپله خوښه حاصل ترلاسه کړي. 5.1 برخه وګورئ Examples د پس منظر ترلاسه کولو سره، حاصل راډیو او د ریاست لیږد د مثال لپارهampد دې په اړه چې شالید څنګه ترلاسه کوي د مهالویش عملیاتو سره تعامل کوي.

ټاکل شوي ترلاسه کول

دا په راتلونکي وخت کې د یوې ټاکلې مودې سره ترلاسه کیږي. د راډیو مهالویش کونکی به د راډیو بدلولو وخت په پام کې ونیسي ترڅو پریکړه وکړي چې ایا عملیات به مهالویش وي یا نه. که دا مهالویش نشي ټاکل کیدی نو مهالویش کونکی د زنګ وهلو سټیک ته ناکام پیښه لیږي. د راډیو عملیات په اوتومات ډول غزول کیږي تر هغه چې سټیک په داوطلبانه ډول حاصل نه کړي، یا مهالویش کوونکی د لوړ لومړیتوب عملیات ترلاسه کوي او مداخله کوي. د ترلاسه کولو غزول سټیک ته اجازه ورکوي چې د لوړې کچې پروتوکول اړتیاو پراساس د راډیو عملیاتو ته دوام ورکړي ، د مثال لپارهampد ترلاسه شوي معلوماتو پراساس د ځواب لیږد.

د لیږد مهال ویش

دا په راتلونکي وخت کې د لږترلږه مودې سره لیږد دی. پدې لږترلږه موده کې د مثال لپاره تمه شوي تعقیبي پیښې شاملې کیدی شيampد IEEE 802.15.4 لیږد لپاره ACK. په هرصورت، د دې عملیاتو لپاره لږترلږه وخت باید غیر متوقع پیښې شاملې نه وي چې ممکن وخت د لږترلږه مودې څخه هاخوا وغزوي، د مثال لپاره.ampپه IEEE 802.15.4 کې د CCA ناکامیو له امله نشتوالی. د راډیو مهالویش کونکی د راډیو بدلولو وخت په پام کې نیسي ترڅو پریکړه وکړي چې ایا عملیات به مهالویش شي یا نه. که دا مهالویش نشي ټاکل کیدی نو مهالویش کونکی د زنګ وهلو سټیک ته ناکام پیښه لیږي.

د راډیو ترتیب

د هرې راډیو عملیات د مخکینۍ تعریف شوي راډیو ترتیب سره تړاو لري چې د هارډویر حالت ټاکي چې باید د عملیاتو ترسره کولو لپاره وکارول شي. د راډیو تشکیلات د سټیک اوسنی حالت تعقیبوي ترڅو راتلونکي راډیو عملیات د ورته راډیو پیرامیټرو څخه کار واخلي. د راډیو تشکیلات ممکن فعال یا غیر فعال وي. که چیرې سټیک د فعال راډیو کنفیګ بدل کړي نو بیا RAIL د هارډویر ترتیب کې هم سمدستي بدلون رامینځته کوي ، د مثال لپارهampیو چینل بدل کړئ. که چیرې د راډیو ترتیب اوس مهال فعال نه وي نو راتلونکی مهال ویش شوي راډیو عملیات به د نوي راډیو تشکیل کاروي.

لومړیتوب

د راډیو هر عملیات یو لومړیتوب لري کوم چې مهالویش کونکي ته په ګوته کوي چې کوم عملیات باید اجرا شي که چیرې د ډیری عملیاتو ترمینځ د وخت تکرار شتون ولري. مهالویش کوونکی د 0 لومړیتوب سره د لوړ لومړیتوب په توګه او 255 ته د ټیټ لومړیتوب په توګه چلند کوي. د راډیو شیډولر به د فزیکي ra rdware ته د لاسرسي لپاره ترټولو لوړ لومړیتوب سره دندې ته اجازه ورکړي. د ډیری دندو سره کنټرول یوازې د بشپړیدو وروسته د راډیو شیډولر ته راستون کیږي ، مګر د شالید ترلاسه کولو په څیر دندې به په هغه صورت کې مداخله وکړي چې د لوړ لومړیتوب سره کار فعال شي.

سټیکونه هر یو د سیلیکون لابراتوار تحلیل پراساس د لومړیتوبونو ډیفالټ سیټ لري چې څنګه د دندې دورې اعظمي کولو لپاره د همکارۍ کولو غوره لاره ده او د عام کارونې قضیې لپاره له مینځه تللو اړیکو څخه مخنیوی وکړئ. د کارونې ځانګړي قضیې ممکن مختلف اړتیاوې ولري. لومړیتوبونه په لاندې ډول دي، له لوړ څخه تر ټیټ پورې

1.  د بلوتوټ LE مهالویش لیږد
2.  بلوتوټ LE مهالویش ترلاسه کول
3.  نور پروتوکول مهالویش شوی لیږد
4.  نور پروتوکول پس منظر ترلاسه کول

دا لومړیتوبونه کیدای شي د غوښتنلیک لخوا تکرار یا بدل شي. دا په غوښتنلیک پورې اړه لري چې پریکړه وکړي چې په کومو شرایطو کې دوی بدل کړي. برخه 4.2 802.15.4 د ریل لومړیتوب او برخه 6.1 بلوتوټ لومړیتوبونه د دوی ځانګړي مثالونو لپاره د لومړیتوبونو په اړه نور توضیحات لري.

د سلیپ وخت

د هرې راډیو عملیات باید "سلپ وخت" ولري، یا د پیل اعظمي وخت، پدې معنی چې په راتلونکي کې ترټولو لرې وخت دی کله چې عملیات پیل شي که چیرې دا د غوښتل شوي پیل وخت کې پیل نشي. دا مهالویش کونکي ته اجازه ورکوي چې د لوړ لومړیتوب پیښو په شاوخوا کې کار وکړي چې په ورته وخت کې پیښیږي ، یا د لوړ لومړیتوب پیښې چې د دوی تمه شوي مودې څخه تیریږي. پروتوکول عموما حکم کوي چې د سلیپ وخت څه کیدی شي، مګر د راډیو شیډولر د دې وړتیا لري چې دا د هر عملیات په اساس اداره کړي، یو سټیک ته اجازه ورکوي چې ځینې پیښې سلیپ کړي مګر نور نه. په عموم کې، IEEE02.15.4 اوږد سلیپ وخت لري او بلوتوټ LE لږ تر لږه سلیپ وخت لري.

حاصل

یوځل چې د راډیو عملیاتو لړۍ په فعاله توګه پرمخ وړل کیږي ، سټیک ممکن د لومړني عملیاتو غزولو عملیاتو اضافه کولو ته دوام ورکړي تر هغه چې سټیک د ځانګړي پیغام تبادلې لپاره نور څه ونه کړي. یو سټیک باید په خپله خوښه حاصل ورکړي پرته لدې چې دا د شالید ترلاسه کول ترسره کړي. که چیرې یو سټیک حاصل ونه کړي نو دا به خپل راډیو عملیاتو ته دوام ورکړي ، او د ټیټ لومړیتوب راډیو عملیات به بیا اړوند سټیک ته ناکامي رامینځته کړي چې د دې راډیو عملیاتو غوښتنه یې کړې. د لوړ لومړیتوب عملیات نشي کولی د اوسني روان، ټیټ لومړیتوب راډیو عملیات مداخله وکړي چې پایله یې نه وي. 5.1 برخه وګورئ Examples د پس منظر ترلاسه کولو سره، حاصل راډیو او د ریاست لیږد د مثال لپارهampپه داسې شرایطو کې چې په ښکاره ډول د راډیو تولید اړین دی.

د راډیو په عملیاتو کې مداخله

د ټاکل شوي راډیو عملیات ممکن مداخله وکړي که چیرې د لوړ لومړیتوب عملیات ورسره ټکر وکړي. دا په لاندې دوو حالتونو کې واقع کیدی شي:

1. د ټاکل شوي راډیو عملیات د تمې څخه ډیر وخت نیسي او اړونده سټیک د لوړ لومړیتوب راډیو عملیات باید پیل نشي.
2. د لوړ لومړیتوب راډیو عملیات اوس مهال ټاکل شوي چې په راتلونکي کې پیښ شي او له مخکې ټاکل شوي ټیټ لومړیتوب عملیاتو سره په ټکر کې دي

د اوږدې مودې راډیو عملیات

د راډیو ځینې اوږدمهاله عملیات کولی شي د محصول په سم عملیاتو باندې پراخه اغیزه ولري. غوښتنلیک ممکن د پروتوکولونو ترمینځ دا عملیات همغږي کولو ته اړتیا ولري. که غوښتنلیک نه وي نو د راډیو مهالویش لومړیتوبونه به لومړیتوب ولري. د مثال لپارهample، د IEEE 802.15.4 انرژي سکین کولی شي اړتیا ولري چې راډیو د کافي انرژي لوستلو راټولولو لپاره پاتې شي. که چیرې غوښتنلیک په سمه توګه عملیات همغږي نه کړي، سکین کیدای شي د لوړ لومړیتوب بلوتوټ عملیات له امله د وخت څخه مخکې خنډ شي.

د راډیو مهالویش جوړونکیamples

ټول پخوانيamples بلوتوټ LE او Zigbee کاروي، مګر اصول په نورو بلوتوټ/802.15.4 ترکیبونو کې پلي کیږي.

مهالویش د ټیټ لومړیتوب Zigbee پس منظر ترلاسه کولو عملیاتو سره پیل کیږي. دا د تل په څیر روټر استازیتوب کوي چې ممکن په نامعلوم وختونو کې د IEEE 802.15.4 پاکټونو ترلاسه کولو ته اړتیا ولري. د بلوتوټ LE اتصال هم فعال دی او سټیک ته اړتیا لري چې هر 30 ms ترلاسه کولو لپاره چمتو وي. د بلوتوټ LE سټیک ممکن د پیوستون د بیاکتنې وړ طبیعت له امله دا دمخه ښه مهالویش کړي.

د لومړیتوب مهال ویش

دا یو بنسټیز پخوانی وړاندې کويampد بیلابیلو راډیو عملیاتو لومړیتوبونو پریکړه کول.

د زیګبی سټیک پریکړه کوي چې دا اړتیا لري چې یو کڅوړه واستوي. دا کیدی شي دا د غوښتنې پراساس پیښې په توګه ترسره کړي ، پدې معنی چې سټیک پریکړه کوي چې دا غواړي اوس مهال پاکټ واستوي پرته لدې چې مهالویش ته دمخه ښه خبر ورکړي. دا د بلوتوټ LE څنګه کار کوي برعکس دی ، چیرې چې ټاکل شوي عملیات په معقول ډول دمخه پیژندل شوي. مهالویش ارزوي چې دا ممکنه ده چې د Zigbee TX 1 راډیو عملیات ترسره کړئ او لاهم په راتلونکي کې د لوړ لومړیتوب بلوتوټ LE استقبال پیښې ته خدمت وکړئ. نو مهالویش کوونکی اجازه ورکوي چې د لیږد پیښې پیښ شي. د Zigbee سټیک د دې لیږد عملیات ټولې برخې ترسره کوي (د MAC ack لپاره انتظار کول)، او بیا په خپله خوښه حاصل ورکوي. د Zigbee د لیږد رادیو عملیاتو اټکل شوي لیږد وخت بیا تکرارونه شامل نه دي.

په دې کې پخوانيample، بلوتوث LE لا دمخه په راتلونکي کې د ترلاسه کولو لپاره ټاکل شوی او د Zigbee سټیک غواړي لیږدول شي. د لومړي Zigbee TX 1 راډیو عملیاتو لپاره د بلوتوټ LE RX 1 راډیو عملیاتو دمخه کافي وخت شتون لري نو مهالویش کونکی سټیک ته اجازه ورکوي چې عملیات ترسره کړي. وروسته، کله چې د Zigbee سټیک د Zigbee TX 2 مهالویش کولو هڅه کوي مهالویش ټاکي چې د لوړ لومړیتوب بلوتوټ LE RX 2 پیښې دمخه کافي وخت شتون نلري. په هرصورت، Zigbee سټیک اشاره کړې چې دا عمل ممکن د پیل وخت تیر کړي. د راډیو مهالویش ټاکي چې د بلوتوټ LE راډیو عملیاتو تمه شوي مودې ته په پام سره د زیګبي عملیات کولی شي له دې پیښې وروسته پیل شي او لاهم د زیګبي سټیک لخوا په ګوته شوي سلیپ وخت کې وي.

که هرڅه د تمې سره سم پرمخ ځي، د Zigbee لیږد عملیات به د مهال ویش له امله د کومې ناکامۍ پرته خپله لومړۍ هڅه وکړي.

د لومړیتوب مداخله Example

دا پخوانیample د لوړ لومړیتوب عملیات په ګوته کوي چې د ټیټ لومړیتوب سره مداخله کوي.

 

 

 

دا پخوانیample د تیر پخواني په څیر پیل کیږيample. Zigbee او بلوتوت LE دواړه د راډیو عملیات لري چې پرته له کوم ټکر څخه ټاکل شوي

وروسته، د Zigbee سټیک پریکړه وکړه چې دا غواړي د Zigbee TX 2 پیښې لپاره بل پیکټ واستوي. مهالویش ټاکي چې دا باید ممکنه وي چې دا پیښه مهالویش کړئ او وروسته د بلوتوټ LE RX 2 پیښې خدمت وکړئ ، د هغه لږترلږه وخت پراساس چې د Zigbee TX 2 پیښه باید واخلي. په هرصورت، د Zigbee TX 2 پیښه د اوږدې تصادفي بیک آف له امله د تمې څخه ډیر وخت نیسي او په وخت کې حاصل نه کوي. دا د دې لامل کیږي چې پیښه د لوړ لومړیتوب ریډ پیریشن سره ټکر شي ، او له همدې امله د راډیو شیډولر د زیګبي پیښه مداخله کوي او د لوړې کچې سټیک ته ناکامي بیرته راګرځوي. د بلوتوټ LE پیښه په نورمال ډول پیښیږي او کله چې دا بشپړ شي دا په داوطلبانه ډول د ټیټ لومړیتوب عملیاتو ته لاسته راوړي.

د راډیو شیډولر څخه د ناکامۍ ترلاسه کولو سره د زیګبي سټیک سمدلاسه هڅه کوي د MAC پیغام بیا هڅه وکړي. دا عملیات مهالویش کوي او د سلیپ وخت پکې شامل دي. پدې وخت کې د بلوتوټ LE سټیک په راډیو کې لومړیتوب لري او پدې توګه عملیات لاهم نشي پیل کیدی ، مګر مهالویش کونکی د نوي راډیو عملیات مني. د بلوتوټ LE سټیک خپل ټاکل شوی ترلاسه کول بشپړوي او راډیو تولیدوي. مهالویش بیا د زیګبي لیږد عملیات رامینځته کوي ځکه چې دا لاهم د لومړني پیل عملیاتو په سلیپ وخت کې دی. وروسته له دې چې لیږد بشپړ شي شیډولر شالید ته راستنیږي عملیات ترلاسه کوي.

د لوړ لومړیتوب عملیات چې تمدید شوي

دا پخوانیample ښیي چې څه پیښیږي کله چې د لوړ لومړیتوب عملیات د اصلي اټکل څخه ډیر وخت نیسي او د ټیټ لومړیتوب عملیات د فرصت له لاسه ورکولو لامل کیږي

په دې حالت کې، بلوتوث LE یو مهال ویش لري چې اوس مهال ترسره کیږي. زیګبي پریکړه کوي چې یو کڅوړه واستوي مګر دا اوس نشي چلیدلی. مهالویش کوونکی د دې انګیرنې لاندې عملیات مني چې د بلوتوټ LE پیښه به د زیګبي پیښې د سلیپ وخت پای ته رسیدو دمخه بشپړه شي. په هرصورت، د بلوتوټ LE پیښه د دې حقیقت له امله اوږدیږي چې اضافي پاکټونه د وسیلو ترمنځ لیږل کیږي. د بلوتوټ LE عملیات لومړیتوب لري نو د زیګبي عملیات په پای کې له سلیپ څخه تیریږي. یوه تېروتنه بیرته ستنې ته راستانه شوې. زیګبي پریکړه کوي چې کڅوړه بیا لیږدوي. یوځل بیا ، د زیګبي سټیک په ګوته کوي چې عملیات باید اوس پیل شي مګر ممکن راتلونکي ته وګرځي. مهالویش د راډیو ترتیب بدلولو په مینځ کې دی نو دا نشي کولی سمدستي عملیات پیل کړي. پرځای یې، دا د راډیو عملیات پیل کولو وخت لږ څه کموي او بیا عملیات اجرا کوي.

پرته له مداخلې د لوړ لومړیتوب عملیات 

په دې کې پخوانيampد راډیو شیډولر په یو نوډ کې روان دی چې د بلوتوټ LE پیریفیرال په توګه عمل کوي او دا نوډ د مختلف مرکزي وسیلو سره یو شمیر اړیکې لري. دا یو دوره ای اعلاناتو بیکن هم لري چې لیږدول کیږي. لاندې شمیره یوه قضیه ښیې چیرې چې دا پیښې په حقیقت کې یو له بل سره پیښیږي او د زیګبي راډیو ترتیب ته د بیرته راستنیدو لپاره کافي وخت ته اجازه نه ورکوي. له همدې امله دا به یوه دوره رامینځته کړي چیرې چې د زیګبي سټیک وي
حتی د سلیپ وخت سره د لیږد توان نلري.

Zigbee له مهالویش څخه غوښتنه کوي چې د لیږد راډیو عملیات مهالویش کړي. که څه هم مهالویش کوونکی پوهیږي چې پیښه به د ټاکل شوي لوړ لومړیتوب عملیاتو له امله ناکامه شي ، دا لاهم ټاکل شوې پیښه مني. دا د دوو دلیلونو لپاره ترسره کیږي. لومړی، شرایط کیدای شي بدلون ومومي او پیښه اجرا شي. دوهم، د راډیو شیډولر په سر کې ناست سټیک ممکن د عمل بیا هڅه کولو هڅه وکړي. که چیرې د ناکام مهالویش پایله سمدلاسه بیرته راستانه شي نو بیا د سټیک هڅه به بریالۍ نه وي ځکه چې هیڅ وخت نه دی تیر شوی. پرځای یې، د پیښې په قطار کې کولو او د سلیپ وخت پای ته رسیدو وروسته د ناکامۍ بیرته راګرځولو سره، بیا هڅه (د خپل سلیپ وخت سره) د بریالیتوب ښه چانس لري ځکه چې د راتلونکو راډیو عملیاتو سیټ به توپیر ولري.

ترلاسه کړئ کله چې د لوړ لومړیتوب عملیات روان وي 

دا پخوانیample روښانه کوي چې څه پیښیږي کله چې بلوتوټ LE فعال وي او د ټیټ لومړیتوب عملیات به ډاټا ترلاسه کړي.

په لومړي حالت کې، کله چې د IEEE 802.15.4 پیغام لیږل کیږي او د بلوتوت LE سټیک د فعال ترلاسه کولو لپاره راډیو کاروي د Zigbee سټیک به د پیغام ترلاسه کولو لپاره آنلاین نه وي. په هرصورت، د پیغام Zigbee لیږونکی به په ډیری قضیو کې بیا هڅه وکړي او د بیک آف او نورو وختونو بدلونونو سره به د بل لوړ لومړیتوب ټاکل شوي بلوتوټ ترلاسه شوي پیښو سره د ټکر احتمال نلري. د Zigbee پیغام په بریالیتوب سره ترلاسه شو

دویمه قضیه ښیي چې، د فعال ترلاسه کولو په صورت کې، د Zigbee سټیک ممکن لاهم مداخله وکړي او پیغام (یا ACK) ترلاسه نکړي. بریالۍ اړیکه د MAC یا لوړې پرت کې بیا هڅه کولو تکیه کوي ترڅو دا پیغام بیا واستوي او د ډینامیک ملټي پروتوکول وسیله تصدیق کړي چې پیغام ترلاسه کوي.

پداسې حال کې چې ممکن د دې په اړه نظرونه شتون ولري چې ایا فعال ترلاسه کول باید مداخله وکړي، دا د مهال ویش لپاره ستونزمنه ده چې دا پریکړه وکړي. په عموم کې د پروتوکولونو پیاوړتیا باید د پیغامونو لپاره اجازه ورکړي چې په بریالیتوب سره حتی د مداخلې سره هم ترلاسه شي

د 802.15.4 پر بنسټ سټیک سره ملټي پروتوکول پلي کول

دا څپرکی د 802.15.4-based سټیک پلي کولو په اړه عمومي معلومات وړاندې کوي لکه Zigbee یا Connect د ملټي پروتوکول غوښتنلیکونو برخې په توګه. د تنظیم کولو څرنګوالي په اړه توضیحاتو لپاره plugins او نور توضیحات چې د آرټیکولر پروتوکول لپاره ځانګړي دي، د لاندې غوښتنلیک نوټونو څخه یو وګورئ:

• AN1133: د بلوتوټ او Zigbee EmberZNet SDK 6.x او ښکته سره متحرک ملټي پروتوکول پراختیا
•  AN1209: د بلوتوټ او نښلولو سره متحرک ملټي پروتوکول پراختیا

د بې سیم پروتوکول ملاتړ

مختلف بېسیم پروتوکولونه مختلف ځانګړتیاوې لري چې د ډینامیک ملټي پروتوکول ډیزاین سره کارول شوي. د مثال لپارهample، د بلوتوټ ټیټ انرژي د راډیو عملیاتو په مهالویش کې خورا سخت او د وړاندوینې وړ دی؛ اعلانات او د پیوستون وقفې په ټاکل شوي وخت کې واقع کیږي. په مقابل کې، د 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	د لوړ لومړیتوب شتون سره دنده

که چیرې یو فعال TX اجرا شي راډیو به په هغه وخت کې خپره شي چې د ورته MAC اعتراف ترلاسه شوی وي (یا وخت پای ته رسیدلی وي).

شالید RX به راډیو په ترلاسه کولو حالت کې پریږدي چې د غیر متناسب پیغامونو ترلاسه کولو لپاره چمتو وي. که چیرې د RX فعال لومړیتوب د شالید RX لومړیتوب څخه توپیر ولري، د ترلاسه کولو لومړیتوب به لوړ شي کله چې یو همغږي کلمه وموندل شي او یوازې هغه وخت ټیټ شي کله چې دا پاکټ فلټر یا بشپړ شي او د هغې ACK لیږل کیږي که چیرې غوښتنه شوې وي.

د لومړیتوبونو توازن

لکه څنګه چې د بلوتوټ لومړیتوبونو 6.1 برخه کې تشریح شوي، په ډیفالټ ډول د بلوتوټ لومړیتوب سلسله د RAIL لومړیتوب رینج 16 - 32 کې نقشه شوې. په عموم کې، بلوتوټ د ټیټ لومړیتوب (32) په کارولو سره پیل کیږي او په متحرک ډول لومړیتوب تر اعظمي حد (16) ته زیاتوي. اړینه ده که پیغامونه بریالي نه وي.

لکه څنګه چې په تیره برخه کې تشریح شوي، د 802.15.4 پر بنسټ سټیک لکه Zigbee یا Connect د 255 د شالید RX لپاره، 255 د فعال RX لپاره، او 100 د فعال TX لپاره د ډیفالټ RAIL لومړیتوب ارزښتونه کاروي.

د دې ډیفالټ ریل لومړیتوبونو په پایله کې ، په 802.15.4 پروتوکول - بلوتوث ملټي پروتوکول غوښتنلیک کې ، د ډیفالټ بلوټوت ترافیک به تل د 802.15.4 پروتوکول ترافیک ته لومړیتوب ورکړي. دا د ډیری غوښتنلیکونو لپاره غوره انتخاب دی، ځکه چې د بلوتوټ ټرافيک د وخت سختې اړتیاوې لري، د 802.15.4 پروتوکولونو برعکس. په هرصورت، که د بلوتوټ ټرافیک بار خورا لوړ وي (د مثال لپارهample، د خورا کوچني ارتباط وقفې په کارولو سره ډیری ډیټا لیږل) ، دا د 802.15.4 پروتوکول ترافیک لپاره ممکنه ده چې راډیو ته د لاسرسي څخه په بشپړ ډول بلاک شي ځکه چې د دې ټیټ لومړیتوب او د موجود راډیو وخت خورا کوچنۍ کړکۍ د بلوتوټ لخوا پاتې کیږي. ترافیک

نوټ: لاندې معلومات اوس مهال یوازې د EmberZNet Zigbee سټیک لپاره د تطبیق وړ دي. د سیلیکون لابراتوار نښلول لاهم د لومړیتوبونو بدلولو لپاره اړین 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 پروتوکول لاسرسي اجازه ورکړل شي، بلوتوټ به ترلاسه کړي. که اړتیا وي په راتلونکو بیاکتنو کې لومړیتوب.

دا طریقه دواړو پروتوکولونو ته اجازه ورکوي چې د دوی د راډیو کارولو په اړه جوړجاړی وکړي پرته لدې چې یو په بل باندې په بشپړ ډول تسلط ولري.

. د ریل سره ملټي پروتوکول پلي کول 

دا څپرکی د هغو کاروونکو لپاره چې د RAIL API په مستقیم ډول د ملکیت پروتوکولونو رامینځته کولو لپاره مصرفوي د RAIL ځانګړتیاو په اړه نور معلومات وړاندې کوي. په ځانګړي توګه دا د ځانګړي راډیو شیډولر قضیې اداره کولو لپاره د RAIL APIs سره د کار کولو څرنګوالي توضیحات وړاندې کوي.

Examples د پس منظر ترلاسه کولو سره، حاصل راډیو او د دولت لیږد

د RAIL ملټي پروتوکول لومړیتوب سیسټم اساسات خورا ساده دي: د راډیو پیښه د لوړ لومړیتوب سره (چې په شمیر کې کوچنۍ ده) به تل د ټیټ لومړیتوب سره نورې کومې راډیو پیښې غصب کړي. په هرصورت، دا موضوع نوره پیچلې کیږي کله چې د دولت لیږدونو او APIs لکه RAIL_StartRx() په پام کې نیولو سره، کوم چې راډیو د نامعلوم وخت لپاره یو ټاکلی حالت ته اړوي. دا برخه ځینې مثالونه وړاندې کويampد دې لپاره چې دا وښیې چې دا وخت بې حده حالتونه څنګه اداره کیږي، او څنګه د غوښتنلیک پرت کولی شي APIs لکه RAIL_YieldRadio() د کنټرول لپاره وکاروي. د پخوانيampپه لاندې ډول دي:

• د یو واحد پروتوکول سره د دولت لیږد
• د دوه پروتوکولونو سره د دولت لیږد
• د دوه پروتوکولونو سره د دولت لیږد او په واحد ډول د لومړیتوبونو زیاتوالی

په دغو پخوانيوamples، RAIL_StartTx() د TX پیښې سرچینه ده چې د شاليد RX مداخله کوي. په هرصورت، یادونه وکړئ چې دا پخوانيamples د RAIL_StartRx() پرته په هرې راډیو API کې د تطبیق وړ دي. په بل عبارت، پخوانیamples په هر هغه API کې د تطبیق وړ دي چې د راډیو پیښه پیل کوي چې شالید RX نه وي

دا پخوانيampد دولت د لیږد په اړه د تمه شوي ملټي پروتوکول چلندونه روښانه کوي. د لنډیز لپاره:

• د یو دولت په لیږد کې، نوی دولت په ورته لومړیتوب کې د اصلي پیښې د غیرمعمولي تمدید په توګه چلند کیږي تر هغه چې 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 () ته د لومړني زنګ سره پیل کیږي ، بیا RAIL_StartTx () ته د لوړ لومړیتوب زنګ سره TX ته ځي. دا مهمه ده چې په یاد ولرئ چې د لیږد ترسره کیدو وروسته ، راډیو د 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 ته اړتیا نه وي، سیلیکون لابراتوار د RAIL_EVENT_TX_PACKET_SENT پیښې اداره کولو برخې په توګه RAIL_YieldRadio() ته زنګ وهلو وړاندیز کوي. دا کار کول د دې لامل کیږي چې په پورتنۍ شکل کې شنه کرښه د مداخلې ځنډ وخت ته راکم شي. که چیرې غوښتنلیک د ACK تمه وکړي، RAIL_YieldRadio() باید غږ شي کله چې ACK ترلاسه شي یا وخت پای ته رسیدلی وي.

د دوه پروتوکولونو سره د دولت لیږد

دا سناریو د TX وروسته د دولت لیږد په اړه لومړۍ سناریو ته ورته ده، مګر بل پروتوکول معرفي کوي.

په دې حالت کې، دا مهمه ده چې په یاد ولرئ چې RAIL_StartRx() د TX لیږد په جریان کې هر وخت ویل کیدی شي. تر هغه وخته چې د دې لومړیتوب د TX له لومړیتوب څخه کم یا مساوي وي، RX به تر هغه وخته پورې پلي نشي تر څو چې غوښتنلیک په پروتوکول A کې _Yield Radio() غږ نه کړي. کله چې RAIL_StartRx() د TX په جریان کې ویل کیږي، RX یوازې دی د پیښو په کتار کې اضافه شوي چې اداره کیږي.

بل کلیدي ټکی دا دی چې که څه هم په پروتوکول A کې RAIL_YieldRadio() به د پروتوکول A له TX څخه په پروتوکول B کې RX ته لیږدوي، په پروتوکول B کې RAIL_Idle() د پروتوکول B څخه RX ته د پروتوکول B څخه RX ته د لیږد لپاره اړین دی. دلته فلسفه دا ده چې د پس منظر RXs واقعیا نشي ترلاسه کیدی، ځکه چې پیښه هیڅکله پای ته نه رسیږي. د وتلو یوازینۍ لار د RAIL_Idle() ته زنګ وهلو سره د شالید RX بندول دي.

 د دوه پروتوکولونو سره د دولت لیږد او په واحد ډول د لومړیتوب زیاتوالی

وروستنۍ سناریو نږدې پخوانۍ سره ورته ده، پرته له دې چې په پروتوکول B کې RAIL_StartRx() ته زنګ په پروتوکول A کې RAIL_StartTx() ته د زنګ په پرتله لوړ لومړیتوب لري.

په دې حالت کې، څرنګه چې د دویم RAIL_StartRx() لومړیتوب د RAIL_StartTx() ته د زنګ له لومړیتوب څخه لوړ دی، RAIL_YieldRadio() ته زنګ وهل نور اړین ندي. ځکه چې دوهم RAIL_StartRx() په لوړ لومړیتوب کې دی، دا د RAIL_StartTx() پیښه غصبوي، د راډیو کنټرول اخلي او د TX پیښه له دولت څخه لیرې کوي. په هر وخت کې د RX په پروتوکول B کې، RAIL_Idle() ته ویل کیدی شي چې په پروتوکول A کې RX ته بیرته راستانه شي، لکه څنګه چې په تیرو پخوانیو کېample.

دلته یادونه وکړئ، کله چې غوښتنلیک د پروتوکول B RX کې RAIL_Idle() ته زنګ ووهي، نو غوښتنلیک د پروتوکول A TX لیږد ته نه راستنیږي. پرځای یې، دا د RX شالید ته ځي، که څه هم غوښتنلیک هیڅکله په پروتوکول کې RAIL_Idle() نه ویل کیږي. A's 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.

د بلوتوټ سره ملټي پروتوکول پلي کول

د توضیحاتو لپاره چې څنګه د RAIL/بلوتوث څراغ/سوئچ ملټي پروتوکول example پلي شوی و، او په RAIL کې ستاسو د خپل پروتوکول سره د ملټي پروتوکول غوښتنلیک رامینځته کولو په اړه د نورو معلوماتو لپاره ، AN1134 وګورئ: په GSDK v2.x یا AN1269 کې د بلوتوټ او ملکیت پروتوکولونو سره ډینامیک ملټي پروتوکول پراختیا په RAIL کې د بلوتوټ او ملکیت پروپرایټری پروپرایل سره متحرک ملټي پروتوکول پراختیا په GSDK v3.x او لوړو کې.

د بلوتوټ لومړیتوبونه

لکه څنګه چې د مختلف عملیاتو ډولونو لپاره د ثابت تعریف شوي لومړیتوبونو سره د Zigbee سره مخالفت ، بلوتوټ د لومړیتوب سپیکٹرم یوې ورکړل شوې ساحې ته د ټولو دندو ګمارلو لپاره یو حد او آفسیټ طریقه کاروي.

په دې کې پخوانيampد بلوتوټ لومړیتوب سلسله، چې پخپله د 0 څخه تر 255 پورې پراخه ده، د شریک ریل لومړیتوب ځای محدودې برخې ته نقشه شوې

د زیګبي برعکس، بلوتوټ د وخت ډیر سخت اړتیاوې لري چیرې چې د ورکړل شوي سلاټ له لاسه ورکول ممکن د پیوستون پای ته ورسیږي. همدارنګه بلوتوت یو لړ مختلف دندې لري لکه (احتمالي څو) ارتباطات، اعلانونه، سکین کول، او د ځوابونو (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) 

د ځوابونو سره د دورې اعلاناتو لیږل د نورو ټولو بلوتوث دندو په پرتله د ډیفالټ لخوا ترټولو لوړ لومړیتوب لري، وروسته له دې چې په بریښنایی شیلف لیبل (ESL) شبکه کې همغږي ساتلو لپاره په PAwR کې ځوابونه ترلاسه کړي.

د PAwR کاري لومړیتوب ډیریږي که چیرې د دندې مهالویش په پرله پسې ډول دوه ځله ناکام شي. لومړیتوب یا د لومړیتوب سلسلې 1/6 لخوا زیات شوی، یا لږ تر لږه د یو لخوا تر هغه چې اعظمي لومړیتوب ته رسیدلی وي. د دندې لومړیتوب د بریالي مهالویش وروسته لږ تر لږه بیرته تنظیم شوی. ورته کړنلاره په دواړو لارښوونو کې د 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) جوړښت د 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 بلوتوث لومړیتوبونو کې لیدل کیدی شي. د ریل_ماپینګ_آفسیټ او ریل_میپینګ_رینج دواړو لپاره ډیفالټ 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

ردول

د سیلیکون لابراتوار اراده لري چې پیرودونکو ته د سیسټم او سافټویر پلي کونکو لپاره د سیلیکون لابراتوار محصولاتو کارولو یا کارولو اراده لرونکي ټولو برخو او ماډلونو وروستي ، دقیق او ژور اسناد چمتو کړي. د ځانګړتیاوو ډاټا، شته ماډلونه او پرفیریلز، د حافظې اندازه او د حافظې پتې هر یو ته راجع کیږي
ځانګړي وسیله، او چمتو شوي "معمولي" پیرامیټونه کولی شي په مختلفو غوښتنلیکونو کې توپیر ولري. د غوښتنلیک مثالampدلته تشریح شوي یوازې د مثالي موخو لپاره دي. د سیلیکون لابراتوار حق لري چې د محصول معلوماتو ، مشخصاتو او توضیحاتو ته له نور خبرتیا پرته بدلونونه رامینځته کړي ، او د شامل شوي معلوماتو دقت یا بشپړتیا په اړه تضمین نه ورکوي. د مخکینۍ خبرتیا پرته، سیلیکون لابراتوار ممکن د تولید پروسې په جریان کې د امنیت یا اعتبار دالیلو لپاره د محصول فرم ویئر تازه کړي. دا ډول بدلونونه به د محصول ځانګړتیاوې یا فعالیت بدل نه کړي. د سیلیکون لابراتوارونه باید پدې سند کې چمتو شوي معلوماتو کارولو پایلو لپاره هیڅ مسؤلیت ونلري. دا سند د کوم مدغم سرکیټونو ډیزاین یا جوړولو لپاره هیڅ جواز نه ورکوي یا په څرګند ډول نه ورکوي. محصولات د FDA ټولګي III وسیلو کې د کارولو لپاره ډیزاین یا مجاز ندي ، هغه غوښتنلیکونه چې د FDA دمخه بازار تصویب ته اړتیا لري یا د سیلیکون لابراتوار ځانګړي لیکلي رضایت پرته د ژوند ملاتړ سیسټمونه. د "ژوند مالتړ سیسټم" هر هغه محصول یا سیسټم دی چې هدف یې د ژوند او/یا روغتیا ملاتړ یا ساتل دي، کوم چې که دا ناکام شي، په معقول ډول تمه کیدی شي د پام وړ شخصي ټپي یا مړینې پایله ولري. د سیلیکون لابراتوار محصولات د نظامي غوښتنلیکونو لپاره ډیزاین یا مجاز ندي. د سیلیکون لابراتوار محصولات باید په هیڅ حالت کې د ډله ایزو ویجاړونکو وسلو په شمول (مګر محدود نه وي) اټومي، بیولوژیکي یا کیمیاوي وسلې، یا توغندي چې د ورته وسلو رسولو وړ وي کارول کیږي. د سیلیکون لابراتوار ټول څرګند او ضمیمه تضمینونه ردوي او په داسې غیر مجاز غوښتنلیکونو کې د سیلیکون لابراتوار محصول کارولو پورې اړوند د کوم ټپ یا زیان لپاره مسؤل یا مسؤل نه وي. یادونه: په دې منځپانګه کې ښايي ناوړه اصطلاحات شامل وي چې اوس له منځه تللي دي. د سیلیکون لابراتوار دا شرایط هرکله چې امکان ولري د جامع ژبې سره ځای په ځای کوي. د نورو معلوماتو لپاره، لیدنه وکړئ 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 او Zentri DMS, Z-Wave®، او نور د سیلیکون لابراتوار سوداګریزې نښې یا راجستر شوي سوداګریزې نښې دي. ARM، CORTEX، Cortex-M3 او THUMB د ARM Holdings سوداګریزې نښې یا راجستر شوي سوداګریزې نښې دي. کیلي د ARM Limited راجستر شوی سوداګریز نښه ده. Wi-Fi د Wi-Fi اتحادیې راجستر شوی سوداګریز نښه ده. نور ټول محصولات یا د برانډ نومونه چې دلته ذکر شوي د دوی اړونده سوداګریزې نښې دي

اسناد / سرچینې

د سیلیکون لابراتوار UG305 متحرک ملټي پروتوکول [pdf] د کارونکي لارښود UG305, UG305 متحرک ملټي پروتوکول, متحرک ملټي پروتوکول, ملټي پروتوکول

حوالې

• د کارن لارښود