Minimize CPU time used by BLE

RE: Minimize CPU time used by BLE

run_ar — Fri, 24 Mar 2017 12:00:51 GMT

ok, maybe better to stick with the device manager then. I don't think it's worth using the experimental peer manager, or backporting the later version.

RE: Minimize CPU time used by BLE

Paul — Wed, 15 Mar 2017 16:28:00 GMT

Thanks run_ar, but SDK10 is the last one supporting S310 softdevice.

RE: Minimize CPU time used by BLE

run_ar — Wed, 15 Mar 2017 15:44:55 GMT

The peer manager in SDK 10 is experimental. I would recommend using at least the first "stable" version, but preferably use the latest and greatest.

RE: Minimize CPU time used by BLE

Paul — Fri, 03 Mar 2017 17:40:38 GMT

Good idea. I can schedule the time slot just a little earlier before the 240ms event to make sure I get the start bit and then schedule another 16 time slots to check the incoming bits and bang out response bits. I am using SDK12.0.0 on other projects which has peer manager module. I noticed that SDK10.0.0 has fstorage and fds as experimental and a BLE relay example using peer manager. Is there any known reason that I cannot use peer manager came with SDK10.0.0?

RE: Minimize CPU time used by BLE

run_ar — Fri, 03 Mar 2017 10:11:18 GMT

You should be able to make this work by using the timeslot API. A Timeslot with high priority has the same priority as a normal connection interval. So if you use a connection interval that is faster than the timeslot interval, the timeslot interval will be scheduled before the connection interval, so if you have a collision the timeslot will take priority as it is already scheduled. But there are a couple of exceptions. e.g. if you have a connection parameter update or the ble connection is about to timeout the ble connection will take priority. What requirements do you have for ANT traffic (Since you are using S310)?

Yes, SDK 10 is the latest SDK that supports S310. You can see this in our compatibility matrix in infocenter.

RE: Minimize CPU time used by BLE

Paul — Thu, 02 Mar 2017 18:21:40 GMT

I am using SDK9.0.0. Is SDK10.0.0 the last SDK supporting S310? Maybe I should update my SDK to V10.0.0.

RE: Minimize CPU time used by BLE

Paul — Thu, 02 Mar 2017 14:40:25 GMT

Thanks. I will check the manual again. I am using S310 V3.0.0. The old machine is sending out a command every 240ms, and nRF51422 has to respond in right timing, receiving 8 bits and respond 8 bits, every bit is 0.5ms. When BLE lower stack pushes the old comm timing away, the old machine is not happy. It happens once every a few minute, not very often, but still not acceptable.

RE: Minimize CPU time used by BLE

run_ar — Thu, 02 Mar 2017 13:46:12 GMT

Does that mean you are using S310 then? which version is it? You should look at the max time for lower stack interrupts, as these are the highest priority. Upperstack interrupts are lower priority so you can use application high to get higher priorities for your application. I would assume the lower stack interrupt is about 1.5 ms maximum (for newer softdevice we are looking at 0.2-0.3 ms). Not sure where you see 100ms.

RE: Minimize CPU time used by BLE

Paul — Thu, 02 Mar 2017 12:53:15 GMT

I am using 51422. According to the user's manual, BLE stack may take over up to 100ms. Is this correct or I am reading it wrong?

RE: Minimize CPU time used by BLE

run_ar — Thu, 02 Mar 2017 09:22:24 GMT

@Paul: How much time does the bit banged communication take (the time critical part that is)? It might be possible to change the interrupt priorities if you only use a few µs of time in your interrupts. But please note that this is not something we have tested internally so it will be unsupported and done at your own risk. It might also be possible to use the timeslot api for this. But the high priority timeslot will have the same priority as normal ble activity so it depends on what is scheduled first. Which softdevice are you using?

RE: Minimize CPU time used by BLE

Roger Clark — Wed, 01 Mar 2017 21:25:55 GMT

I'm not sure if its possible to make the BLE stack lower priority as this would mean that the BLE would fail to work correctly.

I think you need to think of an alternative strategy

What nRF5x processor are you using, e.f. can you use PPI or some similar feature to handle the bit banging