സിലിക്കൺ ലാബ്സ് 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 എന്നിവയ്ക്കൊപ്പം ഡൈനാമിക് മൾട്ടിപ്രോട്ടോക്കോൾ വികസനം
ടെർമിനോളജി
ഡൈനാമിക് മൾട്ടിപ്രോട്ടോക്കോൾ നടപ്പിലാക്കുന്നതിനുള്ള ചില പ്രത്യേക പദങ്ങൾ താഴെ പട്ടികപ്പെടുത്തുന്നു
റേഡിയോ അബ്സ്ട്രാക്ഷൻ ഇൻ്റർഫേസ് ലെയർ (റെയിൽ): ഉയർന്ന തലത്തിലുള്ള കോഡ് EFR32 റേഡിയോയിലേക്ക് ആക്സസ് നേടുന്ന പൊതു API.
റേഡിയോ ഓപ്പറേഷൻ: ഒരു നിർദ്ദിഷ്ട പ്രവർത്തനം ഷെഡ്യൂൾ ചെയ്യണം. ഒരു റേഡിയോ പ്രവർത്തനത്തിന് ഒരു റേഡിയോ കോൺഫിഗറേഷനും മുൻഗണനയും ഉണ്ട്. ഓരോ സ്റ്റാക്കിനും റേഡിയോ ഷെഡ്യൂളറിന് രണ്ട് റേഡിയോ ഓപ്പറേഷനുകൾ വരെ ചെയ്യാൻ അഭ്യർത്ഥിക്കാം (പശ്ചാത്തലം സ്വീകരിക്കുക, ഷെഡ്യൂൾ ചെയ്ത സ്വീകരിക്കുക അല്ലെങ്കിൽ ഷെഡ്യൂൾ ചെയ്യുക
- പശ്ചാത്തല സ്വീകരണം: സ്ഥിരമായി സ്വീകരിക്കുക, ഷെഡ്യൂൾ ചെയ്ത പ്രവർത്തനങ്ങൾ തടസ്സപ്പെടുത്താൻ ഉദ്ദേശിച്ചുള്ളതാണ്, അവ പൂർത്തീകരിച്ചതിന് ശേഷം തിരികെ നൽകുക.
- ഷെഡ്യൂൾ ചെയ്ത സ്വീകരണം: പാക്കറ്റുകൾ സ്വീകരിക്കുക അല്ലെങ്കിൽ ഒരു നിശ്ചിത സമയത്തിലും കാലയളവിലും RSSI കണക്കാക്കുക. (RAIL-ൽ പ്രവർത്തിക്കുന്ന ഡെവലപ്പർമാർ, RAIL API-യുടെ അടിസ്ഥാനത്തിൽ, ഈ പ്രമാണത്തിൽ ഉപയോഗിച്ചിരിക്കുന്ന "ഷെഡ്യൂൾഡ് റിസീവ്" എന്നത് RAIL_StartRx ഒഴികെയുള്ള ഏതൊരു സ്വീകരിക്കൽ പ്രവർത്തനത്തെയും സൂചിപ്പിക്കുന്നു, മാത്രമല്ല ഇത് RAIL_ScheduleRx-ലേക്ക് മാത്രം പരിമിതപ്പെടുത്തിയിട്ടില്ല.)
- ഷെഡ്യൂൾ ചെയ്ത ട്രാൻസ്മിt: ഉടനടി ട്രാൻസ്മിറ്റ്, ഷെഡ്യൂൾ ചെയ്ത (ഭാവി) ട്രാൻസ്മിറ്റ് അല്ലെങ്കിൽ CCA-ആശ്രിത ട്രാൻസ്മിറ്റ് ഉൾപ്പെടെ വിവിധ ട്രാൻസ്മിറ്റ് പ്രവർത്തനങ്ങളിൽ ഏതെങ്കിലും ഒന്ന്. (RAIL-ൽ പ്രവർത്തിക്കുന്ന ഡവലപ്പർമാർ, RAIL API-യുടെ അടിസ്ഥാനത്തിൽ, ഈ ഡോക്യുമെൻ്റിൽ ഉപയോഗിച്ചിരിക്കുന്ന "ഷെഡ്യൂൾഡ് ട്രാൻസ്മിറ്റ്" എന്നത് ഏതൊരു ട്രാൻസ്മിറ്റ് പ്രവർത്തനത്തെയും സൂചിപ്പിക്കുന്നു, മാത്രമല്ല ഇത് RAIL_StartScheduledTx-ലേക്ക് പരിമിതപ്പെടുത്തിയിട്ടില്ല.
Rഅഡിയോ കോൺഫിg: ഒരു റേഡിയോ പ്രവർത്തനം നടത്താൻ ഉപയോഗിക്കേണ്ട ഹാർഡ്വെയറിൻ്റെ അവസ്ഥ നിർണ്ണയിക്കുന്നു.
റേഡിയോ ഷെഡ്യൂളർ: റേഡിയോയിലേക്ക് ആക്സസ് ഉള്ളത് ഏതെന്ന് നിർണ്ണയിക്കാൻ വ്യത്യസ്ത പ്രോട്ടോക്കോളുകൾക്കിടയിൽ മദ്ധ്യസ്ഥത വഹിക്കുന്ന റെയിൽ ഘടകം.
മുൻഗണന: ഓരോ സ്റ്റാക്കിൽ നിന്നുമുള്ള ഓരോ പ്രവർത്തനത്തിനും ഒരു ഡിഫോൾട്ട് മുൻഗണനയുണ്ട്. ഒരു അപ്ലിക്കേഷന് സ്ഥിരസ്ഥിതി മുൻഗണനകൾ മാറ്റാൻ കഴിയും.
സ്ലിപ്പ് സമയം: അഭ്യർത്ഥിച്ച ആരംഭ സമയത്ത് പ്രവർത്തനം ആരംഭിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ ഭാവിയിലെ പരമാവധി സമയം.
വരുമാനം: ഒരു സ്റ്റാക്ക് ഒരു ഓപ്പറേഷൻ അല്ലെങ്കിൽ ഓപ്പറേഷൻ സീക്വൻസിൻ്റെ അവസാനം സ്വമേധയാ നൽകണം, അത് ഒരു പശ്ചാത്തല സ്വീകരണം നടത്തുന്നില്ലെങ്കിൽ. സ്റ്റാക്ക് ലഭിക്കുന്നത് വരെ, ഷെഡ്യൂളർ കുറഞ്ഞ മുൻഗണനയുള്ള ജോലികൾ ഷെഡ്യൂൾ ചെയ്യില്ല
RTOS (റിയൽ ടൈം ഓപ്പറേറ്റിംഗ് സിസ്റ്റം) കേർണൽ: ടാസ്ക് മാനേജ്മെൻ്റിനും ഇൻ്റർടാസ്ക് ആശയവിനിമയത്തിനും സമന്വയത്തിനും ഉത്തരവാദിത്തമുള്ള ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിൻ്റെ ഭാഗം. ഈ നടപ്പിലാക്കൽ Micrium OS-5 കേർണൽ ഉപയോഗിക്കുന്നു.
വാസ്തുവിദ്യ
Dynamic Multiprotocol EFR32 ഹാർഡ്വെയറും RAIL സോഫ്റ്റ്വെയറും അതിൻ്റെ നിർമ്മാണ ബ്ലോക്കുകളായി ഉപയോഗിക്കുന്നു. സിഗ്ബീ, ബ്ലൂടൂത്ത്, കൂടാതെ/അല്ലെങ്കിൽ മറ്റേതെങ്കിലും സ്റ്റാൻഡേർഡ് അധിഷ്ഠിത അല്ലെങ്കിൽ പ്രൊപ്രൈറ്ററി പ്രോട്ടോക്കോളുകൾ വ്യത്യസ്ത പ്രോട്ടോക്കോളുകൾക്കിടയിൽ കോഡിൻ്റെ നിർവ്വഹണം നിയന്ത്രിക്കുന്നതിന് മൈക്രോയം ഉപയോഗിച്ച് ഈ അടിസ്ഥാനരഹിതമായ പാളികൾക്ക് മുകളിൽ നിർമ്മിക്കാൻ കഴിയും. സോഫ്റ്റ്വെയർ മൊഡ്യൂളുകളുടെ പൊതുവായ ഘടന താഴെ കൊടുത്തിരിക്കുന്ന ഡയഗ്രം വ്യക്തമാക്കുന്നു.
പതിപ്പ് 2.0 മുതൽ, RAIL-ന് ഒരു റേഡിയോ കോൺഫിഗറേഷൻ ഹാൻഡിൽ RAIL API കോളുകളിലേക്ക് കൈമാറേണ്ടതുണ്ട്. ഈ കോൺഫിഗറേഷൻ സ്റ്റാക്ക് ഉപയോഗിക്കുന്ന വിവിധ PHY പാരാമീറ്ററുകൾ വിവരിക്കുന്നു
CPU നിർവ്വഹണ സമയം പങ്കിടാൻ സ്റ്റാക്കുകളും ആപ്ലിക്കേഷൻ ലോജിക്കും അനുവദിക്കുന്ന ഒരു RTOS ആണ് Micrium OS.
റേഡിയോ ഷെഡ്യൂളർ എന്നത് ഒരു സോഫ്റ്റ്വെയർ ലൈബ്രറിയാണ്, അത് വിശ്വാസ്യത വർദ്ധിപ്പിക്കുന്നതിനും കാലതാമസം കുറയ്ക്കുന്നതിനുമായി റേഡിയോ പ്രവർത്തനങ്ങൾ നടത്താൻ സ്റ്റാക്കുകളുടെ അഭ്യർത്ഥനകൾക്ക് ബുദ്ധിപരമായി ഉത്തരം നൽകുന്നു. റേഡിയോ ഷെഡ്യൂളറിനെ ബൈപാസ് ചെയ്യുന്ന റേഡിയോയിൽ ഏർപ്പെടാത്ത API-കൾ RAIL നൽകുന്നു.
റേഡിയോ ഷെഡ്യൂളറിൽ നിന്നുള്ള നിർദ്ദേശങ്ങൾക്ക് മറുപടിയായി RAIL കോർ EFR32 ഹാർഡ്വെയർ കോൺഫിഗർ ചെയ്യുന്നു.
സിംഗിൾ ഫേംവെയർ ചിത്രം
Dynamic Multiprotocol ഒരു സോഫ്റ്റ്വെയർ ഡെവലപ്പറെ EFR32-ലേക്ക് ലോഡുചെയ്യുന്ന ഒരൊറ്റ മോണോലിത്തിക്ക് ബൈനറി സൃഷ്ടിക്കാൻ അനുവദിക്കുന്നു. മുഴുവൻ ബൈനറിയും നവീകരിച്ചാണ് സോഫ്റ്റ്വെയർ അപ്ഡേറ്റുകൾ ചെയ്യുന്നത്. ഗെക്ക് ഒട്ട്ലോഡർ ഉപയോഗിച്ചാണ് ഇത് ചെയ്യുന്നത്, ഇതിൻ്റെ വിശദാംശങ്ങൾ UG266-ൽ കാണാം: GSDK 3.2-നുള്ള Silicon Labs Gecko Bootloader User's Guide and Lower and UG489: Silicon LabsGecko Bootloader User's Guide for GSDK 4.0.
സ്വതന്ത്ര സ്റ്റാക്ക് പ്രവർത്തനം
സിലിക്കൺ ലാബ് സ്റ്റാക്കുകൾ ഇപ്പോഴും ഡൈനാമിക് മൾട്ടിപ്രോട്ടോകോൾ സാഹചര്യത്തിൽ പരസ്പരം സ്വതന്ത്രമായി പ്രവർത്തിക്കുന്നു. ചില ദീർഘകാല റേഡിയോ പ്രവർത്തനങ്ങൾ മറ്റൊരു പ്രോട്ടോക്കോളിൻ്റെ ലേറ്റൻസിയിലും അനുസൃതമായ പ്രവർത്തനത്തിലും സ്വാധീനം ചെലുത്തും. ഈ ഇവൻ്റുകൾക്കായി എന്തെങ്കിലും പ്രത്യേക പരിഗണനകൾ നിർണ്ണയിക്കേണ്ടത് ആപ്ലിക്കേഷനാണ്. കൂടുതൽ വിവരങ്ങൾക്ക് വിഭാഗം 2. റേഡിയോ ഷെഡ്യൂളർ കാണുക.
റേഡിയോ ഷെഡ്യൂളർ
റേഡിയോ ഷെഡ്യൂളർ റെയിൽ (റേഡിയോ അബ്സ്ട്രാക്ഷൻ ഇൻ്റർഫേസ് ലെയർ) ൻ്റെ ഒരു ഘടകമാണ്. RAIL ഒരു അവബോധജന്യവും എളുപ്പത്തിൽ ഇഷ്ടാനുസൃതമാക്കാവുന്നതുമായ റേഡിയോ ഇൻ്റർഫേസ് ലെയറും API നൽകുന്നു, അത് കുത്തക അല്ലെങ്കിൽ മാനദണ്ഡങ്ങൾ അടിസ്ഥാനമാക്കിയുള്ള വയർലെസ് പ്രോട്ടോക്കോളുകളെ പിന്തുണയ്ക്കുന്നു. ഷെഡ്യൂൾ ചെയ്യാനും മുൻഗണന നൽകാനും കഴിയുന്ന റേഡിയോ പ്രവർത്തനങ്ങൾ അനുവദിക്കുന്നതിനാണ് റേഡിയോ ഷെഡ്യൂളർ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. ഓരോ പ്രോട്ടോക്കോളിലെയും വ്യത്യസ്ത റേഡിയോ പ്രവർത്തനങ്ങൾ സാഹചര്യത്തെ ആശ്രയിച്ച് കൂടുതലോ കുറവോ പ്രാധാന്യമുള്ളതോ കൂടുതലോ കുറവോ സമയ സെൻസിറ്റീവ് ആയിരിക്കാം. പൊരുത്തക്കേടുകളെക്കുറിച്ചുള്ള തീരുമാനങ്ങൾ എടുക്കുമ്പോഴും അവ എങ്ങനെ തീർപ്പാക്കാമെന്നും ഷെഡ്യൂളർക്ക് അവ കണക്കിലെടുക്കാനാകും
നിങ്ങൾ RAIL-ൽ ഒരു ഇഷ്ടാനുസൃത പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് ആപ്ലിക്കേഷനുകൾ വികസിപ്പിക്കുന്നില്ലെങ്കിൽ, മിക്ക റേഡിയോ ഷെഡ്യൂളർ ഫംഗ്ഷനുകളും അണ്ടർലൈയിംഗ് സ്റ്റാക്കും RAIL കോഡും ഉപയോഗിച്ച് സ്വയമേവ കൈകാര്യം ചെയ്യും. നിങ്ങൾ സ്റ്റാക്ക് അതിൻ്റെ സാധാരണ API വഴി മാത്രമേ ഉപയോഗിക്കാവൂ.
ഉയർന്ന തലത്തിൽ, സ്റ്റാക്ക് ഒരു റേഡിയോ പ്രവർത്തനം അയയ്ക്കുന്നു (ഉദാample a ഷെഡ്യൂൾഡ് റിസീവ് അല്ലെങ്കിൽ ഷെഡ്യൂൾഡ് ട്രാൻസ്മിറ്റ്). റേഡിയോ പ്രവർത്തനങ്ങൾ ആണ്
അവരുടെ പാരാമീറ്ററുകൾ അടിസ്ഥാനമാക്കി ഭാവിയിൽ ക്യൂവിൽ നിർത്തുകയും പിന്നീട് സേവനം ചെയ്യുകയും ചെയ്യുന്നു. റേഡിയോ ഓപ്പറേഷൻ ആരംഭിക്കാൻ സമയമാകുമ്പോൾ ഷെഡ്യൂളർ ഒരു മത്സര പരിപാടി നിലവിലുണ്ടോ ഇല്ലയോ എന്നും പ്രവർത്തനം വൈകാൻ കഴിയുമോ ഇല്ലയോ എന്നും പരിശോധിക്കുന്നു. ഷെഡ്യൂളറിന് ഇവൻ്റ് പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, അത് ഉയർന്ന ലെയറിലേക്ക് ഫലം നൽകുന്നു, അത് പുതിയ പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് വീണ്ടും ശ്രമിക്കാം.
റേഡിയോ പ്രവർത്തനം ആരംഭിച്ചുകഴിഞ്ഞാൽ, മുമ്പത്തെ പ്രവർത്തനത്തിൻ്റെ ഫലങ്ങളെ അടിസ്ഥാനമാക്കി അനുബന്ധ സ്റ്റാക്കിന് ഷെഡ്യൂളർക്ക് അധിക പ്രവർത്തനങ്ങൾ അയയ്ക്കാൻ കഴിയും (ഉദാ.ampഒരു എസികെക്കായി കാത്തിരിക്കുന്നു). ഓരോ ഓപ്പറേഷൻ അല്ലെങ്കിൽ പ്രവർത്തനങ്ങളുടെ ക്രമം അവസാനിക്കുമ്പോൾ, സ്റ്റാക്ക് റേഡിയോയുടെ ഉപയോഗം നൽകണം.
റേഡിയോ പ്രവർത്തനങ്ങൾ
ഷെഡ്യൂളറിലെ ഓരോ ഇവൻ്റിനെയും റേഡിയോ ഓപ്പറേഷൻസ് എന്ന് വിളിക്കുന്ന ഘടകങ്ങളായി വിഭജിച്ചിരിക്കുന്നു, അവ ഒരു റേഡിയോ കോൺഫിഗറുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു.
എല്ലാ ഓപ്പറേഷനും ഒരു മുൻഗണനയുണ്ട്, സമയബന്ധിതമായി ഓവർലാപ്പ് ചെയ്യുന്ന ഉയർന്ന മുൻഗണനയുള്ള പ്രവർത്തനം ഷെഡ്യൂളർക്ക് ലഭിക്കുകയാണെങ്കിൽ അത് തടസ്സപ്പെടും. ഷെഡ്യൂൾ പാരാമീറ്ററുകൾ അടിസ്ഥാനമാക്കി പ്രവർത്തിപ്പിക്കാൻ കഴിയാത്ത താഴ്ന്ന മുൻഗണനയുള്ള റേഡിയോ പ്രവർത്തനങ്ങൾ പരാജയപ്പെടും, അവ വീണ്ടും ശ്രമിക്കേണ്ടത് ബന്ധപ്പെട്ട സ്റ്റാക്കിൻ്റെ ചുമതലയാണ്. ഷെഡ്യൂളർ സ്റ്റാക്കിൽ നിന്ന് ഒരു റേഡിയോ ഓപ്പറേഷൻ സജീവമായി പ്രവർത്തിപ്പിച്ചുകഴിഞ്ഞാൽ, അത് സ്വമേധയാ ലഭിക്കുന്നത് വരെ അല്ലെങ്കിൽ ഷെഡ്യൂളർക്ക് ഉയർന്ന മുൻഗണനയുള്ള റേഡിയോ ഓപ്പറേഷൻ ലഭിക്കുന്നതുവരെ അധിക റേഡിയോ പ്രവർത്തനങ്ങൾ അയയ്ക്കുന്നത് തുടരാം.
- പശ്ചാത്തല സ്വീകരണം
- ഷെഡ്യൂൾ ചെയ്ത സ്വീകരണം
- ഷെഡ്യൂൾ ചെയ്ത ട്രാൻസ്മിറ്റ്
ഓരോ സ്റ്റാക്കിനും റേഡിയോ ഷെഡ്യൂളറോട് ഒരു സമയം രണ്ട് റേഡിയോ പ്രവർത്തനങ്ങൾ (പശ്ചാത്തല സ്വീകരിക്കൽ, ഷെഡ്യൂൾ ചെയ്ത റിസീവ് അല്ലെങ്കിൽ ഷെഡ്യൂൾഡ് ട്രാൻസ്മിറ്റ്) ചെയ്യാൻ ആവശ്യപ്പെടാം:
ഓരോ പ്രവർത്തനത്തിനും ഇനിപ്പറയുന്ന പാരാമീറ്ററുകൾ ഉണ്ട്:
ആരംഭ സമയം | ഭാവിയിൽ ഏത് ഘട്ടത്തിലാണ് ഈ റേഡിയോ പ്രവർത്തനം പ്രവർത്തിക്കുക എന്നതിൻ്റെ സൂചന. ഇത് "ഇപ്പോൾ പ്രവർത്തിപ്പിക്കാം" അല്ലെങ്കിൽ ഭാവിയിൽ മൈക്രോസെക്കൻഡിൽ ചില മൂല്യങ്ങൾ ഉണ്ടാകാം. |
മുൻഗണന | പ്രവർത്തനത്തിൻ്റെ ആപേക്ഷിക മുൻഗണന സൂചിപ്പിക്കുന്ന ഒരു നമ്പർ. സ്ഥിരസ്ഥിതി ക്രമീകരണങ്ങൾ ഉപയോഗിക്കുമ്പോൾ, ബ്ലൂടൂത്ത് എൽഇ റേഡിയോ പ്രവർത്തനങ്ങൾക്ക് സിഗ്ബീ പ്രവർത്തനങ്ങളേക്കാൾ എപ്പോഴും മുൻഗണനയുണ്ട്. |
സ്ലിപ്പ് സമയം | ഇവൻ്റ് ആരംഭിക്കുന്ന സമയത്തിനപ്പുറം കാലതാമസം വരുത്താനും ഇപ്പോഴും സ്റ്റാക്കിന് സ്വീകാര്യമായിരിക്കാനുമുള്ള സമയം. ഇത് 0 ആയിരിക്കാം, ഈ സാഹചര്യത്തിൽ ഇവൻ്റ് സ്ലിപ്പ് ചെയ്യാൻ കഴിയില്ല. |
ഇടപാട് സമയം | ഇടപാട് പൂർത്തിയാക്കാൻ എടുക്കുന്ന ഏകദേശ സമയം. ട്രാൻസ്മിറ്റ് ഇവൻ്റുകൾ സാധാരണയായി കൂടുതൽ നന്നായി നിർവചിക്കപ്പെട്ട ഇടപാട് സമയമുണ്ട്, അതേസമയം സ്വീകരിക്കുന്ന ഇവൻ്റുകൾ പലപ്പോഴും അജ്ഞാതമാണ്. ഒരു ഇവൻ്റ് പ്രവർത്തിപ്പിക്കാൻ കഴിയുമോ എന്ന് നിർണ്ണയിക്കാൻ റേഡിയോ ഷെഡ്യൂളറെ സഹായിക്കുന്നതിന് ഇത് ഉപയോഗിക്കുന്നു. |
എക്സിക്യൂട്ട് ചെയ്യുന്ന പ്രവർത്തനത്തിന് അനുയോജ്യമായ ഈ വിവിധ പാരാമീറ്ററുകൾ സ്റ്റാക്ക് നിർവചിക്കുന്നു. ഉദാample, ബ്ലൂടൂത്ത് കണക്ഷൻ ഇവൻ്റുകൾ ഭാവിയിൽ പലപ്പോഴും ഷെഡ്യൂൾ ചെയ്യപ്പെടുന്നു, കൂടാതെ അനുവദനീയമായ സ്ലിപ്പ് ഇല്ല, എന്നാൽ Zigbee ട്രാൻസ്മിറ്റ് ഇവൻ്റുകൾ പലപ്പോഴും ഒരു ചെറിയ തുക വൈകുകയും പിന്നീട് നക്ഷത്രം നൽകുകയും ചെയ്യും.
റെയിൽ റേഡിയോ ഷെഡ്യൂളറുടെ വീക്ഷണകോണിൽ, ഷെഡ്യൂൾഡ് ട്രാൻസ്മിറ്റും ഷെഡ്യൂൾഡ് റിസീവും ഒരുപോലെയാണ്. അവ രണ്ടും റേഡിയോയുടെ ഉപയോഗം ആവശ്യമുള്ള ലളിതമായ പ്രവർത്തനങ്ങളാണ്, അതിനാൽ ഒരേസമയം എക്സിക്യൂട്ട് ചെയ്യാൻ കഴിയില്ല. ഒരു TX അല്ലെങ്കിൽ RX API എന്ന് വിളിക്കപ്പെടുന്ന RAIL API ലെയറിൽ മാത്രമേ ഐഫൻസ് പ്രകടമാകൂ.
പശ്ചാത്തല സ്വീകരണം
ഇത് മറ്റ് പ്രവർത്തനങ്ങളാൽ തടസ്സപ്പെടുത്താൻ ഉദ്ദേശിച്ചുള്ള ഒരു തുടർച്ചയായ സ്വീകരിക്കൽ മോഡാണ്, അവ പൂർത്തീകരിച്ചതിന് ശേഷം തിരികെ നൽകും. മറ്റ് പ്രവർത്തനങ്ങളെ അപേക്ഷിച്ച് പശ്ചാത്തല സ്വീകരണത്തിന് ഉയർന്ന മുൻഗണനയുണ്ടെങ്കിൽ, ആ റേഡിയോ പ്രവർത്തനങ്ങൾ ഷെഡ്യൂൾ ചെയ്യപ്പെടില്ല, പ്രവർത്തിക്കുകയുമില്ല. മുൻഗണന മാറ്റുന്നതിനോ സ്വമേധയാ വിളവെടുക്കുന്നതിനോ സ്റ്റാക്കുകളോ ആപ്ലിക്കേഷനോ ആണ്. വകുപ്പ് 5.1 കാണുക ഉദാampപശ്ചാത്തല സ്വീകരണം, യീൽഡ് റേഡിയോ, സ്റ്റേറ്റ് ട്രാൻസിഷൻ എന്നിവയുള്ള ലെസ്ampഷെഡ്യൂൾ ചെയ്ത പ്രവർത്തനങ്ങളുമായി പശ്ചാത്തലം എങ്ങനെ സംവദിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ.
cheduled സ്വീകരിക്കുക
ഇത് ഭാവിയിൽ ഒരു നിർദ്ദിഷ്ട ദൈർഘ്യമുള്ള ഒരു സ്വീകരിക്കലാണ്. ഓപ്പറേഷൻ ഷെഡ്യൂൾ ചെയ്യണോ വേണ്ടയോ എന്ന് തീരുമാനിക്കുന്നതിന് റേഡിയോ ഷെഡ്യൂളർ റേഡിയോ സ്വിച്ചിംഗ് സമയം കണക്കിലെടുക്കും. ഇത് ഷെഡ്യൂൾ ചെയ്യാൻ കഴിയുന്നില്ലെങ്കിൽ, കോളിംഗ് സ്റ്റാക്കിലേക്ക് ഷെഡ്യൂളർ ഒരു പരാജയ ഇവൻ്റ് അയയ്ക്കുന്നു. സ്റ്റാക്ക് സ്വമേധയാ ലഭിക്കുന്നത് വരെ റേഡിയോ പ്രവർത്തനം സ്വയമേവ നീട്ടുന്നു, അല്ലെങ്കിൽ ഷെഡ്യൂളർക്ക് ഉയർന്ന മുൻഗണനയുള്ള പ്രവർത്തനം ലഭിക്കുകയും അത് തടസ്സപ്പെടുത്തുകയും ചെയ്യും. സ്വീകരിക്കൽ വിപുലീകരിക്കുന്നത് ഉയർന്ന ലെവൽ പ്രോട്ടോക്കോളിൻ്റെ ആവശ്യകതകളെ അടിസ്ഥാനമാക്കി ഒരു റേഡിയോ പ്രവർത്തനം തുടരാൻ സ്റ്റാക്കിനെ അനുവദിക്കുന്നു, ഉദാഹരണത്തിന്ampലഭിച്ച ഡാറ്റയെ അടിസ്ഥാനമാക്കി ഒരു പ്രതികരണത്തിൻ്റെ സംപ്രേക്ഷണം.
ഷെഡ്യൂൾ ചെയ്ത ട്രാൻസ്മിറ്റ്
ഭാവിയിൽ ഏറ്റവും കുറഞ്ഞ ദൈർഘ്യമുള്ള ഒരു ട്രാൻസ്മിറ്റാണിത്. ഈ കുറഞ്ഞ കാലയളവിൽ പ്രതീക്ഷിക്കുന്ന ഫോളോ-ഓൺ ഇവൻ്റുകൾ ഉൾപ്പെടാം, ഉദാഹരണത്തിന്ampഒരു IEEE 802.15.4 ട്രാൻസ്മിറ്റിലേക്ക് ഒരു ACK നൽകുക. എന്നിരുന്നാലും, ഈ പ്രവർത്തനത്തിനുള്ള ഏറ്റവും കുറഞ്ഞ സമയം, ഏറ്റവും കുറഞ്ഞ കാലയളവിനപ്പുറം സമയം നീട്ടിയേക്കാവുന്ന അപ്രതീക്ഷിത സംഭവങ്ങൾ ഉൾപ്പെടുത്തേണ്ടതില്ല, ഉദാഹരണത്തിന്ampIEEE 802.15.4 ലെ CCA പരാജയങ്ങൾ മൂലമുള്ള പോരായ്മകൾ. ഓപ്പറേഷൻ ഷെഡ്യൂൾ ചെയ്യണോ വേണ്ടയോ എന്ന് തീരുമാനിക്കുന്നതിന് റേഡിയോ ഷെഡ്യൂളർ റേഡിയോ സ്വിച്ചിംഗ് സമയം കണക്കിലെടുക്കുന്നു. ഇത് ഷെഡ്യൂൾ ചെയ്യാൻ കഴിയുന്നില്ലെങ്കിൽ, കോളിംഗ് സ്റ്റാക്കിലേക്ക് ഷെഡ്യൂളർ ഒരു പരാജയ ഇവൻ്റ് അയയ്ക്കുന്നു.
റേഡിയോ കോൺഫിഗറേഷൻ
ഓരോ റേഡിയോ ഓപ്പറേഷനും ഒരു മുൻ നിർവചിച്ച റേഡിയോ കോൺഫിഗറുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു, അത് പ്രവർത്തനം നടത്താൻ ഉപയോഗിക്കേണ്ട ഹാർഡ്വെയറിൻ്റെ അവസ്ഥ നിർണ്ണയിക്കുന്നു. റേഡിയോ കോൺഫിഗറേഷനുകൾ സ്റ്റാക്കിൻ്റെ നിലവിലെ അവസ്ഥയുടെ ട്രാക്ക് സൂക്ഷിക്കുന്നു, അതുവഴി ഭാവിയിലെ റേഡിയോ പ്രവർത്തനങ്ങൾ അതേ റേഡിയോ പാരാമീറ്ററുകൾ ഉപയോഗിക്കും. റേഡിയോ കോൺഫിഗറേഷനുകൾ സജീവമോ പ്രവർത്തനരഹിതമോ ആകാം. സ്റ്റാക്ക് ഒരു സജീവ റേഡിയോ കോൺഫിഗറേഷൻ മാറ്റുകയാണെങ്കിൽ, ഹാർഡ്വെയർ കോൺഫിഗറേഷനിലും റെയിൽ ഉടനടി മാറ്റം വരുത്തുന്നു, ഉദാഹരണത്തിന്ampഒരു ചാനൽ മാറ്റുകയാണ്. റേഡിയോ കോൺഫിഗേഷൻ നിലവിൽ സജീവമല്ലെങ്കിൽ, അടുത്ത ഷെഡ്യൂൾ ചെയ്ത റേഡിയോ ഓപ്പറേഷൻ പുതിയ റേഡിയോ കോൺഫിഗറേഷൻ ഉപയോഗിക്കും.
മുൻഗണന
ഓരോ റേഡിയോ ഓപ്പറേഷനും ഒരു മുൻഗണനയുണ്ട്, അത് ഒന്നിലധികം പ്രവർത്തനങ്ങൾക്കിടയിൽ ടൈമിംഗ് ഓവർലാപ്പ് ഉണ്ടെങ്കിൽ ഏത് ഓപ്പറേഷൻ എക്സിക്യൂട്ട് ചെയ്യണമെന്ന് ഷെഡ്യൂളർക്ക് സൂചിപ്പിക്കുന്നു. ഷെഡ്യൂളർ 0 യുടെ മുൻഗണനയെ ഉയർന്ന മുൻഗണനയായും 255 ഏറ്റവും കുറഞ്ഞ മുൻഗണനയായും കണക്കാക്കുന്നു. റേഡിയോ ഷെഡ്യൂളർ, ഫിസിക്കൽ ra rdware ആക്സസ്സുചെയ്യുന്നതിന് ഉയർന്ന മുൻഗണനയുള്ള ചുമതലയെ അനുവദിക്കും. മിക്ക ടാസ്ക്കുകളിലും നിയന്ത്രണം റേഡിയോ ഷെഡ്യൂളറിലേക്ക് തിരികെ നൽകും, എന്നാൽ ഉയർന്ന മുൻഗണനയുള്ള ഒരു ടാസ്ക് സജീവമാകുമ്പോൾ പശ്ചാത്തല സ്വീകരണം പോലുള്ള ജോലികൾ തടസ്സപ്പെടും.
ഡ്യൂട്ടി സൈക്കിൾ പരമാവധിയാക്കാനും ഒരു ജനറിക് യൂസ് കെയ്സിനായി ഡ്രോപ്പ് ചെയ്ത കണക്ഷനുകൾ ഒഴിവാക്കാനും എങ്ങനെ സഹകരിക്കാം എന്നതിനെക്കുറിച്ചുള്ള സിലിക്കൺ ലാബ്സിൻ്റെ വിശകലനത്തെ അടിസ്ഥാനമാക്കി സ്റ്റാക്കുകൾ ഓരോന്നിനും ഒരു ഡിഫോൾട്ട് മുൻഗണനകളുണ്ട്. നിർദ്ദിഷ്ട ഉപയോഗ കേസുകൾക്ക് വ്യത്യസ്ത ആവശ്യങ്ങൾ ഉണ്ടായിരിക്കാം. മുൻഗണനകൾ താഴെ പറയുന്നവയാണ്, ഉയർന്നത് മുതൽ താഴെ വരെ
- ബ്ലൂടൂത്ത് LE ഷെഡ്യൂൾഡ് ട്രാൻസ്മിറ്റ്
- ബ്ലൂടൂത്ത് LE ഷെഡ്യൂൾ ചെയ്ത സ്വീകരണം
- മറ്റ് പ്രോട്ടോക്കോൾ ഷെഡ്യൂൾ ചെയ്ത ട്രാൻസ്മിറ്റ്
- മറ്റ് പ്രോട്ടോക്കോൾ പശ്ചാത്തലം സ്വീകരിക്കുക
ഈ മുൻഗണനകൾ ആപ്ലിക്കേഷൻ അസാധുവാക്കുകയോ മാറ്റുകയോ ചെയ്യാം. ഏത് സാഹചര്യത്തിലാണ് അവ മാറ്റേണ്ടതെന്ന് തീരുമാനിക്കേണ്ടത് അപേക്ഷയാണ്. വിഭാഗം 4.2 802.15.4 റെയിൽ മുൻഗണനയും വിഭാഗം 6.1 ബ്ലൂടൂത്ത് മുൻഗണനകളും അവയുടെ നിർദ്ദിഷ്ട സംഭവങ്ങളുടെ മുൻഗണനകളെക്കുറിച്ചുള്ള കൂടുതൽ വിശദാംശങ്ങൾ ഉൾക്കൊള്ളുന്നു.
സ്ലിപ്പ് സമയം
എല്ലാ റേഡിയോ ഓപ്പറേഷനും ഒരു "സ്ലിപ്പ് സമയം" അല്ലെങ്കിൽ പരമാവധി ആരംഭ സമയം ഉണ്ടായിരിക്കണം, അതായത് അഭ്യർത്ഥിച്ച ആരംഭ സമയത്ത് പ്രവർത്തനം ആരംഭിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ ഭാവിയിലെ ഏറ്റവും കൂടുതൽ സമയം. ഒരേ സമയം സംഭവിക്കുന്ന ഉയർന്ന മുൻഗണനയുള്ള ഇവൻ്റുകൾ അല്ലെങ്കിൽ അവരുടെ പ്രതീക്ഷിക്കുന്ന കാലയളവ് കവിയുന്ന ഉയർന്ന മുൻഗണന ഇവൻ്റുകൾ എന്നിവയിൽ പ്രവർത്തിക്കാൻ ഇത് ഷെഡ്യൂളറെ അനുവദിക്കുന്നു. സ്ലിപ്പ് സമയം എന്തായിരിക്കുമെന്ന് പ്രോട്ടോക്കോൾ സാധാരണയായി നിർദ്ദേശിക്കുന്നു, എന്നാൽ റേഡിയോ ഷെഡ്യൂളറിന് ഇത് ഒരു ഓപ്പറേഷൻ അടിസ്ഥാനത്തിൽ കൈകാര്യം ചെയ്യാൻ കഴിയും, ചില ഇവൻ്റുകൾ സ്ലിപ്പ് ചെയ്യാൻ ഒരു സ്റ്റാക്കിനെ അനുവദിക്കുന്നു എന്നാൽ മറ്റുള്ളവയല്ല. പൊതുവേ, IEEE02.15.4-ന് കൂടുതൽ സ്ലിപ്പ് സമയമുണ്ട്, ബ്ലൂടൂത്ത് LE-യ്ക്ക് കുറഞ്ഞ സ്ലിപ്പ് സമയമുണ്ട്.
വരുമാനം
റേഡിയോ പ്രവർത്തനങ്ങളുടെ ഒരു ശ്രേണി സജീവമായി പ്രവർത്തിപ്പിച്ചുകഴിഞ്ഞാൽ, പ്രത്യേക സന്ദേശ കൈമാറ്റത്തിനായി സ്റ്റാക്കിന് കൂടുതലൊന്നും ചെയ്യാനില്ലാത്തതുവരെ പ്രാരംഭ പ്രവർത്തനത്തെ വിപുലീകരിക്കുന്ന പ്രവർത്തനങ്ങൾ സ്റ്റാക്ക് ചേർക്കുന്നത് തുടരാം. പശ്ചാത്തലം സ്വീകരിക്കുന്നില്ലെങ്കിൽ ഒരു സ്റ്റാക്ക് സ്വമേധയാ വിളവ് നൽകണം. ഒരു സ്റ്റാക്ക് വഴങ്ങുന്നില്ലെങ്കിൽ, അത് അതിൻ്റെ റേഡിയോ പ്രവർത്തനം വിപുലീകരിക്കുന്നത് തുടരും, കൂടാതെ കുറഞ്ഞ മുൻഗണനയുള്ള റേഡിയോ പ്രവർത്തനങ്ങൾ ആ റേഡിയോ ഓപ്പറേഷൻ അഭ്യർത്ഥിച്ച അനുബന്ധ സ്റ്റാക്കിലേക്ക് വീണ്ടും പരാജയത്തിന് കാരണമാകും. ഉയർന്ന മുൻഗണനയുള്ള പ്രവർത്തനത്തിന് നിലവിൽ പ്രവർത്തിക്കുന്ന, കുറഞ്ഞ മുൻഗണനയുള്ള റേഡിയോ പ്രവർത്തനത്തെ തടസ്സപ്പെടുത്താൻ കഴിയില്ല. വിഭാഗം 5.1 കാണുക ഉദാampപശ്ചാത്തല സ്വീകരണം, യീൽഡ് റേഡിയോ, സ്റ്റേറ്റ് ട്രാൻസിഷൻ എന്നിവയുള്ള ലെസ്ampറേഡിയോ വ്യക്തമായി നൽകേണ്ട സാഹചര്യങ്ങൾ കുറവാണ്.
ഒരു റേഡിയോ പ്രവർത്തനത്തെ തടസ്സപ്പെടുത്തുന്നു
ഉയർന്ന മുൻഗണനാ പ്രവർത്തനവുമായി വൈരുദ്ധ്യമുണ്ടായാൽ ഷെഡ്യൂൾ ചെയ്ത റേഡിയോ പ്രവർത്തനം തടസ്സപ്പെട്ടേക്കാം. ഇനിപ്പറയുന്ന രണ്ട് സാഹചര്യങ്ങളിൽ ഇത് സംഭവിക്കാം:
- ഒരു ഷെഡ്യൂൾ ചെയ്ത റേഡിയോ ഓപ്പറേഷന് പ്രതീക്ഷിച്ചതിലും കൂടുതൽ സമയമെടുക്കും, അനുബന്ധ സ്റ്റാക്ക് ലഭിക്കില്ല, ഉയർന്ന മുൻഗണനയുള്ള റേഡിയോ ഓപ്പറേഷൻ ആരംഭിക്കണം.
- ഉയർന്ന മുൻഗണനയുള്ള ഒരു റേഡിയോ ഓപ്പറേഷൻ ഭാവിയിൽ സംഭവിക്കാൻ ഷെഡ്യൂൾ ചെയ്തിരിക്കുന്നു, കൂടാതെ ഇതിനകം ഷെഡ്യൂൾ ചെയ്തിരിക്കുന്ന കുറഞ്ഞ മുൻഗണനയുള്ള പ്രവർത്തനവുമായി വൈരുദ്ധ്യങ്ങളും
ദീർഘകാല റേഡിയോ പ്രവർത്തനങ്ങൾ
ചില ദീർഘകാല റേഡിയോ പ്രവർത്തനങ്ങൾ ഉൽപ്പന്നത്തിൻ്റെ ശരിയായ പ്രവർത്തനത്തിൽ വലിയ സ്വാധീനം ചെലുത്തും. പ്രോട്ടോക്കോളുകൾക്കിടയിൽ അപ്ലിക്കേഷന് ഈ പ്രവർത്തനങ്ങൾ ഏകോപിപ്പിക്കേണ്ടതുണ്ട്. ആപ്ലിക്കേഷൻ ഇല്ലെങ്കിൽ റേഡിയോ ഷെഡ്യൂളർ മുൻഗണനകൾക്ക് മുൻഗണന നൽകും. ഉദാample, ഒരു IEEE 802.15.4 എനർജി സ്കാനിന് ആവശ്യമായ ഊർജ്ജ റീഡിംഗുകൾ ശേഖരിക്കുന്നതിന് റേഡിയോ തുടരേണ്ടതുണ്ട്. ആപ്ലിക്കേഷൻ ശരിയായി പ്രവർത്തനങ്ങളെ ഏകോപിപ്പിക്കുന്നില്ലെങ്കിൽ, ഉയർന്ന മുൻഗണനയുള്ള ബ്ലൂടൂത്ത് പ്രവർത്തനം കാരണം സ്കാൻ അകാലത്തിൽ തടസ്സപ്പെട്ടേക്കാം.
റേഡിയോ ഷെഡ്യൂളർ എക്സിampലെസ്
എല്ലാവരും മുൻampബ്ലൂടൂത്ത് LE, Zigbee എന്നിവ ഉപയോഗിക്കുന്നു, എന്നാൽ മറ്റ് ബ്ലൂടൂത്ത്/802.15.4 കോമ്പിനേഷനുകൾക്ക് തത്ത്വങ്ങൾ ബാധകമാണ്.
കുറഞ്ഞ മുൻഗണനയുള്ള Zigbee പശ്ചാത്തലം സ്വീകരിക്കുന്ന പ്രവർത്തനത്തിലൂടെയാണ് ഷെഡ്യൂളർ ആരംഭിക്കുന്നത്. അജ്ഞാതമായ സമയങ്ങളിൽ IEEE 802.15.4 പാക്കറ്റുകൾ ലഭിക്കേണ്ട എല്ലായ്പ്പോഴും ഓൺ റൂട്ടറിനെ ഇത് പ്രതിനിധീകരിക്കുന്നു. ഒരു ബ്ലൂടൂത്ത് LE കണക്ഷനും സജീവമാണ്, കൂടാതെ ഓരോ 30 എംഎസിലും സ്വീകരിക്കാൻ സ്റ്റാക്ക് തയ്യാറാകേണ്ടതുണ്ട്. ബ്ലൂടൂത്ത് LE സ്റ്റാക്ക് കണക്ഷൻ്റെ റിഡിക്റ്റബിൾ സ്വഭാവം കാരണം ഇത് മുൻകൂട്ടി ഷെഡ്യൂൾ ചെയ്തേക്കാം.
മുൻഗണനാ ഷെഡ്യൂളിംഗ്
ഇത് ഒരു അടിസ്ഥാന മുൻകൂർ നൽകുന്നുampവ്യത്യസ്ത റേഡിയോ ഓപ്പറേഷനുകളുടെ മുൻഗണനകൾ വിലയിരുത്തുന്നതിനുള്ള le.
ഒരു പാക്കറ്റ് അയക്കണമെന്ന് സിഗ്ബി സ്റ്റാക്ക് തീരുമാനിക്കുന്നു. ഇത് ഒരു ഓൺ-ഡിമാൻഡ് ഇവൻ്റായി ഇത് ചെയ്തേക്കാം, അതായത് ഷെഡ്യൂളറെ മുൻകൂട്ടി അറിയിക്കാതെ തന്നെ ഇപ്പോൾ ഒരു പാക്കറ്റ് അയയ്ക്കണമെന്ന് സ്റ്റാക്ക് തീരുമാനിക്കുന്നു. ബ്ലൂടൂത്ത് എൽഇ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിന് വിരുദ്ധമാണ് ഇത്, ഷെഡ്യൂൾ ചെയ്ത പ്രവർത്തനങ്ങൾ വളരെ മുമ്പേ അറിയാവുന്നതായിരിക്കും. Zigbee TX 1 റേഡിയോ ഓപ്പറേഷൻ നടത്താനും ഭാവിയിൽ ഉയർന്ന മുൻഗണനയുള്ള ബ്ലൂടൂത്ത് LE റിസപ്ഷൻ ഇവൻ്റിന് സേവനം നൽകാനും കഴിയുമെന്ന് ഷെഡ്യൂളർ വിലയിരുത്തുന്നു. അതിനാൽ ട്രാൻസ്മിറ്റ് ഇവൻ്റ് സംഭവിക്കാൻ ഷെഡ്യൂളർ അനുവദിക്കുന്നു. Zigbee സ്റ്റാക്ക് ഈ ട്രാൻസ്മിറ്റ് പ്രവർത്തനത്തിൻ്റെ എല്ലാ ഭാഗങ്ങളും നിർവഹിക്കുന്നു (ഒരു MAC ആക്കിനായി കാത്തിരിക്കുന്നു), തുടർന്ന് സ്വമേധയാ വിളവ് നൽകുന്നു. Zigbee ട്രാൻസ്മിറ്റ് റേഡിയോ പ്രവർത്തനത്തിൻ്റെ ഏകദേശ ഇടപാട് സമയം വീണ്ടും ശ്രമങ്ങൾ ഉൾപ്പെടുന്നില്ല.
ഇതിൽ മുൻample, ബ്ലൂടൂത്ത് LE, ഭാവിയിൽ ലഭിക്കാൻ ഇതിനകം ഷെഡ്യൂൾ ചെയ്തിട്ടുണ്ട്, കൂടാതെ Zigbee സ്റ്റാക്ക് സംപ്രേഷണം ചെയ്യാൻ ആഗ്രഹിക്കുന്നു. ആദ്യത്തെ Zigbee TX 1 റേഡിയോ പ്രവർത്തനത്തിന് ബ്ലൂടൂത്ത് LE RX 1 റേഡിയോ ഓപ്പറേഷന് മുമ്പ് മതിയായ സമയമുണ്ട്, അതിനാൽ ഷെഡ്യൂളർ സ്റ്റാക്കിനെ പ്രവർത്തനം നടത്താൻ അനുവദിക്കുന്നു. പിന്നീട്, Zigbee സ്റ്റാക്ക് Zigbee TX 2 ഷെഡ്യൂൾ ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ, ഉയർന്ന മുൻഗണനയുള്ള Bluetooth LE RX 2 ഇവൻ്റിന് മുമ്പ് മതിയായ സമയം ഇല്ലെന്ന് ഷെഡ്യൂളർ നിർണ്ണയിക്കുന്നു. എന്നിരുന്നാലും, ഈ പ്രവർത്തനം അതിൻ്റെ ആരംഭ സമയം തെറ്റിയേക്കാമെന്ന് സിഗ്ബീ സ്റ്റാക്ക് സൂചിപ്പിച്ചു. ബ്ലൂടൂത്ത് LE റേഡിയോ ഓപ്പറേഷൻ്റെ പ്രതീക്ഷിക്കുന്ന കാലയളവ് കണക്കിലെടുക്കുമ്പോൾ, ആ ഇവൻ്റിന് ശേഷം Zigbee പ്രവർത്തനം ആരംഭിക്കാമെന്നും ഇപ്പോഴും Zigbee സ്റ്റാക്ക് സൂചിപ്പിക്കുന്ന സ്ലിപ്പ് സമയത്തിനുള്ളിൽ ആയിരിക്കുമെന്നും റേഡിയോ ഷെഡ്യൂളർ നിർണ്ണയിക്കുന്നു.
എല്ലാം പ്രതീക്ഷിച്ചതുപോലെ നടക്കുകയാണെങ്കിൽ, ഷെഡ്യൂളിംഗ് കാരണം പരാജയങ്ങളൊന്നും കൂടാതെ Zigbee ട്രാൻസ്മിറ്റ് ഓപ്പറേഷൻ അതിൻ്റെ ആദ്യ ശ്രമം നടത്തും.
മുൻഗണനാ തടസ്സം Example
ഈ മുൻampതാഴ്ന്ന മുൻഗണനയെ തടസ്സപ്പെടുത്തുന്ന ഉയർന്ന മുൻഗണനയുള്ള പ്രവർത്തനത്തെ le ചിത്രീകരിക്കുന്നു.
ഈ മുൻampമുമ്പത്തെ മുൻ പോലെ തന്നെ le ആരംഭിക്കുന്നുample. സിഗ്ബി, ബ്ലൂടൂത്ത് LE എന്നിവയ്ക്ക് ഒരു റേഡിയോ ഓപ്പറേഷൻ ഉണ്ട്, അത് കൂട്ടിയിടിക്കാതെ ഷെഡ്യൂൾ ചെയ്തിരിക്കുന്നു
പിന്നീട്, Zigbee TX 2 ഇവൻ്റിനായി മറ്റൊരു പാക്കറ്റ് അയയ്ക്കണമെന്ന് സിഗ്ബി സ്റ്റാക്ക് തീരുമാനിക്കുന്നു. Zigbee TX 2 ഇവൻ്റ് എടുക്കേണ്ട ഏറ്റവും കുറഞ്ഞ സമയത്തെ അടിസ്ഥാനമാക്കി, ഈ ഇവൻ്റ് ഷെഡ്യൂൾ ചെയ്യാനും ബ്ലൂടൂത്ത് LE RX 2 ഇവൻ്റ് പിന്നീട് സേവനം നൽകാനും കഴിയുമെന്ന് ഷെഡ്യൂളർ നിർണ്ണയിക്കുന്നു. എന്നിരുന്നാലും, ഒരു നീണ്ട റാൻഡം ബാക്ക്ഓഫ് കാരണം Zigbee TX 2 ഇവൻ്റ് പ്രതീക്ഷിച്ചതിലും കൂടുതൽ സമയമെടുക്കുന്നു, അത് കൃത്യസമയത്ത് വഴങ്ങുന്നില്ല. ഇത് ഇവൻ്റിനെ ഉയർന്ന മുൻഗണനയുള്ള റാഡ് പെറേഷനുമായി കൂട്ടിയിടിക്കുന്നതിന് കാരണമാകുന്നു, അതിനാൽ റേഡിയോ ഷെഡ്യൂളർ സിഗ്ബീ ഇവൻ്റിനെ തടസ്സപ്പെടുത്തുകയും ഉയർന്ന ലെവൽ സ്റ്റാക്കിലേക്ക് ഒരു പരാജയം തിരികെ നൽകുകയും ചെയ്യുന്നു. Th ബ്ലൂടൂത്ത് LE ഇവൻ്റ് സാധാരണയായി സംഭവിക്കുന്നു, അത് പൂർത്തിയാകുമ്പോൾ അത് സ്വമേധയാ കുറഞ്ഞ മുൻഗണനയുള്ള പ്രവർത്തനങ്ങൾക്ക് വഴങ്ങുന്നു.
റേഡിയോ ഷെഡ്യൂളറിൽ നിന്ന് പരാജയം ലഭിക്കുമ്പോൾ, സിഗ്ബി സ്റ്റാക്ക് ഉടൻ തന്നെ MAC സന്ദേശം വീണ്ടും പരീക്ഷിക്കാൻ ശ്രമിക്കുന്നു. ഇത് ഓപ്പറേഷൻ ഷെഡ്യൂൾ ചെയ്യുകയും ഒരു സ്ലിപ്പ് സമയം ഉൾപ്പെടുത്തുകയും ചെയ്യുന്നു. ഈ ഘട്ടത്തിൽ ബ്ലൂടൂത്ത് LE സ്റ്റാക്കിന് റേഡിയോയേക്കാൾ മുൻഗണനയുണ്ട്, അതിനാൽ പ്രവർത്തനം ഇതുവരെ ആരംഭിക്കാൻ കഴിയില്ല, പക്ഷേ ഷെഡ്യൂളർ പുതിയ റേഡിയോ പ്രവർത്തനം അംഗീകരിക്കുന്നു. ബ്ലൂടൂത്ത് LE സ്റ്റാക്ക് അതിൻ്റെ ഷെഡ്യൂൾ ചെയ്ത സ്വീകരണം പൂർത്തിയാക്കി റേഡിയോ നൽകുന്നു. പ്രാരംഭ പ്രവർത്തനത്തിൻ്റെ സ്ലിപ്പ് സമയത്തിനുള്ളിൽ തന്നെ ആയതിനാൽ, ഷെഡ്യൂളർ Zigbee ട്രാൻസ്മിറ്റ് പ്രവർത്തനം സംഭവിക്കാൻ ട്രിഗർ ചെയ്യുന്നു. ട്രാൻസ്മിറ്റ് പൂർത്തിയാക്കിയ ശേഷം ഷെഡ്യൂളർ ബാക്ക്ഗ്രൗണ്ട് സ്വീകരിക്കുന്ന പ്രവർത്തനത്തിലേക്ക് മടങ്ങുന്നു.
വിപുലീകരിച്ചിരിക്കുന്ന ഉയർന്ന മുൻഗണനാ പ്രവർത്തനം
ഈ മുൻampഉയർന്ന മുൻഗണനയുള്ള പ്രവർത്തനത്തിന് യഥാർത്ഥത്തിൽ പ്രതീക്ഷിച്ചതിലും കൂടുതൽ സമയമെടുക്കുകയും കുറഞ്ഞ മുൻഗണനയുള്ള പ്രവർത്തനത്തിന് അതിൻ്റെ അവസരം നഷ്ടപ്പെടുകയും ചെയ്യുമ്പോൾ എന്താണ് സംഭവിക്കുന്നതെന്ന് le കാണിക്കുന്നു
ഈ സാഹചര്യത്തിൽ, Bluetooth LE-ന് നിലവിൽ നടക്കുന്ന ഒരു ഷെഡ്യൂൾഡ് റിസീവുണ്ട്. സിഗ്ബി ഒരു പാക്കറ്റ് അയയ്ക്കാൻ തീരുമാനിക്കുന്നു, പക്ഷേ അത് ഇപ്പോൾ പ്രവർത്തിപ്പിക്കാൻ കഴിയില്ല. Zigbee ഇവൻ്റിൻ്റെ സ്ലിപ്പ് സമയം അവസാനിക്കുന്നതിന് മുമ്പ് Bluetooth LE ഇവൻ്റ് പൂർത്തിയാകുമെന്ന അനുമാനത്തിൽ ഷെഡ്യൂളർ പ്രവർത്തനം അംഗീകരിക്കുന്നു. എന്നിരുന്നാലും, ഉപകരണങ്ങൾക്കിടയിൽ അധിക പാക്കറ്റുകൾ അയയ്ക്കുന്നതിനാൽ ബ്ലൂടൂത്ത് LE ഇവൻ്റ് ദീർഘനേരം നീണ്ടുനിൽക്കുന്നു. ബ്ലൂടൂത്ത് LE ഓപ്പറേഷന് മുൻഗണന ഉള്ളതിനാൽ Zigbee പ്രവർത്തനം ഒടുവിൽ സ്ലിപ്പ് ഇല്ലാതായി. ഒരു പിശക് സ്റ്റാക്കിലേക്ക് തിരികെ വന്നു. പാക്കറ്റ് വീണ്ടും ട്രാൻസ്മിറ്റ് ചെയ്യാൻ സിഗ്ബി തീരുമാനിക്കുന്നു. വീണ്ടും, സിഗ്ബീ സ്റ്റാക്ക് സൂചിപ്പിക്കുന്നത് പ്രവർത്തനം ഇപ്പോൾ ആരംഭിക്കണമെന്നും എന്നാൽ ഭാവിയിലേക്ക് വഴുതിവീണേക്കാം. റേഡിയോ കോൺഫിഗറേഷൻ മാറ്റുന്നതിൻ്റെ മധ്യത്തിലാണ് ഷെഡ്യൂളർ, അതിനാൽ ഇതിന് ഉടൻ പ്രവർത്തനം ആരംഭിക്കാൻ കഴിയില്ല. പകരം, ഇത് റേഡിയോ ഓപ്പറേഷൻ ആരംഭിക്കുന്ന സമയം ഒരു ചെറിയ തുക സ്ലിപ്പ് ചെയ്യുകയും തുടർന്ന് പ്രവർത്തനം നടപ്പിലാക്കുകയും ചെയ്യുന്നു.
തടസ്സങ്ങളില്ലാതെ ഉയർന്ന മുൻഗണനയുള്ള പ്രവർത്തനം
ഇതിൽ മുൻample റേഡിയോ ഷെഡ്യൂളർ ബ്ലൂടൂത്ത് LE പെരിഫറൽ ആയി പ്രവർത്തിക്കുന്ന ഒരു നോഡിലാണ് പ്രവർത്തിക്കുന്നത്, കൂടാതെ ആ നോഡിന് വ്യത്യസ്ത സെൻട്രൽ ഉപകരണങ്ങളിലേക്ക് നിരവധി കണക്ഷനുകൾ ഉണ്ട്. പ്രക്ഷേപണം ചെയ്യപ്പെടുന്ന ഒരു ആനുകാലിക പരസ്യ ബീക്കണും ഇതിലുണ്ട്. ഈ ഇവൻ്റുകൾ ഫലത്തിൽ പുറകിൽ നിന്ന് സംഭവിക്കുകയും സിഗ്ബി റേഡിയോ കോൺഫിഗറിലേക്ക് മടങ്ങാൻ മതിയായ സമയം അനുവദിക്കാതിരിക്കുകയും ചെയ്യുന്ന ഒരു കേസ് ഇനിപ്പറയുന്ന ചിത്രം കാണിക്കുന്നു. അതിനാൽ ഇത് സിഗ്ബീ സ്റ്റാക്ക് ഉള്ള ഒരു കാലഘട്ടം സൃഷ്ടിക്കും
സ്ലിപ്പ് സമയം കൊണ്ട് പോലും സംപ്രേക്ഷണം ചെയ്യാൻ കഴിയില്ല.
ഒരു ട്രാൻസ്മിറ്റ് റേഡിയോ ഓപ്പറേഷൻ ഷെഡ്യൂൾ ചെയ്യാൻ സിഗ്ബി ഷെഡ്യൂളറോട് ആവശ്യപ്പെടുന്നു. ഷെഡ്യൂൾ ചെയ്ത ഉയർന്ന മുൻഗണനാ പ്രവർത്തനങ്ങൾ കാരണം ഇവൻ്റ് പരാജയപ്പെടുമെന്ന് ഷെഡ്യൂളർക്ക് അറിയാമെങ്കിലും, ഷെഡ്യൂൾ ചെയ്ത ഇവൻ്റ് അത് ഇപ്പോഴും അംഗീകരിക്കുന്നു. രണ്ട് കാരണങ്ങളാലാണ് ഇത് ചെയ്യുന്നത്. ആദ്യം, സാഹചര്യങ്ങൾ മാറുകയും ഇവൻ്റ് നടപ്പിലാക്കുകയും ചെയ്യാം. രണ്ടാമതായി, റേഡിയോ ഷെഡ്യൂളറിന് മുകളിൽ ഇരിക്കുന്ന സ്റ്റാക്ക് പ്രവർത്തനം വീണ്ടും ശ്രമിക്കാൻ ശ്രമിച്ചേക്കാം. പരാജയപ്പെട്ട ഷെഡ്യൂളിംഗിൻ്റെ ഫലം ഉടനടി തിരികെ നൽകിയാൽ, സമയം കടന്നുപോയിട്ടില്ലാത്തതിനാൽ വീണ്ടും ശ്രമിക്കാനുള്ള സ്റ്റാക്കിൻ്റെ ശ്രമം വിജയിക്കാൻ സാധ്യതയില്ല. പകരം, ഇവൻ്റ് ക്യൂവിൽ നിർത്തി സ്ലിപ്പ് സമയം അവസാനിച്ചതിന് ശേഷം പരാജയം തിരികെ നൽകുന്നതിലൂടെ, വരാനിരിക്കുന്ന റേഡിയോ പ്രവർത്തനങ്ങളുടെ സെറ്റ് വ്യത്യസ്തമായതിനാൽ വീണ്ടും ശ്രമിക്കുന്നതിന് (സ്വന്തം സ്ലിപ്പ് സമയത്തോടെ) വിജയിക്കാനുള്ള മികച്ച അവസരമുണ്ട്.
ഉയർന്ന മുൻഗണനയുള്ള പ്രവർത്തനം പ്രവർത്തിക്കുമ്പോൾ സ്വീകരിക്കുക
ഈ മുൻampബ്ലൂടൂത്ത് LE സജീവമായിരിക്കുമ്പോൾ എന്താണ് സംഭവിക്കുന്നതെന്ന് le വ്യക്തമാക്കുന്നു, കൂടാതെ കുറഞ്ഞ മുൻഗണനയുള്ള പ്രവർത്തനത്തിന് ഡാറ്റ ലഭിക്കുകയും ചെയ്യും.
ആദ്യ സന്ദർഭത്തിൽ, ഒരു IEEE 802.15.4 സന്ദേശം അയയ്ക്കുമ്പോൾ, ബ്ലൂടൂത്ത് LE സ്റ്റാക്ക് സജീവമായി സ്വീകരിക്കുന്നതിന് റേഡിയോ ഉപയോഗിക്കുമ്പോൾ, സന്ദേശം സ്വീകരിക്കുന്നതിന് Zigbee സ്റ്റാക്ക് ഓൺലൈനിലായിരിക്കില്ല. എന്നിരുന്നാലും, സിഗ്ബീ സന്ദേശം അയച്ചയാൾ മിക്ക കേസുകളിലും വീണ്ടും ശ്രമിക്കും, കൂടാതെ ബാക്ക്ഓഫുകളും മറ്റ് സമയ മാറ്റങ്ങളും ഉപയോഗിച്ച് കൂട്ടിയിടിക്കാൻ സാധ്യതയില്ലാത്ത മറ്റൊരു ഉയർന്ന മുൻഗണന ഷെഡ്യൂൾ ചെയ്ത ബ്ലൂടൂത്ത് സ്വീകരിക്കുന്ന ഇവൻ്റുകളുമായി വൈരുദ്ധ്യമുണ്ടാകില്ല. സിഗ്ബീ സന്ദേശം വിജയകരമായി ലഭിച്ചു
രണ്ടാമത്തെ കേസ് കാണിക്കുന്നത്, സജീവമായ ഒരു സ്വീകരണത്തിൻ്റെ കാര്യത്തിൽ, Zigbee സ്റ്റാക്ക് ഇപ്പോഴും തടസ്സപ്പെട്ടേക്കാം, സന്ദേശം സ്വീകരിക്കില്ല (അല്ലെങ്കിൽ ACK). വിജയകരമായ ആശയവിനിമയം, ഈ സന്ദേശം വീണ്ടും അയയ്ക്കുന്നതിനും ഡൈനാമിക് മൾട്ടിപ്രോട്ടോക്കോൾ ഉപകരണം സന്ദേശം സ്വീകരിക്കുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുന്നതിനും MAC-ലോ ഉയർന്ന ലെയറിലോ വീണ്ടും ശ്രമിക്കുന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.
സജീവമായി സ്വീകരിക്കുന്നത് തടസ്സപ്പെടുത്തണമോ വേണ്ടയോ എന്നതിനെക്കുറിച്ചുള്ള പരിഗണനകൾ ഉണ്ടാകാമെങ്കിലും, ആ തീരുമാനം എടുക്കാൻ ഷെഡ്യൂളർക്ക് ബുദ്ധിമുട്ടാണ്. പൊതുവേ, പ്രോട്ടോക്കോളുകളുടെ ദൃഢത, തടസ്സങ്ങളുണ്ടായാലും സന്ദേശങ്ങൾ വിജയകരമായി സ്വീകരിക്കുന്നതിന് അനുവദിക്കണം.
802.15.4-അടിസ്ഥാന സ്റ്റാക്ക് ഉപയോഗിച്ച് മൾട്ടിപ്രോട്ടോക്കോൾ നടപ്പിലാക്കുന്നു
ഒരു മൾട്ടിപ്രോട്ടോക്കോൾ ആപ്ലിക്കേഷനുകളുടെ ഭാഗമായി Zigbee അല്ലെങ്കിൽ Connect പോലുള്ള 802.15.4-അടിസ്ഥാന സ്റ്റാക്ക് നടപ്പിലാക്കുന്നതിനെക്കുറിച്ചുള്ള പൊതുവായ വിവരങ്ങൾ ഈ അധ്യായം നൽകുന്നു. എങ്ങനെ കോൺഫിഗർ ചെയ്യാം എന്നതിനെക്കുറിച്ചുള്ള പ്രത്യേകതകൾക്കായി 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 മുൻഗണനയിൽ നിന്ന് വ്യത്യസ്തമാണെങ്കിൽ, ഒരു സമന്വയ വാക്ക് കണ്ടെത്തുമ്പോഴെല്ലാം സ്വീകരിക്കുന്ന മുൻഗണന ഉയർത്തും, ആ പാക്കറ്റ് ഫിൽട്ടർ ചെയ്യുകയോ പൂർത്തിയാക്കുകയോ ചെയ്താൽ മാത്രമേ അത് താഴ്ത്തുകയുള്ളൂ.
മുൻഗണനകൾ സന്തുലിതമാക്കൽ
വിഭാഗം 6.1 ബ്ലൂടൂത്ത് മുൻഗണനകളിൽ വിശദീകരിച്ചതുപോലെ, ബ്ലൂടൂത്ത് മുൻഗണനാ ശ്രേണി ഡിഫോൾട്ടായി RAIL മുൻഗണനാ ശ്രേണി 16 - 32-ലേക്ക് മാപ്പ് ചെയ്തിരിക്കുന്നു. പൊതുവേ, Bluetooth കുറഞ്ഞ മുൻഗണന (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 സ്റ്റാക്കിന് മാത്രമേ ബാധകമാകൂ. സിലിക്കൺ ലാബ്സ് കണക്റ്റിന് ഇതുവരെ മുൻഗണനകൾ മാറ്റാൻ ആവശ്യമായ 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 API-കൾക്കൊപ്പം എങ്ങനെ പ്രവർത്തിക്കാം എന്നതിനെക്കുറിച്ചുള്ള വിശദാംശങ്ങൾ ഇത് വാഗ്ദാനം ചെയ്യുന്നു.
Exampപശ്ചാത്തല സ്വീകരണം, യീൽഡ് റേഡിയോ, സ്റ്റേറ്റ് ട്രാൻസിഷൻ എന്നിവയുള്ള ലെസ്
RAIL മൾട്ടിപ്രോട്ടോക്കോൾ മുൻഗണനാ സംവിധാനത്തിൻ്റെ അടിസ്ഥാനകാര്യങ്ങൾ വളരെ ലളിതമാണ്: ഉയർന്ന മുൻഗണനയുള്ള (അതായത്, എണ്ണത്തിൽ ചെറുത്) ഒരു റേഡിയോ ഇവൻ്റ് എല്ലായ്പ്പോഴും കുറഞ്ഞ മുൻഗണനയുള്ള മറ്റേതെങ്കിലും റേഡിയോ ഇവൻ്റുകൾ തട്ടിയെടുക്കും. എന്നിരുന്നാലും, RAIL_StartRx() പോലുള്ള സംസ്ഥാന സംക്രമണങ്ങളും API-കളും പരിഗണിക്കുമ്പോൾ ഈ വിഷയം കൂടുതൽ സങ്കീർണമാകുന്നു, ഇത് റേഡിയോയെ അനിശ്ചിതകാലത്തേക്ക് ഒരു നിശ്ചിത അവസ്ഥയിലേക്ക് കൊണ്ടുവരുന്നു. ഈ വിഭാഗം ചില ചിത്രീകരണങ്ങൾ നൽകുന്നുampഈ സമയ-പരിധിയില്ലാത്ത അവസ്ഥകൾ എങ്ങനെ കൈകാര്യം ചെയ്യപ്പെടുന്നുവെന്നും അവ നിയന്ത്രിക്കാൻ RAIL_YieldRadio() പോലുള്ള API-കൾ ആപ്ലിക്കേഷൻ ലെയറിന് എങ്ങനെ ഉപയോഗിക്കാമെന്നും കാണിച്ചുതരാം. മുൻamples ഇനിപ്പറയുന്നവയാണ്:
- ഒരൊറ്റ പ്രോട്ടോക്കോൾ ഉള്ള സംസ്ഥാന സംക്രമണങ്ങൾ
- രണ്ട് പ്രോട്ടോക്കോളുകളുള്ള സംസ്ഥാന പരിവർത്തനങ്ങൾ
- രണ്ട് പ്രോട്ടോക്കോളുകളുള്ള സംസ്ഥാന പരിവർത്തനങ്ങളും ഏകതാനമായി വർദ്ധിച്ചുവരുന്ന മുൻഗണനകളും
ഇതിൽ മുൻamples, RAIL_StartTx() എന്നത് പശ്ചാത്തല RX-നെ തടസ്സപ്പെടുത്തുന്ന TX ഇവൻ്റിൻ്റെ ഉറവിടമാണ്. എന്നിരുന്നാലും, ഇവ മുൻampRAIL_StartRx() ഒഴികെയുള്ള ഏതൊരു റേഡിയോ API-യ്ക്കും les ബാധകമാണ്. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, മുൻampപശ്ചാത്തലം RX അല്ലാത്ത ഒരു റേഡിയോ ഇവൻ്റ് ആരംഭിക്കുന്ന ഏതൊരു API-നും les ബാധകമാണ്
ഈ മുൻ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 ഉപയോഗിക്കുന്നു). RAIL_StartRx() എന്നതിലേക്കുള്ള പ്രാരംഭ കോളോടെ RX-ൽ റേഡിയോ ആരംഭിക്കുന്നു, തുടർന്ന് RAIL_StartTx() എന്നതിലേക്കുള്ള ഉയർന്ന മുൻഗണനയുള്ള കോളോടെ TX-ലേക്ക് നീങ്ങുന്നു. സംപ്രേക്ഷണം പൂർത്തിയാക്കിയ ശേഷം, RAIL_SetTxTransitions() വ്യക്തമാക്കിയ അവസ്ഥയിലേക്ക് റേഡിയോ സംക്രമണം ചെയ്യുന്നു എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്, കൂടാതെ RAIL_YieldRadio() വിളിക്കുന്നത് വരെ TX-ൻ്റെ അതേ മുൻഗണനയിലും ചാനലിലും അത് അനിശ്ചിതകാലത്തേക്ക് സംസ്ഥാനത്ത് തുടരും. അതിനുശേഷം, തുടക്കത്തിൽ വ്യക്തമാക്കിയ മുൻഗണനയും ചാനലും ഉപയോഗിച്ച് റേഡിയോ RX-ലേക്ക് മടങ്ങുന്നു.
റേഡിയോ സജീവമായി നൽകേണ്ടതിൻ്റെ ആവശ്യകത, അങ്ങനെ RAIL_YieldRadio() API പ്രധാനമായും ACK'ing കാരണം ആവശ്യമായിരുന്നു. ഡിസൈൻ തത്വശാസ്ത്രം, കാരണം TX ഉം സ്വീകരിച്ച ACK ഉം ആണ് viewed ഒരേ ഇടപാടിൻ്റെ ഭാഗമായി, ഒരു നോഡ് പ്രക്ഷേപണം ചെയ്യുകയും ഒരു ACK പ്രതീക്ഷിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, അതിന് RX-ലേക്ക് പരിവർത്തനം ചെയ്യാനും യഥാർത്ഥ TX-ൻ്റെ അതേ പ്രവർത്തനത്തിൻ്റെ (അതിനാൽ അതേ മുൻഗണന) ഭാഗമായി ACK കേൾക്കുന്നത് തുടരാനും കഴിയും. പൊതുവേ, എന്നിരുന്നാലും, ഒരു ACK ആവശ്യമുണ്ടോ ഇല്ലയോ എന്ന് RAIL-ന് സ്വന്തമായി അറിയാൻ കഴിയില്ല. ഇത് പാക്കറ്റ് ഉള്ളടക്കങ്ങൾ അല്ലെങ്കിൽ മറ്റ് ആപ്ലിക്കേഷൻ ലോജിക് പോലുള്ള മറ്റ് ഘടകങ്ങളെ ആശ്രയിച്ചിരിക്കും, അതിനാൽ RAIL_ConfigAutoAck() ഉപയോഗിച്ച് ACK'ing കോൺഫിഗർ ചെയ്തിട്ടുണ്ടോ എന്ന് പരിശോധിച്ച് ലളിതമായി നിർണ്ണയിക്കാൻ കഴിയില്ല. അതിനാൽ, ഒരു റേഡിയോ ഇടപാട് പൂർത്തിയാകുമ്പോൾ വിവേചനാധികാരം അവശേഷിക്കുന്നു tication/stack.
ഒരു ACK ആവശ്യമില്ലെങ്കിൽ, RAIL_EVENT_TX_PACKET_SENT ഇവൻ്റ് കൈകാര്യം ചെയ്യുന്നതിൻ്റെ ഭാഗമായി RAIL_YieldRadio()-ലേക്ക് വിളിക്കാൻ സിലിക്കൺ ലാബ്സ് ശുപാർശ ചെയ്യുന്നു. ഇത് ചെയ്യുന്നത് മുകളിലെ ചിത്രത്തിലെ ഗ്രീൻ ലൈൻ ഇൻ്ററപ്റ്റ് ലേറ്റൻസി ടൈം വരെ കുറയ്ക്കുന്നതിന് കാരണമാകുന്നു. ആപ്ലിക്കേഷൻ ഒരു ACK പ്രതീക്ഷിക്കുന്നുവെങ്കിൽ, ACK ലഭിക്കുമ്പോഴോ അല്ലെങ്കിൽ സമയപരിധി കഴിഞ്ഞതായി കണക്കാക്കുമ്പോഴോ RAIL_YieldRadio() വിളിക്കണം.
രണ്ട് പ്രോട്ടോക്കോളുകളുള്ള സംസ്ഥാന പരിവർത്തനങ്ങൾ
ഈ സാഹചര്യം TX-ന് ശേഷമുള്ള സംസ്ഥാന പരിവർത്തനങ്ങളെ സംബന്ധിച്ച ആദ്യ സാഹചര്യത്തിന് സമാനമാണ്, എന്നാൽ മറ്റൊരു പ്രോട്ടോക്കോൾ അവതരിപ്പിക്കുന്നു.
ഈ സാഹചര്യത്തിൽ, TX ഇടപാട് സമയത്ത് എപ്പോൾ വേണമെങ്കിലും RAIL_StartRx() വിളിക്കാൻ കഴിയുമെന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. അതിൻ്റെ മുൻഗണന TX-ൻ്റെ മുൻഗണനയേക്കാൾ കുറവോ തുല്യമോ ആണെങ്കിൽ, പ്രോട്ടോക്കോൾ A-യിൽ ആപ്ലിക്കേഷൻ _Yield Radio() എന്ന് വിളിക്കുന്നത് വരെ RX പ്രാബല്യത്തിൽ വരില്ല. TX സമയത്ത് RAIL_StartRx() വിളിക്കുമ്പോൾ, RX എന്നത് കേവലം കൈകാര്യം ചെയ്യേണ്ട സംഭവങ്ങളുടെ ക്യൂവിലേക്ക് ചേർത്തു.
മറ്റൊരു പ്രധാന കാര്യം, പ്രോട്ടോക്കോൾ A-യിലെ RAIL_YieldRadio() പ്രോട്ടോക്കോൾ A-യിലെ TX-ൽ നിന്ന് പ്രോട്ടോക്കോൾ B-യിലെ RX-ലേക്ക് മാറുമെങ്കിലും, B-യിലെ RX-ൽ നിന്ന് Protocol A-ലെ RX-ലേക്ക് പരിവർത്തനം ചെയ്യാൻ പ്രോട്ടോക്കോൾ B-യിലെ ഒരു RAIL_Idle() ആവശ്യമാണ്. ഇവൻ്റ് ഒരിക്കലും അവസാനിച്ചിട്ടില്ലാത്തതിനാൽ, പശ്ചാത്തല RX-കൾ യഥാർത്ഥത്തിൽ നൽകാനാവില്ല എന്നതാണ് ഇവിടെയുള്ള തത്വശാസ്ത്രം. RAIL_Idle() എന്നതിലേക്കുള്ള കോൾ ഉപയോഗിച്ച് പശ്ചാത്തല RX നിർത്തുക എന്നതാണ് പുറത്തുകടക്കാനുള്ള ഏക മാർഗം.
രണ്ട് പ്രോട്ടോക്കോളുകളുള്ള സംസ്ഥാന പരിവർത്തനങ്ങളും ഏകതാനമായി വർദ്ധിച്ചുവരുന്ന മുൻഗണനയും
പ്രോട്ടോക്കോൾ എയിലെ RAIL_StartTx()-ലേക്കുള്ള കോളിനേക്കാൾ ഉയർന്ന മുൻഗണനയാണ് പ്രോട്ടോക്കോൾ B-യിലെ RAIL_StartRx() എന്നതിലേക്കുള്ള കോൾ ഒഴികെയുള്ള അവസാന സാഹചര്യം മുമ്പത്തേതിന് സമാനമാണ്.
ഈ സാഹചര്യത്തിൽ, രണ്ടാമത്തെ RAIL_StartRx() ൻ്റെ മുൻഗണന RAIL_StartTx() എന്നതിലേക്കുള്ള കോളിൻ്റെ മുൻഗണനയേക്കാൾ കൂടുതലായതിനാൽ, RAIL_YieldRadio() ലേക്ക് ഇനി ഒരു കോൾ ആവശ്യമില്ല. രണ്ടാമത്തെ RAIL_StartRx() ന് ഉയർന്ന മുൻഗണനയുള്ളതിനാൽ, അത് RAIL_StartTx() ഇവൻ്റിനെ തട്ടിയെടുക്കുകയും റേഡിയോയുടെ നിയന്ത്രണം ഏറ്റെടുക്കുകയും സംസ്ഥാനത്ത് നിന്ന് TX ഇവൻ്റ് നീക്കം ചെയ്യുകയും ചെയ്യുന്നു. എപ്പോൾ വേണമെങ്കിലും പ്രോട്ടോക്കോൾ B-യിലെ RX-ൽ, RAIL_Idle() മുമ്പത്തെ മുൻ പോലെ, പ്രോട്ടോക്കോൾ A-യിലെ RX-ലേക്ക് മടങ്ങാൻ വിളിക്കാവുന്നതാണ്.ample.
ഇവിടെ ശ്രദ്ധിക്കുക, പ്രോട്ടോക്കോൾ ബിയുടെ RX-ൽ ആപ്ലിക്കേഷൻ RAIL_Idle() എന്ന് വിളിക്കുമ്പോൾ, പ്രോട്ടോക്കോൾ A-യുടെ TX ട്രാൻസിഷനിലേക്ക് ആപ്ലിക്കേഷൻ തിരികെ വരില്ല. പകരം, അത് പശ്ചാത്തലമായ RX-ലേക്ക് പോകുന്നു, പ്രോട്ടോക്കോളിൽ ആപ്ലിക്കേഷൻ ഒരിക്കലും RAIL_Idle() എന്ന് വിളിച്ചിട്ടില്ലെങ്കിലും. എയുടെ 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 അല്ല, നിഷ്ക്രിയാവസ്ഥയിലേക്ക് മടങ്ങാൻ ഇടയാക്കും.
ബ്ലൂടൂത്ത് ഉപയോഗിച്ച് മൾട്ടിപ്രോട്ടോക്കോൾ നടപ്പിലാക്കുന്നു
റെയിൽ/ബ്ലൂടൂത്ത് ലൈറ്റ്/സ്വിച്ച് മൾട്ടിപ്രോട്ടോക്കോൾ എങ്ങനെ എന്നതിനെക്കുറിച്ചുള്ള വിശദാംശങ്ങൾക്ക്ample നടപ്പിലാക്കി, കൂടാതെ RAIL-ൽ നിങ്ങളുടെ സ്വന്തം പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് ഒരു മൾട്ടിപ്രോട്ടോകോൾ ആപ്ലിക്കേഷൻ വികസിപ്പിക്കുന്നതിനെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾക്ക്, AN1134 കാണുക: ബ്ലൂടൂത്തിനൊപ്പം ഡൈനാമിക് മൾട്ടിപ്രോട്ടോകോൾ ഡെവലപ്മെൻ്റ്, GSDK v2.x-ലെ RAIL-ലെ പ്രൊപ്രൈറ്ററി പ്രോട്ടോക്കോളുകൾ അല്ലെങ്കിൽ AN1269 Dynamic Multiprotocol Development with Bluetooth and Proto GSDK v3.x-ലും ഉയർന്നതിലും.
ബ്ലൂടൂത്ത് മുൻഗണനകൾ
വ്യത്യസ്ത പ്രവർത്തന തരങ്ങൾക്കായി സ്ഥിരമായി നിർവചിക്കപ്പെട്ട മുൻഗണനകളുള്ള സിഗ്ബിക്ക് വിരുദ്ധമായി, മുൻഗണനാ സ്പെക്ട്രത്തിൻ്റെ ഒരു നിശ്ചിത മേഖലയിലേക്ക് എല്ലാ ടാസ്ക്കുകളും നൽകുന്നതിന് ബ്ലൂടൂത്ത് ഒരു ശ്രേണിയും ഓഫ്സെറ്റ് സമീപനവും ഉപയോഗിക്കുന്നു.
ഇതിൽ മുൻamp0 മുതൽ 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 പ്രതികരണ സ്ലോട്ട് കാലതാമസം അവസാനിക്കുന്നു |
ഇത് കൈകാര്യം ചെയ്യുന്നതിനായി ബ്ലൂടൂത്ത് ഷെഡ്യൂളർ, അതിൻ്റെ മുൻഗണനകൾ റെയിൽ റേഡിയോ ഷെഡ്യൂളറിലേക്ക് മാപ്പ് ചെയ്യുന്നു, ഓരോ ടാസ്ക്കിനും ഇനിപ്പറയുന്ന പാരാമീറ്ററുകൾ കണക്കിലെടുക്കുന്നു:
- ആരംഭ സമയം
- കുറഞ്ഞ സമയം
- പരമാവധി സമയം
- മുൻഗണന
ആരംഭ സമയം നീക്കിയാൽ, മൊത്തം റണ്ണിംഗ് സമയം യഥാക്രമം കുറയുന്നു, അതായത് സ്ലാക്ക് കുറയുന്നു. കൂടാതെ മുൻഗണനകൾ ചലനാത്മകമായി ക്രമീകരിക്കാവുന്നതാണ്.
കണക്ഷനുകൾ
കണക്ഷനുകൾക്ക് താരതമ്യേന ഉയർന്ന മുൻഗണനയുണ്ട്. ഒരു കണക്ഷൻ്റെ ആരംഭ സമയം നീക്കാൻ കഴിയില്ല.
ബ്ലൂടൂത്ത് ഷെഡ്യൂളർ മുൻഗണന ചലനാത്മകമായി വർദ്ധിപ്പിക്കുന്നു, കണക്ഷൻ മേൽനോട്ട സമയപരിധിയോട് അടുക്കുകയും അതിനടുത്തുള്ള പരമാവധി മുൻഗണനയിൽ എത്തുകയും ചെയ്യുന്നു. TX ക്യൂവിലുള്ള TX പാക്കറ്റും ഒരു കണക്ഷൻ്റെ മുൻഗണന വർദ്ധിപ്പിക്കുന്നു.
കണക്ഷൻ തുടക്കം
കണക്ഷൻ ആരംഭിക്കുന്നത് ഒരു കണക്ഷൻ സ്ഥാപിക്കുന്നതിന് ടാർഗെറ്റ് ഉപകരണത്തിൽ നിന്നുള്ള പരസ്യങ്ങൾ സ്കാൻ ചെയ്യുന്നു. കൂടുതൽ ശക്തമായ കണക്ഷൻ സ്ഥാപിക്കാൻ അനുവദിക്കുന്നതിന് സ്കാനറുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഇതിന് ഉയർന്ന മുൻഗണനയുണ്ട്.
പരസ്യങ്ങൾ
സ്ഥിരസ്ഥിതിയായി പരസ്യങ്ങൾക്ക് മുൻഗണന കുറവാണ്, അവയുടെ ആരംഭ പോയിൻ്റ് നീക്കാൻ കഴിയും. ആരംഭ സമയവും പരമാവധി സമയവും നിർവചിക്കുന്നത് പരസ്യ ഇടവേളയാണ്.
ഒരു പരസ്യം അയയ്ക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, പരസ്യങ്ങളുടെ മുൻഗണന സാവധാനത്തിൽ വർദ്ധിക്കുകയും ഒരു പരസ്യം വിജയകരമായി അയച്ചുകഴിഞ്ഞാൽ അത് പുനഃക്രമീകരിക്കുകയും ചെയ്യും.
സ്കാനർ
ഡിഫോൾട്ടായി, ഈ ജോലികൾക്ക് ഏറ്റവും കുറഞ്ഞ മുൻഗണനയുണ്ട്. സ്കാനിംഗ് ഇടവേളയും വിൻഡോ വലുപ്പവും അനുസരിച്ചാണ് ആരംഭം, ഏറ്റവും കുറഞ്ഞത്, പരമാവധി സമയം എന്നിവ നിർവചിച്ചിരിക്കുന്നത്. ഉയർന്ന മുൻഗണനയുള്ള ടാസ്ക് തടസ്സപ്പെടുമ്പോഴും സ്കാനിംഗ് തുടരാം. ഇത് സംഭവിക്കുകയാണെങ്കിൽ, ഓരോ സ്കാനിംഗ് ഇടവേളയിലും ആവശ്യമുള്ള സ്കാൻ വിൻഡോ വലുപ്പം എത്തിയെന്ന് ഉറപ്പാക്കാൻ സ്കാൻ സമയം ശേഖരിക്കപ്പെടും.
പരസ്യങ്ങൾ പോലെ, ആവശ്യമുള്ള സ്കാൻ ഇടവേളയോ വിൻഡോ വലുപ്പമോ മുമ്പ് നിറവേറ്റാൻ കഴിയാത്ത സാഹചര്യത്തിൽ മുൻഗണന വർദ്ധിപ്പിക്കും. സ്കാൻ ഇടവേളയോ വിൻഡോ വലുപ്പമോ എത്തിക്കഴിഞ്ഞാൽ അത് അതിൻ്റെ പ്രാരംഭ മുൻഗണനയിലേക്ക് പുനഃസജ്ജമാക്കും.
പ്രതികരണങ്ങളോടുകൂടിയ ആനുകാലിക പരസ്യം (PAwR)
പ്രതികരണങ്ങൾക്കൊപ്പം ആനുകാലിക പരസ്യം അയയ്ക്കുന്നതിന് മറ്റെല്ലാ ബ്ലൂടൂത്ത് ടാസ്ക്കുകളേക്കാളും ഡിഫോൾട്ടായി ഉയർന്ന മുൻഗണനയുണ്ട്, തുടർന്ന് ഒരു ഇലക്ട്രോണിക് ഷെൽഫ് ലേബൽ (ESL) നെറ്റ്വർക്കിൽ സമന്വയം നിലനിർത്തുന്നതിന് PAwR-ൽ പ്രതികരണങ്ങൾ സ്വീകരിക്കുന്നു.
ടാസ്ക് ഷെഡ്യൂളിംഗ് തുടർച്ചയായി രണ്ടുതവണ പരാജയപ്പെടുകയാണെങ്കിൽ PAwR ടാസ്ക് മുൻഗണന വർദ്ധിപ്പിക്കും. മുൻഗണനാ ശ്രേണിയുടെ 1/6-ൽ ഒന്നുകിൽ വർധിപ്പിക്കും, അല്ലെങ്കിൽ പരമാവധി മുൻഗണനയിൽ എത്തുന്നതുവരെ കുറഞ്ഞത് ഒന്ന് കൂടി. വിജയകരമായ ഷെഡ്യൂളിങ്ങിന് ശേഷം ടാസ്ക് മുൻഗണന ഏറ്റവും കുറഞ്ഞതിലേക്ക് പുനഃസജ്ജമാക്കുന്നു. രണ്ട് ദിശകളിലുമുള്ള PAwR പരസ്യദാതാവിനും സിൻക്രൊണൈസറിനും ഒരേ നടപടിക്രമം ബാധകമാണ്
Exampബ്ലൂടൂത്ത് ഷെഡ്യൂളർ ഓപ്പറേഷൻ്റെ le
ഈ മുൻampബ്ലൂടൂത്ത് ഷെഡ്യൂളർ എങ്ങനെ മൂന്ന് കണക്ഷൻ ടാസ്ക്കുകളും ഒരു പരസ്യ ടാസ്ക്കുകളും ഷെഡ്യൂൾ ചെയ്യുമെന്ന് le വ്യക്തമാക്കുന്നു, ഓരോന്നിനും വ്യത്യസ്ത മുൻഗണനകൾ ഉണ്ട്. ഇനിപ്പറയുന്ന കണക്കുകളിൽ ചാരനിറത്തിലുള്ള ഭാഗം ഒരു ടാസ്ക്കിന് ആവശ്യമായ ഏറ്റവും കുറഞ്ഞ റൺടൈമിനെയും നീല ഭാഗം ടാസ്ക്കിന് ഉപയോഗിക്കാനാകുന്ന പരമാവധി റൺടൈമിനെയും, വഴക്കമുള്ളതാണെങ്കിൽ, ടാസ്ക് നീക്കാൻ കഴിയുന്ന പ്രദേശത്തെയും സൂചിപ്പിക്കുന്നു. പ്രാരംഭ സജ്ജീകരണത്തിൽ ഇനിപ്പറയുന്ന ചിത്രം കാണിക്കുന്നു
താഴെ കാണിച്ചിരിക്കുന്നതുപോലെ, ഉയർന്ന മുൻഗണനയുള്ള ടാസ്ക്കുകളൊന്നും ഓവർലാപ്പ് ചെയ്യാത്തതിനാൽ പ്രവർത്തിപ്പിക്കേണ്ട ആദ്യത്തെ ടാസ്ക് Conn1 ആണ്.
ഉയർന്ന മുൻഗണനയുള്ള Conn1-നൊപ്പം Adv2 ഓവർലാപ്പ് ചെയ്യുന്നു. 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 ബ്ലൂടൂത്ത് മുൻഗണനകളിലും ഈ വിഭാഗത്തിലും ലിസ്റ്റ് ചെയ്തിരിക്കുന്നതുപോലെ സ്റ്റാക്ക് അതിൻ്റെ ഡിഫോൾട്ട് മുൻഗണനകൾ ഉപയോഗിക്കുന്നു.
പോയിൻ്റർ അസാധുവാണെങ്കിൽ, അത് ചുവടെ നിർവചിച്ചിരിക്കുന്ന മുൻഗണന ക്രമീകരണങ്ങളുടെ ഘടനയിലേക്ക് പോയിൻ്റ് ചെയ്യണം:
sandman, Cinemax, adv_min, adv_min, cinnamon, conn_max, intimin, intima എന്നീ പാരാമീറ്ററുകൾ യഥാക്രമം സ്കാനിംഗ്, പരസ്യം, കണക്ഷനുകൾ, ഇനീഷ്യേഷനുകൾ എന്നിവയ്ക്കുള്ള ഏറ്റവും കുറഞ്ഞതും കൂടിയതുമായ മുൻഗണനകൾ നിർവ്വചിക്കുന്നു. മുകളിലെ 6.1.1 സ്കാനറിലേക്കുള്ള 6.1.4 കണക്ഷനുകളിൽ വിവരിച്ചിരിക്കുന്നതുപോലെ മുൻഗണനകൾ മിനിമം, പരമാവധി അതിരുകൾക്കിടയിൽ നീങ്ങും.
RAIL മാപ്പിംഗ് പാരാമീറ്ററുകൾ, rail_mapping_offset, rail_mapping_range, ബ്ലൂടൂത്ത് ലിങ്ക് ലെയർ മുൻഗണനകൾ ആഗോള റെയിൽ റേഡിയോ ഷെഡ്യൂളർ മുൻഗണനകളിലേക്ക് മാപ്പ് ചെയ്യുന്നതെങ്ങനെയെന്ന് നിർവ്വചിക്കുന്നു. ഈ മൂല്യങ്ങളുടെ മാപ്പിംഗ് 6.1 ബ്ലൂടൂത്ത് മുൻഗണനകളിൽ കാണാൻ കഴിയും. rail_mapping_offset, rail_mapping_range എന്നിവയുടെ സ്ഥിരസ്ഥിതി 16 ആണ്.
സ്കാനിംഗിൻ്റെയും പരസ്യത്തിൻ്റെയും മുൻഗണന ചലനാത്മകമായി മാറുമ്പോൾ adv_step, സ്കാൻ സ്റ്റെപ്പ് പാരാമീറ്ററുകൾ സ്റ്റെപ്പ് വലുപ്പം നിർവചിക്കുന്നു. അവസാനമായി, pawr_tx_min, pawr_tx_min, pawr_tx_min, pawr_rx_max എന്നീ പരാമീറ്ററുകൾ പാര പരസ്യദാതാവിനും സിൻക്രൊണൈസർ TX, RX ഇവൻ്റുകൾക്കും ഓരോ ഉപഇവൻ്റിനുമുള്ള മുൻഗണനാ ശ്രേണി നിർവചിക്കുന്നു.
IoT പോർട്ട്ഫോളിയോ
www.silabs.com/products
ഗുണനിലവാരം
www.silabs.com/qualitty
പിന്തുണയും കമ്മ്യൂണിറ്റിയും
www.silabs.com/community
നിരാകരണം
സിലിക്കൺ ലാബ്സ് ഉൽപ്പന്നങ്ങൾ ഉപയോഗിക്കുന്നതോ ഉപയോഗിക്കാൻ ഉദ്ദേശിക്കുന്നതോ ആയ സിസ്റ്റം, സോഫ്റ്റ്വെയർ നടപ്പിലാക്കുന്നവർക്കായി ലഭ്യമായ എല്ലാ പെരിഫറലുകളുടെയും മൊഡ്യൂളുകളുടെയും ഏറ്റവും പുതിയതും കൃത്യവും ആഴത്തിലുള്ളതുമായ ഡോക്യുമെൻ്റേഷൻ ഉപഭോക്താക്കൾക്ക് നൽകാൻ സിലിക്കൺ ലാബ്സ് ഉദ്ദേശിക്കുന്നു. സ്വഭാവ ഡാറ്റ, ലഭ്യമായ മൊഡ്യൂളുകളും പെരിഫറലുകളും, മെമ്മറി വലുപ്പങ്ങളും മെമ്മറി വിലാസങ്ങളും ഓരോന്നിനെയും പരാമർശിക്കുന്നു
നിർദ്ദിഷ്ട ഉപകരണം, നൽകിയിരിക്കുന്ന "സാധാരണ" പാരാമീറ്ററുകൾ എന്നിവ വ്യത്യസ്ത ആപ്ലിക്കേഷനുകളിൽ വ്യത്യാസപ്പെടാം. അപേക്ഷ മുൻampഇവിടെ വിവരിച്ചിരിക്കുന്നത് ചിത്രീകരണ ആവശ്യങ്ങൾക്ക് മാത്രമുള്ളതാണ്. ഉൽപ്പന്ന വിവരങ്ങൾ, സ്പെസിഫിക്കേഷനുകൾ, വിവരണങ്ങൾ എന്നിവയിൽ കൂടുതൽ അറിയിപ്പ് കൂടാതെ മാറ്റങ്ങൾ വരുത്താനുള്ള അവകാശം സിലിക്കൺ ലാബിൽ നിക്ഷിപ്തമാണ്, കൂടാതെ ഉൾപ്പെടുത്തിയ വിവരങ്ങളുടെ കൃത്യതയോ പൂർണ്ണതയോ സംബന്ധിച്ച് വാറൻ്റി നൽകുന്നില്ല. മുൻകൂർ അറിയിപ്പ് കൂടാതെ, സുരക്ഷാ അല്ലെങ്കിൽ വിശ്വാസ്യത കാരണങ്ങളാൽ നിർമ്മാണ പ്രക്രിയയിൽ സിലിക്കൺ ലാബ്സ് ഉൽപ്പന്ന ഫേംവെയർ അപ്ഡേറ്റ് ചെയ്തേക്കാം. അത്തരം മാറ്റങ്ങൾ ഉൽപ്പന്നത്തിൻ്റെ സവിശേഷതകളെയോ പ്രകടനത്തെയോ മാറ്റില്ല. ഈ ഡോക്യുമെൻ്റിൽ നൽകിയിരിക്കുന്ന വിവരങ്ങളുടെ ഉപയോഗത്തിൻ്റെ അനന്തരഫലങ്ങൾക്ക് സിലിക്കൺ ലാബുകൾക്ക് ഒരു ബാധ്യതയുമില്ല. ഏതെങ്കിലും ഇൻ്റഗ്രേറ്റഡ് സർക്യൂട്ടുകൾ രൂപകൽപ്പന ചെയ്യുന്നതിനോ നിർമ്മിക്കുന്നതിനോ ഉള്ള ഏതെങ്കിലും ലൈസൻസ് ഈ പ്രമാണം സൂചിപ്പിക്കുന്നില്ല അല്ലെങ്കിൽ വ്യക്തമായി നൽകുന്നില്ല. ഉൽപ്പന്നങ്ങൾ ഏതെങ്കിലും FDA ക്ലാസ് III ഉപകരണങ്ങളിൽ, FDA പ്രീമാർക്കറ്റ് അംഗീകാരം ആവശ്യമുള്ള ആപ്ലിക്കേഷനുകൾ അല്ലെങ്കിൽ സിലിക്കൺ ലാബുകളുടെ പ്രത്യേക രേഖാമൂലമുള്ള സമ്മതമില്ലാതെ ലൈഫ് സപ്പോർട്ട് സിസ്റ്റങ്ങൾക്കുള്ളിൽ ഉപയോഗിക്കുന്നതിന് രൂപകൽപ്പന ചെയ്യുകയോ അംഗീകരിക്കുകയോ ചെയ്തിട്ടില്ല. ഒരു "ലൈഫ് സപ്പോർട്ട് സിസ്റ്റം" എന്നത് ജീവൻ കൂടാതെ/അല്ലെങ്കിൽ ആരോഗ്യത്തെ പിന്തുണയ്ക്കുന്നതിനോ നിലനിർത്തുന്നതിനോ ഉദ്ദേശിച്ചുള്ള ഏതെങ്കിലും ഉൽപ്പന്നമോ സംവിധാനമോ ആണ്, അത് പരാജയപ്പെടുകയാണെങ്കിൽ, കാര്യമായ വ്യക്തിഗത പരിക്കോ മരണമോ ഉണ്ടാക്കുമെന്ന് ന്യായമായും പ്രതീക്ഷിക്കാം. സിലിക്കൺ ലാബ്സ് ഉൽപ്പന്നങ്ങൾ സൈനിക ആപ്ലിക്കേഷനുകൾക്കായി രൂപകൽപ്പന ചെയ്യുകയോ അംഗീകരിക്കുകയോ ചെയ്തിട്ടില്ല. ആണവ, ജൈവ അല്ലെങ്കിൽ രാസായുധങ്ങൾ, അല്ലെങ്കിൽ അത്തരം ആയുധങ്ങൾ എത്തിക്കാൻ കഴിവുള്ള മിസൈലുകൾ എന്നിവയുൾപ്പെടെ (എന്നാൽ അതിൽ മാത്രം പരിമിതപ്പെടുന്നില്ല) വൻ നശീകരണ ആയുധങ്ങളിൽ സിലിക്കൺ ലാബ്സ് ഉൽപ്പന്നങ്ങൾ ഒരു സാഹചര്യത്തിലും ഉപയോഗിക്കരുത്. സിലിക്കൺ ലാബ്സ് എല്ലാ എക്സ്പ്രസ്സ്, ഇൻപ്ലൈഡ് വാറൻ്റികളും നിരാകരിക്കുന്നു, അത്തരം അനധികൃത ആപ്ലിക്കേഷനുകളിൽ സിലിക്കൺ ലാബ്സ് ഉൽപ്പന്നത്തിൻ്റെ ഉപയോഗവുമായി ബന്ധപ്പെട്ട ഏതെങ്കിലും പരിക്കുകൾക്കോ കേടുപാടുകൾക്കോ ഉത്തരവാദിയോ ബാധ്യസ്ഥനോ ആയിരിക്കില്ല. ശ്രദ്ധിക്കുക: ഈ ഉള്ളടക്കത്തിൽ ഇപ്പോൾ കാലഹരണപ്പെട്ട നിന്ദ്യമായ പദാവലി അടങ്ങിയിരിക്കാം. സാധ്യമാകുന്നിടത്തെല്ലാം സിലിക്കൺ ലാബ്സ് ഈ നിബന്ധനകളെ ഉൾക്കൊള്ളുന്ന ഭാഷ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നു. കൂടുതൽ വിവരങ്ങൾക്ക്, www.silabs.com/about-us/inclusive-lexicon-project സന്ദർശിക്കുക
വ്യാപാരമുദ്ര വിവരം
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs®, സിലിക്കൺ ലാബ്സ് ലോഗോ®, Blueridge®, Blueridge Logo®, EFM®, EFM32®, EFR, Ember®, എനർജി മൈക്രോ, എനർജി മൈക്രോ, അവയുടെ ലോഗോ എന്നിവയുടെ സംയോജനം , "ലോകത്തിലെ ഏറ്റവും ഊർജ്ജ സൗഹൃദ മൈക്രോ കൺട്രോളറുകൾ", റിപൈൻ സിഗ്നലുകൾ®, വിച്ഛേദിക്കുക , n-ലിങ്ക്, ത്രെഡ് ആർച്ച്®, Elin®, EZRadioPRO®, EZRadioPRO®, Gecko®, Gecko OS, Gecko OS Studio, Studision32, Precisionp3 , Telegenic, the Telegenic Logo®, Suppress® , Sentry, the Sentry logo, Zentri DMS, Z-Wave® എന്നിവയും മറ്റുള്ളവയും സിലിക്കൺ ലാബുകളുടെ വ്യാപാരമുദ്രകളോ രജിസ്റ്റർ ചെയ്ത വ്യാപാരമുദ്രകളോ ആണ്. ARM, CORTEX, Cortex-MXNUMX, THUMB എന്നിവ ARM ഹോൾഡിംഗിൻ്റെ വ്യാപാരമുദ്രകളോ രജിസ്റ്റർ ചെയ്ത വ്യാപാരമുദ്രകളോ ആണ്. ARM ലിമിറ്റഡിൻ്റെ രജിസ്റ്റർ ചെയ്ത വ്യാപാരമുദ്രയാണ് കേളി. വൈഫൈ അലയൻസിൻ്റെ രജിസ്റ്റർ ചെയ്ത വ്യാപാരമുദ്രയാണ് വൈഫൈ. ഇവിടെ പരാമർശിച്ചിരിക്കുന്ന മറ്റെല്ലാ ഉൽപ്പന്നങ്ങളും ബ്രാൻഡ് പേരുകളും അതത് ഹോൾഡിൻ്റെ വ്യാപാരമുദ്രകളാണ്
പ്രമാണങ്ങൾ / വിഭവങ്ങൾ
![]() |
സിലിക്കൺ ലാബ്സ് UG305 ഡൈനാമിക് മൾട്ടിപ്രോട്ടോക്കോൾ [pdf] ഉപയോക്തൃ ഗൈഡ് UG305, UG305 ഡൈനാമിക് മൾട്ടിപ്രോട്ടോകോൾ, ഡൈനാമിക് മൾട്ടിപ്രോട്ടോകോൾ, മൾട്ടിപ്രോട്ടോകോൾ |