Scheduling priorities in Softdevice and Bluetooth Core Specification

Question

Greetings, I did some research on the priority settings of BLE. Though Softdevice set some scheduling priorities on BLE-related timing events , I can't find the corresponding description in Bluetooth Core Specification.Is this Nordic specific feature? 
 Another thing I'm interested in is whether I can change these priority settings.

Edvin · Accepted Answer

Hello, 
 A quick read through your link, in the section starting with: 
 " The Bluetooth stack uses dynamic priorities, which means that ..." 
 It seems like it is pretty much the same as in our priorities in the SoftDevice. 
 As you can see in the table from the link in my previous reply, The highest priority is connections that are about to time out. Then comes the types of tasks that are related to entering connections, and then comes the rest, such as connection events (once every connection interval, on connections that are not about to time out). 
 From your SiLabs link, I don't interpret this as you can set the priorities yourself. All priorities are starting with the minimum priority from the table, and then, as they are skipped (not prioritized), the priority gradually increases until it reaches max. When this task is ran by the CPU, it will return to the minimum priority. Pretty much the same as in the softdevice (without knowing anything on how they are actually implemented). 
 
 This is not something that you can change in the softdevice (and apparently not in the SiLabs Bluetooth stack either). 
 
 I am not sure whether this actually comes from the specification or not. But in my opinion, it doesn't really matter, as you still will not be able to change these priorities. If you have multiple connections (or even one) and you intend to advertise or scan at the same time, then you will drop some connection events from time to time. But that is the reason behind the dynamic priorities is that you will not be able to have control of all timings. Without it you would only be able to maintain one connection, advertising or scanning properly. 
 
 Best regards, 
 Edvin

Emil Lenngren · Answer

The core specification does not include algorithms for scheduling or prioritizing radio events. The specification theoretically allows an implementation to have multiple radios so that all secheduled events can run concurrently from what I can see, although this is not mentioned explicitly. The specification is in fact written in such a way that it never keeps in mind that events might overlap. The specification however acknowledges in some places that events can be missed due to scheduling overlaps, but nothing about how these should be prioritized. 
 It is thus up to each Bluetooth stack developer to come up with their own ideas how to best handle the cases when radio events overlap, and the radio hardware can only do one task at a time. You can therefore assume different stability results for different Bluetooth stacks when they get overloaded with many concurrent events.

Scheduling priorities in Softdevice and Bluetooth Core Specification

Top Replies