Maximum time an event handler may block the application

RE: Maximum time an event handler may block the application

Thomas — Wed, 29 Mar 2017 14:32:12 GMT

That's good to know. Yeah, I'm following the tutorial now. edit: irrelevant. And yes, it's milliseconds.

RE: Maximum time an event handler may block the application

Hung Bui — Wed, 29 Mar 2017 14:09:20 GMT

What did you mean by 275 and 280 ? Were they 275ms and 280ms ? Note that Even if you have lower connection interval, it's possible to have long timeslot period (longer than connection interval) as the softdevice would skip some connection event to give the timeslot priority (not if that would cause connection timeout). Have a look at the timeslot tutorial here.

RE: Maximum time an event handler may block the application

endnode — Wed, 29 Mar 2017 09:32:47 GMT

Yes, with such long connection interval it should be stable.

RE: Maximum time an event handler may block the application

Thomas — Wed, 29 Mar 2017 09:29:58 GMT

Alright, thanks! I was just looking in that document. If I understand correctly I should use sd_radio_request() to obtain a time slot. Which initially has a maximum of 100 ms but can be extended up to 128 s (depending on the other activities). We're currently using an connection interval in between 275 and 280. So that means we should be able to obtain a time slot of 170 ms.

RE: Maximum time an event handler may block the application

endnode — Wed, 29 Mar 2017 09:11:51 GMT

It's kind of evident that blocking the MCU for 170ms isn't good idea, especially if you are running any BLE activity with lower interval (connection or advertising). There is time-slot API mechanism in later S110 as well as all newer SD flavors, see this explanation for S132 (there is similar section in S110 Soft Device Specification v2.0 document but that is released just as PDF). If you decide to use it and encounter any problem there are plenty Q&A on this forum about time-slot API usage and problems.