Concurrent use of the Flash API, Radio Timeslot API, and/or one or more Bluetooth®
Low Energy roles can affect interrupt latency.
The same interrupt priority levels are used by all Flash API, Radio Timeslot API, and Bluetooth Low Energy roles. When using more than one of these
concurrently, their respective events can be scheduled back-to-back (see Scheduling for more on
scheduling). In those cases, the last interrupt in the activity by one module/role can be
directly followed by the first interrupt of the next activity. Therefore, to find the real
worst-case interrupt latency in these cases, the application developer must add the latency of
the first and last interrupt for all combinations of roles that are used.
For example, if the application uses the Radio Timeslot API while having a
Bluetooth Low Energy advertiser running, the worst-case interrupt
latency or interruption for an application interrupt is the largest of the following
SoftDevice interrupts having higher priority level (lower numerical value) than the
application interrupt:
- the worst-case interrupt latency of the Radio Timeslot API
- the worst-case interrupt latency of the Bluetooth Low Energy
advertiser role
- the sum of the max time of the first interrupt of the Radio Timeslot API and the last
interrupt of the Bluetooth Low Energy advertiser role
- the sum of the max time of the first interrupt of the Bluetooth Low Energy
advertiser role and the last interrupt of the Radio Timeslot API