This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Minimize CPU time used by BLE

My application is doing kind of old communication with an old machine. Communication line is bit banged by an GPIO. Baud rate is 0.5ms. "Start bit" is still used to synchronized the start of a packet. I use GPIOIE to get the start bit, then Timer2 is used to receive 8 bit data and sending back a 8 bit response byte. So very simple.

Without BLE enabled, the communication is fine. Wth BLE enabled, the communication is almost OK, except missing data every 5 to 10 minutes.

I believe the reason is timer2 or GPIO interrupt get bumped off by BLE interrupts once for a while when they happen at the same time.

I only need to bring data corruption ratio into an acceptable range.

The BLE feature is minimum in this application, as long as smartphone can change 2 parameters. So I want to make the BLE stack lowest priority and minimize the time occupied by BLE stack, and anything I can do to minimize the BLE activity.

Thanks

Paul

  • 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

  • @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?

  • 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?

  • 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.

  • 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.

Related