BLE ANT App Timer

[Alex]

Hi all,

I have a firmware in which I want to use BLE and ANT communication (with Softdevice S310) to send and receive commands from other Nordic devices or smartphones. I also have 64 RGB LEDs WS2812 which have a specific communication protocol and I want to update the color of the LEDs at a given frequency. I plan to do that by instantiating an App Timer as described here.

It is important that the communication to the LEDs is not interrupted by any events or interrupts.

So I have BLE & ANT events as well as a timer handler.

What is the best way to handle this? It is important that the communication to the LEDs is not interrupted and that I can still communicate through BLE and ANT from time to time.

One possibility would be to setup a radio notification with ble_radio_notification_init(NRF_APP_PRIORITY_HIGH, NRF_RADIO_NOTIFICATION_DISTANCE_2680US,myradio_callback_handler); to know when the radio is active. Then I could set a flag each time I enter my Timeout handler to request for an update of the LEDs color. In the main loop, I could just check these two conditions to be active at the same time and then update the LEDs.

Is there a better way to do this? Would a Scheduler or a TImeslot API be more appropriate?

Best regards

[Anders Strand]

Hello.

In the WS2812 data sheet, we can see that the shortest pulse we must send is 0.35 uS. The lowest time we can count with the app_timer is 32 uS, because it uses the 32khz RTC timer.

You can find a library for using ws2812 with the nRF51 on this github page. This implementation bit-bangs the protocol using assembly. This is the most common way of interfacing to the ws2812 (afaik). They also included a note about using the lib with a softdevice. As you suggested, it uses the radio notification API.

Sending data to one led will take about 32 uS. Since it is so fast, it is ok to just do a blocking implementation (bit banging). Just do it right after the radio events are finished.

The timeslot API could also be used, but you would not be guaranteed a slot 100% periodically.

-Anders

[Anders Strand]

It depends on wether or not is would stop other more important things from executing. If you do not have important stuff in main() or in other interrupt handler, it should be fine. But yes, it is a good rule of thumb to keep interrupt handlers short :)