સિલિકોન લેબ્સ UG305 ડાયનેમિક મલ્ટિપ્રોટોકોલ વપરાશકર્તા માર્ગદર્શિકા

પરિચય

આ દસ્તાવેજ વર્ણવે છે કે સિલીકોન લેબ્સ સોફ્ટવેરને એક વાયરલેસ ચિપ પર બહુવિધ પ્રોટોકોલ્સ દ્વારા ઉપયોગમાં લેવા માટે કેવી રીતે ડિઝાઇન કરવામાં આવ્યું છે. ડાયનેમિક મલ્ટિપ્રોટોકોલ રેડિયોને સમય-સ્લાઈસ કરે છે અને એક જ સમયે વિવિધ વાયરલેસ પ્રોટોકોલને વિશ્વસનીય રીતે કાર્ય કરવા સક્ષમ કરવા માટે રૂપરેખાંકનોમાં ઝડપથી ફેરફાર કરે છે.

નોંધ: આ દસ્તાવેજમાંની Zigbee-વિશિષ્ટ માહિતી આવૃત્તિ 6.10.x અને તેનાથી નીચેના પર લાગુ થાય છે.
વિશિષ્ટ ગતિશીલ મલ્ટિપ્રોટોકોલ અમલીકરણો પરની વિગતો નીચેની એપ્લિકેશન નોંધોમાં પ્રદાન કરવામાં આવી છે:
AN1133: બ્લૂટૂથ અને Zigbee EmberZNet SDK 6.x અને નીચલા સાથે ડાયનેમિક મલ્ટિપ્રોટોકોલ વિકાસ
AN1134: GSDK v2.x માં RAIL પર બ્લૂટૂથ અને પ્રોપ્રાઇટરી પ્રોટોકોલ સાથે ડાયનેમિક મલ્ટિપ્રોટોકોલ ડેવલપમેન્ટ
AN1269: GSDK v3.x અને ઉચ્ચતરમાં RAIL પર Bluetooth® અને પ્રોપ્રાઇટરી પ્રોટોકોલ સાથે ડાયનેમિક મલ્ટિપ્રોટોકોલ ડેવલપમેન્ટ
AN1209: બ્લૂટૂથ અને કનેક્ટ સાથે ડાયનેમિક મલ્ટિપ્રોટોકોલ ડેવલપમેન્ટ
AN1265: GSDK v3.x માં Bluetooth® અને OpenThread સાથે ડાયનેમિક મલ્ટિપ્રોટોકોલ વિકાસ

પરિભાષા

ડાયનેમિક મલ્ટિપ્રોટોકોલ અમલીકરણ માટે વિશિષ્ટ પરિભાષાઓની કેટલીક સૂચિ નીચે આપેલ છે

રેડિયો એબ્સ્ટ્રેક્શન ઈન્ટરફેસ લેયર (RAIL): સામાન્ય API જેના દ્વારા ઉચ્ચ સ્તરનો કોડ EFR32 રેડિયોની ઍક્સેસ મેળવે છે.

રેડિયો ઓપરેશન: સુનિશ્ચિત કરવાની ચોક્કસ ક્રિયા. રેડિયો ઓપરેશનમાં રેડિયો ગોઠવણી અને પ્રાથમિકતા બંને હોય છે. દરેક સ્ટેક વિનંતી કરી શકે છે કે રેડિયો શેડ્યૂલર બે રેડિયો ઓપરેશન્સ કરે (બેકગ્રાઉન્ડ રિસીવ અને ક્યાં તો શેડ્યુલ્ડ રીસીવ અથવા શેડ્યુલ્ડ

• પૃષ્ઠભૂમિ પ્રાપ્ત: નિરંતર પ્રાપ્ત, સુનિશ્ચિત કામગીરીમાં વિક્ષેપ લાવવાના હેતુથી, અને તેમના પૂર્ણ થયા પછી પાછા ફર્યા.
• અનુસૂચિત પ્રાપ્ત: ચોક્કસ સમય અને અવધિ પર પેકેટો પ્રાપ્ત કરો અથવા RSSI ની ગણતરી કરો. (RAIL પર કામ કરતા ડેવલપર્સ, નોંધ કરો કે RAIL API ના સંદર્ભમાં, આ દસ્તાવેજમાં વપરાયેલ “શિડ્યુલ્ડ રીસીવ” એ RAIL_StartRx સિવાયના કોઈપણ રીસીવ ઓપરેશનનો સંદર્ભ આપે છે, અને તે માત્ર RAIL_ScheduleRx સુધી મર્યાદિત નથી.)
• સુનિશ્ચિત ટ્રાન્સમીt: તાત્કાલિક ટ્રાન્સમિટ, સુનિશ્ચિત (ભવિષ્ય) ટ્રાન્સમિટ અથવા CCA આશ્રિત ટ્રાન્સમિટ સહિત વિવિધ ટ્રાન્સમિટ ઑપરેશન્સમાંથી કોઈપણ એક. (RAIL પર કામ કરતા ડેવલપર્સ, નોંધ કરો કે RAIL APIના સંદર્ભમાં, આ દસ્તાવેજમાં વપરાયેલ “શેડ્યુલ્ડ ટ્રાન્સમિટ” એ કોઈપણ ટ્રાન્સમિટ ઑપરેશનનો સંદર્ભ આપે છે, અને તે RAIL_StartScheduledTx સુધી મર્યાદિત નથી.

Radio કોન્ફીg: હાર્ડવેરની સ્થિતિ નક્કી કરે છે જેનો ઉપયોગ રેડિયો ઓપરેશન કરવા માટે થવો જોઈએ.

રેડિયો શેડ્યૂલર: રેલ ઘટક કે જે રેડિયોની ઍક્સેસ હશે તે નિર્ધારિત કરવા માટે વિવિધ પ્રોટોકોલ વચ્ચે મધ્યસ્થી કરે છે.

પ્રાથમિકતા: દરેક સ્ટેકમાંથી દરેક કામગીરીની ડિફોલ્ટ પ્રાથમિકતા હોય છે. એપ્લિકેશન ડિફોલ્ટ પ્રાથમિકતાઓને બદલી શકે છે.

સ્લિપ સમય: ભવિષ્યમાં મહત્તમ સમય જ્યારે ઑપરેશન શરૂ કરી શકાય જો તે વિનંતી કરેલ પ્રારંભ સમયે શરૂ ન થઈ શકે.

ઉપજ: ઑપરેશન અથવા ઑપરેશનના ક્રમના અંતે સ્ટેક સ્વેચ્છાએ ઉપજ આપવો જોઈએ, સિવાય કે તે બેકગ્રાઉન્ડ રીસીવ કરી રહ્યું હોય. જ્યાં સુધી સ્ટેક ઉપજ ન આપે ત્યાં સુધી, શેડ્યૂલર નીચી પ્રાધાન્યતાવાળા કાર્યોને સુનિશ્ચિત કરશે નહીં

RTOS (રીઅલ ટાઇમ ઓપરેટિંગ સિસ્ટમ) કર્નલ: ઓપરેટિંગ સિસ્ટમનો ભાગ જે કાર્ય વ્યવસ્થાપન અને ઇન્ટરટાસ્ક કમ્યુનિકેશન અને સિંક્રોનાઇઝેશન માટે જવાબદાર છે. આ અમલીકરણ Micrium OS-5 કર્નલનો ઉપયોગ કરે છે.

આર્કિટેક્ચર

ડાયનેમિક મલ્ટીપ્રોટોકોલ EFR32 હાર્ડવેર અને રેલ સોફ્ટવેરનો ઉપયોગ તેના બિલ્ડીંગ બ્લોક તરીકે કરે છે. Zigbee, Bluetooth, અને/અથવા અન્ય કોઈપણ ધોરણો-આધારિત અથવા માલિકીનું પ્રોટોકોલ પછી અલગ-અલગ પ્રોટોકોલ વચ્ચેના કોડના અમલને મેનેજ કરવા માટે Micrium નો ઉપયોગ કરીને, આ બિનરાષ્ટ્રીય સ્તરોની ટોચ પર બનાવી શકાય છે. નીચેનો આકૃતિ સોફ્ટવેર મોડ્યુલોની સામાન્ય રચના સમજાવે છે.

 

સંસ્કરણ 2.0 થી શરૂ કરીને, RAIL ને RAIL API કૉલ્સ માટે રેડિયો રૂપરેખાંકન હેન્ડલ પસાર કરવાની જરૂર છે. આ રૂપરેખાંકન સ્ટેક દ્વારા ઉપયોગમાં લેવાતા વિવિધ PHY પરિમાણોનું વર્ણન કરે છે

Micrium OS એ RTOS છે જે સ્ટેક્સ અને એપ્લિકેશન લોજિકને CPU એક્ઝેક્યુશન સમય શેર કરવાની મંજૂરી આપે છે.

રેડિયો શેડ્યૂલર એ એક સોફ્ટવેર લાઇબ્રેરી છે જે વિશ્વસનીયતા વધારવા અને વિલંબને ઘટાડવા માટે રેડિયો ઓપરેશન્સ કરવા માટે સ્ટેક્સ દ્વારા વિનંતીઓનો બુદ્ધિપૂર્વક જવાબ આપે છે. RAIL દ્વારા પૂરા પાડવામાં આવેલ API જે રેડિયો શેડ્યૂલરને બાયપાસ કરતા નથી.

RAIL કોર રેડિયો શેડ્યૂલરની સૂચનાઓના જવાબમાં EFR32 હાર્ડવેરને ગોઠવે છે.

સિંગલ ફર્મવેર ઇમેજ

ડાયનેમિક મલ્ટીપ્રોટોકોલ સોફ્ટવેર ડેવલપરને EFR32 પર લોડ થયેલ સિંગલ મોનોલિથિક બાઈનરી જનરેટ કરવાની મંજૂરી આપે છે. સોફ્ટવેર અપડેટ્સ સમગ્ર બાઈનરીને અપગ્રેડ કરીને કરવામાં આવે છે. આ Geck otloader નો ઉપયોગ કરીને પરિપૂર્ણ થાય છે, જેની વિગતો UG266 માં મળી શકે છે: GSDK 3.2 અને લોઅર અને UG489 માટે સિલિકોન લેબ્સ ગેકો બુટલોડર વપરાશકર્તાની માર્ગદર્શિકા: GSDK 4.0 અને ઉચ્ચ માટે સિલિકોન લેબ્સગેકો બુટલોડર વપરાશકર્તાની માર્ગદર્શિકા.

સ્વતંત્ર સ્ટેક ઓપરેશન

ડાયનેમિક મલ્ટિપ્રોટોકોલ પરિસ્થિતિમાં સિલિકોન લેબ્સ સ્ટેક્સ હજી પણ એક બીજાથી સ્વતંત્ર રીતે કાર્ય કરે છે. અમુક લાંબા સમય સુધી ચાલતા રેડિયો ઓપરેશન્સ અન્ય પ્રોટોકોલની લેટન્સી અને સુસંગત કામગીરી પર અસર કરશે. આ ઇવેન્ટ્સ માટે કોઈ વિશેષ વિચારણાઓ નક્કી કરવી તે એપ્લિકેશન પર નિર્ભર છે. વધુ માહિતી માટે વિભાગ 2 જુઓ. રેડિયો શેડ્યૂલર.

રેડિયો શેડ્યૂલર

રેડિયો શેડ્યૂલર એ RAIL (રેડિયો એબ્સ્ટ્રેક્શન ઈન્ટરફેસ લેયર) નો એક ઘટક છે. RAIL એક સાહજિક, સરળતાથી-કસ્ટમાઇઝ કરી શકાય તેવું રેડિયો ઇન્ટરફેસ લેયર અને API પ્રદાન કરે છે, જે માલિકી અથવા ધોરણો-આધારિત વાયરલેસ પ્રોટોકોલને સપોર્ટ કરે છે. રેડિયો શેડ્યૂલર એ રેડિયો ઑપરેશન્સ માટે પરવાનગી આપવા માટે ડિઝાઇન કરવામાં આવ્યું છે જે શેડ્યૂલ કરી શકાય અને પ્રાથમિકતા આપી શકાય. દરેક પ્રોટોકોલમાં અલગ-અલગ રેડિયો ઓપરેશન્સ પરિસ્થિતિના આધારે વધુ કે ઓછા મહત્વના અથવા વધુ કે ઓછા સમય માટે સંવેદનશીલ હોઈ શકે છે. તકરાર અને તેનો નિર્ણય કેવી રીતે લેવો તે અંગે નિર્ણય લેતી વખતે શેડ્યૂલર તેને ધ્યાનમાં લઈ શકે છે

જ્યાં સુધી તમે RAIL પર કસ્ટમ પ્રોટોકોલ સાથે એપ્લીકેશનો વિકસાવતા નથી, ત્યાં સુધી મોટાભાગના રેડિયો શેડ્યૂલર ફંક્શન્સ અંતર્ગત સ્ટેક અને RAIL કોડ દ્વારા આપમેળે નિયંત્રિત થાય છે. તમારે ફક્ત તેના સામાન્ય API દ્વારા સ્ટેકનો ઉપયોગ કરવાની જરૂર છે.

ઉચ્ચ સ્તરે, સ્ટેક રેડિયો ઓપરેશન મોકલે છે (ઉદાample a શેડ્યુલ્ડ રીસીવ અથવા શેડ્યુલ્ડ ટ્રાન્સમિટ). રેડિયો કામગીરી છે
કતારબદ્ધ અને પછી તેમના પરિમાણોના આધારે ભાવિ સમયે સેવા આપવામાં આવે છે. જ્યારે રેડિયો ઑપરેશન શરૂ કરવાનો સમય હોય ત્યારે શેડ્યૂલર તપાસ કરે છે કે કોઈ સ્પર્ધાત્મક ઇવેન્ટ અસ્તિત્વમાં છે કે નહીં અને ઑપરેશનમાં વિલંબ થઈ શકે કે નહીં. જો શેડ્યૂલર ઇવેન્ટ ચલાવી શકતું નથી, તો તે પરિણામને ઉચ્ચ સ્તર પર પરત કરે છે, જે નવા પરિમાણો સાથે ફરીથી પ્રયાસ કરી શકે છે.

એકવાર રેડિયો ઑપરેશન શરૂ થઈ જાય પછી, અનુરૂપ સ્ટેક અગાઉના ઑપરેશનના પરિણામોના આધારે શેડ્યૂલરને વધારાની ઑપરેશન મોકલી શકે છે (ઉદા.ampACK ની રાહ જોઈ રહી છે). દરેક ઑપરેશન અથવા ઑપરેશનના ક્રમના અંતે સ્ટેકને રેડિયોનો ઉપયોગ મળવો જોઈએ.

રેડિયો ઓપરેશન્સ

શેડ્યૂલરમાં દરેક ઇવેન્ટને રેડિયો ઓપરેશન્સ નામના ઘટકોમાં વિભાજિત કરવામાં આવે છે, જે રેડિયો રૂપરેખા અને પ્રાથમિકતા સાથે સંકળાયેલા હોય છે.

દરેક ઑપરેશનની પ્રાથમિકતા હોય છે અને જો શેડ્યૂલરને ઉચ્ચ પ્રાધાન્યતા ઑપરેશન મળે છે જે સમયસર ઓવરલેપ થાય છે તો તેમાં વિક્ષેપ આવે છે. લોઅર પ્રાયોરિટી રેડિયો ઓપરેશન્સ કે જે તેમના શેડ્યૂલ પેરામીટર્સના આધારે ચલાવી શકાતા નથી તે નિષ્ફળ જશે, અને તેનો ફરીથી પ્રયાસ કરવો તે સંબંધિત સ્ટેક પર છે. એકવાર શેડ્યૂલર સ્ટેકમાંથી સક્રિય રીતે રેડિયો ઑપરેશન ચલાવે છે, જ્યાં સુધી તે સ્વેચ્છાએ ઉપજ ન આપે અથવા જ્યાં સુધી શેડ્યૂલરને ઉચ્ચ પ્રાધાન્યતા રેડિયો ઑપરેશન ન મળે અને તેને પ્રીમ્પ્પ્ટ ન કરે ત્યાં સુધી સ્ટેક વધારાના રેડિયો ઑપરેશન્સ મોકલવાનું ચાલુ રાખી શકે છે.

• પૃષ્ઠભૂમિ પ્રાપ્ત
• અનુસૂચિત પ્રાપ્ત
• સુનિશ્ચિત ટ્રાન્સમિટ

દરેક સ્ટેક રેડિયો શેડ્યૂલરને એક સમયે બે રેડિયો ઓપરેશન્સ (બેકગ્રાઉન્ડ રીસીવ અને શેડ્યુલ્ડ રીસીવ અથવા શેડ્યુલ્ડ ટ્રાન્સમિટ) કરવા માટે કહી શકે છે:

દરેક કામગીરીમાં નીચેના પરિમાણો હોય છે:

પ્રારંભ સમય	ભવિષ્યમાં કયા સમયે આ રેડિયો ઓપરેશન ચાલશે તેનો સંકેત. આ "અત્યારે ચલાવો" અથવા ભવિષ્યમાં માઇક્રોસેકન્ડ્સમાં અમુક મૂલ્ય હોઈ શકે છે.
પ્રાથમિકતા	એક સંખ્યા જે ઑપરેશનની સંબંધિત પ્રાથમિકતા દર્શાવે છે. ડિફૉલ્ટ સેટિંગ્સનો ઉપયોગ કરતી વખતે, બ્લૂટૂથ LE રેડિયો ઑપરેશન્સ લગભગ હંમેશા Zigbee ઑપરેશન્સ કરતાં વધુ અગ્રતા ધરાવે છે.
સ્લિપ સમય	સમયની માત્રા કે ઇવેન્ટ તેના પ્રારંભ સમય કરતાં વધુ વિલંબિત થઈ શકે છે અને હજુ પણ સ્ટેક માટે સ્વીકાર્ય છે. આ 0 હોઈ શકે છે, આ કિસ્સામાં ઇવેન્ટને સ્લિપ કરી શકાતી નથી.
વ્યવહાર સમય	વ્યવહાર પૂર્ણ કરવામાં જેટલો સમય લાગે તેટલો અંદાજિત સમય. ટ્રાન્સમિટ ઇવેન્ટ્સમાં સામાન્ય રીતે વધુ સારી રીતે વ્યાખ્યાયિત ટ્રાન્ઝેક્શન સમય હોય છે, જ્યારે પ્રાપ્ત ઇવેન્ટ્સ ઘણીવાર અજાણ હોય છે. આનો ઉપયોગ રેડિયો શેડ્યૂલરને ઇવેન્ટ ચલાવી શકાય કે કેમ તે નક્કી કરવામાં મદદ કરવા માટે થાય છે.

સ્ટેક આ વિવિધ પરિમાણોને એક્ઝિક્યુટ કરવામાં આવી રહેલા ઓપરેશન માટે યોગ્ય વ્યાખ્યાયિત કરે છે. માજી માટેample, બ્લૂટૂથ કનેક્શન ઇવેન્ટ્સ ઘણીવાર ભવિષ્યમાં શેડ્યૂલ કરવામાં આવે છે અને તેમાં કોઈ મંજૂર સ્લિપ હોતી નથી, જ્યારે Zigbee ટ્રાન્સમિટ ઇવેન્ટ્સમાં ઘણી વાર થોડી રકમ વિલંબિત થઈ શકે છે અને પછીથી સ્ટાર થઈ શકે છે.

RAIL રેડિયો શેડ્યૂલરના પરિપ્રેક્ષ્યમાં, શેડ્યૂલ્ડ ટ્રાન્સમિટ અને શેડ્યૂલ રિસિવ સમાન છે. તે બંને સરળ કામગીરી છે જેમાં રેડિયોના ઉપયોગની જરૂર પડે છે અને તેથી તે એકસાથે ચલાવી શકાતી નથી. આ સંદર્ભ ફક્ત RAIL API સ્તર પર જ સ્પષ્ટ છે, જ્યાં ક્યાં તો TX અથવા RX API કહેવામાં આવે છે.

પૃષ્ઠભૂમિ પ્રાપ્ત

આ એક સતત રીસીવ મોડ છે જેનો હેતુ અન્ય ઓપરેશન્સ દ્વારા વિક્ષેપિત કરવાનો છે, અને તેમના પૂર્ણ થયા પછી પરત આવે છે. જો બેકગ્રાઉન્ડ રીસીવ અન્ય ઓપરેશન્સ કરતાં વધુ પ્રાધાન્યતા ધરાવે છે, તો તે રેડિયો ઓપરેશન્સ શેડ્યુલ કરવામાં આવશે નહીં અને ચાલશે નહીં. અગ્રતા અથવા સ્વેચ્છાએ ઉપજ બદલવા માટે તે સ્ટેક્સ અથવા એપ્લિકેશન પર આધારિત છે. કલમ 5.1 જુઓ Exampપૂર્વ માટે બેકગ્રાઉન્ડ રીસીવ, યીલ્ડ રેડિયો અને સ્ટેટ ટ્રાન્ઝિશન સાથે લેસampપૃષ્ઠભૂમિ કેવી રીતે પ્રાપ્ત કરે છે તે સુનિશ્ચિત કામગીરી સાથે ક્રિયાપ્રતિક્રિયા કરે છે.

અનુસૂચિત પ્રાપ્ત

આ ચોક્કસ સમયગાળા સાથે ભાવિ સમયે પ્રાપ્ત થાય છે. ઓપરેશન શેડ્યૂલ કરવામાં આવશે કે નહીં તે નક્કી કરવા માટે રેડિયો શેડ્યૂલર રેડિયો સ્વિચિંગ સમયને ધ્યાનમાં લેશે. જો તે શેડ્યૂલ કરી શકાતું નથી, તો શેડ્યૂલર કૉલિંગ સ્ટેક પર નિષ્ફળ ઇવેન્ટ મોકલે છે. જ્યાં સુધી સ્ટેક સ્વૈચ્છિક રીતે પ્રાપ્ત ન કરે અથવા શેડ્યૂલરને ઉચ્ચ પ્રાથમિકતાની કામગીરી પ્રાપ્ત થાય અને તેમાં વિક્ષેપ ન આવે ત્યાં સુધી રેડિયો ઑપરેશન ઑટોમૅટિક રીતે લંબાય છે. પ્રાપ્તિને લંબાવવાથી સ્ટેકને ઉચ્ચ સ્તરના પ્રોટોકોલની જરૂરિયાતોને આધારે રેડિયો ઓપરેશન ચાલુ રાખવાની મંજૂરી મળે છે, જેમ કેampપ્રાપ્ત ડેટાના આધારે પ્રતિસાદનું પ્રસારણ.

સુનિશ્ચિત ટ્રાન્સમિટ

આ ન્યૂનતમ સમયગાળા સાથે ભવિષ્યના સમયે ટ્રાન્સમિટ છે. આ ન્યૂનતમ અવધિમાં અપેક્ષિત ફોલો-ઓન ઇવેન્ટ્સનો સમાવેશ થઈ શકે છે, ભૂતપૂર્વ માટેampIEEE 802.15.4 ટ્રાન્સમિટ માટે ACK. જો કે, આ કામગીરી માટેના ન્યૂનતમ સમયમાં અણધારી ઘટનાઓનો સમાવેશ કરવો જરૂરી નથી કે જે લઘુત્તમ અવધિ કરતાં સમય લંબાવી શકે, ભૂતપૂર્વ માટેampIEEE 802.15.4 માં CCA નિષ્ફળતાને કારણે અભાવ. રેડિયો શેડ્યૂલર ઓપરેશન શેડ્યૂલ કરવામાં આવશે કે નહીં તે નક્કી કરવા માટે રેડિયો સ્વિચિંગ સમયને ધ્યાનમાં લે છે. જો તે શેડ્યૂલ કરી શકાતું નથી, તો શેડ્યૂલર કૉલિંગ સ્ટેક પર નિષ્ફળ ઇવેન્ટ મોકલે છે.

રેડિયો રૂપરેખા

દરેક રેડિયો ઓપરેશન પૂર્વવ્યાખ્યાયિત રેડિયો રૂપરેખા સાથે સંકળાયેલું છે જે હાર્ડવેરની સ્થિતિ નક્કી કરે છે જેનો ઉપયોગ ઓપરેશન કરવા માટે થવો જોઈએ. રેડિયો રૂપરેખાઓ સ્ટેકની વર્તમાન સ્થિતિનો ટ્રૅક રાખે છે જેથી ભાવિ રેડિયો ઑપરેશન્સ સમાન રેડિયો પરિમાણોનો ઉપયોગ કરે. રેડિયો રૂપરેખાઓ સક્રિય અથવા નિષ્ક્રિય હોઈ શકે છે. જો સ્ટેક સક્રિય રેડિયો રૂપરેખામાં ફેરફાર કરે છે, તો રેલ હાર્ડવેર રૂપરેખાંકનમાં પણ તાત્કાલિક ફેરફાર કરે છે.ampચેનલ બદલો. જો રેડિયો રૂપરેખા હાલમાં સક્રિય નથી, તો પછીનું સુનિશ્ચિત રેડિયો ઓપરેશન નવી રેડિયો રૂપરેખાનો ઉપયોગ કરશે.

પ્રાથમિકતા

દરેક રેડિયો ઑપરેશનની પ્રાથમિકતા હોય છે જે શેડ્યૂલરને સૂચવે છે કે જો બહુવિધ ઑપરેશન્સ વચ્ચે ટાઇમિંગ ઓવરલેપ હોય તો કયું ઑપરેશન એક્ઝિક્યુટ કરવું જોઈએ. શેડ્યૂલર 0 ની પ્રાથમિકતાને સૌથી વધુ અગ્રતા અને 255 ને સૌથી નીચી પ્રાથમિકતા માને છે. રેડિયો શેડ્યૂલર ભૌતિક ra rdware ઍક્સેસ કરવા માટે ઉચ્ચતમ અગ્રતા સાથે કાર્યને મંજૂરી આપશે. મોટા ભાગના કાર્યો સાથે નિયંત્રણ ફક્ત પૂર્ણ થયા પછી જ રેડિયો શેડ્યૂલરને પરત કરવામાં આવે છે, પરંતુ ઉચ્ચ અગ્રતા ધરાવતું કાર્ય સક્રિય થવાના કિસ્સામાં પૃષ્ઠભૂમિ મેળવવા જેવા કાર્યોમાં વિક્ષેપ આવશે.

દરેક સ્ટેક્સમાં ફરજ ચક્રને મહત્તમ બનાવવા અને સામાન્ય ઉપયોગના કેસ માટે કનેક્શન છોડવાને ટાળવા માટે કેવી રીતે શ્રેષ્ઠ સહકાર આપવો તે અંગે સિલિકોન લેબ્સના વિશ્લેષણના આધારે પ્રાથમિકતાઓનો ડિફોલ્ટ સેટ હોય છે. ચોક્કસ ઉપયોગના કેસોની વિવિધ જરૂરિયાતો હોઈ શકે છે. પ્રાથમિકતાઓ નીચે મુજબ છે, ઉચ્ચથી નીચી સુધી

1.  બ્લૂટૂથ LE શેડ્યૂલ ટ્રાન્સમિટ
2.  Bluetooth LE સુનિશ્ચિત પ્રાપ્ત
3.  અન્ય પ્રોટોકોલ સુનિશ્ચિત ટ્રાન્સમિટ
4.  અન્ય પ્રોટોકોલ પૃષ્ઠભૂમિ પ્રાપ્ત

એપ્લિકેશન દ્વારા આ પ્રાથમિકતાઓ ઓવરરાઇડ અથવા બદલાઈ શકે છે. કયા સંજોગોમાં તેમને બદલવા તે અરજી પર નિર્ભર છે. વિભાગ 4.2 802.15.4 RAIL પ્રાધાન્યતા અને વિભાગ 6.1 બ્લૂટૂથ પ્રાધાન્યતાઓ તેમના ચોક્કસ ઉદાહરણો માટે પ્રાથમિકતાઓ પર વધુ વિગતો ધરાવે છે.

સ્લિપ સમય

દરેક રેડિયો ઑપરેશનમાં "સ્લિપ ટાઈમ" અથવા મહત્તમ શરુઆતનો સમય હોવો જોઈએ, જેનો અર્થ ભવિષ્યમાં સૌથી દૂરનો સમય છે જ્યારે ઑપરેશન શરૂ કરી શકાય છે જો તે વિનંતી કરેલ શરુઆત સમયે શરૂ ન થઈ શકે. આ શેડ્યૂલરને તે જ સમયે બનતી ઉચ્ચ અગ્રતાવાળી ઘટનાઓ અથવા તેમની અપેક્ષિત અવધિ કરતાં વધી રહેલી ઉચ્ચ અગ્રતાવાળી ઘટનાઓની આસપાસ કામ કરવાની મંજૂરી આપે છે. પ્રોટોકોલ સામાન્ય રીતે નક્કી કરે છે કે સ્લિપનો સમય શું હોઈ શકે છે, પરંતુ રેડિયો શેડ્યૂલર આને પ્રતિ-ઑપરેશનના આધારે હેન્ડલ કરવામાં સક્ષમ છે, જે સ્ટેકને કેટલીક ઇવેન્ટ્સને સ્લિપ કરવાની મંજૂરી આપે છે પરંતુ અન્યને નહીં. સામાન્ય રીતે, IEEE02.15.4 નો સ્લિપ સમય લાંબો હોય છે અને બ્લૂટૂથ LE નો સ્લિપ સમય ન્યૂનતમ હોય છે.

ઉપજ

એકવાર રેડિયો ઑપરેશન્સનો ક્રમ સક્રિય રીતે ચલાવવામાં આવે પછી, સ્ટેક પ્રારંભિક ઑપરેશનને લંબાવતા ઑપરેશન્સ ઉમેરવાનું ચાલુ રાખી શકે છે જ્યાં સુધી સ્ટેકને ચોક્કસ મેસેજ એક્સચેન્જ માટે વધુ કંઈ કરવાનું ન હોય. સ્ટેક સ્વેચ્છાએ ઉપજ આપવો જોઈએ સિવાય કે તે પૃષ્ઠભૂમિ પ્રાપ્ત કરી રહ્યું હોય. જો સ્ટેક ઉપજતું નથી, તો તે તેના રેડિયો ઑપરેશનને લંબાવવાનું ચાલુ રાખશે, અને નીચી પ્રાધાન્યતાવાળા રેડિયો ઑપરેશન્સ પછી તે રેડિયો ઑપરેશનની વિનંતી કરતા સંબંધિત સ્ટેકમાં નિષ્ફળતાને ટ્રિગર કરશે. ઉચ્ચ પ્રાયોરિટી ઓપરેશન હાલમાં ચાલી રહેલ, નીચી પ્રાધાન્યતાવાળા રેડિયો ઓપરેશનને વિક્ષેપિત કરી શકતું નથી જે ઉપજ્યું નથી. વિભાગ 5.1 જુઓ Exampપૂર્વ માટે બેકગ્રાઉન્ડ રીસીવ, યીલ્ડ રેડિયો અને સ્ટેટ ટ્રાન્ઝિશન સાથે લેસampકેટલીક પરિસ્થિતિઓ જ્યાં સ્પષ્ટપણે રેડિયો આપવો જરૂરી છે.

રેડિયો ઓપરેશનમાં વિક્ષેપ

સુનિશ્ચિત રેડિયો ઑપરેશનમાં વિક્ષેપ આવી શકે છે જો ઉચ્ચ પ્રાથમિકતા ઑપરેશન તેની સાથે વિરોધાભાસી હોય. આ નીચેના બે સંજોગોમાં થઈ શકે છે:

1. સુનિશ્ચિત રેડિયો ઑપરેશન અપેક્ષા કરતાં વધુ સમય લે છે અને સંબંધિત સ્ટેક ઉચ્ચ પ્રાથમિકતા રેડિયો ઑપરેશન શરૂ થવી જોઈએ તે પ્રાપ્ત કરતું નથી.
2. ઉચ્ચ અગ્રતા ધરાવતું રેડિયો ઑપરેશન હમણાં જ ભવિષ્યમાં થવાનું સુનિશ્ચિત કરવામાં આવ્યું છે અને નિમ્ન અગ્રતાના ઑપરેશન સાથે વિરોધાભાસ પહેલેથી જ સુનિશ્ચિત થયેલ છે.

લાંબા ગાળાના રેડિયો ઓપરેશન્સ

ચોક્કસ લાંબા સમય સુધી ચાલતા રેડિયો ઓપરેશન્સ ઉત્પાદનના યોગ્ય સંચાલન પર મોટી અસર કરી શકે છે. એપ્લિકેશનને પ્રોટોકોલ વચ્ચે આ કામગીરીનું સંકલન કરવાની જરૂર પડી શકે છે. જો એપ્લિકેશન ન થાય તો રેડિયો શેડ્યૂલરની પ્રાથમિકતાઓને અગ્રતા આપવામાં આવશે. માજી માટેample, IEEE 802.15.4 એનર્જી સ્કેન માટે જરૂરી છે કે પર્યાપ્ત ઉર્જા રીડિંગ્સ એકત્ર કરવા માટે રેડિયો ચાલુ રહે. જો એપ્લિકેશન કામગીરીને યોગ્ય રીતે સંકલન કરતી નથી, તો ઉચ્ચ પ્રાથમિકતાવાળા બ્લૂટૂથ ઓપરેશનને કારણે સ્કેન અકાળે વિક્ષેપિત થઈ શકે છે.

રેડિયો શેડ્યૂલર Exampલેસ

બધા ભૂતપૂર્વamples Bluetooth LE અને Zigbee નો ઉપયોગ કરે છે, પરંતુ સિદ્ધાંતો અન્ય Bluetooth/802.15.4 સંયોજનોને લાગુ પડે છે.

શેડ્યૂલરની શરૂઆત ઓછી પ્રાધાન્યતાવાળી ઝિગ્બી બેકગ્રાઉન્ડ રીસીવ ઓપરેશનથી થાય છે. આ હંમેશા-ચાલુ રાઉટરનું પ્રતિનિધિત્વ કરે છે જેને અજાણ્યા સમયે IEEE 802.15.4 પેકેટ્સ પ્રાપ્ત કરવાની જરૂર પડી શકે છે. બ્લૂટૂથ LE કનેક્શન પણ સક્રિય છે અને સ્ટેકને દર 30 ms પ્રાપ્ત કરવા માટે તૈયાર હોવું જરૂરી છે. બ્લૂટૂથ LE સ્ટેક કનેક્શનની અનુમાનિત પ્રકૃતિને કારણે આને અગાઉથી સુનિશ્ચિત કરી શકે છે.

પ્રાધાન્યતા સુનિશ્ચિત

આ મૂળભૂત ભૂતપૂર્વ પ્રદાન કરે છેampવિવિધ રેડિયો કામગીરીની પ્રાથમિકતાઓ નક્કી કરવા.

Zigbee સ્ટેક નક્કી કરે છે કે તેને એક પેકેટ મોકલવાની જરૂર છે. તે આને ઑન-ડિમાન્ડ ઇવેન્ટ તરીકે કરી શકે છે, એટલે કે સ્ટેક નક્કી કરે છે કે તે શેડ્યૂલરને અગાઉથી જાણ કર્યા વિના હવે પેકેટ મોકલવા માંગે છે. આ બ્લૂટૂથ LE કેવી રીતે કાર્ય કરે છે તેનાથી વિપરીત છે, જ્યાં સુનિશ્ચિત કામગીરી વ્યાજબી રીતે અગાઉથી જાણીતી છે. શેડ્યૂલર મૂલ્યાંકન કરે છે કે Zigbee TX 1 રેડિયો ઑપરેશન કરવું શક્ય છે અને હજુ પણ ભવિષ્યમાં ઉચ્ચ અગ્રતા ધરાવતા બ્લૂટૂથ LE રિસેપ્શન ઇવેન્ટને સેવા આપે છે. તેથી શેડ્યૂલર ટ્રાન્સમિટ ઇવેન્ટને થવા દે છે. ઝિગ્બી સ્ટેક આ ટ્રાન્સમિટ ઓપરેશનના તમામ ટુકડાઓ કરે છે (MAC ack ની રાહ જોવી), અને પછી સ્વેચ્છાએ ઉપજ આપે છે. Zigbee ટ્રાન્સમિટ રેડિયો ઑપરેશનના અંદાજિત ટ્રાન્ઝેક્શન સમયમાં ફરીથી પ્રયાસોનો સમાવેશ થતો નથી.

આમાં માજીample, Bluetooth LE પહેલેથી જ ભવિષ્યમાં પ્રાપ્ત કરવા માટે સુનિશ્ચિત થયેલ છે અને Zigbee સ્ટેક ટ્રાન્સમિટ કરવા માંગે છે. પ્રથમ Zigbee TX 1 રેડિયો ઑપરેશન માટે બ્લૂટૂથ LE RX 1 રેડિયો ઑપરેશન પહેલાં પૂરતો સમય છે જેથી શેડ્યૂલર સ્ટેકને ઑપરેશન કરવા માટે પરવાનગી આપે છે. બાદમાં, જ્યારે Zigbee સ્ટેક Zigbee TX 2 શેડ્યૂલ કરવાનો પ્રયાસ કરે છે ત્યારે શેડ્યૂલર નક્કી કરે છે કે ઉચ્ચ પ્રાધાન્યતા બ્લૂટૂથ LE RX 2 ઇવેન્ટ પહેલાં પૂરતો સમય નથી. જો કે, Zigbee સ્ટેકે સંકેત આપ્યો છે કે આ ક્રિયા તેનો પ્રારંભ સમય સરકી શકે છે. રેડિયો શેડ્યૂલર નક્કી કરે છે કે બ્લૂટૂથ LE રેડિયો ઑપરેશનની અપેક્ષિત અવધિને જોતાં Zigbee ઑપરેશન તે ઇવેન્ટ પછી શરૂ થઈ શકે છે અને હજુ પણ Zigbee સ્ટેક દ્વારા સૂચવવામાં આવેલા સ્લિપ સમયની અંદર હોઈ શકે છે.

જો બધુ અપેક્ષિત છે, તો ઝિગ્બી ટ્રાન્સમિટ ઓપરેશનનો પ્રથમ પ્રયાસ શેડ્યુલિંગને કારણે કોઈપણ નિષ્ફળતા વિના થશે.

પ્રાધાન્યતા વિક્ષેપ ઉદાample

આ માજીample નીચલી અગ્રતાવાળી કામગીરીમાં વિક્ષેપ પાડતી ઉચ્ચ પ્રાથમિકતાની કામગીરીને સમજાવે છે.

 

 

 

આ માજીample અગાઉના ex ની જેમ જ શરૂ થાય છેample Zigbee અને Bluetooth LE બંને પાસે રેડિયો ઓપરેશન છે જે કોઈપણ અથડામણ વિના સુનિશ્ચિત થયેલ છે

બાદમાં, Zigbee સ્ટેક નક્કી કરે છે કે તે Zigbee TX 2 ઇવેન્ટ માટે બીજું પેકેટ મોકલવા માંગે છે. શેડ્યૂલર નિર્ધારિત કરે છે કે Zigbee TX 2 ઇવેન્ટ લેવો આવશ્યક છે તે ઓછામાં ઓછા સમયના આધારે, આ ઇવેન્ટને શેડ્યૂલ કરવી અને બ્લૂટૂથ LE RX 2 ઇવેન્ટને પછીથી સેવા આપવી શક્ય હોવી જોઈએ. જો કે, લાંબા રેન્ડમ બેકઓફને કારણે Zigbee TX 2 ઇવેન્ટ અપેક્ષિત કરતાં વધુ સમય લે છે અને સમયસર પરિણામ આપતી નથી. આ ઘટનાને ઉચ્ચ પ્રાધાન્યતા રેડ પેરેશન સાથે અથડાવાનું કારણ બને છે, અને તેથી રેડિયો શેડ્યૂલર ઝિગ્બી ઇવેન્ટમાં વિક્ષેપ પાડે છે અને ઉચ્ચ સ્તરના સ્ટેકમાં નિષ્ફળતા પરત કરે છે. બ્લૂટૂથ LE ઇવેન્ટ સામાન્ય રીતે થાય છે અને જ્યારે તે પૂર્ણ થાય છે ત્યારે તે સ્વૈચ્છિક રીતે કોઈપણ નીચી અગ્રતા કામગીરી માટે ઉપજ આપે છે.

રેડિયો શેડ્યૂલરમાંથી નિષ્ફળતા પ્રાપ્ત કર્યા પછી, Zigbee સ્ટેક તરત જ MAC સંદેશનો ફરીથી પ્રયાસ કરવાનો પ્રયાસ કરે છે. તે ઓપરેશનને સુનિશ્ચિત કરે છે અને સ્લિપ સમયનો સમાવેશ કરે છે. આ સમયે બ્લૂટૂથ LE સ્ટેક રેડિયો પર પ્રાથમિકતા ધરાવે છે અને આમ ઓપરેશન હજી શરૂ કરી શકાતું નથી, પરંતુ શેડ્યૂલર નવા રેડિયો ઓપરેશનને સ્વીકારે છે. બ્લૂટૂથ LE સ્ટેક તેની સુનિશ્ચિત પ્રાપ્તિ પૂર્ણ કરે છે અને રેડિયો ઉપજ આપે છે. શેડ્યૂલર પછી ઝિગ્બી ટ્રાન્સમિટ ઑપરેશનને થવા માટે ટ્રિગર કરે છે કારણ કે તે હજુ પણ પ્રારંભિક સ્ટાર્ટ ઑપરેશનના સ્લિપ સમયની અંદર છે. ટ્રાન્સમિટ પૂર્ણ થયા પછી શેડ્યૂલર બેકગ્રાઉન્ડ રીસીવ ઓપરેશન પર પરત ફરે છે.

ઉચ્ચ પ્રાથમિકતા કામગીરી કે જે વિસ્તૃત છે

આ માજીample એ બતાવે છે કે જ્યારે ઉચ્ચ પ્રાથમિકતાની કામગીરી મૂળ અપેક્ષિત કરતાં વધુ સમય લે છે અને નીચી પ્રાથમિકતાવાળી કામગીરી તેની તક ગુમાવી દે છે ત્યારે શું થાય છે

આ કિસ્સામાં, બ્લૂટૂથ LE પાસે શેડ્યુલ્ડ રીસીવ છે જે હાલમાં થઈ રહ્યું છે. Zigbee એક પેકેટ મોકલવાનું નક્કી કરે છે પરંતુ તે અત્યારે ચલાવી શકાતું નથી. શેડ્યૂલર એ ધારણા હેઠળ ઑપરેશન સ્વીકારે છે કે બ્લૂટૂથ LE ઇવેન્ટ Zigbee ઇવેન્ટના સ્લિપ સમયના અંત પહેલા પૂર્ણ થશે. જો કે, ઉપકરણો વચ્ચે વધારાના પેકેટો મોકલવામાં આવે છે તે હકીકતને કારણે Bluetooth LE ઇવેન્ટ લાંબા સમય સુધી લંબાય છે. બ્લૂટૂથ LE ઑપરેશન પ્રાધાન્ય ધરાવે છે તેથી Zigbee ઑપરેશન આખરે બહાર નીકળી જાય છે. સ્ટેક પર એક ભૂલ પરત કરવામાં આવે છે. Zigbee પેકેટ ફરીથી ટ્રાન્સમિટ કરવાનું નક્કી કરે છે. ફરીથી, ઝિગ્બી સ્ટેક સૂચવે છે કે ઓપરેશન હવે શરૂ થવું જોઈએ પરંતુ ભવિષ્યમાં સરકી શકે છે. શેડ્યૂલર રેડિયો રૂપરેખા બદલવાની મધ્યમાં છે તેથી તે તરત જ ઑપરેશન શરૂ કરી શકતું નથી. તેના બદલે, તે રેડિયો ઑપરેશન શરૂ થવાના સમયને થોડી માત્રામાં સ્લિપ કરે છે અને પછી ઑપરેશનને એક્ઝિક્યુટ કરે છે.

વિક્ષેપ વિના ઉચ્ચ પ્રાથમિકતા કામગીરી 

આમાં માજીampરેડિયો શેડ્યૂલર બ્લૂટૂથ LE પેરિફેરલ તરીકે કામ કરતા નોડ પર ચાલી રહ્યું છે અને તે નોડ વિવિધ કેન્દ્રીય ઉપકરણો સાથે સંખ્યાબંધ કનેક્શન ધરાવે છે. તેની પાસે સામયિક જાહેરાત દીવાદાંડી પણ છે જે પ્રસારિત થાય છે. નીચેનો આંકડો એવો કિસ્સો બતાવે છે કે જ્યાં આ ઘટનાઓ વર્ચ્યુઅલ રીતે બેક-ટુ-બેક થઈ રહી છે અને Zigbee રેડિયો રૂપરેખા પર પાછા સ્વિચ કરવા માટે પૂરતો સમય આપતી નથી. તેથી તે સમયગાળો બનાવશે જ્યાં ઝિગ્બી સ્ટેક છે
સ્લિપ સમય સાથે પણ ટ્રાન્સમિટ કરવામાં અસમર્થ.

ઝિગ્બી શેડ્યૂલરને ટ્રાન્સમિટ રેડિયો ઑપરેશન શેડ્યૂલ કરવા કહે છે. સુનિશ્ચિત કરનારને ખબર હોવા છતાં કે સુનિશ્ચિત ઉચ્ચ અગ્રતા કામગીરીને કારણે ઇવેન્ટ નિષ્ફળ જશે, તેમ છતાં તે સુનિશ્ચિત ઇવેન્ટને સ્વીકારે છે. આ બે કારણોસર કરવામાં આવે છે. પ્રથમ, સંજોગો બદલાઈ શકે છે અને ઘટનાને અમલમાં મૂકી શકાય છે. બીજું, રેડિયો શેડ્યૂલરની ટોચ પર બેઠેલું સ્ટેક ક્રિયાનો ફરીથી પ્રયાસ કરવાનો પ્રયાસ કરી શકે છે. જો નિષ્ફળ શેડ્યુલિંગનું પરિણામ તરત જ પાછું આપવામાં આવ્યું હતું, તો સ્ટેકનો ફરીથી પ્રયાસ કરવાનો પ્રયાસ સફળ થવાની શક્યતા નથી કારણ કે સમય પસાર થયો નથી. તેના બદલે, ઇવેન્ટને કતાર કરીને અને સ્લિપનો સમય સમાપ્ત થયા પછી નિષ્ફળતા પરત કરીને, ફરીથી પ્રયાસ (તેના પોતાના સ્લિપ સમય સાથે) સફળતાની વધુ સારી તક ધરાવે છે કારણ કે આગામી રેડિયો ઓપરેશન્સનો સેટ અલગ હશે.

જ્યારે ઉચ્ચ પ્રાથમિકતાની કામગીરી ચાલી રહી હોય ત્યારે પ્રાપ્ત કરો 

આ માજીample સમજાવે છે કે જ્યારે બ્લૂટૂથ LE સક્રિય હોય ત્યારે શું થાય છે અને ઓછી પ્રાથમિકતાવાળી કામગીરી ડેટા પ્રાપ્ત કરશે.

પ્રથમ કિસ્સામાં, જ્યારે IEEE 802.15.4 સંદેશ મોકલવામાં આવે છે અને બ્લૂટૂથ LE સ્ટેક સક્રિય રીસીવ માટે રેડિયોનો ઉપયોગ કરી રહ્યું હોય ત્યારે Zigbee સ્ટેક સંદેશ પ્રાપ્ત કરવા માટે ઓનલાઈન રહેશે નહીં. જો કે, સંદેશ મોકલનાર ઝિગ્બી મોટા ભાગના કિસ્સાઓમાં ફરી પ્રયાસ કરશે અને બેકઓફ અને અન્ય સમયના ફેરફારો સાથે અન્ય ઉચ્ચ પ્રાથમિકતા શેડ્યૂલ કરેલ બ્લૂટૂથ મેળવેલી ઘટનાઓ સાથે અથડાવાની શક્યતા નથી. Zigbee સંદેશ સફળતાપૂર્વક પ્રાપ્ત થયો છે

બીજો કિસ્સો દર્શાવે છે કે, સક્રિય રીસીવના કિસ્સામાં, Zigbee સ્ટેક હજુ પણ વિક્ષેપિત થઈ શકે છે અને સંદેશ પ્રાપ્ત (અથવા ACK) કરી શકશે નહીં. સફળ સંચાર આ સંદેશને ફરીથી મોકલવા અને ડાયનેમિક મલ્ટિપ્રોટોકોલ ઉપકરણ સંદેશ પ્રાપ્ત કરે છે તેની ચકાસણી કરવા માટે MAC અથવા ઉચ્ચ સ્તર પરના પ્રયાસો પર આધાર રાખે છે.

જ્યારે સક્રિય પ્રાપ્તિમાં વિક્ષેપ થવો જોઈએ કે નહીં તે અંગે વિચારણાઓ હોઈ શકે છે, શેડ્યૂલર માટે તે નિર્ધારણ કરવું મુશ્કેલ છે. સામાન્ય રીતે પ્રોટોકોલની મજબુતતા વિક્ષેપ સાથે પણ સંદેશાઓને સફળતાપૂર્વક પ્રાપ્ત કરવાની મંજૂરી આપવી જોઈએ

802.15.4-આધારિત સ્ટેક સાથે મલ્ટિપ્રોટોકોલનો અમલ

આ પ્રકરણ 802.15.4-આધારિત સ્ટેક જેવા કે મલ્ટીપ્રોટોકોલ એપ્લિકેશનના ભાગ રૂપે 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) સુધી અગ્રતા વધારી દે છે. જો સંદેશા સફળ ન થાય તો જરૂરી છે.

અગાઉના વિભાગમાં વર્ણવ્યા મુજબ, Zigbee અથવા Connect જેવા 802.15.4-આધારિત સ્ટેક બેકગ્રાઉન્ડ RX માટે 255, સક્રિય RX માટે 255 અને સક્રિય TX માટે 100 ની ડિફોલ્ટ 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

કારણ કે બ્લૂટૂથ શરૂઆતમાં તેની RAIL પ્રાધાન્યતા 32 પર સેટ કરે છે, આ 802.15.4 પ્રાથમિકતા સેટિંગ્સ શરૂઆતમાં બ્લૂટૂથ કરતાં 802.15.4 ટ્રાફિકને વધુ પ્રાધાન્ય આપે છે, જે 802.15.4 પ્રોટોકોલને ટ્રાફિકની હાજરીમાં પણ સફળતાપૂર્વક ટ્રાન્સમિટ કરવાની અથવા પ્રાપ્ત કરવાની તક આપે છે. બ્લૂટૂથ ટ્રાફિકનો મોટો ભાર. બીજી બાજુ, બ્લૂટૂથ ગતિશીલ રીતે તેની પ્રાથમિકતામાં વધારો કરશે જો તે શેડ્યૂલરથી 802.15.4 ટ્રાફિકથી બમ્પ કરવામાં આવશે, 16 ની ઉચ્ચ અગ્રતા સુધી. આમ 802.15.4 પ્રોટોકોલને શરૂઆતમાં રેડિયોની ઍક્સેસની મંજૂરી આપ્યા પછી, બ્લૂટૂથ તેની પ્રાધાન્યતામાં વધારો કરશે. જો જરૂરી હોય તો અનુગામી પ્રયાસો પર અગ્રતા.

આ અભિગમ બંને પ્રોટોકોલને રેડિયોના તેમના ઉપયોગ સાથે સમાધાન કરવાની મંજૂરી આપે છે, જેમાં એક બીજા પર સંપૂર્ણ રીતે વર્ચસ્વ જમાવી શક્યું નથી.

. રેલ સાથે મલ્ટિપ્રોટોકોલનો અમલ 

આ પ્રકરણ RAIL ની વિશેષતાઓ વિશે વધુ માહિતી પ્રદાન કરે છે જેઓ માલિકી પ્રોટોકોલ વિકસાવવા માટે સીધા RAIL API નો ઉપયોગ કરે છે. ખાસ કરીને તે ચોક્કસ રેડિયો શેડ્યૂલર કેસને હેન્ડલ કરવા માટે RAIL API સાથે કેવી રીતે કામ કરવું તેની વિગતો આપે છે.

Exampબેકગ્રાઉન્ડ રીસીવ, યીલ્ડ રેડિયો અને સ્ટેટ ટ્રાન્ઝિશન સાથે લેસ

RAIL મલ્ટિપ્રોટોકોલ અગ્રતા પ્રણાલીના મૂળભૂત સિદ્ધાંતો એકદમ સરળ છે: ઉચ્ચ પ્રાધાન્યતા (એટલે ​​​​કે, સંખ્યામાં ઓછી) સાથેની રેડિયો ઇવેન્ટ હંમેશા નીચી અગ્રતા સાથે અન્ય કોઈપણ રેડિયો ઇવેન્ટને હડપ કરશે. જો કે, રાજ્યના સંક્રમણો અને APIs જેમ કે RAIL_StartRx(), જે રેડિયોને અનિશ્ચિત સમય માટે ચોક્કસ સ્થિતિમાં મૂકે છે ત્યારે આ વિષય વધુ જટિલ બની જાય છે. આ વિભાગ કેટલાક ઉદાહરણ પૂરા પાડે છેampઆ સમય-અનબાઉન્ડ સ્ટેટ્સ કેવી રીતે હેન્ડલ કરવામાં આવે છે તે દર્શાવવા માટે, અને એપ્લિકેશન સ્તર તેમને નિયંત્રિત કરવા માટે RAIL_YieldRadio() જેવા API નો ઉપયોગ કેવી રીતે કરી શકે છે. માજીampલેસ નીચે મુજબ છે:

• સિંગલ પ્રોટોકોલ સાથે રાજ્ય સંક્રમણો
• બે પ્રોટોકોલ સાથે રાજ્ય સંક્રમણો
• State Transitions with Two Protocols and Monotonically Increasing Priorities

આમાં માજીamples, RAIL_StartTx() એ TX ઇવેન્ટનો સ્ત્રોત છે જે પૃષ્ઠભૂમિ RX ને વિક્ષેપિત કરે છે. જો કે, નોંધ કરો કે આ ભૂતપૂર્વampલેસ RAIL_StartRx() સિવાય કોઈપણ રેડિયો API પર લાગુ થાય છે. બીજા શબ્દોમાં કહીએ તો, ભૂતપૂર્વamples કોઈપણ એપીઆઈ પર લાગુ થાય છે જે રેડિયો ઇવેન્ટ શરૂ કરે છે જે પૃષ્ઠભૂમિ RX નથી

આ માજીampલેસ રાજ્ય સંક્રમણોના સંદર્ભમાં અપેક્ષિત મલ્ટીપ્રોટોકોલ વર્તણૂકોનું વર્ણન કરે છે. સારાંશ માટે:

• રાજ્યના સંક્રમણમાં, જ્યાં સુધી RAIL_YieldRadio()ને બોલાવવામાં ન આવે ત્યાં સુધી નવા રાજ્યને તે જ અગ્રતા પર મૂળ ઘટનાના અનિશ્ચિત વિસ્તરણ તરીકે ગણવામાં આવે છે.
• પૃષ્ઠભૂમિ RX ઇવેન્ટ્સ RAIL_YieldRadio() દ્વારા પ્રભાવિત થતી નથી. ફક્ત RAIL_Idle() પૃષ્ઠભૂમિ RX રાજ્યમાંથી પ્રોટોકોલને કાયમી ધોરણે દૂર કરી શકે છે.
• ઉચ્ચ પ્રાધાન્યતાવાળી ઇવેન્ટ હંમેશા નીચી પ્રાધાન્યતાવાળી ઇવેન્ટને હડપ કરશે, અન્ય કોઈપણ API કૉલ્સને ધ્યાનમાં લીધા વિના.
• RAIL_YieldRadio() અથવા RAIL_Idle() દ્વારા માત્ર RAIL_StartRx() પ્રાપ્ત થયેલ ઉચ્ચ પ્રાધાન્યતા ઇવેન્ટમાંથી 'પાછળ' કરી શકાય છે.
• RAIL_StartRx() સિવાયની તમામ રેડિયો ઇવેન્ટને સમાપ્ત કરવા અને પછીની ઇવેન્ટમાં આગળ વધવા માટે RAIL_YieldRadio()ની જરૂર છે.
• RAIL_YieldRadio() પરનો કૉલ RAIL_Idle() વડે બદલી શકાતો નથી. RAIL_Idle() આપેલ પ્રોટોકોલ માટે તમામ ઇવેન્ટ્સને સાફ કરે છે

.સિંગલ પ્રોટોકોલ સાથે રાજ્ય સંક્રમણો

આ પ્રથમ માજીample એક જ પ્રોટોકોલ સાથે રેડિયોની વર્તણૂકની તપાસ કરે છે (એટલે ​​​​કે, જ્યાં સમાન AIL_Handle_t બધા રેડિયો ફંક્શન કૉલ્સ માટે વપરાય છે). રેડિયો RX માં RAIL_StartRx() ને પ્રારંભિક કૉલ સાથે શરૂ થાય છે, પછી RAIL_StartTx() પર ઉચ્ચ પ્રાથમિકતાવાળા કૉલ સાથે TX માં જાય છે. એ નોંધવું અગત્યનું છે કે ટ્રાન્સમિટ થયા પછી, RAIL_SetTxTransitions() દ્વારા ઉલ્લેખિત રાજ્યમાં રેડિયો સંક્રમણ થાય છે, અને જ્યાં સુધી RAIL_YieldRadio() ન કહેવાય ત્યાં સુધી તે TX જેવી જ પ્રાથમિકતા અને ચેનલ પર અનિશ્ચિત સમય સુધી રાજ્યમાં રહે છે. તે પછી, રેડિયો આરએક્સ પર પાછો આવે છે, શરૂઆતમાં ઉલ્લેખિત પ્રાથમિકતા અને ચેનલ સાથે.

રેડિયોને સક્રિયપણે ઉપજાવવાની જરૂરિયાત, અને આમ RAIL_YieldRadio() API એ ACK'ing ને કારણે મોટાભાગે જરૂરી હતું. ડિઝાઇન ફિલસૂફી તે છે, કારણ કે TX અને પ્રાપ્ત ACK બંને છે viewed એ જ ટ્રાન્ઝેક્શનના ભાગ રૂપે, જો કોઈ નોડ ACK ટ્રાન્સમિટ કરે છે અને તેની અપેક્ષા રાખે છે, તો તે RX બંનેમાં સંક્રમણ કરવામાં સક્ષમ હોવું જોઈએ અને મૂળ TXની સમાન કામગીરી (અને તેથી સમાન અગ્રતા)ના ભાગ રૂપે ACK માટે સાંભળવાનું ચાલુ રાખવું જોઈએ. સામાન્ય રીતે, જો કે, રેલ તેની જાતે જાણી શકતું નથી કે 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 થી પ્રોટોકોલ A પર RX માં સંક્રમણ માટે જરૂરી છે. અહીં ફિલસૂફી એ છે કે પૃષ્ઠભૂમિ RXs ખરેખર ઉપજાવી શકાતા નથી, કારણ કે ઘટના ખરેખર ક્યારેય સમાપ્ત થતી નથી. બહાર નીકળવાનો એકમાત્ર રસ્તો એ છે કે RAIL_Idle() પર કૉલ કરીને પૃષ્ઠભૂમિ RX ને રોકો.

 State Transitions with Two Protocols and Monotonically Increasing Prioritie

પ્રોટોકોલ B પર RAIL_StartRx() ને કરવામાં આવેલ કૉલ સિવાય, પ્રોટોકોલ A પર RAIL_StartTx() ને કૉલ કરતાં વધુ પ્રાધાન્યતા પર છે.

આ કિસ્સામાં, બીજા RAIL_StartRx() ની પ્રાધાન્યતા RAIL_StartTx() ને કૉલની પ્રાથમિકતા કરતાં વધુ હોવાથી, RAIL_YieldRadio() પર કૉલ કરવાની હવે જરૂર નથી. કારણ કે બીજું RAIL_StartRx() ઉચ્ચ અગ્રતા પર છે, તે RAIL_StartTx() ઇવેન્ટને હડપ કરે છે, રેડિયો પર નિયંત્રણ મેળવે છે અને રાજ્યમાંથી TX ઇવેન્ટને દૂર કરે છે. પ્રોટોકોલ B પર તે RX દરમિયાન કોઈપણ સમયે, 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() વચ્ચેના તફાવત પર ભાર મૂકવા માટે એ નોંધવું અગત્યનું છે કે, આ તમામ ભૂતપૂર્વ માટેampજો, RAIL_YieldRadio() પરનો કૉલ RAIL_Idle() સાથે બદલી શકાતો નથી. RAIL_Idle() આપેલ પ્રોટોકોલ માટે તમામ ઇવેન્ટ્સને સાફ કરે છે - બંને બેકગ્રાઉન્ડ (એટલે ​​કે, RAIL_StartRx() દ્વારા શરૂ કરાયેલ) અને શેડ્યુલ્ડ (એટલે ​​કે, RAIL_StartRx()) ઓપરેશન્સ સિવાયના API દ્વારા શરૂ કરવામાં આવે છે. RAIL_Idle() ખરેખર હજુ પણ એપ્લિકેશનને TX સંક્રમણ સ્થિતિમાંથી બહાર નીકળવાનું કારણ બનશે, પરંતુ તે પૃષ્ઠભૂમિ RX ને પણ સાફ કરશે, જેના કારણે એપ્લિકેશન નિષ્ક્રિય થઈ જશે, RX નહીં.

બ્લૂટૂથ સાથે મલ્ટિપ્રોટોકોલનો અમલ

RAIL/Bluetooth light/switch કેવી રીતે મલ્ટિપ્રોટોકોલ example લાગુ કરવામાં આવ્યો હતો, અને RAIL પર તમારા પોતાના પ્રોટોકોલ સાથે મલ્ટિપ્રોટોકોલ એપ્લિકેશન વિકસાવવા વિશે વધુ માહિતી માટે, AN1134 જુઓ: બ્લૂટૂથ સાથે ડાયનેમિક મલ્ટિપ્રોટોકોલ ડેવલપમેન્ટ અને GSDK v2.x માં RAIL પર પ્રોપ્રાઈટરી પ્રોટોકોલ્સ અથવા AN1269 ડાયનેમિક મલ્ટિપ્રોટોકોલ ડેવલપમેન્ટ અને બ્લૂટૂથ સાથે પ્રોપ્રાઈટરી પ્રોપ્રાઈટરી પ્રોટોકોલ. GSDK v3.x અને ઉચ્ચમાં.

બ્લૂટૂથ પ્રાથમિકતાઓ

વિવિધ પ્રકારની કામગીરી માટે સ્થિર રીતે વ્યાખ્યાયિત પ્રાથમિકતાઓ સાથે ઝિગ્બીના વિરોધમાં, બ્લૂટૂથ પ્રાધાન્યતા સ્પેક્ટ્રમના આપેલ ક્ષેત્રને તમામ કાર્યો સોંપવા માટે શ્રેણી અને ઑફસેટ અભિગમનો ઉપયોગ કરે છે.

આમાં માજી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 બ્લૂટૂથ પ્રાથમિકતાઓ તેમજ આ વિભાગમાં સૂચિબદ્ધ છે.

જો પોઈન્ટર નલ ન હોય તો તે નીચે વ્યાખ્યાયિત પ્રમાણે અગ્રતા સેટિંગ્સના સ્ટ્રક્ચર તરફ નિર્દેશ કરે છે:

સેન્ડમેન, સિનેમેક્સ, 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 અને scan સ્ટેપ પેરામીટર્સ સ્ટેપ સાઈઝને વ્યાખ્યાયિત કરે છે. છેલ્લે, 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® અને Silicon Labs logo®, Blueridge®, Blueridge Logo®, EFM®, EFM32®, EFR, Ember®, એનર્જી માઇક્રો, એનર્જી માઇક્રો લોગો અને તેના સંયોજનો , “વિશ્વના સૌથી ઉર્જા અનુકૂળ માઇક્રો કંટ્રોલર્સ”, 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 હોલ્ડિંગ્સના ટ્રેડમાર્ક અથવા રજિસ્ટર્ડ ટ્રેડમાર્ક છે. કેલી એ એઆરએમ લિમિટેડનું નોંધાયેલ ટ્રેડમાર્ક છે. Wi-Fi એ Wi-Fi એલાયન્સનું નોંધાયેલ ટ્રેડમાર્ક છે. અહીં ઉલ્લેખિત અન્ય તમામ ઉત્પાદનો અથવા બ્રાન્ડ નામો તેમના સંબંધિત હોલ્ડના ટ્રેડમાર્ક છે

દસ્તાવેજો / સંસાધનો

સિલિકોન લેબ્સ UG305 ડાયનેમિક મલ્ટિપ્રોટોકોલ [પીડીએફ] વપરાશકર્તા માર્ગદર્શિકા UG305, UG305 ડાયનેમિક મલ્ટીપ્રોટોકોલ, ડાયનેમિક મલ્ટીપ્રોટોકોલ, મલ્ટીપ્રોટોકોલ

સંદર્ભો

• વપરાશકર્તા માર્ગદર્શિકા