SILICON LABS UG305 ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕਾਲ ਯੂਜ਼ਰ ਗਾਈਡ

ਜਾਣ-ਪਛਾਣ

ਇਹ ਦਸਤਾਵੇਜ਼ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਸਿਲੀਕਾਨ ਲੈਬਜ਼ ਸੌਫਟਵੇਅਰ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਵਾਇਰਲੈੱਸ ਚਿੱਪ 'ਤੇ ਮਲਟੀਪਲ ਪ੍ਰੋਟੋਕੋਲ ਦੁਆਰਾ ਵਰਤੇ ਜਾਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਰੇਡੀਓ ਨੂੰ ਸਮਾਂ-ਸਲਾਈਸ ਕਰਦਾ ਹੈ ਅਤੇ ਵੱਖ-ਵੱਖ ਵਾਇਰਲੈੱਸ ਪ੍ਰੋਟੋਕੋਲਾਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਬਣਾਉਣ ਲਈ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲਦਾ ਹੈ।

ਨੋਟ ਕਰੋ: ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ Zigbee-ਵਿਸ਼ੇਸ਼ ਜਾਣਕਾਰੀ ਵਰਜਨ 6.10.x ਅਤੇ ਇਸਤੋਂ ਹੇਠਲੇ ਲਈ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।
ਖਾਸ ਗਤੀਸ਼ੀਲ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਲਾਗੂ ਕਰਨ ਦੇ ਵੇਰਵੇ ਹੇਠਾਂ ਦਿੱਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੋਟਸ ਵਿੱਚ ਦਿੱਤੇ ਗਏ ਹਨ:
AN1133: ਬਲੂਟੁੱਥ ਅਤੇ Zigbee EmberZNet SDK 6.x ਅਤੇ ਹੇਠਲੇ ਨਾਲ ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਵਿਕਾਸ
AN1134: GSDK v2.x ਵਿੱਚ RAIL ਉੱਤੇ ਬਲੂਟੁੱਥ ਅਤੇ ਮਲਕੀਅਤ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਨਾਲ ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਵਿਕਾਸ
AN1269: ਬਲੂਟੁੱਥ® ਦੇ ਨਾਲ ਗਤੀਸ਼ੀਲ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਵਿਕਾਸ ਅਤੇ GSDK v3.x ਅਤੇ ਉੱਚ ਵਿੱਚ ਰੇਲ ਉੱਤੇ ਮਲਕੀਅਤ ਪ੍ਰੋਟੋਕੋਲ
AN1209: ਬਲੂਟੁੱਥ ਅਤੇ ਕਨੈਕਟ ਦੇ ਨਾਲ ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਵਿਕਾਸ
AN1265: GSDK v3.x ਵਿੱਚ Bluetooth® ਅਤੇ OpenThread ਨਾਲ ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਵਿਕਾਸ

ਸ਼ਬਦਾਵਲੀ

ਹੇਠਾਂ ਗਤੀਸ਼ੀਲ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਲਾਗੂ ਕਰਨ ਲਈ ਕੁਝ ਖਾਸ ਪਰਿਭਾਸ਼ਾਵਾਂ ਦੀ ਸੂਚੀ ਦਿੱਤੀ ਗਈ ਹੈ

ਰੇਡੀਓ ਐਬਸਟਰੈਕਸ਼ਨ ਇੰਟਰਫੇਸ ਲੇਅਰ (RAIL): ਆਮ API ਜਿਸ ਰਾਹੀਂ ਉੱਚ ਪੱਧਰੀ ਕੋਡ EFR32 ਰੇਡੀਓ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।

ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ: ਨਿਯਤ ਕੀਤੀ ਜਾਣ ਵਾਲੀ ਇੱਕ ਖਾਸ ਕਾਰਵਾਈ। ਇੱਕ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਇੱਕ ਰੇਡੀਓ ਸੰਰਚਨਾ ਅਤੇ ਤਰਜੀਹ ਦੋਵੇਂ ਹੁੰਦੇ ਹਨ। ਹਰੇਕ ਸਟੈਕ ਬੇਨਤੀ ਕਰ ਸਕਦਾ ਹੈ ਕਿ ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਦੋ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨਾਂ (ਬੈਕਗ੍ਰਾਉਂਡ ਪ੍ਰਾਪਤ ਕਰੋ ਅਤੇ ਜਾਂ ਤਾਂ ਅਨੁਸੂਚਿਤ ਪ੍ਰਾਪਤ ਕਰੋ ਜਾਂ ਅਨੁਸੂਚਿਤ ਕਰੋ)

• ਬੈਕਗ੍ਰਾਊਂਡ ਪ੍ਰਾਪਤ ਕਰੋ: ਸਥਾਈ ਪ੍ਰਾਪਤੀ, ਅਨੁਸੂਚਿਤ ਕਾਰਵਾਈਆਂ ਦੁਆਰਾ ਵਿਘਨ ਪਾਉਣ ਦਾ ਇਰਾਦਾ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵਾਪਸ ਪਰਤਿਆ।
• ਅਨੁਸੂਚਿਤ ਪ੍ਰਾਪਤੀ: ਇੱਕ ਨਿਸ਼ਚਿਤ ਸਮੇਂ ਅਤੇ ਅਵਧੀ 'ਤੇ ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਕਰੋ ਜਾਂ RSSI ਦੀ ਗਣਨਾ ਕਰੋ। (ਰੇਲ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਡਿਵੈਲਪਰ, ਨੋਟ ਕਰੋ ਕਿ RAIL API ਦੇ ਸੰਦਰਭ ਵਿੱਚ, ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਵਰਤੇ ਗਏ "ਸ਼ਡਿਊਲਡ ਰਿਸੀਵ" ਦਾ ਮਤਲਬ RAIL_StartRx ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਵੀ ਰਿਸੀਵ ਓਪਰੇਸ਼ਨ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹ ਸਿਰਫ਼ RAIL_ScheduleRx ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ ਹੈ।)
• ਅਨੁਸੂਚਿਤ ਟ੍ਰਾਂਸਮੀt: ਤਤਕਾਲ ਟ੍ਰਾਂਸਮਿਟ, ਅਨੁਸੂਚਿਤ (ਭਵਿੱਖ ਵਿੱਚ) ਟ੍ਰਾਂਸਮਿਟ, ਜਾਂ CCA-ਨਿਰਭਰ ਟ੍ਰਾਂਸਮਿਟ ਸਮੇਤ ਵੱਖ-ਵੱਖ ਟ੍ਰਾਂਸਮਿਟ ਓਪਰੇਸ਼ਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਇੱਕ। (ਰੇਲ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਡਿਵੈਲਪਰ, ਨੋਟ ਕਰੋ ਕਿ RAIL API ਦੇ ਰੂਪ ਵਿੱਚ, "ਸ਼ਡਿਊਲਡ ਟ੍ਰਾਂਸਮਿਟ" ਜਿਵੇਂ ਕਿ ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਵਰਤਿਆ ਗਿਆ ਹੈ, ਕਿਸੇ ਵੀ ਟ੍ਰਾਂਸਮਿਟ ਓਪਰੇਸ਼ਨ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ ਇਹ RAIL_StartScheduledTx ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ ਹੈ।

Radio Config: ਹਾਰਡਵੇਅਰ ਦੀ ਸਥਿਤੀ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਜੋ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ: RAIL ਕੰਪੋਨੈਂਟ ਜੋ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਵੱਖ-ਵੱਖ ਪ੍ਰੋਟੋਕੋਲਾਂ ਵਿਚਕਾਰ ਆਰਬਿਟਰੇਟ ਕਰਦਾ ਹੈ ਕਿ ਕਿਸ ਕੋਲ ਰੇਡੀਓ ਤੱਕ ਪਹੁੰਚ ਹੋਵੇਗੀ।

ਤਰਜੀਹ: ਹਰੇਕ ਸਟੈਕ ਤੋਂ ਹਰੇਕ ਓਪਰੇਸ਼ਨ ਦੀ ਇੱਕ ਡਿਫੌਲਟ ਤਰਜੀਹ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਡਿਫੌਲਟ ਤਰਜੀਹਾਂ ਨੂੰ ਬਦਲ ਸਕਦੀ ਹੈ।

ਸਲਿੱਪ ਟਾਈਮ: ਭਵਿੱਖ ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ ਸਮਾਂ ਜਦੋਂ ਓਪਰੇਸ਼ਨ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ ਇਹ ਬੇਨਤੀ ਕੀਤੇ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ 'ਤੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ।

ਪੈਦਾਵਾਰ: ਇੱਕ ਸਟੈਕ ਨੂੰ ਇੱਕ ਓਪਰੇਸ਼ਨ ਜਾਂ ਓਪਰੇਸ਼ਨਾਂ ਦੇ ਕ੍ਰਮ ਦੇ ਅੰਤ ਵਿੱਚ ਸਵੈਇੱਛਤ ਤੌਰ 'ਤੇ ਉਪਜ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਇਹ ਇੱਕ ਬੈਕਗ੍ਰਾਉਂਡ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੁੰਦਾ। ਜਦੋਂ ਤੱਕ ਸਟੈਕ ਪੈਦਾ ਨਹੀਂ ਹੁੰਦਾ, ਸ਼ਡਿਊਲਰ ਘੱਟ ਤਰਜੀਹੀ ਕੰਮਾਂ ਨੂੰ ਤਹਿ ਨਹੀਂ ਕਰੇਗਾ

RTOS (ਰੀਅਲ ਟਾਈਮ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ) ਕਰਨਲ: ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦਾ ਉਹ ਹਿੱਸਾ ਜੋ ਕਾਰਜ ਪ੍ਰਬੰਧਨ, ਅਤੇ ਇੰਟਰਟਾਸਕ ਸੰਚਾਰ ਅਤੇ ਸਮਕਾਲੀਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਇਹ ਲਾਗੂਕਰਨ ਮਾਈਕਰਿਅਮ OS-5 ਕਰਨਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਆਰਕੀਟੈਕਚਰ

ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ EFR32 ਹਾਰਡਵੇਅਰ ਅਤੇ RAIL ਸੌਫਟਵੇਅਰ ਨੂੰ ਇਸਦੇ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਵਜੋਂ ਵਰਤਦਾ ਹੈ। ਜ਼ਿਗਬੀ, ਬਲੂਟੁੱਥ, ਅਤੇ/ਜਾਂ ਕੋਈ ਹੋਰ ਮਿਆਰ-ਅਧਾਰਤ ਜਾਂ ਮਲਕੀਅਤ ਪ੍ਰੋਟੋਕੋਲ ਫਿਰ ਵੱਖ-ਵੱਖ ਪ੍ਰੋਟੋਕੋਲਾਂ ਦੇ ਵਿਚਕਾਰ ਕੋਡ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਮਾਈਕਰਿਅਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਇਹਨਾਂ ਬੇਮਿਸਾਲ ਪਰਤਾਂ ਦੇ ਸਿਖਰ 'ਤੇ ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ। ਹੇਠਾਂ ਦਿੱਤਾ ਚਿੱਤਰ ਸਾਫਟਵੇਅਰ ਮੋਡੀਊਲ ਦੀ ਆਮ ਬਣਤਰ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

 

ਸੰਸਕਰਣ 2.0 ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ, RAIL ਨੂੰ RAIL API ਕਾਲਾਂ ਲਈ ਇੱਕ ਰੇਡੀਓ ਸੰਰਚਨਾ ਹੈਂਡਲ ਪਾਸ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਸੰਰਚਨਾ ਵੱਖ-ਵੱਖ PHY ਪੈਰਾਮੀਟਰਾਂ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ ਜੋ ਸਟੈਕ ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ ਹਨ

ਮਾਈਕਰਿਅਮ OS ਇੱਕ RTOS ਹੈ ਜੋ ਸਟੈਕ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਤਰਕ ਨੂੰ CPU ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਟਾਈਮ ਸ਼ੇਅਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਇੱਕ ਸਾਫਟਵੇਅਰ ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜੋ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਕਰਨ ਅਤੇ ਲੇਟੈਂਸੀ ਨੂੰ ਘੱਟ ਕਰਨ ਲਈ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਕਰਨ ਲਈ ਸਟੈਕ ਦੁਆਰਾ ਬੇਨਤੀਆਂ ਦਾ ਸਮਝਦਾਰੀ ਨਾਲ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। RAIL ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ API ਜੋ ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਨੂੰ ਬਾਈਪਾਸ ਨਹੀਂ ਕਰਦੇ ਹਨ।

RAIL ਕੋਰ ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਦੀਆਂ ਹਦਾਇਤਾਂ ਦੇ ਜਵਾਬ ਵਿੱਚ EFR32 ਹਾਰਡਵੇਅਰ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਦਾ ਹੈ।

ਸਿੰਗਲ ਫਰਮਵੇਅਰ ਚਿੱਤਰ

ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਇੱਕ ਸੌਫਟਵੇਅਰ ਡਿਵੈਲਪਰ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਮੋਨੋਲਿਥਿਕ ਬਾਈਨਰੀ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜੋ ਇੱਕ EFR32 ਉੱਤੇ ਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸੌਫਟਵੇਅਰ ਅੱਪਡੇਟ ਪੂਰੀ ਬਾਈਨਰੀ ਨੂੰ ਅੱਪਗਰੇਡ ਕਰਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਗੇਕ ਓਟਲੋਡਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੂਰਾ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਦੇ ਵੇਰਵੇ UG266 ਵਿੱਚ ਲੱਭੇ ਜਾ ਸਕਦੇ ਹਨ: GSDK 3.2 ਅਤੇ ਲੋਅਰ ਅਤੇ UG489 ਲਈ ਸਿਲੀਕਾਨ ਲੈਬਜ਼ ਗੀਕੋ ਬੂਟਲੋਡਰ ਉਪਭੋਗਤਾ ਦੀ ਗਾਈਡ: GSDK 4.0 ਅਤੇ ਉੱਚ ਲਈ ਸਿਲੀਕੋਨ ਲੈਬਸਗੇਕੋ ਬੂਟਲੋਡਰ ਉਪਭੋਗਤਾ ਦੀ ਗਾਈਡ।

ਸੁਤੰਤਰ ਸਟੈਕ ਓਪਰੇਸ਼ਨ

ਸਿਲੀਕਾਨ ਲੈਬਜ਼ ਸਟੈਕ ਅਜੇ ਵੀ ਇੱਕ ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਸਥਿਤੀ ਵਿੱਚ ਇੱਕ ਦੂਜੇ ਤੋਂ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ। ਕੁਝ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨਾਂ ਦਾ ਕਿਸੇ ਹੋਰ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਲੇਟੈਂਸੀ ਅਤੇ ਅਨੁਕੂਲ ਓਪਰੇਸ਼ਨ 'ਤੇ ਅਸਰ ਪਵੇਗਾ। ਇਹਨਾਂ ਸਮਾਗਮਾਂ ਲਈ ਕੋਈ ਵਿਸ਼ੇਸ਼ ਵਿਚਾਰ ਨਿਰਧਾਰਤ ਕਰਨਾ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ ਸੈਕਸ਼ਨ 2 ਦੇਖੋ। ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ।

ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ

ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਰੇਲ (ਰੇਡੀਓ ਐਬਸਟਰੈਕਸ਼ਨ ਇੰਟਰਫੇਸ ਲੇਅਰ) ਦਾ ਇੱਕ ਹਿੱਸਾ ਹੈ। ਰੇਲ ਇੱਕ ਅਨੁਭਵੀ, ਆਸਾਨੀ ਨਾਲ ਅਨੁਕੂਲਿਤ ਰੇਡੀਓ ਇੰਟਰਫੇਸ ਲੇਅਰ ਅਤੇ API ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜੋ ਮਲਕੀਅਤ ਜਾਂ ਮਿਆਰ-ਅਧਾਰਿਤ ਵਾਇਰਲੈੱਸ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਨੂੰ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ ਜੋ ਅਨੁਸੂਚਿਤ ਅਤੇ ਤਰਜੀਹੀ ਹੋ ਸਕਦੇ ਹਨ। ਸਥਿਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਹਰੇਕ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਘੱਟ ਜਾਂ ਵੱਧ ਮਹੱਤਵਪੂਰਨ, ਜਾਂ ਵੱਧ ਜਾਂ ਘੱਟ ਸਮਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਹੋ ਸਕਦੇ ਹਨ। ਸ਼ਡਿਊਲਰ ਵਿਵਾਦਾਂ ਬਾਰੇ ਫੈਸਲੇ ਲੈਂਦੇ ਸਮੇਂ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਨਿਰਣਾ ਕਰਨਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਸਕਦਾ ਹੈ

ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ RAIL 'ਤੇ ਕਸਟਮ ਪ੍ਰੋਟੋਕੋਲ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦਾ ਵਿਕਾਸ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋ, ਜ਼ਿਆਦਾਤਰ ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਫੰਕਸ਼ਨ ਅੰਡਰਲਾਈੰਗ ਸਟੈਕ ਅਤੇ ਰੇਲ ਕੋਡ ਦੁਆਰਾ ਆਪਣੇ ਆਪ ਹੀ ਸੰਭਾਲੇ ਜਾਂਦੇ ਹਨ। ਤੁਹਾਨੂੰ ਸਿਰਫ ਇਸਦੇ ਆਮ API ਦੁਆਰਾ ਸਟੈਕ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.

ਉੱਚ ਪੱਧਰ 'ਤੇ, ਸਟੈਕ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਭੇਜਦਾ ਹੈ (ਉਦਾਹਰਣ ਲਈampਅਨੁਸੂਚਿਤ ਪ੍ਰਾਪਤੀ ਜਾਂ ਅਨੁਸੂਚਿਤ ਟ੍ਰਾਂਸਮਿਟ)। ਰੇਡੀਓ ਸੰਚਾਲਨ ਹਨ
ਕਤਾਰਬੱਧ ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਦੇ ਮਾਪਦੰਡਾਂ ਦੇ ਅਧਾਰ ਤੇ ਭਵਿੱਖ ਦੇ ਸਮੇਂ ਵਿੱਚ ਸੇਵਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਜਦੋਂ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਸਮਾਂ ਹੁੰਦਾ ਹੈ ਤਾਂ ਸ਼ਡਿਊਲਰ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਕੋਈ ਮੁਕਾਬਲਾ ਕਰਨ ਵਾਲੀ ਘਟਨਾ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਕੀ ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਦੇਰੀ ਹੋ ਸਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇਕਰ ਸ਼ਡਿਊਲਰ ਇਵੈਂਟ ਨੂੰ ਨਹੀਂ ਚਲਾ ਸਕਦਾ ਹੈ ਤਾਂ ਇਹ ਨਤੀਜੇ ਨੂੰ ਉੱਚੀ ਪਰਤ 'ਤੇ ਵਾਪਸ ਕਰ ਦਿੰਦਾ ਹੈ, ਜੋ ਨਵੇਂ ਪੈਰਾਮੀਟਰਾਂ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ।

ਇੱਕ ਵਾਰ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਸੰਬੰਧਿਤ ਸਟੈਕ ਸ਼ਡਿਊਲਰ ਨੂੰ ਪਿਛਲੀ ਕਾਰਵਾਈ ਦੇ ਨਤੀਜਿਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਵਾਧੂ ਓਪਰੇਸ਼ਨ ਭੇਜ ਸਕਦਾ ਹੈ (ਸਾਬਕਾ ਲਈampਇੱਕ ACK ਦੀ ਉਡੀਕ)। ਹਰੇਕ ਓਪਰੇਸ਼ਨ ਜਾਂ ਓਪਰੇਸ਼ਨ ਦੇ ਕ੍ਰਮ ਦੇ ਅੰਤ 'ਤੇ ਸਟੈਕ ਨੂੰ ਰੇਡੀਓ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਰੇਡੀਓ ਆਪ੍ਰੇਸ਼ਨ

ਸ਼ਡਿਊਲਰ ਵਿੱਚ ਹਰੇਕ ਇਵੈਂਟ ਨੂੰ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨਜ਼ ਨਾਮਕ ਤੱਤਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਰੇਡੀਓ ਸੰਰਚਨਾ ਅਤੇ ਤਰਜੀਹ ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ।

ਹਰ ਓਪਰੇਸ਼ਨ ਦੀ ਇੱਕ ਤਰਜੀਹ ਹੁੰਦੀ ਹੈ ਅਤੇ ਜੇਕਰ ਸ਼ਡਿਊਲਰ ਨੂੰ ਇੱਕ ਉੱਚ ਤਰਜੀਹੀ ਓਪਰੇਸ਼ਨ ਮਿਲਦਾ ਹੈ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਓਵਰਲੈਪ ਹੁੰਦਾ ਹੈ ਤਾਂ ਰੁਕਾਵਟ ਹੁੰਦੀ ਹੈ। ਹੇਠਲੇ ਤਰਜੀਹ ਵਾਲੇ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਜੋ ਉਹਨਾਂ ਦੇ ਅਨੁਸੂਚੀ ਮਾਪਦੰਡਾਂ ਦੇ ਅਧਾਰ ਤੇ ਨਹੀਂ ਚਲਾਏ ਜਾ ਸਕਦੇ ਹਨ, ਅਸਫਲ ਹੋ ਜਾਣਗੇ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਲਈ ਇਹ ਸਬੰਧਤ ਸਟੈਕ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਸ਼ਡਿਊਲਰ ਸਟੈਕ ਤੋਂ ਇੱਕ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਨੂੰ ਸਰਗਰਮੀ ਨਾਲ ਚਲਾਉਂਦਾ ਹੈ, ਸਟੈਕ ਵਾਧੂ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਉਦੋਂ ਤੱਕ ਭੇਜਣਾ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਇਹ ਸਵੈ-ਇੱਛਾ ਨਾਲ ਪੈਦਾ ਨਹੀਂ ਹੁੰਦਾ, ਜਾਂ ਜਦੋਂ ਤੱਕ ਸ਼ਡਿਊਲਰ ਇੱਕ ਉੱਚ ਤਰਜੀਹੀ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਇਸਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਪਹਿਲਾਂ ਨਹੀਂ ਦਿੰਦਾ।

• ਬੈਕਗ੍ਰਾਊਂਡ ਪ੍ਰਾਪਤ ਕਰੋ
• ਅਨੁਸੂਚਿਤ ਪ੍ਰਾਪਤੀ
• ਅਨੁਸੂਚਿਤ ਟ੍ਰਾਂਸਮਿਟ

ਹਰੇਕ ਸਟੈਕ ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਨੂੰ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਦੋ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨਾਂ (ਬੈਕਗ੍ਰਾਊਂਡ ਰਿਸੀਵ ਅਤੇ ਜਾਂ ਤਾਂ ਅਨੁਸੂਚਿਤ ਪ੍ਰਾਪਤ ਜਾਂ ਅਨੁਸੂਚਿਤ ਟ੍ਰਾਂਸਮਿਟ) ਕਰਨ ਲਈ ਕਹਿ ਸਕਦਾ ਹੈ:

ਹਰੇਕ ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਹੇਠ ਲਿਖੇ ਮਾਪਦੰਡ ਹੁੰਦੇ ਹਨ:

ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ	ਇੱਕ ਸੰਕੇਤ ਭਵਿੱਖ ਵਿੱਚ ਕਿਸ ਬਿੰਦੂ 'ਤੇ ਇਹ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਚੱਲੇਗਾ। ਇਹ "ਹੁਣੇ ਚਲਾਓ" ਜਾਂ ਭਵਿੱਖ ਵਿੱਚ ਮਾਈਕ੍ਰੋਸਕਿੰਡ ਵਿੱਚ ਕੁਝ ਮੁੱਲ ਹੋ ਸਕਦਾ ਹੈ।
ਤਰਜੀਹ	ਇੱਕ ਸੰਖਿਆ ਜੋ ਕਾਰਵਾਈ ਦੀ ਸੰਬੰਧਿਤ ਤਰਜੀਹ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ। ਡਿਫੌਲਟ ਸੈਟਿੰਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਬਲੂਟੁੱਥ LE ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਲਗਭਗ ਹਮੇਸ਼ਾਂ Zigbee ਓਪਰੇਸ਼ਨਾਂ ਨਾਲੋਂ ਉੱਚ ਤਰਜੀਹ ਹੁੰਦੇ ਹਨ।
ਸਲਿੱਪ ਟਾਈਮ	ਸਮੇਂ ਦੀ ਇੱਕ ਮਾਤਰਾ ਜਿਸ ਵਿੱਚ ਇਵੈਂਟ ਇਸਦੇ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਤੋਂ ਦੇਰੀ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਸਟੈਕ ਲਈ ਸਵੀਕਾਰਯੋਗ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ 0 ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸ ਸਥਿਤੀ ਵਿੱਚ ਇਵੈਂਟ ਨੂੰ ਖਿਸਕਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ।
ਲੈਣ-ਦੇਣ ਦਾ ਸਮਾਂ	ਲੈਣ-ਦੇਣ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਲੱਗਣ ਵਾਲੇ ਸਮੇਂ ਦੀ ਅੰਦਾਜ਼ਨ ਮਾਤਰਾ। ਟ੍ਰਾਂਸਮਿਟ ਇਵੈਂਟਸ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਪਰਿਭਾਸ਼ਿਤ ਲੈਣ-ਦੇਣ ਦਾ ਸਮਾਂ ਹੁੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਪ੍ਰਾਪਤ ਘਟਨਾਵਾਂ ਅਕਸਰ ਅਣਜਾਣ ਹੁੰਦੀਆਂ ਹਨ। ਇਹ ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਨੂੰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਕੋਈ ਇਵੈਂਟ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਸਟੈਕ ਇਹਨਾਂ ਵੱਖ-ਵੱਖ ਮਾਪਦੰਡਾਂ ਨੂੰ ਲਾਗੂ ਕੀਤੇ ਜਾ ਰਹੇ ਓਪਰੇਸ਼ਨ ਲਈ ਉਚਿਤ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਸਾਬਕਾ ਲਈampਲੇ, ਬਲੂਟੁੱਥ ਕਨੈਕਸ਼ਨ ਇਵੈਂਟਸ ਅਕਸਰ ਭਵਿੱਖ ਵਿੱਚ ਨਿਯਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ ਕੋਈ ਪਰਚੀ ਨਹੀਂ ਹੁੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਜ਼ਿਗਬੀ ਟ੍ਰਾਂਸਮਿਟ ਇਵੈਂਟਾਂ ਵਿੱਚ ਅਕਸਰ ਥੋੜ੍ਹੀ ਜਿਹੀ ਦੇਰੀ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸਟਾਰ ਹੋ ਸਕਦੇ ਹਨ।

ਰੇਲ ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਅਨੁਸੂਚਿਤ ਟ੍ਰਾਂਸਮਿਟ ਅਤੇ ਅਨੁਸੂਚਿਤ ਪ੍ਰਾਪਤੀ ਇੱਕੋ ਜਿਹੇ ਹਨ। ਇਹ ਦੋਵੇਂ ਸਿਰਫ਼ ਓਪਰੇਸ਼ਨ ਹਨ ਜਿਨ੍ਹਾਂ ਲਈ ਰੇਡੀਓ ਦੀ ਵਰਤੋਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਇੱਕੋ ਸਮੇਂ ਚਲਾਇਆ ਨਹੀਂ ਜਾ ਸਕਦਾ। ਇਫਫਰੈਂਸ ਸਿਰਫ RAIL API ਲੇਅਰ 'ਤੇ ਸਪੱਸ਼ਟ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਜਾਂ ਤਾਂ TX ਜਾਂ RX API ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

ਬੈਕਗ੍ਰਾਊਂਡ ਪ੍ਰਾਪਤ ਕਰੋ

ਇਹ ਇੱਕ ਲਗਾਤਾਰ ਰਿਸੀਵ ਮੋਡ ਹੈ ਜਿਸਦਾ ਉਦੇਸ਼ ਦੂਜੇ ਓਪਰੇਸ਼ਨਾਂ ਦੁਆਰਾ ਰੁਕਾਵਟ ਪਾਉਣਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਬੈਕਗ੍ਰਾਊਂਡ ਰਿਸੀਵ ਹੋਰ ਓਪਰੇਸ਼ਨਾਂ ਨਾਲੋਂ ਉੱਚੀ ਤਰਜੀਹ ਹੈ, ਤਾਂ ਉਹ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਸਮਾਂਬੱਧ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ ਅਤੇ ਨਹੀਂ ਚੱਲੇਗਾ। ਇਹ ਪਹਿਲ ਜਾਂ ਸਵੈ-ਇੱਛਾ ਨਾਲ ਉਪਜ ਨੂੰ ਬਦਲਣ ਲਈ ਸਟੈਕ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਧਾਰਾ 5.1 ਦੇਖੋampਸਾਬਕਾ ਲਈ ਬੈਕਗ੍ਰਾਉਂਡ ਰਿਸੀਵ, ਯੀਲਡ ਰੇਡੀਓ ਅਤੇ ਸਟੇਟ ਟ੍ਰਾਂਜਿਸ਼ਨ ਦੇ ਨਾਲampਬੈਕਗ੍ਰਾਉਂਡ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਨੁਸੂਚਿਤ ਕਾਰਵਾਈਆਂ ਨਾਲ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ।

ਨਿਰਧਾਰਤ ਪ੍ਰਾਪਤ ਕਰੋ

ਇਹ ਇੱਕ ਨਿਸ਼ਚਿਤ ਅਵਧੀ ਦੇ ਨਾਲ ਭਵਿੱਖ ਦੇ ਸਮੇਂ ਵਿੱਚ ਪ੍ਰਾਪਤੀ ਹੈ। ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਰੇਡੀਓ ਬਦਲਣ ਦੇ ਸਮੇਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੇਗਾ ਕਿ ਓਪਰੇਸ਼ਨ ਨਿਯਤ ਕੀਤਾ ਜਾਵੇਗਾ ਜਾਂ ਨਹੀਂ। ਜੇਕਰ ਇਹ ਨਿਯਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਤਾਂ ਸ਼ਡਿਊਲਰ ਕਾਲਿੰਗ ਸਟੈਕ ਨੂੰ ਇੱਕ ਫੇਲ ਇਵੈਂਟ ਭੇਜਦਾ ਹੈ। ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਉਦੋਂ ਤੱਕ ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਸਟੈਕ ਸਵੈ-ਇੱਛਾ ਨਾਲ ਪੈਦਾ ਨਹੀਂ ਹੁੰਦਾ, ਜਾਂ ਸ਼ਡਿਊਲਰ ਨੂੰ ਉੱਚ ਤਰਜੀਹੀ ਕਾਰਵਾਈ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਰੁਕਾਵਟ ਨਹੀਂ ਆਉਂਦੀ। ਰਿਸੀਵ ਨੂੰ ਵਧਾਉਣਾ ਸਟੈਕ ਨੂੰ ਉੱਚ ਪੱਧਰੀ ਪ੍ਰੋਟੋਕੋਲ ਦੀਆਂ ਲੋੜਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਜਾਰੀ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਸਾਬਕਾ ਲਈampਪ੍ਰਾਪਤ ਡੇਟਾ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਜਵਾਬ ਦਾ ਸੰਚਾਰ.

ਅਨੁਸੂਚਿਤ ਟ੍ਰਾਂਸਮਿਟ

ਇਹ ਇੱਕ ਘੱਟੋ-ਘੱਟ ਅਵਧੀ ਦੇ ਨਾਲ ਭਵਿੱਖ ਦੇ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਸੰਚਾਰ ਹੈ। ਇਸ ਘੱਟੋ-ਘੱਟ ਅਵਧੀ ਵਿੱਚ ਪੂਰਵ ਲਈ ਸੰਭਾਵਿਤ ਫਾਲੋ-ਆਨ ਇਵੈਂਟ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹਨampਇੱਕ IEEE 802.15.4 ਸੰਚਾਰ ਲਈ ਇੱਕ ACK। ਹਾਲਾਂਕਿ, ਇਸ ਓਪਰੇਸ਼ਨ ਲਈ ਘੱਟੋ-ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਅਚਾਨਕ ਘਟਨਾਵਾਂ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਜੋ ਘੱਟੋ-ਘੱਟ ਮਿਆਦ ਤੋਂ ਵੱਧ ਸਮਾਂ ਵਧਾ ਸਕਦੀਆਂ ਹਨ, ਸਾਬਕਾ ਲਈampIEEE 802.15.4 ਵਿੱਚ CCA ਅਸਫਲਤਾਵਾਂ ਦੇ ਕਾਰਨ ਕਮੀ। ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਰੇਡੀਓ ਬਦਲਣ ਦੇ ਸਮੇਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦਾ ਹੈ ਕਿ ਓਪਰੇਸ਼ਨ ਨਿਯਤ ਕੀਤਾ ਜਾਵੇਗਾ ਜਾਂ ਨਹੀਂ। ਜੇਕਰ ਇਹ ਨਿਯਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਤਾਂ ਸ਼ਡਿਊਲਰ ਕਾਲਿੰਗ ਸਟੈਕ ਨੂੰ ਇੱਕ ਫੇਲ ਇਵੈਂਟ ਭੇਜਦਾ ਹੈ।

ਰੇਡੀਓ ਸੰਰਚਨਾ

ਹਰੇਕ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਇੱਕ ਪਹਿਲਾਂ ਤੋਂ ਪਰਿਭਾਸ਼ਿਤ ਰੇਡੀਓ ਸੰਰਚਨਾ ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ ਜੋ ਹਾਰਡਵੇਅਰ ਦੀ ਸਥਿਤੀ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਜੋ ਓਪਰੇਸ਼ਨ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਰੇਡੀਓ ਕੌਂਫਿਗਸ ਸਟੈਕ ਦੀ ਮੌਜੂਦਾ ਸਥਿਤੀ 'ਤੇ ਨਜ਼ਰ ਰੱਖਦੇ ਹਨ ਤਾਂ ਜੋ ਭਵਿੱਖ ਦੇ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਉਸੇ ਰੇਡੀਓ ਮਾਪਦੰਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਗੇ। ਰੇਡੀਓ ਸੰਰਚਨਾ ਸਰਗਰਮ ਜਾਂ ਸੁਸਤ ਹੋ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਸਟੈਕ ਇੱਕ ਸਰਗਰਮ ਰੇਡੀਓ ਸੰਰਚਨਾ ਨੂੰ ਬਦਲਦਾ ਹੈ ਤਾਂ ਰੇਲ ਹਾਰਡਵੇਅਰ ਸੰਰਚਨਾ ਵਿੱਚ ਵੀ ਤੁਰੰਤ ਬਦਲਾਅ ਕਰਦਾ ਹੈ, ਸਾਬਕਾ ਲਈampਚੈਨਲ ਬਦਲ ਰਿਹਾ ਹੈ। ਜੇਕਰ ਰੇਡੀਓ ਸੰਰਚਨਾ ਵਰਤਮਾਨ ਵਿੱਚ ਕਿਰਿਆਸ਼ੀਲ ਨਹੀਂ ਹੈ ਤਾਂ ਅਗਲਾ ਅਨੁਸੂਚਿਤ ਰੇਡੀਓ ਸੰਚਾਲਨ ਨਵੀਂ ਰੇਡੀਓ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ।

ਤਰਜੀਹ

ਹਰੇਕ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਦੀ ਇੱਕ ਤਰਜੀਹ ਹੁੰਦੀ ਹੈ ਜੋ ਸ਼ਡਿਊਲਰ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਕਿ ਜੇਕਰ ਕਈ ਓਪਰੇਸ਼ਨਾਂ ਵਿਚਕਾਰ ਸਮਾਂ ਓਵਰਲੈਪ ਹੁੰਦਾ ਹੈ ਤਾਂ ਕਿਹੜਾ ਓਪਰੇਸ਼ਨ ਚਲਾਇਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸ਼ਡਿਊਲਰ 0 ਦੀ ਤਰਜੀਹ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਅਤੇ 255 ਨੂੰ ਸਭ ਤੋਂ ਘੱਟ ਤਰਜੀਹ ਮੰਨਦਾ ਹੈ। ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਭੌਤਿਕ ra rdware ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਵਾਲੇ ਕੰਮ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ। ਜ਼ਿਆਦਾਤਰ ਕਾਰਜਾਂ ਦੇ ਨਾਲ ਨਿਯੰਤਰਣ ਨੂੰ ਪੂਰਾ ਹੋਣ 'ਤੇ ਹੀ ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਨੂੰ ਵਾਪਸ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਉੱਚ ਤਰਜੀਹ ਵਾਲਾ ਕਾਰਜ ਸਰਗਰਮ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਬੈਕਗ੍ਰਾਉਂਡ ਪ੍ਰਾਪਤ ਕਰਨ ਵਰਗੇ ਕਾਰਜਾਂ ਵਿੱਚ ਰੁਕਾਵਟ ਪਵੇਗੀ।

ਹਰੇਕ ਸਟੈਕ ਵਿੱਚ ਸਿਲੀਕੋਨ ਲੈਬਜ਼ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਅਧਾਰ ਤੇ ਤਰਜੀਹਾਂ ਦਾ ਇੱਕ ਡਿਫੌਲਟ ਸੈੱਟ ਹੁੰਦਾ ਹੈ ਕਿ ਡਿਊਟੀ ਚੱਕਰ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਕਿਵੇਂ ਸਹਿਯੋਗ ਕਰਨਾ ਹੈ ਅਤੇ ਇੱਕ ਆਮ ਵਰਤੋਂ ਦੇ ਕੇਸ ਲਈ ਡ੍ਰੌਪ ਕੁਨੈਕਸ਼ਨਾਂ ਤੋਂ ਬਚਣਾ ਹੈ। ਖਾਸ ਵਰਤੋਂ ਦੇ ਕੇਸਾਂ ਦੀਆਂ ਵੱਖੋ ਵੱਖਰੀਆਂ ਲੋੜਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਤਰਜੀਹਾਂ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹਨ, ਉੱਚ ਤੋਂ ਹੇਠਲੇ ਤੱਕ

1.  ਬਲੂਟੁੱਥ LE ਅਨੁਸੂਚਿਤ ਟ੍ਰਾਂਸਮਿਟ
2.  ਬਲੂਟੁੱਥ LE ਅਨੁਸੂਚਿਤ ਪ੍ਰਾਪਤ
3.  ਹੋਰ ਪ੍ਰੋਟੋਕੋਲ ਅਨੁਸੂਚਿਤ ਟ੍ਰਾਂਸਮਿਟ
4.  ਹੋਰ ਪ੍ਰੋਟੋਕੋਲ ਬੈਕਗ੍ਰਾਉਂਡ ਪ੍ਰਾਪਤ ਕਰੋ

ਇਹ ਤਰਜੀਹਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦੁਆਰਾ ਓਵਰਰਾਈਡ ਜਾਂ ਬਦਲੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਬਿਨੈਪੱਤਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕਿਨ੍ਹਾਂ ਹਾਲਾਤਾਂ ਵਿੱਚ ਬਦਲਣਾ ਹੈ। ਸੈਕਸ਼ਨ 4.2 802.15.4 ਰੇਲ ਪ੍ਰਾਥਮਿਕਤਾ ਅਤੇ ਸੈਕਸ਼ਨ 6.1 ਬਲੂਟੁੱਥ ਤਰਜੀਹਾਂ ਵਿੱਚ ਉਹਨਾਂ ਦੀਆਂ ਖਾਸ ਸਥਿਤੀਆਂ ਲਈ ਤਰਜੀਹਾਂ ਬਾਰੇ ਹੋਰ ਵੇਰਵੇ ਸ਼ਾਮਲ ਹਨ।

ਸਲਿੱਪ ਟਾਈਮ

ਹਰੇਕ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਦਾ ਇੱਕ "ਸਲਿੱਪ ਸਮਾਂ" ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਜਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ, ਭਾਵ ਭਵਿੱਖ ਵਿੱਚ ਸਭ ਤੋਂ ਦੂਰ ਦਾ ਸਮਾਂ ਜਦੋਂ ਓਪਰੇਸ਼ਨ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ ਇਹ ਬੇਨਤੀ ਕੀਤੇ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ 'ਤੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਸ਼ਡਿਊਲਰ ਨੂੰ ਉੱਚ ਤਰਜੀਹੀ ਇਵੈਂਟਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਜੋ ਇੱਕੋ ਸਮੇਂ ਵਾਪਰ ਰਹੀਆਂ ਹਨ, ਜਾਂ ਉੱਚ ਤਰਜੀਹ ਵਾਲੇ ਇਵੈਂਟਸ ਜੋ ਉਹਨਾਂ ਦੀ ਉਮੀਦ ਕੀਤੀ ਮਿਆਦ ਤੋਂ ਵੱਧ ਹਨ। ਪ੍ਰੋਟੋਕੋਲ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਸਲਿੱਪ ਸਮਾਂ ਕੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਇਸ ਨੂੰ ਪ੍ਰਤੀ-ਓਪਰੇਸ਼ਨ ਦੇ ਆਧਾਰ 'ਤੇ ਸੰਭਾਲਣ ਦੇ ਸਮਰੱਥ ਹੈ, ਜਿਸ ਨਾਲ ਸਟੈਕ ਕੁਝ ਘਟਨਾਵਾਂ ਨੂੰ ਖਿਸਕਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਪਰ ਹੋਰਾਂ ਨੂੰ ਨਹੀਂ। ਆਮ ਤੌਰ 'ਤੇ, IEEE02.15.4 ਦਾ ਸਲਿੱਪ ਸਮਾਂ ਲੰਬਾ ਹੁੰਦਾ ਹੈ ਅਤੇ ਬਲੂਟੁੱਥ LE ਦਾ ਘੱਟ ਤੋਂ ਘੱਟ ਸਲਿੱਪ ਸਮਾਂ ਹੁੰਦਾ ਹੈ।

ਪੈਦਾਵਾਰ

ਇੱਕ ਵਾਰ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨਾਂ ਦਾ ਇੱਕ ਕ੍ਰਮ ਸਰਗਰਮੀ ਨਾਲ ਚਲਾਇਆ ਜਾ ਰਿਹਾ ਹੈ, ਸਟੈਕ ਸ਼ੁਰੂਆਤੀ ਕਾਰਵਾਈ ਨੂੰ ਵਧਾਉਣ ਲਈ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਜੋੜਨਾ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਸਟੈਕ ਕੋਲ ਖਾਸ ਸੰਦੇਸ਼ ਐਕਸਚੇਂਜ ਲਈ ਹੋਰ ਕੁਝ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਸਟੈਕ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਉਦੋਂ ਤੱਕ ਪੈਦਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਇਹ ਇੱਕ ਬੈਕਗ੍ਰਾਉਂਡ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੁੰਦਾ। ਜੇਕਰ ਇੱਕ ਸਟੈਕ ਉਪਜ ਨਹੀਂ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਇਸਦੇ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਨੂੰ ਵਧਾਉਣਾ ਜਾਰੀ ਰੱਖੇਗਾ, ਅਤੇ ਘੱਟ ਤਰਜੀਹ ਵਾਲੇ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਫਿਰ ਸੰਬੰਧਿਤ ਸਟੈਕ ਵਿੱਚ ਇੱਕ ਅਸਫਲਤਾ ਨੂੰ ਟਰਿੱਗਰ ਕਰਨਗੇ ਜਿਸਨੇ ਉਸ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਦੀ ਬੇਨਤੀ ਕੀਤੀ ਸੀ। ਇੱਕ ਉੱਚ ਤਰਜੀਹੀ ਓਪਰੇਸ਼ਨ ਵਰਤਮਾਨ ਵਿੱਚ ਚੱਲ ਰਹੇ, ਘੱਟ ਤਰਜੀਹ ਵਾਲੇ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਵਿਘਨ ਨਹੀਂ ਪਾ ਸਕਦਾ ਹੈ ਜਿਸਦਾ ਨਤੀਜਾ ਨਹੀਂ ਨਿਕਲਿਆ ਹੈ। ਸੈਕਸ਼ਨ 5.1 ਦੇਖੋampਸਾਬਕਾ ਲਈ ਬੈਕਗ੍ਰਾਉਂਡ ਰਿਸੀਵ, ਯੀਲਡ ਰੇਡੀਓ ਅਤੇ ਸਟੇਟ ਟ੍ਰਾਂਜਿਸ਼ਨ ਦੇ ਨਾਲampਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਜਿੱਥੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਰੇਡੀਓ ਨੂੰ ਉਪਜਾਉਣਾ ਜ਼ਰੂਰੀ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਰੁਕਾਵਟ

ਇੱਕ ਅਨੁਸੂਚਿਤ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਵਿੱਚ ਵਿਘਨ ਪੈ ਸਕਦਾ ਹੈ ਜੇਕਰ ਇੱਕ ਉੱਚ ਤਰਜੀਹੀ ਓਪਰੇਸ਼ਨ ਇਸਦਾ ਵਿਰੋਧ ਕਰਦਾ ਹੈ। ਇਹ ਹੇਠ ਲਿਖੀਆਂ ਦੋ ਸਥਿਤੀਆਂ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ:

1. ਇੱਕ ਅਨੁਸੂਚਿਤ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਉਮੀਦ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੈਂਦਾ ਹੈ ਅਤੇ ਸੰਬੰਧਿਤ ਸਟੈਕ ਉੱਚ ਤਰਜੀਹ ਵਾਲੇ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਨੂੰ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦਾ ਹੈ।
2. ਇੱਕ ਉੱਚ ਤਰਜੀਹੀ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਹੁਣੇ ਹੀ ਭਵਿੱਖ ਵਿੱਚ ਹੋਣ ਲਈ ਨਿਯਤ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਨਿਯਤ ਘੱਟ ਤਰਜੀਹ ਵਾਲੇ ਓਪਰੇਸ਼ਨ ਨਾਲ ਟਕਰਾਅ ਹੈ

ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਰੇਡੀਓ ਸੰਚਾਲਨ

ਕੁਝ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨਾਂ ਦਾ ਉਤਪਾਦ ਦੇ ਸਹੀ ਸੰਚਾਲਨ 'ਤੇ ਬਾਹਰੀ ਪ੍ਰਭਾਵ ਹੋ ਸਕਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇਹਨਾਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਵਿਚਕਾਰ ਤਾਲਮੇਲ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ ਨਹੀਂ ਆਉਂਦੀ ਤਾਂ ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਦੀਆਂ ਤਰਜੀਹਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਵੇਗੀ। ਸਾਬਕਾ ਲਈample, ਇੱਕ IEEE 802.15.4 ਊਰਜਾ ਸਕੈਨ ਲਈ ਲੋੜੀਂਦੀ ਊਰਜਾ ਰੀਡਿੰਗਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਲਈ ਰੇਡੀਓ ਨੂੰ ਚਾਲੂ ਰੱਖਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ ਸਹੀ ਢੰਗ ਨਾਲ ਓਪਰੇਸ਼ਨਾਂ ਦਾ ਤਾਲਮੇਲ ਨਹੀਂ ਕਰਦੀ ਹੈ, ਤਾਂ ਉੱਚ ਤਰਜੀਹ ਵਾਲੇ ਬਲੂਟੁੱਥ ਓਪਰੇਸ਼ਨ ਦੇ ਕਾਰਨ ਸਕੈਨ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਸਾਬਕਾamples

ਸਾਰੇ ਸਾਬਕਾamples ਬਲੂਟੁੱਥ LE ਅਤੇ Zigbee ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਪਰ ਸਿਧਾਂਤ ਹੋਰ ਬਲੂਟੁੱਥ/802.15.4 ਸੰਜੋਗਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।

ਸ਼ਡਿਊਲਰ ਘੱਟ ਤਰਜੀਹ ਵਾਲੇ ਜ਼ਿਗਬੀ ਬੈਕਗ੍ਰਾਊਂਡ ਰਿਸੀਵ ਓਪਰੇਸ਼ਨ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਹਮੇਸ਼ਾ-ਚਾਲੂ ਰਾਊਟਰ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਅਣਜਾਣ ਸਮੇਂ 'ਤੇ IEEE 802.15.4 ਪੈਕੇਟ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ। ਇੱਕ ਬਲੂਟੁੱਥ LE ਕਨੈਕਸ਼ਨ ਵੀ ਕਿਰਿਆਸ਼ੀਲ ਹੈ ਅਤੇ ਸਟੈਕ ਨੂੰ ਹਰ 30 ms ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋਣ ਦੀ ਲੋੜ ਹੈ। ਬਲੂਟੁੱਥ LE ਸਟੈਕ ਕਨੈਕਸ਼ਨ ਦੀ ਰੀਡੈਕਟੇਬਲ ਪ੍ਰਕਿਰਤੀ ਦੇ ਕਾਰਨ ਇਸ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਤਹਿ ਕਰ ਸਕਦਾ ਹੈ।

ਤਰਜੀਹੀ ਸਮਾਂ-ਸਾਰਣੀ

ਇਹ ਇੱਕ ਬੁਨਿਆਦੀ ਸਾਬਕਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈampਵੱਖ-ਵੱਖ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨਾਂ ਦੀਆਂ ਤਰਜੀਹਾਂ ਦਾ ਨਿਰਣਾ ਕਰਨਾ।

Zigbee ਸਟੈਕ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਇੱਕ ਪੈਕੇਟ ਭੇਜਣ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਇੱਕ ਆਨ-ਡਿਮਾਂਡ ਇਵੈਂਟ ਦੇ ਤੌਰ 'ਤੇ ਅਜਿਹਾ ਕਰ ਸਕਦਾ ਹੈ, ਭਾਵ ਸਟੈਕ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਸ਼ਡਿਊਲਰ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਸੂਚਿਤ ਕੀਤੇ ਬਿਨਾਂ ਹੁਣ ਇੱਕ ਪੈਕੇਟ ਭੇਜਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਇਹ ਇਸ ਦੇ ਉਲਟ ਹੈ ਕਿ ਬਲੂਟੁੱਥ LE ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ ਅਨੁਸੂਚਿਤ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ। ਸ਼ਡਿਊਲਰ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ ਕਿ Zigbee TX 1 ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਕਰਨਾ ਸੰਭਵ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਭਵਿੱਖ ਵਿੱਚ ਉੱਚ ਤਰਜੀਹ ਵਾਲੇ ਬਲੂਟੁੱਥ LE ਰਿਸੈਪਸ਼ਨ ਇਵੈਂਟ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ। ਇਸ ਲਈ ਸ਼ਡਿਊਲਰ ਪ੍ਰਸਾਰਿਤ ਘਟਨਾ ਵਾਪਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ. ਜ਼ਿਗਬੀ ਸਟੈਕ ਇਸ ਟ੍ਰਾਂਸਮਿਟ ਓਪਰੇਸ਼ਨ ਦੇ ਸਾਰੇ ਟੁਕੜਿਆਂ ਨੂੰ ਕਰਦਾ ਹੈ (ਇੱਕ MAC ack ਦੀ ਉਡੀਕ ਵਿੱਚ), ਅਤੇ ਫਿਰ ਸਵੈ-ਇੱਛਾ ਨਾਲ ਝਾੜ ਦਿੰਦਾ ਹੈ। ਜ਼ਿਗਬੀ ਟ੍ਰਾਂਸਮਿਟ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਦੇ ਅੰਦਾਜ਼ਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਸਮੇਂ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ਾਂ ਸ਼ਾਮਲ ਨਹੀਂ ਹਨ।

ਇਸ ਵਿੱਚ ਸਾਬਕਾample, ਬਲੂਟੁੱਥ LE ਪਹਿਲਾਂ ਹੀ ਭਵਿੱਖ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਤਹਿ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ Zigbee ਸਟੈਕ ਪ੍ਰਸਾਰਿਤ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ। ਪਹਿਲੇ Zigbee TX 1 ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਲਈ ਬਲੂਟੁੱਥ LE RX 1 ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਕਾਫ਼ੀ ਸਮਾਂ ਹੁੰਦਾ ਹੈ ਇਸ ਲਈ ਸ਼ਡਿਊਲਰ ਸਟੈਕ ਨੂੰ ਓਪਰੇਸ਼ਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਬਾਅਦ ਵਿੱਚ, ਜਦੋਂ Zigbee ਸਟੈਕ Zigbee TX 2 ਨੂੰ ਤਹਿ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਤਾਂ ਸ਼ਡਿਊਲਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਉੱਚ ਤਰਜੀਹ ਵਾਲੇ ਬਲੂਟੁੱਥ LE RX 2 ਇਵੈਂਟ ਤੋਂ ਪਹਿਲਾਂ ਕਾਫ਼ੀ ਸਮਾਂ ਨਹੀਂ ਹੈ। ਹਾਲਾਂਕਿ, Zigbee ਸਟੈਕ ਨੇ ਸੰਕੇਤ ਦਿੱਤਾ ਹੈ ਕਿ ਇਹ ਕਾਰਵਾਈ ਇਸਦੇ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਨੂੰ ਖਿਸਕ ਸਕਦੀ ਹੈ। ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਬਲੂਟੁੱਥ LE ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਦੀ ਸੰਭਾਵਿਤ ਮਿਆਦ ਦੇ ਮੱਦੇਨਜ਼ਰ ਜ਼ਿਗਬੀ ਓਪਰੇਸ਼ਨ ਉਸ ਘਟਨਾ ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਅਜੇ ਵੀ ਜ਼ਿਗਬੀ ਸਟੈਕ ਦੁਆਰਾ ਦਰਸਾਏ ਗਏ ਸਲਿੱਪ ਸਮੇਂ ਦੇ ਅੰਦਰ ਹੋ ਸਕਦਾ ਹੈ।

ਜੇਕਰ ਸਭ ਕੁਝ ਉਮੀਦ ਅਨੁਸਾਰ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਜ਼ਿਗਬੀ ਟ੍ਰਾਂਸਮਿਟ ਓਪਰੇਸ਼ਨ ਦਾ ਪਹਿਲਾ ਯਤਨ ਸਮਾਂ-ਸਾਰਣੀ ਦੇ ਕਾਰਨ ਬਿਨਾਂ ਕਿਸੇ ਅਸਫਲਤਾ ਦੇ ਹੋਵੇਗਾ।

ਤਰਜੀਹੀ ਰੁਕਾਵਟ ਸਾਬਕਾample

ਇਹ ਸਾਬਕਾample ਇੱਕ ਉੱਚ ਤਰਜੀਹੀ ਕਾਰਵਾਈ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਘੱਟ ਤਰਜੀਹ ਵਾਲੇ ਇੱਕ ਵਿੱਚ ਰੁਕਾਵਟ ਪਾਉਂਦਾ ਹੈ।

 

 

 

ਇਹ ਸਾਬਕਾample ਪਿਛਲੇ ਸਾਬਕਾ ਵਾਂਗ ਹੀ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈample. Zigbee ਅਤੇ ਬਲੂਟੁੱਥ LE ਦੋਵਾਂ ਕੋਲ ਇੱਕ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਹੈ ਜੋ ਬਿਨਾਂ ਕਿਸੇ ਟੱਕਰ ਦੇ ਤਹਿ ਕੀਤਾ ਗਿਆ ਹੈ

ਬਾਅਦ ਵਿੱਚ, Zigbee ਸਟੈਕ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਇਹ Zigbee TX 2 ਇਵੈਂਟ ਲਈ ਇੱਕ ਹੋਰ ਪੈਕੇਟ ਭੇਜਣਾ ਚਾਹੁੰਦਾ ਹੈ। ਸ਼ਡਿਊਲਰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ Zigbee TX 2 ਇਵੈਂਟ ਨੂੰ ਲੱਗਣ ਵਾਲੇ ਘੱਟੋ-ਘੱਟ ਸਮੇਂ ਦੇ ਆਧਾਰ 'ਤੇ, ਇਸ ਇਵੈਂਟ ਨੂੰ ਤਹਿ ਕਰਨਾ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਬਲੂਟੁੱਥ LE RX 2 ਇਵੈਂਟ ਦੀ ਸੇਵਾ ਕਰਨਾ ਸੰਭਵ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਹਾਲਾਂਕਿ, Zigbee TX 2 ਇਵੈਂਟ ਲੰਬੇ ਬੇਤਰਤੀਬੇ ਬੈਕਆਫ ਦੇ ਕਾਰਨ ਉਮੀਦ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੈਂਦਾ ਹੈ ਅਤੇ ਸਮੇਂ ਸਿਰ ਉਪਜ ਨਹੀਂ ਦਿੰਦਾ। ਇਹ ਇਵੈਂਟ ਨੂੰ ਉੱਚ ਤਰਜੀਹੀ ਰੈਡ ਪਰੀਸ਼ਨ ਨਾਲ ਟਕਰਾਉਣ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਜ਼ਿਗਬੀ ਈਵੈਂਟ ਵਿੱਚ ਵਿਘਨ ਪਾਉਂਦਾ ਹੈ ਅਤੇ ਉੱਚ ਪੱਧਰੀ ਸਟੈਕ ਵਿੱਚ ਅਸਫਲਤਾ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਬਲੂਟੁੱਥ LE ਇਵੈਂਟ ਆਮ ਤੌਰ 'ਤੇ ਵਾਪਰਦਾ ਹੈ ਅਤੇ ਜਦੋਂ ਇਹ ਪੂਰਾ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਇਹ ਸਵੈਇੱਛਤ ਤੌਰ 'ਤੇ ਕਿਸੇ ਵੀ ਘੱਟ ਤਰਜੀਹੀ ਓਪਰੇਸ਼ਨ ਲਈ ਪੈਦਾ ਹੁੰਦਾ ਹੈ।

ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਤੋਂ ਅਸਫਲਤਾ ਪ੍ਰਾਪਤ ਕਰਨ 'ਤੇ Zigbee ਸਟੈਕ ਤੁਰੰਤ MAC ਸੁਨੇਹੇ ਨੂੰ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਇਹ ਕਾਰਵਾਈ ਨੂੰ ਤਹਿ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸਲਿੱਪ ਸਮਾਂ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। ਇਸ ਬਿੰਦੂ 'ਤੇ ਬਲੂਟੁੱਥ LE ਸਟੈਕ ਦੀ ਰੇਡੀਓ ਨਾਲੋਂ ਤਰਜੀਹ ਹੈ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਓਪਰੇਸ਼ਨ ਅਜੇ ਸ਼ੁਰੂ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਸ਼ਡਿਊਲਰ ਨਵੇਂ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਬਲੂਟੁੱਥ LE ਸਟੈਕ ਆਪਣੀ ਅਨੁਸੂਚਿਤ ਪ੍ਰਾਪਤੀ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ ਅਤੇ ਰੇਡੀਓ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਸ਼ਡਿਊਲਰ ਫਿਰ ਜ਼ਿਗਬੀ ਟਰਾਂਸਮਿਟ ਓਪਰੇਸ਼ਨ ਨੂੰ ਚਾਲੂ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਅਜੇ ਵੀ ਸ਼ੁਰੂਆਤੀ ਸ਼ੁਰੂਆਤੀ ਕਾਰਵਾਈ ਦੇ ਸਲਿੱਪ ਸਮੇਂ ਦੇ ਅੰਦਰ ਹੈ। ਟਰਾਂਸਮਿਟ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸ਼ਡਿਊਲਰ ਬੈਕਗ੍ਰਾਊਂਡ ਰਿਸੀਵ ਓਪਰੇਸ਼ਨ 'ਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ।

ਉੱਚ ਤਰਜੀਹੀ ਓਪਰੇਸ਼ਨ ਜੋ ਵਧਾਇਆ ਗਿਆ ਹੈ

ਇਹ ਸਾਬਕਾample ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇੱਕ ਉੱਚ ਤਰਜੀਹੀ ਓਪਰੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਅਨੁਮਾਨ ਤੋਂ ਵੱਧ ਸਮਾਂ ਲੈਂਦੀ ਹੈ ਅਤੇ ਇੱਕ ਘੱਟ ਤਰਜੀਹੀ ਓਪਰੇਸ਼ਨ ਇਸਦੇ ਮੌਕੇ ਨੂੰ ਗੁਆ ਦਿੰਦਾ ਹੈ

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਬਲੂਟੁੱਥ LE ਵਿੱਚ ਇੱਕ ਅਨੁਸੂਚਿਤ ਪ੍ਰਾਪਤੀ ਹੈ ਜੋ ਵਰਤਮਾਨ ਵਿੱਚ ਹੋ ਰਹੀ ਹੈ। ਜ਼ਿਗਬੀ ਨੇ ਇੱਕ ਪੈਕੇਟ ਭੇਜਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਪਰ ਇਸਨੂੰ ਹੁਣੇ ਨਹੀਂ ਚਲਾਇਆ ਜਾ ਸਕਦਾ। ਸ਼ਡਿਊਲਰ ਇਸ ਧਾਰਨਾ ਦੇ ਤਹਿਤ ਕਾਰਵਾਈ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਕਿ ਬਲੂਟੁੱਥ LE ਇਵੈਂਟ Zigbee ਇਵੈਂਟ ਦੇ ਸਲਿੱਪ ਸਮੇਂ ਦੇ ਅੰਤ ਤੋਂ ਪਹਿਲਾਂ ਪੂਰਾ ਹੋ ਜਾਵੇਗਾ। ਹਾਲਾਂਕਿ, ਬਲੂਟੁੱਥ LE ਇਵੈਂਟ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਵਧਦਾ ਹੈ ਕਿ ਡਿਵਾਈਸਾਂ ਵਿਚਕਾਰ ਵਾਧੂ ਪੈਕੇਟ ਭੇਜੇ ਜਾਂਦੇ ਹਨ। ਬਲੂਟੁੱਥ LE ਓਪਰੇਸ਼ਨ ਦੀ ਤਰਜੀਹ ਹੈ ਇਸਲਈ Zigbee ਓਪਰੇਸ਼ਨ ਆਖਰਕਾਰ ਸਲਿੱਪ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਗਲਤੀ ਸਟੈਕ ਵਿੱਚ ਵਾਪਸ ਆ ਗਈ ਹੈ। ਜ਼ਿਗਬੀ ਨੇ ਪੈਕੇਟ ਨੂੰ ਦੁਬਾਰਾ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਦੁਬਾਰਾ ਫਿਰ, ਜ਼ਿਗਬੀ ਸਟੈਕ ਸੰਕੇਤ ਕਰਦਾ ਹੈ ਕਿ ਕਾਰਵਾਈ ਹੁਣ ਸ਼ੁਰੂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਪਰ ਭਵਿੱਖ ਵਿੱਚ ਖਿਸਕ ਸਕਦੀ ਹੈ। ਸ਼ਡਿਊਲਰ ਰੇਡੀਓ ਸੰਰਚਨਾ ਨੂੰ ਬਦਲਣ ਦੇ ਵਿਚਕਾਰ ਹੈ ਇਸਲਈ ਇਹ ਤੁਰੰਤ ਕਾਰਵਾਈ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਰੇਡੀਓ ਓਪਰੇਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਦੇ ਸਮੇਂ ਨੂੰ ਥੋੜੀ ਮਾਤਰਾ ਵਿੱਚ ਘਟਾਉਂਦਾ ਹੈ ਅਤੇ ਫਿਰ ਓਪਰੇਸ਼ਨ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ।

ਬਿਨਾਂ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ ਉੱਚ ਤਰਜੀਹੀ ਓਪਰੇਸ਼ਨ 

ਇਸ ਵਿੱਚ ਸਾਬਕਾample ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਬਲੂਟੁੱਥ 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) ਤੱਕ ਤਰਜੀਹ ਵਧਾਉਂਦਾ ਹੈ। ਲੋੜ ਹੈ ਜੇਕਰ ਸੁਨੇਹੇ ਸਫਲ ਨਹੀਂ ਹੋ ਰਹੇ ਹਨ।

ਜਿਵੇਂ ਕਿ ਪਿਛਲੇ ਸੈਕਸ਼ਨ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਇੱਕ 802.15.4-ਅਧਾਰਿਤ ਸਟੈਕ ਜਿਵੇਂ ਕਿ ਜ਼ਿਗਬੀ ਜਾਂ ਕਨੈਕਟ ਬੈਕਗ੍ਰਾਉਂਡ RX ਲਈ 255, ਕਿਰਿਆਸ਼ੀਲ RX ਲਈ 255, ਅਤੇ ਕਿਰਿਆਸ਼ੀਲ TX ਲਈ 100 ਦੇ ਡਿਫੌਲਟ ਰੇਲ ਤਰਜੀਹੀ ਮੁੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਇਹਨਾਂ ਡਿਫਾਲਟ ਰੇਲ ਤਰਜੀਹਾਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ, ਇੱਕ 802.15.4 ਪ੍ਰੋਟੋਕੋਲ-ਬਲਿਊਟੁੱਥ ਮਲਟੀਪ੍ਰੋਟੋਕਾਲ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ, ਮੂਲ ਰੂਪ ਵਿੱਚ ਬਲੂਟੁੱਥ ਟ੍ਰੈਫਿਕ ਹਮੇਸ਼ਾ 802.15.4 ਪ੍ਰੋਟੋਕੋਲ ਟ੍ਰੈਫਿਕ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਲਵੇਗਾ। ਇਹ ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਇੱਕ ਵਧੀਆ ਵਿਕਲਪ ਹੈ, ਕਿਉਂਕਿ ਬਲੂਟੁੱਥ ਟ੍ਰੈਫਿਕ ਵਿੱਚ 802.15.4 ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਉਲਟ, ਸਮੇਂ ਦੀਆਂ ਸਖ਼ਤ ਜ਼ਰੂਰਤਾਂ ਹਨ। ਹਾਲਾਂਕਿ, ਜੇਕਰ ਬਲੂਟੁੱਥ ਟ੍ਰੈਫਿਕ ਲੋਡ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈample, ਇੱਕ ਬਹੁਤ ਹੀ ਛੋਟੇ ਕੁਨੈਕਸ਼ਨ ਅੰਤਰਾਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬਹੁਤ ਸਾਰਾ ਡਾਟਾ ਭੇਜਣਾ), 802.15.4 ਪ੍ਰੋਟੋਕੋਲ ਟ੍ਰੈਫਿਕ ਲਈ ਰੇਡੀਓ ਤੱਕ ਪਹੁੰਚ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਲੌਕ ਕੀਤਾ ਜਾਣਾ ਸੰਭਵ ਹੈ ਕਿਉਂਕਿ ਇਸਦੀ ਘੱਟ ਤਰਜੀਹ ਅਤੇ ਬਲੂਟੁੱਥ ਦੁਆਰਾ ਬਚੇ ਰੇਡੀਓ ਸਮੇਂ ਦੀਆਂ ਬਹੁਤ ਛੋਟੀਆਂ ਵਿੰਡੋਜ਼ ਹਨ। ਆਵਾਜਾਈ

ਨੋਟ ਕਰੋ: ਨਿਮਨਲਿਖਤ ਜਾਣਕਾਰੀ ਵਰਤਮਾਨ ਵਿੱਚ ਸਿਰਫ EmberZNet Zigbee ਸਟੈਕ 'ਤੇ ਲਾਗੂ ਹੈ। Silicon Labs Connect ਕੋਲ ਅਜੇ ਤੱਕ ਤਰਜੀਹਾਂ ਨੂੰ ਬਦਲਣ ਲਈ ਲੋੜੀਂਦਾ API ਨਹੀਂ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ 802.15.4-ਅਧਾਰਿਤ ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਵਿਕਸਤ ਕਰ ਰਹੇ ਹੋ, ਅਤੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਬਲੂਟੁੱਥ ਟ੍ਰੈਫਿਕ ਦੀ ਮੌਜੂਦਗੀ ਵਿੱਚ ਉਸ ਟ੍ਰੈਫਿਕ ਦਾ ਸਫਲ ਹੋਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੀ API ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਵਿੱਚ ਦਰਸਾਏ ਅਨੁਸਾਰ ਡਿਫੌਲਟ ਤਰਜੀਹਾਂ ਨੂੰ ਅਨੁਕੂਲ ਕਰ ਸਕਦੇ ਹੋ:

ਨੰ.	ਨਾਮ	ਪੂਰਵ-ਨਿਰਧਾਰਤ ਸੈਟਿੰਗ
1	ਐਕਟਿਵ TX	23
2	ਸਰਗਰਮ RX	24
3	ਬੈਕਗ੍ਰਾਊਂਡ RX	255

ਕਿਉਂਕਿ ਬਲੂਟੁੱਥ ਸ਼ੁਰੂ ਵਿੱਚ ਆਪਣੀ ਰੇਲ ਪ੍ਰਾਥਮਿਕਤਾ ਨੂੰ 32 'ਤੇ ਸੈੱਟ ਕਰਦਾ ਹੈ, ਇਹ 802.15.4 ਤਰਜੀਹ ਸੈਟਿੰਗਾਂ ਸ਼ੁਰੂ ਵਿੱਚ ਬਲੂਟੁੱਥ ਨਾਲੋਂ 802.15.4 ਟ੍ਰੈਫਿਕ ਨੂੰ ਉੱਚ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਹਨ, ਜੋ ਕਿ 802.15.4 ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਇੱਕ ਬਹੁਤ ਦੀ ਮੌਜੂਦਗੀ ਵਿੱਚ ਵੀ ਸਫਲਤਾਪੂਰਵਕ ਆਵਾਜਾਈ ਨੂੰ ਸੰਚਾਰਿਤ ਕਰਨ ਜਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਮੌਕਾ ਦਿੰਦੀ ਹੈ। ਬਲੂਟੁੱਥ ਟ੍ਰੈਫਿਕ ਦਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ। ਦੂਜੇ ਪਾਸੇ, ਬਲੂਟੁੱਥ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਆਪਣੀ ਤਰਜੀਹ ਵਧਾਏਗਾ ਜੇਕਰ ਇਹ ਸ਼ਡਿਊਲਰ ਤੋਂ 802.15.4 ਟ੍ਰੈਫਿਕ ਦੁਆਰਾ ਬੰਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, 16 ਦੀ ਉੱਚ ਤਰਜੀਹ ਤੱਕ। ਇਸ ਤਰ੍ਹਾਂ 802.15.4 ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਰੇਡੀਓ ਤੱਕ ਪਹੁੰਚ ਦੀ ਆਗਿਆ ਦੇਣ ਤੋਂ ਬਾਅਦ, ਬਲੂਟੁੱਥ ਲਵੇਗਾ। ਜੇਕਰ ਲੋੜ ਹੋਵੇ ਤਾਂ ਅਗਲੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ 'ਤੇ ਤਰਜੀਹ।

ਇਹ ਪਹੁੰਚ ਦੋਨਾਂ ਪ੍ਰੋਟੋਕੋਲਾਂ ਨੂੰ ਰੇਡੀਓ ਦੀ ਵਰਤੋਂ 'ਤੇ ਸਮਝੌਤਾ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ, ਬਿਨਾਂ ਇੱਕ ਦੂਜੇ 'ਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਾਵੀ ਹੋਣ ਦੇ ਯੋਗ ਹੋਣ ਦੇ.

. ਰੇਲ ਨਾਲ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਲਾਗੂ ਕਰਨਾ 

ਇਹ ਅਧਿਆਇ ਉਹਨਾਂ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਰੇਲ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਾਰੇ ਵਧੇਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜੋ ਮਲਕੀਅਤ ਪ੍ਰੋਟੋਕੋਲ ਵਿਕਸਤ ਕਰਨ ਲਈ ਸਿੱਧੇ RAIL API ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਖਾਸ ਤੌਰ 'ਤੇ ਇਹ ਖਾਸ ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਕੇਸਾਂ ਨੂੰ ਸੰਭਾਲਣ ਲਈ RAIL APIs ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ ਬਾਰੇ ਵੇਰਵੇ ਪੇਸ਼ ਕਰਦਾ ਹੈ।

Exampਬੈਕਗ੍ਰਾਉਂਡ ਰਿਸੀਵ, ਯੀਲਡ ਰੇਡੀਓ ਅਤੇ ਸਟੇਟ ਟ੍ਰਾਂਜਿਸ਼ਨ ਦੇ ਨਾਲ

ਰੇਲ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਪ੍ਰਾਥਮਿਕਤਾ ਪ੍ਰਣਾਲੀ ਦੇ ਬੁਨਿਆਦੀ ਤੱਤ ਕਾਫ਼ੀ ਸਿੱਧੇ ਹਨ: ਇੱਕ ਉੱਚ ਤਰਜੀਹ ਵਾਲਾ ਇੱਕ ਰੇਡੀਓ ਇਵੈਂਟ (ਜੋ ਕਿ ਸੰਖਿਆ ਵਿੱਚ ਛੋਟਾ ਹੈ) ਹਮੇਸ਼ਾ ਘੱਟ ਤਰਜੀਹ ਵਾਲੇ ਕਿਸੇ ਹੋਰ ਰੇਡੀਓ ਇਵੈਂਟ ਨੂੰ ਹੜੱਪ ਲਵੇਗਾ। ਹਾਲਾਂਕਿ, ਇਹ ਵਿਸ਼ਾ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਸਟੇਟ ਪਰਿਵਰਤਨ ਅਤੇ APIs ਜਿਵੇਂ ਕਿ RAIL_StartRx(), ਜੋ ਕਿ ਰੇਡੀਓ ਨੂੰ ਇੱਕ ਅਨਿਸ਼ਚਿਤ ਸਮੇਂ ਲਈ ਇੱਕ ਨਿਸ਼ਚਿਤ ਅਵਸਥਾ ਵਿੱਚ ਰੱਖਦੇ ਹਨ। ਇਹ ਭਾਗ ਕੁਝ ਦ੍ਰਿਸ਼ਟਾਂਤ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈampਇਹ ਦਰਸਾਉਣ ਲਈ ਕਿ ਇਹ ਸਮਾਂ-ਅਨਬਾਉਂਡ ਸਟੇਟਸ ਕਿਵੇਂ ਹੈਂਡਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕਿਵੇਂ ਐਪਲੀਕੇਸ਼ਨ ਲੇਅਰ ਉਹਨਾਂ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਲਈ RAIL_YieldRadio() ਵਰਗੇ API ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੀ ਹੈ। ਸਾਬਕਾamples ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹਨ:

• ਇੱਕ ਸਿੰਗਲ ਪ੍ਰੋਟੋਕੋਲ ਨਾਲ ਸਟੇਟ ਪਰਿਵਰਤਨ
• ਦੋ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਨਾਲ ਰਾਜ ਪਰਿਵਰਤਨ
• ਦੋ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਮੋਨੋਟੋਨੀਲੀ ਵਧ ਰਹੀ ਤਰਜੀਹਾਂ ਦੇ ਨਾਲ ਰਾਜ ਪਰਿਵਰਤਨ

ਇਨ੍ਹਾਂ ਵਿੱਚ ਸਾਬਕਾamples, RAIL_StartTx() TX ਇਵੈਂਟ ਦਾ ਸਰੋਤ ਹੈ ਜੋ ਪਿਛੋਕੜ RX ਨੂੰ ਰੋਕਦਾ ਹੈ। ਨੋਟ ਕਰੋ, ਹਾਲਾਂਕਿ, ਇਹ ਸਾਬਕਾamples RAIL_StartRx() ਨੂੰ ਛੱਡ ਕੇ ਕਿਸੇ ਵੀ ਰੇਡੀਓ API 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਸਾਬਕਾamples ਕਿਸੇ ਵੀ API 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ ਜੋ ਇੱਕ ਰੇਡੀਓ ਇਵੈਂਟ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਜੋ ਬੈਕਗ੍ਰਾਊਂਡ 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() ਨੂੰ ਕਾਲ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ, ਰੇਡੀਓ ਸ਼ੁਰੂ ਵਿੱਚ ਨਿਰਧਾਰਤ ਤਰਜੀਹ ਅਤੇ ਚੈਨਲ ਦੇ ਨਾਲ, RX ਤੇ ਵਾਪਸ ਆ ਜਾਂਦਾ ਹੈ।

ਰੇਡੀਓ ਨੂੰ ਸਰਗਰਮੀ ਨਾਲ ਪੈਦਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ RAIL_YieldRadio() API ACK'ing ਦੇ ਕਾਰਨ ਜ਼ਰੂਰੀ ਸੀ। ਡਿਜ਼ਾਈਨ ਫ਼ਲਸਫ਼ਾ ਇਹ ਹੈ ਕਿ, ਕਿਉਂਕਿ ਇੱਕ TX ਅਤੇ ਇੱਕ ਪ੍ਰਾਪਤ ACK ਦੋਵੇਂ ਹਨ viewed ਉਸੇ ਲੈਣ-ਦੇਣ ਦੇ ਹਿੱਸੇ ਵਜੋਂ, ਜੇਕਰ ਇੱਕ ਨੋਡ ਇੱਕ ACK ਨੂੰ ਸੰਚਾਰਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਇਹ RX ਵਿੱਚ ਤਬਦੀਲੀ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ACK ਨੂੰ ਉਸੇ ਓਪਰੇਸ਼ਨ (ਅਤੇ ਇਸਲਈ ਉਹੀ ਤਰਜੀਹ) ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਅਸਲੀ TX ਵਾਂਗ ਸੁਣਨਾ ਜਾਰੀ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਹਾਲਾਂਕਿ, ਰੇਲ ਆਪਣੇ ਆਪ ਇਹ ਨਹੀਂ ਜਾਣ ਸਕਦੀ ਕਿ 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 ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇੱਥੇ ਫਲਸਫਾ ਇਹ ਹੈ ਕਿ ਬੈਕਗ੍ਰਾਉਂਡ ਆਰਐਕਸ ਅਸਲ ਵਿੱਚ ਪੈਦਾ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਕਿਉਂਕਿ ਘਟਨਾ ਅਸਲ ਵਿੱਚ ਕਦੇ ਖਤਮ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਬਾਹਰ ਜਾਣ ਦਾ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੈ RAIL_Idle() ਨੂੰ ਇੱਕ ਕਾਲ ਦੇ ਨਾਲ ਪਿਛੋਕੜ RX ਨੂੰ ਰੋਕਣਾ।

 ਦੋ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਮੋਨੋਟੋਨੀਲੀ ਵਧ ਰਹੀ ਤਰਜੀਹ ਦੇ ਨਾਲ ਰਾਜ ਪਰਿਵਰਤਨ

ਅੰਤਮ ਦ੍ਰਿਸ਼ ਪਿਛਲੇ ਇੱਕ ਵਰਗਾ ਹੀ ਹੈ, ਸਿਵਾਏ ਪ੍ਰੋਟੋਕੋਲ B 'ਤੇ RAIL_StartRx() ਨੂੰ ਕਾਲ ਪ੍ਰੋਟੋਕੋਲ A 'ਤੇ RAIL_StartTx() ਨੂੰ ਕੀਤੀ ਗਈ ਕਾਲ ਨਾਲੋਂ ਉੱਚ ਤਰਜੀਹ 'ਤੇ ਹੈ।

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਕਿਉਂਕਿ ਦੂਜੇ RAIL_StartRx() ਦੀ ਤਰਜੀਹ RAIL_StartTx() ਦੀ ਕਾਲ ਦੀ ਤਰਜੀਹ ਨਾਲੋਂ ਵੱਧ ਹੈ, RAIL_YieldRadio() ਨੂੰ ਕਾਲ ਕਰਨ ਦੀ ਹੁਣ ਲੋੜ ਨਹੀਂ ਹੈ। ਕਿਉਂਕਿ ਦੂਜਾ RAIL_StartRx() ਉੱਚ ਤਰਜੀਹ 'ਤੇ ਹੈ, ਇਹ RAIL_StartTx() ਇਵੈਂਟ ਨੂੰ ਹੜੱਪ ਲੈਂਦਾ ਹੈ, ਰੇਡੀਓ ਦਾ ਕੰਟਰੋਲ ਲੈ ਲੈਂਦਾ ਹੈ ਅਤੇ TX ਇਵੈਂਟ ਨੂੰ ਰਾਜ ਤੋਂ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਪ੍ਰੋਟੋਕੋਲ B 'ਤੇ ਉਸ RX ਦੌਰਾਨ ਕਿਸੇ ਵੀ ਸਮੇਂ, RAIL_Idle() ਨੂੰ ਪ੍ਰੋਟੋਕੋਲ A 'ਤੇ RX 'ਤੇ ਵਾਪਸ ਜਾਣ ਲਈ ਬੁਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਪਿਛਲੇ ਐਕਸ.ample.

ਇੱਥੇ ਨੋਟ ਕਰੋ ਕਿ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ ਬੀ ਦੇ ਆਰਐਕਸ 'ਤੇ RAIL_Idle() ਨੂੰ ਕਾਲ ਕਰਦੀ ਹੈ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ A ਦੇ TX ਪਰਿਵਰਤਨ 'ਤੇ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦੀ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਬੈਕਗ੍ਰਾਉਂਡ RX 'ਤੇ ਜਾਂਦੀ ਹੈ, ਭਾਵੇਂ ਕਿ ਪ੍ਰੋਟੋਕੋਲ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਦੇ ਵੀ RAIL_Idle() ਨਹੀਂ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਏ ਦਾ 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()) ਓਪਰੇਸ਼ਨਾਂ ਤੋਂ ਇਲਾਵਾ API ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੇ ਗਏ ਹਨ। RAIL_Idle() ਅਸਲ ਵਿੱਚ ਅਜੇ ਵੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ TX ਪਰਿਵਰਤਨ ਸਥਿਤੀ ਤੋਂ ਬਾਹਰ ਨਿਕਲਣ ਦਾ ਕਾਰਨ ਬਣੇਗਾ, ਪਰ ਇਹ ਬੈਕਗ੍ਰਾਉਂਡ RX ਨੂੰ ਵੀ ਸਾਫ਼ ਕਰੇਗਾ, ਜਿਸ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਨਿਸ਼ਕਿਰਿਆ 'ਤੇ ਵਾਪਸ ਆ ਜਾਵੇਗੀ, ਨਾ ਕਿ RX।

ਬਲੂਟੁੱਥ ਨਾਲ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਲਾਗੂ ਕਰਨਾ

ਰੇਲ/ਬਲਿਊਟੁੱਥ ਲਾਈਟ/ਸਵਿੱਚ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਕਿਵੇਂ ਇਸ ਬਾਰੇ ਵੇਰਵੇ ਲਈ ਸਾਬਕਾample ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ RAIL 'ਤੇ ਤੁਹਾਡੇ ਆਪਣੇ ਪ੍ਰੋਟੋਕੋਲ ਨਾਲ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਐਪਲੀਕੇਸ਼ਨ ਵਿਕਸਿਤ ਕਰਨ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ, AN1134 ਦੇਖੋ: ਬਲੂਟੁੱਥ ਨਾਲ ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਡਿਵੈਲਪਮੈਂਟ ਅਤੇ GSDK v2.x ਵਿੱਚ ਰੇਲ 'ਤੇ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਜਾਂ AN1269 ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਡਿਵੈਲਪਮੈਂਟ ਨਾਲ ਬਲੂਟੁੱਥ ਅਤੇ ਪ੍ਰੋਪ੍ਰਾਇਟਰੀ ਪ੍ਰੋਪਰਾਈਲ. GSDK v3.x ਅਤੇ ਉੱਚ ਵਿੱਚ।

ਬਲੂਟੁੱਥ ਤਰਜੀਹਾਂ

ਵੱਖ-ਵੱਖ ਓਪਰੇਸ਼ਨ ਕਿਸਮਾਂ ਲਈ ਸਥਿਰ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਪ੍ਰਾਥਮਿਕਤਾਵਾਂ ਦੇ ਨਾਲ ਜ਼ਿਗਬੀ ਦੇ ਉਲਟ, ਬਲੂਟੁੱਥ ਤਰਜੀਹੀ ਸਪੈਕਟ੍ਰਮ ਦੇ ਦਿੱਤੇ ਗਏ ਖੇਤਰ ਲਈ ਸਾਰੇ ਕਾਰਜ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਇੱਕ ਰੇਂਜ ਅਤੇ ਆਫਸੈੱਟ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਇਸ ਵਿੱਚ ਸਾਬਕਾampਬਲੂਟੁੱਥ ਪ੍ਰਾਥਮਿਕਤਾ ਰੇਂਜ, ਜੋ ਕਿ ਆਪਣੇ ਆਪ ਵਿੱਚ 0 ਤੋਂ 255 ਤੱਕ ਫੈਲੀ ਹੋਈ ਹੈ, ਨੂੰ ਸ਼ੇਅਰਡ ਰੇਲ ਪ੍ਰਾਥਮਿਕਤਾ ਸਪੇਸ ਦੇ ਇੱਕ ਸੀਮਤ ਹਿੱਸੇ ਵਿੱਚ ਮੈਪ ਕੀਤਾ ਗਿਆ ਹੈ

Zigbee ਦੇ ਉਲਟ, ਬਲੂਟੁੱਥ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਖ਼ਤ ਸਮਾਂ ਲੋੜਾਂ ਹਨ ਜਿੱਥੇ ਇੱਕ ਦਿੱਤੇ ਸਲਾਟ ਨੂੰ ਗੁਆਉਣ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਕੁਨੈਕਸ਼ਨ ਸਮਾਪਤ ਹੋ ਸਕਦਾ ਹੈ। ਨਾਲ ਹੀ ਬਲੂਟੁੱਥ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਕਾਰਜਾਂ ਦੀ ਇੱਕ ਸੀਮਾ ਹੈ ਜਿਵੇਂ (ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਮਲਟੀਪਲ) ਕਨੈਕਸ਼ਨ, ਇਸ਼ਤਿਹਾਰ, ਸਕੈਨਿੰਗ, ਅਤੇ ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ (PAwR) ਪ੍ਰਸਾਰਣ ਅਤੇ ਰਿਸੈਪਸ਼ਨ ਨਾਲ ਪੀਰੀਅਡਿਕ ਐਡਵਰਟਾਈਜ਼ਿੰਗ।

ਸਾਰਣੀ 6.1. ਬਲੂਟੁੱਥ ਵਿੱਚ ਵੱਖਰੀਆਂ ਤਰਜੀਹਾਂ

1	ਕਨੈਕਸ਼ਨ	135 ਤੋਂ 0 ਤੱਕ	ਕਨੈਕਸ਼ਨ ਇਵੈਂਟ ਸਮਾਪਤ ਹੁੰਦਾ ਹੈ
2	ਕਨੈਕਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ	55 ਤੋਂ 15 ਤੱਕ	ਸ਼ੁਰੂਆਤੀ ਵਿੰਡੋ ਖਤਮ ਹੁੰਦੀ ਹੈ
3	ਇਸ਼ਤਿਹਾਰ	175 ਤੋਂ 127 ਤੱਕ	ਇਸ਼ਤਿਹਾਰਬਾਜ਼ੀ ਸਮਾਗਮ ਸਮਾਪਤ ਹੋਇਆ
4	ਸਕੈਨਰ	191 ਤੋਂ 143 ਤੱਕ	ਸਕੈਨ ਵਿੰਡੋ ਖਤਮ ਹੁੰਦੀ ਹੈ
5	PAwR TX	15 ਤੋਂ 5 ਤੱਕ	ਵਿਗਿਆਪਨਕਰਤਾ: PAwR ਜਵਾਬ ਸਲਾਟ ਦੇਰੀ ਸਮਾਪਤੀ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ਰ: PAwR ਜਵਾਬ ਸਲਾਟ ਸਮਾਪਤ
6	PAwR RX	20 ਤੋਂ 10 ਤੱਕ	ਇਸ਼ਤਿਹਾਰਦਾਤਾ: PAwR ਜਵਾਬ ਸਲਾਟ ਸਮਾਪਤੀ ਸਮਕਾਲੀਕਰਨ: PAwR ਜਵਾਬ ਸਲਾਟ ਦੇਰੀ ਸਮਾਪਤ

ਇਸ ਨੂੰ ਸੰਭਾਲਣ ਲਈ ਬਲੂਟੁੱਥ ਸ਼ਡਿਊਲਰ, ਜਿਸ ਦੀਆਂ ਤਰਜੀਹਾਂ RAIL ਰੇਡੀਓ ਸ਼ਡਿਊਲਰ ਨਾਲ ਮੈਪ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, ਹਰੇਕ ਕੰਮ ਲਈ ਹੇਠਾਂ ਦਿੱਤੇ ਮਾਪਦੰਡਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦਾ ਹੈ:

1.  ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ
2.  ਘੱਟੋ-ਘੱਟ ਸਮਾਂ
3.  ਵੱਧ ਤੋਂ ਵੱਧ ਸਮਾਂ
4.  ਤਰਜੀਹ
   

ਜੇਕਰ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਨੂੰ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੁੱਲ ਚੱਲਣ ਦਾ ਸਮਾਂ ਕ੍ਰਮਵਾਰ ਘਟਾਇਆ ਜਾਂਦਾ ਹੈ, ਯਾਨੀ ਢਿੱਲ ਘਟ ਜਾਂਦੀ ਹੈ। ਨਾਲ ਹੀ ਤਰਜੀਹਾਂ ਨੂੰ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਐਡਜਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਕਨੈਕਸ਼ਨ

ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਮੁਕਾਬਲਤਨ ਉੱਚ ਤਰਜੀਹ ਹੈ। ਕਨੈਕਸ਼ਨ ਦੇ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ ਨੂੰ ਮੂਵ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਬਲੂਟੁੱਥ ਸ਼ਡਿਊਲਰ ਦੁਆਰਾ ਤਰਜੀਹ ਨੂੰ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ, ਜਿੰਨਾ ਕੁਨੈਕਸ਼ਨ ਨਿਗਰਾਨੀ ਦੇ ਸਮੇਂ ਦੇ ਨੇੜੇ ਪਹੁੰਚਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਨੇੜੇ ਵੱਧ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। TX ਕਤਾਰ ਵਿੱਚ ਇੱਕ TX ਪੈਕੇਟ ਵੀ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਦੀ ਤਰਜੀਹ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ।

ਕਨੈਕਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ

ਕਨੈਕਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਲਈ ਟੀਚੇ ਵਾਲੇ ਡਿਵਾਈਸ ਤੋਂ ਇਸ਼ਤਿਹਾਰਾਂ ਨੂੰ ਸਕੈਨ ਕਰਦੀ ਹੈ। ਵਧੇਰੇ ਮਜ਼ਬੂਤ ​​ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਲਈ ਸਕੈਨਰ ਦੇ ਮੁਕਾਬਲੇ ਇਸਦੀ ਉੱਚ ਤਰਜੀਹ ਹੈ।

ਇਸ਼ਤਿਹਾਰ

ਪੂਰਵ-ਨਿਰਧਾਰਤ ਤੌਰ 'ਤੇ ਇਸ਼ਤਿਹਾਰਾਂ ਦੀ ਤਰਜੀਹ ਘੱਟ ਹੁੰਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਨੂੰ ਮੂਵ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ ਅਤੇ ਅਧਿਕਤਮ ਸਮਾਂ ਇਸ਼ਤਿਹਾਰ ਦੇ ਅੰਤਰਾਲ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਜੇਕਰ ਕੋਈ ਇਸ਼ਤਿਹਾਰ ਨਹੀਂ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਸ਼ਤਿਹਾਰਾਂ ਦੀ ਤਰਜੀਹ ਹੌਲੀ-ਹੌਲੀ ਵਧ ਜਾਂਦੀ ਹੈ ਅਤੇ ਇੱਕ ਵਾਰ ਵਿਗਿਆਪਨ ਸਫਲਤਾਪੂਰਵਕ ਭੇਜੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਰੀਸੈਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸਕੈਨਰ

ਮੂਲ ਰੂਪ ਵਿੱਚ, ਇਹਨਾਂ ਕੰਮਾਂ ਦੀ ਸਭ ਤੋਂ ਘੱਟ ਤਰਜੀਹ ਹੁੰਦੀ ਹੈ। ਸ਼ੁਰੂ, ਘੱਟੋ-ਘੱਟ ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਸਮਾਂ ਸਕੈਨਿੰਗ ਅੰਤਰਾਲ ਅਤੇ ਵਿੰਡੋ ਆਕਾਰ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਕੈਨਿੰਗ ਉਦੋਂ ਵੀ ਜਾਰੀ ਰਹਿ ਸਕਦੀ ਹੈ ਜਦੋਂ ਉੱਚ ਤਰਜੀਹ ਵਾਲੇ ਕੰਮ ਵਿੱਚ ਰੁਕਾਵਟ ਆਉਂਦੀ ਹੈ। ਜੇਕਰ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਤਾਂ ਸਕੈਨ ਕਰਨ ਦਾ ਸਮਾਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਇਕੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਹਰੇਕ ਸਕੈਨਿੰਗ ਅੰਤਰਾਲ 'ਤੇ ਲੋੜੀਂਦੇ ਸਕੈਨ ਵਿੰਡੋ ਦਾ ਆਕਾਰ ਪਹੁੰਚ ਗਿਆ ਹੈ।

ਜਿਵੇਂ ਕਿ ਇਸ਼ਤਿਹਾਰਾਂ ਦੇ ਨਾਲ ਤਰਜੀਹ ਨੂੰ ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ ਜੇਕਰ ਲੋੜੀਂਦਾ ਸਕੈਨ ਅੰਤਰਾਲ ਜਾਂ ਵਿੰਡੋ ਦਾ ਆਕਾਰ ਪਹਿਲਾਂ ਪੂਰਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸਕੈਨ ਅੰਤਰਾਲ ਜਾਂ ਵਿੰਡੋ ਦਾ ਆਕਾਰ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਆਪਣੀ ਸ਼ੁਰੂਆਤੀ ਤਰਜੀਹ 'ਤੇ ਰੀਸੈਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਜਵਾਬਾਂ ਦੇ ਨਾਲ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਵਿਗਿਆਪਨ (PAwR) 

ਜਵਾਬਾਂ ਦੇ ਨਾਲ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਇਸ਼ਤਿਹਾਰ ਭੇਜਣਾ ਨੂੰ ਹੋਰ ਸਾਰੇ ਬਲੂਟੁੱਥ ਕਾਰਜਾਂ ਨਾਲੋਂ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਲੈਕਟ੍ਰਾਨਿਕ ਸ਼ੈਲਫ ਲੇਬਲ (ESL) ਨੈਟਵਰਕ ਵਿੱਚ ਸਮਕਾਲੀਕਰਨ ਨੂੰ ਬਣਾਈ ਰੱਖਣ ਲਈ PAwR ਵਿੱਚ ਜਵਾਬ ਪ੍ਰਾਪਤ ਹੁੰਦੇ ਹਨ।

ਇੱਕ PAwR ਕਾਰਜ ਪ੍ਰਾਥਮਿਕਤਾ ਨੂੰ ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ ਜੇਕਰ ਟਾਸਕ ਸ਼ਡਿਊਲਿੰਗ ਲਗਾਤਾਰ ਦੋ ਵਾਰ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ। ਪ੍ਰਾਥਮਿਕਤਾ ਜਾਂ ਤਾਂ ਤਰਜੀਹੀ ਰੇਂਜ ਦੇ 1/6ਵੇਂ ਹਿੱਸੇ ਦੁਆਰਾ, ਜਾਂ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਦੁਆਰਾ ਵੱਧ ਤੋਂ ਵੱਧ ਤਰਜੀਹ ਤੱਕ ਪਹੁੰਚਣ ਤੱਕ ਵਧਾਈ ਜਾਂਦੀ ਹੈ। ਸਫਲਤਾਪੂਰਵਕ ਸਮਾਂ-ਸਾਰਣੀ ਤੋਂ ਬਾਅਦ ਕਾਰਜ ਤਰਜੀਹ ਨੂੰ ਘੱਟੋ-ਘੱਟ 'ਤੇ ਰੀਸੈਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹੀ ਵਿਧੀ PAwR ਵਿਗਿਆਪਨਕਰਤਾ ਅਤੇ ਸਮਕਾਲੀ ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਦੋਵਾਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ

Exampਬਲੂਟੁੱਥ ਸ਼ਡਿਊਲਰ ਓਪਰੇਸ਼ਨ ਦਾ le 

ਇਹ ਸਾਬਕਾample ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਬਲੂਟੁੱਥ ਸ਼ਡਿਊਲਰ ਤਿੰਨ ਕੁਨੈਕਸ਼ਨ ਕਾਰਜਾਂ ਅਤੇ ਇੱਕ ਇਸ਼ਤਿਹਾਰ ਕਾਰਜ ਨੂੰ ਤਹਿ ਕਰੇਗਾ, ਹਰੇਕ ਵਿੱਚ ਵੱਖੋ ਵੱਖਰੀਆਂ ਤਰਜੀਹਾਂ ਹਨ। ਹੇਠਾਂ ਦਿੱਤੇ ਅੰਕੜਿਆਂ ਵਿੱਚ ਸਲੇਟੀ ਹਿੱਸਾ ਇੱਕ ਕੰਮ ਲਈ ਲੋੜੀਂਦੇ ਘੱਟੋ-ਘੱਟ ਰਨਟਾਈਮ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਅਤੇ ਨੀਲਾ ਹਿੱਸਾ ਵੱਧ ਤੋਂ ਵੱਧ ਰਨਟਾਈਮ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜਿਸ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਅਤੇ, ਜੇਕਰ ਲਚਕਦਾਰ ਹੋਵੇ, ਤਾਂ ਉਹ ਖੇਤਰ ਜਿੱਥੇ ਕੰਮ ਨੂੰ ਮੂਵ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਹੇਠਲਾ ਚਿੱਤਰ ਸ਼ੁਰੂਆਤੀ ਸੈੱਟਅੱਪ ਵਿੱਚ ਦਿਖਾਉਂਦਾ ਹੈ

ਜਿਵੇਂ ਕਿ ਹੇਠਾਂ ਦਿਖਾਇਆ ਗਿਆ ਹੈ Conn1 ਚਲਾਉਣ ਲਈ ਪਹਿਲਾ ਕੰਮ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕਿਸੇ ਉੱਚ ਤਰਜੀਹ ਵਾਲੇ ਕੰਮ ਨਾਲ ਓਵਰਲੈਪ ਨਹੀਂ ਹੁੰਦਾ ਹੈ।

Adv1 ਉੱਚ ਤਰਜੀਹ Conn2 ਨਾਲ ਓਵਰਲੈਪ ਕਰਦਾ ਹੈ। Adv1 ਲਚਕੀਲਾ ਹੈ ਅਤੇ ਇਸਲਈ ਹੇਠਾਂ ਦਿੱਤੇ ਚਿੱਤਰ ਵਿੱਚ ਦਰਸਾਏ ਅਨੁਸਾਰ ਅੱਗੇ ਵਧਦਾ ਹੈ।

Conn2 ਉੱਚ ਤਰਜੀਹੀ ਕਾਰਜ Conn4 ਨਾਲ ਓਵਰਲੈਪ ਕਰਦਾ ਹੈ। ਕਿਉਂਕਿ Conn2 ਲਚਕਦਾਰ ਨਹੀਂ ਹੈ, Conn2 ਦੀ ਸਮਾਂ-ਸਾਰਣੀ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ।

Conn4 ਹੋਰ ਕਾਰਜਾਂ ਨਾਲ ਓਵਰਲੈਪ ਨਹੀਂ ਕਰਦਾ, ਇਸਲਈ Conn1 ਅੰਤ ਨੂੰ Conn4 ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਰੋਕਣ ਲਈ ਐਡਜਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

Conn4 ਹੋਰ ਕਾਰਜਾਂ ਨਾਲ ਓਵਰਲੈਪ ਨਹੀਂ ਕਰਦਾ, ਇਸਲਈ Conn1 ਅੰਤ ਨੂੰ Conn4 ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਰੋਕਣ ਲਈ ਐਡਜਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਤਰਜੀਹਾਂ ਨੂੰ ਸੋਧਣਾ

“sl_bt_configuration_t” (v3.x)/”gecko_configuration_t” (v2.x) struct sl_bt_stack_config_t ਢਾਂਚੇ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਖੇਤਰ “bluetooth.linklayer_priorities” ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਜੋ ਤਰਜੀਹੀ ਸੰਰਚਨਾ ਲਈ ਇੱਕ ਪੁਆਇੰਟਰ ਹੈ। ਜੇਕਰ ਪੁਆਇੰਟਰ NULL ਹੈ ਤਾਂ ਸਟੈਕ ਆਪਣੀ ਡਿਫੌਲਟ ਤਰਜੀਹਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਉਪਰੋਕਤ ਸੈਕਸ਼ਨ 6.1 ਬਲੂਟੁੱਥ ਤਰਜੀਹਾਂ ਦੇ ਨਾਲ ਨਾਲ ਇਸ ਭਾਗ ਵਿੱਚ ਸੂਚੀਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ।

ਜੇਕਰ ਪੁਆਇੰਟਰ ਨਲ ਨਹੀਂ ਹੈ ਤਾਂ ਇਸ ਨੂੰ ਹੇਠਾਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਅਨੁਸਾਰ ਤਰਜੀਹੀ ਸੈਟਿੰਗਾਂ ਦੇ ਢਾਂਚੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:

ਪੈਰਾਮੀਟਰ ਸੈਂਡਮੈਨ, ਸਿਨੇਮੈਕਸ, adv_min, adv_min, ਦਾਲਚੀਨੀ, 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ਇੱਥੇ ਵਰਣਿਤ les ਸਿਰਫ਼ ਵਿਆਖਿਆ ਦੇ ਉਦੇਸ਼ਾਂ ਲਈ ਹਨ। ਸਿਲੀਕਾਨ ਲੈਬਜ਼ ਇੱਥੇ ਉਤਪਾਦ ਦੀ ਜਾਣਕਾਰੀ, ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਅਤੇ ਵਰਣਨ ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਹੋਰ ਨੋਟਿਸ ਦੇ ਬਦਲਾਅ ਕਰਨ ਦਾ ਅਧਿਕਾਰ ਰਾਖਵਾਂ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਸ਼ਾਮਲ ਕੀਤੀ ਗਈ ਜਾਣਕਾਰੀ ਦੀ ਸ਼ੁੱਧਤਾ ਜਾਂ ਸੰਪੂਰਨਤਾ ਦੀ ਵਾਰੰਟੀ ਨਹੀਂ ਦਿੰਦੀ ਹੈ। ਪੂਰਵ ਸੂਚਨਾ ਦੇ ਬਿਨਾਂ, ਸਿਲੀਕਾਨ ਲੈਬ ਸੁਰੱਖਿਆ ਜਾਂ ਭਰੋਸੇਯੋਗਤਾ ਕਾਰਨਾਂ ਕਰਕੇ ਨਿਰਮਾਣ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਉਤਪਾਦ ਫਰਮਵੇਅਰ ਨੂੰ ਅੱਪਡੇਟ ਕਰ ਸਕਦੀ ਹੈ। ਅਜਿਹੀਆਂ ਤਬਦੀਲੀਆਂ ਉਤਪਾਦ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਨਹੀਂ ਬਦਲਦੀਆਂ। ਇਸ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਦਿੱਤੀ ਗਈ ਜਾਣਕਾਰੀ ਦੀ ਵਰਤੋਂ ਦੇ ਨਤੀਜਿਆਂ ਲਈ ਸਿਲੀਕਾਨ ਲੈਬਜ਼ ਦੀ ਕੋਈ ਜ਼ਿੰਮੇਵਾਰੀ ਨਹੀਂ ਹੋਵੇਗੀ। ਇਹ ਦਸਤਾਵੇਜ਼ ਕਿਸੇ ਵੀ ਏਕੀਕ੍ਰਿਤ ਸਰਕਟਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਜਾਂ ਬਣਾਉਣ ਲਈ ਕਿਸੇ ਵੀ ਲਾਇਸੈਂਸ ਨੂੰ ਸੰਕੇਤ ਜਾਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਉਤਪਾਦਾਂ ਨੂੰ ਕਿਸੇ ਵੀ 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®, 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 ਲੋਗੋ ਅਤੇ Zentri DMS, Z-Wave®, ਅਤੇ ਹੋਰ ਸਿਲੀਕਾਨ ਲੈਬਜ਼ ਦੇ ਟ੍ਰੇਡਮਾਰਕ ਜਾਂ ਰਜਿਸਟਰਡ ਟ੍ਰੇਡਮਾਰਕ ਹਨ। ARM, CORTEX, Cortex-M3 ਅਤੇ THUMB ARM ਹੋਲਡਿੰਗਜ਼ ਦੇ ਟ੍ਰੇਡਮਾਰਕ ਜਾਂ ਰਜਿਸਟਰਡ ਟ੍ਰੇਡਮਾਰਕ ਹਨ। ਕੇਲੀ ARM ਲਿਮਿਟੇਡ ਦਾ ਰਜਿਸਟਰਡ ਟ੍ਰੇਡਮਾਰਕ ਹੈ। Wi-Fi Wi-Fi ਅਲਾਇੰਸ ਦਾ ਇੱਕ ਰਜਿਸਟਰਡ ਟ੍ਰੇਡਮਾਰਕ ਹੈ। ਇੱਥੇ ਦਰਸਾਏ ਗਏ ਹੋਰ ਸਾਰੇ ਉਤਪਾਦ ਜਾਂ ਬ੍ਰਾਂਡ ਨਾਮ ਉਹਨਾਂ ਦੇ ਸੰਬੰਧਿਤ ਹੋਲਡ ਦੇ ਟ੍ਰੇਡਮਾਰਕ ਹਨ

ਦਸਤਾਵੇਜ਼ / ਸਰੋਤ

ਸਿਲੀਕਾਨ ਲੈਬਜ਼ UG305 ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ [pdf] ਯੂਜ਼ਰ ਗਾਈਡ UG305, UG305 ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ, ਡਾਇਨਾਮਿਕ ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ, ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ

ਹਵਾਲੇ

• ਯੂਜ਼ਰ ਮੈਨੂਅਲ