I'm developing a peripheral with s132 v5.1.0 that supports multiple concurrent connections. I've looked at section 15 of the SoftDevice Spec and I have a couple of questions.
Section 15 of the SoftDevice Spec says "Activity B will be blocked and its timing-event will be rescheduled for a later time". What will this "later time" be? Simply the next time the timing-event would normally fire? For example, if the timing-event for an advertiser-role with an interval of 1s collides with the peripheral-role timing-event that was already scheduled, will there be just 2s between the advertising packets being sent?
Also, is there a way for the application to be notified of such a collision?
Softdevice has a Radio Event Manager (REM) that is a scheduler to manage Radio timeslot. When softdevice mentions scheduler, then it means a scheduler for Radio and not the CPU.
Since there is only one radio, there will be only one event at a time that would get the radio access. In your question, if the device has a connection and also is a advertiser (for example), then the REM (scheduler) makes sure that only one get the radio access based on the priority. Little confusing part is that the flash access uses the same REM scheduler since radio activity affects flash access, so they need to mutually exclusive. The easiest way to fix this problem was to give a radio time slot for flash access. That is while flash access, it is made sure that radio is off.
There could be collisions when both a connection and the advertising role requests REM a timeslot, at this time, the above mentioned priority is taken into affect and the one that wins is given radio access.
You didn't answer any of my questions. I understand priority. I'm asking about what happens to the event that doesn't "win" i.e. the one that gets rescheduled.