nRF5_SDK_15.0.0_a53641a\examples\ble_peripheral\ble_app_uart

[Baruch]

/**@brief   Function for handling app_uart events.
 *
 * @details This function will receive a single character from the app_uart module and append it to
 *          a string. The string will be be sent over BLE when the last character received was a
 *          'new line' '\n' (hex 0x0A) or if the string has reached the maximum data length.
 */
/**@snippet [Handling the data received over UART] */
void uart_event_handle(app_uart_evt_t * p_event)

I'm under the impression that this piece of the given example is an interrupt handler. Am I correct? If yes, then there another snippet:

                do
                {
                    uint16_t length = (uint16_t)index;
                    err_code = ble_nus_data_send(&m_nus, data_array, &length, m_conn_handle);
                    if ( (err_code != NRF_ERROR_INVALID_STATE) && (err_code != NRF_ERROR_BUSY) &&
                         (err_code != NRF_ERROR_NOT_FOUND) )
                    {
                        APP_ERROR_CHECK(err_code);
                    }
                } while (err_code == NRF_ERROR_BUSY);

So, is there a while loop inside an iterrupt? 

Could you please correct me if my assumptions are wrong and explain what is going on inside NUS in the case it was busy and how will it become available while the code is looping unless, of course, there are nested interrupt and their priorities are capable of managing such condition.

Thanks. 

[Håkon Alseth]

Hi,

 

I'm under the impression that this piece of the given example is an interrupt handler. Am I correct?

You are correct. This is in the UART interrupt context.

So, is there a while loop inside an iterrupt? 

Yes, that is correct.

The SoftDevice will, when packets are being uploaded through the ble_nus_data_send(...) function, send these in a higher interrupt priority. In the case your buffers are full when calling this function, you will not hang forever (although; you will busy-loop in a unoptimized fashion)

 

The return code _BUSY from function ble_nus_data_send() will derive from the call to sd_ble_gatts_hvx(). The _BUSY return here is described as:

* @retval ::NRF_ERROR_BUSY For @ref BLE_GATT_HVX_INDICATION Procedure already in progress. Wait for a @ref BLE_GATTS_EVT_HVC event and retry.

 

Ideally, you want to wait for the event as described above, but this event will be fetched by the application in the same interrupt priority as the uart_event_handle(). Note: this is the event only, not the actual transmission on-air. On-air transmission and data handling is performed in higher interrupt levels.

 

Best regards,

Håkon

[Baruch]

Hi,

Ideally, I'd like to have a nonblocking call with the immediate status return. We have to live with what we have, do we not?! SD from my standpoint should be acting as RTOS and it is user responsibility to use it correctly. Dealing with nested interrupts is a very dangerous endeavor and could cause starvation, especially when all information available is just a tip of the SD iceberg...But it is just my OFO.  

[Håkon Alseth]

Hi,

 

I agree with you that while-loops in interrupt handlers is not the most optimal situation.

The implementation in ble_app_uart's main.c is provided as an example, and if the uart handling in the application does not fit your needs in terms of how it behaves or the interrupt levels it uses, I'd recommend that you re-implement it for your needs.

 

Kind regards,

Håkon

[Baruch]

Hi,

Excellent suggestion! Are you kidding me? Is this the example of how NOT to do? It is like saying that this file system is given to you as an example only, if you need a reliable one, then rewrite it for your needs. I was actually expecting to have a decent API and example of implementation...The picture is not looking good :( Could you please recommend me a better example/quick solution? 

My best,

BR 

PS: I'm closing this case but