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

Queries on nus_data_send() functionality?

Hi, I have a few general questions on nus_data_send(). 

First off, is there another known way of transferring an array/string via ble to the Nordic mobile app other than the NUS service? 

Secondly, does the nus_data_send() function always need an interrupt/event to get called? 

I am starting with the BLE_UART example in Embedded Studio (SDK 15.2). The main program goes into an indefinite for (';;) loop idle state handle after calling advertising_start(). The way I see this is that the chip is continuously in a low power mode and it advertising so it needs an interrupt (GPIO or NUS or UART)  to initiate a data transfer? 


Why does a program including BLE have to move into a low power sleep state? Can I write a custom data send function including the nus_data_send() and call it in the main successfully with the idle_state_mgmt () function running in an infinite loop at the end? Should the data_send() in the below main program work (i.e. be called despite the for(;;) loop after the advertising  )? 

int main(void)
{
    bool erase_bonds;

    // Initialize.
    uart_init();
    log_init();
    timers_init();
    buttons_leds_init(&erase_bonds);
    power_management_init();
    ble_stack_init();
    gap_params_init();
    gatt_init();
    services_init();
    advertising_init();
    conn_params_init();
    // SPI 
    init_pins(); 

    nrf_delay_ms (10); 
    // initialize the SPI for ADC ADS1220 communication 
    init_spi(); 

    // Start execution.
    printf("\r\nUART started.\r\n");
    NRF_LOG_INFO("Debug logging for UART over RTT started.");
    advertising_start();

    data_send() ; 

   
    for  (;;)
    {
       idle_state_handle(); 
    }
   
   

}

Parents
  • Not sure if this helps, but it's easy to forget that the application is effectively multi-threaded. ble_nus_data_send() is by default invoked within an event, which is effectively an interrupt to the main(). One might think that sprinkling a few other ble_nus_data_send() calls in (say) main() would not be an issue, but in that case one invocation may be interrupted by another, following which the send buffer data_array becomes corrupted as two messages stomp on each other. Since the serial port i/o and the BLE serial packets are all events, this can get interesting; throw in yet another call from the SPI interrupt and without adding a lock or semaphore or other signal at some point data corruption will occur. 

Reply
  • Not sure if this helps, but it's easy to forget that the application is effectively multi-threaded. ble_nus_data_send() is by default invoked within an event, which is effectively an interrupt to the main(). One might think that sprinkling a few other ble_nus_data_send() calls in (say) main() would not be an issue, but in that case one invocation may be interrupted by another, following which the send buffer data_array becomes corrupted as two messages stomp on each other. Since the serial port i/o and the BLE serial packets are all events, this can get interesting; throw in yet another call from the SPI interrupt and without adding a lock or semaphore or other signal at some point data corruption will occur. 

Children
Related