using ADC and SD Streaming

RE: using ADC and SD Streaming

Stefan Birnir Sverrisson — Fri, 22 Aug 2014 10:46:15 GMT

I have added to my former reply in order to answer your questions.

RE: using ADC and SD Streaming

Stefan Birnir Sverrisson — Fri, 22 Aug 2014 10:45:07 GMT

The third revision hardware will be pin compatible with the current second revision. for your other question/questions, I recommend to create other thread/threads to make it easier for other users to find our questions and answers, see devzone.nordicsemi.com/.../ devzone.nordicsemi.com/.../ devzone.nordicsemi.com/.../

RE: using ADC and SD Streaming

Scott Buchanan — Thu, 21 Aug 2014 16:49:32 GMT

A follow up question as well.

Despite the warnings in the documentation I tried setting the priority to the ADC handling routine to _HIGH. The ADC start task is tied to the timer2 cpm[0] through ppi channel 0 as shown below. With this arrangement the BLE works fine but I'm still dropping the point during the transmission.

My expectation would have been either to not drop points as the interrupt is HIGH or to have the BLE not work as it was interfering with the radio.

I had thought the PPI channels and peripherals were independent of the CPU and therefore timer2 would trigger the ADC even during the radio usage AND given that the interrupt priority of the ADC was high the interrupt would get serviced resulting in one of the two above results.

My question is why did neither of the two possible outcome occur? It seems like the SD is suppressing PPI channel 0? Is that correct?

void ars_audio_init() {
NRF_ADC->INTENSET   = ADC_INTENSET_END_Msk;
NRF_ADC->CONFIG =   (ADC_CONFIG_RES_10bit               << ADC_CONFIG_RES_Pos)     |
                    (MICROPHONE_INPUT_PRESCALING        << ADC_CONFIG_INPSEL_Pos)  |
                    (MICROPHONE_REFERENCE_PRESCALING    << ADC_CONFIG_REFSEL_Pos)  |
                    (MICROPHONE_ANALOG_INPUT            << ADC_CONFIG_PSEL_Pos)    |
                    (ADC_CONFIG_EXTREFSEL_None          << ADC_CONFIG_EXTREFSEL_Pos);
NRF_ADC->EVENTS_END = 0;
NRF_ADC->ENABLE     = ADC_ENABLE_ENABLE_Enabled;

// Enable ADC interrupt
NVIC_ClearPendingIRQ(ADC_IRQn);
NVIC_SetPriority(ADC_IRQn, NRF_APP_PRIORITY_HIGH);
NVIC_EnableIRQ(ADC_IRQn);

//Setup the power control for the microphone

//Also set up microphone pin with high drive

NRF_GPIO->PIN_CNF[MICROPHONE_POWER_PIN_NUMBER] = 0x301;  //output and high drive
nrf_gpio_pin_clear(MICROPHONE_POWER_PIN_NUMBER);

sd_ppi_channel_assign(0, &(NRF_TIMER2->EVENTS_COMPARE[0]), &(NRF_ADC->TASKS_START));
sd_ppi_channel_enable_clr(0x1);

}

RE: using ADC and SD Streaming

Scott Buchanan — Thu, 21 Aug 2014 15:10:22 GMT

Stefan,

Thanks. That helps a lot. Is there information available on the new hardware. I can sign an NDA.

Specifically, is it pin compatible with the current hardware so we could re-work our current prototypes?

Also, how do I sent the number of packets/transmission? I can't find a reference for that.

Thanks again

RE: using ADC and SD Streaming

Stefan Birnir Sverrisson — Thu, 21 Aug 2014 09:32:37 GMT

Hi Scott

Sampling rate of 2kHz with the ADC not possible with the current softdevice and the current hardware. The reasons behind that are discussed on this thread. However, it should be possible to sample with several kHz with the third revision nRF51 hardware that will be released in a few weeks.

It does not help in this case to set the priority of the ADC interrupt to "Application High", because the radio interrupts related to the BLE protocol still have higher priority. The BLE radio interrupts run with LowerStack priority, see figures 76 and 77 in the nRF51 Series Reference Manual v2.1.

You are correct, by enabling PPI, you are independent of the CPU, but for the ADC sampling, you are using the PPI in one step and the CPU in another step. First, TIMER2 will start the ADC sampling, independent of the CPU, by triggering the ADC->START task (NRF_ADC->TASKS_START) and this is done via PPI channel. The ADC will use 68us to create the sample and then put the result in the ADC->RESULT register. The ADC->RESULT register only contains one sample, so you need the CPU to extract data from the ADC->RESULT register before the ADC samples again (typically performed in the ADC interrupt handler), if you fail to do so, the data in the ADC->RESULT register will be overridden. The CPU is blocked for ca 0.8-6.0 seconds by the S110 BLE softdevice because of BLE connection event. How long the CPU is blocked depends on the amount of data that are sent over the BLE link in each BLE connection event. This means that the CPU is not able to extract data from the ADC->RESULT register when it is blocked by the softdevice.