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

How to disable buffer in Nordic Uart Service?

I'm trying to replace a RS232 cable with a BLE bridge with the Nordic Uart Service.

One nRF52832 configured as central (app_uart_example_central) and an other one as peripheral. The connection is working well with putty or the nRF connect app on the phone. But there is a 60 character buffer and I can't find the code to change it.

Does someone know how to disable that buffer to send incoming data as it comes?

Details: Chip: nRF52832 IDE: Keil5.23 Softdevice: s132

Parents
  • Hi Torbjørn,

    thanks for your tip with the timer.

    I created a app_timer (single_shot) which is (re-)started after a recieved byte on the UART. So the last bytes in the buffer are send after a few ticks. But sometimes there are delays which are a lot longer than the timer should be.

    void uart_event_handle(app_uart_evt_t * p_event)
    {
    static uint8_t data_array[BLE_NUS_MAX_DATA_LEN];
    static uint8_t index = 0;
    uint32_t       err_code;
    
    switch (p_event->evt_type)
    {
      // event is called when timer expiers
    		  case APP_CLEAR_BUFFER:
    				  //copy of APP_UART_DATA_READY without getting byte from UART --> no new byte there...
            if (index != 0)
            {
                NRF_LOG_DEBUG("Ready to send data over BLE NUS\r\n");
                NRF_LOG_HEXDUMP_DEBUG(data_array, index);
    
                do
                {
                    err_code = ble_nus_string_send(&m_nus, data_array, index);
                    if ( (err_code != NRF_ERROR_INVALID_STATE) && (err_code != NRF_ERROR_BUSY) )
                    {
                        APP_ERROR_CHECK(err_code);
                    }
                } while (err_code == NRF_ERROR_BUSY);
    
                index = 0;
            }
            break;				
    		
    		case APP_UART_DATA_READY:
                        // ...
       }
    

    Any idea what causes this delay?

  • Hi Hermann

    Have you modified the UART driver to do the timeout internally?

    It's hard to say why the problem occurs, but I assume it is related to how the app_timer callback is reset if you receive more data before the timeout should occur.

    I think it would be simpler from a logical standpoint to use a repeated timer instead, and check the state of the buffer in the timer, sending a packet if the buffer contains more than 0 bytes.

    Best regards
    Torbjørn

  • Hello, do you have news fr this post? thank you

Reply Children
Related