BLE ANT App Timer

RE: BLE ANT App Timer

Anders Strand — Wed, 08 Jun 2016 09:32:29 GMT

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 :)

RE: BLE ANT App Timer

Alex — Tue, 07 Jun 2016 22:57:33 GMT

I have 64 LEDs to update. That makes 64 * 32us = 2048us Is that ok to update the LEDs in the timer event handler itself? I thought that it was good practice to have few instructions executed in a short amount of time in the event handlers in general...

RE: BLE ANT App Timer

Anders Strand — Tue, 07 Jun 2016 08:14:40 GMT

With BLE only, one can schedule things between connection events using the app_timer. With ANT trown into the mix, things will be a bit more complex. What you can try is the following: Create an app_timer which updates the led at the frequency you want (probably 20+ Hz?). In the timer event handler, check if it is "safe" to update the leds. You can check this by checking if the radio is being used soon with the radio event notifications. In this way, you will lose some led updates here and there, but it might be few enough that you won't notice.

RE: BLE ANT App Timer

Alex — Mon, 06 Jun 2016 17:37:13 GMT

Thanks for the answer, Anders. Yes I have seen this code for the WS2812 and I am using it already. My concern is that I need to update the colors of the LEDs more often than just at the single moment where the radio events are finished. I was then thinking of updating the LEDs in the main loop based on the status of a flag set in the radio callback as defined here:

void myradio_callback_handler(bool radio_active)
{
	if (radio_active) // radio going active
	{
		bNeoShow = false;
	}
	else if (radio_active == false) //radio inactive
    {
		bNeoShow = true;
    }
}

RE: BLE ANT App Timer

Anders Strand — Mon, 06 Jun 2016 13:37:33 GMT

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