Slow conversion of external ADC with SoftDevice

[Filya]

Hi

There was a problem using the external ADC  AD7792 in a project with SoftDevice. The problem is that when the ADC is processed in a project with SoftDevice, the waiting time for the end of the ADC conversion significantly increases - 10.5 seconds. The delay occurs at the moment when the ADC must respond to the completion of the conversion (low level RDY).

If use a project without SoftDevice (from the examples of "peripheral"), then the conversion is completed faster - 4.5 seconds.
I also tried to comment out the initialization of everything connected with bluetooth, leaving only the timer and ADC processing functions, but it did not give any results. Therefore, I can not understand why in projects where bluetooth is used (from the "ble_peripheral" examples), such a delay occurs.

To control the ADC, I use the usual pin switching. I do not use SPI module.

Maybe someone came across a similar or there are suggestions, what could be the reason ? 

Chip: SKB501 (analog nRF52840);

SDK: nRF5_SDK_15.2.0;

Softdevice: s132_nrf52_6.1.0_softdevice;

Thank you in advance.

[Edvin]

To control the ADC, I use the usual pin switching. I do not use SPI module.

 Can you explain what you mean by this? How do you control the ADC, and how do you get the data?

[Filya]

I control the ADC by personally switching pins using the nrf_gpio_pin_set / nrf_gpio_pin_clear commands (for SCLK and DIN pins). And with the help of nrf_gpio_pin_read (DOUT/RDY pin), I read the data from the ADC.

[awneil]

Filya said:

I control the ADC by personally switching pins

commonly known as  "bit-banging",  which is obviously going to be affected by the CPU load - such as the SoftDevice.

So this is to be expected.

Should be obvious from observing the signals on an oscilloscope.

The reason microcontrollers have hardware for stuff like this is precisely so that it does not require CPU resources!

[Edvin]

Did you figure out why it takes more time when you use the softdevice? Does it take more time before you send the SPI cmd? Does it take more time before you get the reply from the AD7792?

Can you try to use a logic analyser on the SPI pins and see what's going on?

[Filya]

SoftDevice continues to work, even if do not declare the functions associated with bluetooth? (ble_stack_init, gap_params_init, gatt_init, etc.)
I just experimented about, removing the declaration of all these functions and leaving only the call of the timer and the function of the ADC and still there was the same delay.
I understand that if SOFTDEVICE_PRESENT is declared, then this already guarantees sufficient CPU load and the ADC will not work correctly with the help of “bit-banging”, do I understand correctly?

[Edvin]

I suggest that you try to use the SPI peripheral on the nRF instead of trying to bitbang the data from the ADC.

 

Filya said:

I understand that if SOFTDEVICE_PRESENT is declared, then this already guarantees sufficient CPU load and the ADC will not work correctly with the help of “bit-banging”, do I understand correctly?

 Not exactly. If you don't use the radio (advertising or in a connection), it shouldn't interrupt you. But we don't know what you are doing in your application, so it is a bit difficult to tell exactly what's happening in your case.

[Filya]

I tried to implement the ADC through SPI and really the time has decreased a little. Now shows 7.5 sec. It used to be 10.5 seconds, without softdevice it was 4.5 seconds.
Perhaps the remaining 3 seconds. they run due to the same CPU load, as I have a pin control in my ADC code anyway to check the status of DOUT / RDY.
Another incomprehensible situation that I mentioned earlier is that when bluetooth functions and other functions are commented out, time still shows 7.5 seconds.

int main(void)
{  
  ConfigPinsSleep();//Pin Configuration 
  
  log_init();
  lfclk_request();
  
  timers_init();
  
//  ble_stack_init();
//  power_management_init();
//  gap_params_init();
//  gatt_init();
//  services_init();
//  advertising_init();
//  conn_params_init();
//  peer_manager_init(); 
  
  //----ADC7792----//
  config_gpio_adc7792();
  spi_init();
  //--------------//
  
  //----SHT3x----//
//  twi_init();
  //------------//
  
//  rtc_init();
    
//  advertising_start();
  
  app_timer_start(m_our_char_timer_id, OUR_CHAR_TIMER_INTERVAL, NULL);
  
  //------LCD------//
//  config_gpio_lcd(); 
//  LCD_Init(150);
//  LCD_Clean(0); 
  //--------------//
  NRF_LOG_INFO("My characteristics started.");
  
  // Enter main loop.
  for (;;)
  {
//    idle_state_handle();

//    Processing_archive();
    
    AD7792_Task(AD7792_TASK_REQ_START_NEW_MEAS, 0, err_adc);

    
  }
}

[Edvin]

Nothing in the softdevice should make this go from 5 to 7 seconds. And at least not when you don't use it. 

Can you specify where these seconds are spent, and how you get the data? Does the AD7792_Task() have a callback, or do you get the data inside this function? Does it take 7.5 seconds from the start of AD7792_Task() until the end of AD7782_Task() (or the callback)?

Have you done some debugging to find out where this time is being used? And again, have you tried to analyze the SPI pins using a logic analyzer?

[Filya]

I'm sorry for the late reply.
Problem solved. True, what exactly affected her is not clear, but now the process is completed in 4.5 seconds. Perhaps all the same, somehow the process was being worked out in parallel.