I've been playing with the simple_uart example and it seems like it might be missing responses. Does it buffer incoming data until the simple_uart_get() is called?
I've been playing with the simple_uart example and it seems like it might be missing responses. Does it buffer incoming data until the simple_uart_get() is called?
There are no buffering in simple_uart itself, but there is a 2-byte (6-byte on latest chip revision) buffer in the hardware itself. If this buffer is overflowed, the OVERRUN field of the ERRORSRC register in the UART peripheral will be set, so you can check for this condition.
If you have hardware flow control enabled, this should also reduce the possibility for this happening, but some peer devices may send enough data to overflow the 2-byte buffer, even when the nRF51822 is signaling that it is not ready. The 6-byte buffer was therefore introduced to cope with such devices, and with this buffer size, hardware flow control should completely remove this problem.
So does the app_uart library provide better buffering support? It looks like you can configure the buffer size on the app_uart_init() call.
The devices I"m working with do not support flow control, but they work on a simple request-response protocol so I don't need to buffer unsolicited data, but I do have to handle the incoming responses after my request.
app_uart does provide a different buffering mechanism, but if the peer device doesn't support flow control you should expect losing bytes if you have a BLE connection ongoing. The reason is that a connection event will block the CPU for several hundred microseconds, in which case the UART buffer will not be emptied, again possibly causing bytes to be lost if the peer device doesn't stop sending.
Take a look at the S110 SoftDevice Specification for details on the blocking caused by the softdevice.
Hi Ole. I have been working with app_uart for a few hours now. But I don't see any code in app_uart dealing with buffering logic. It does set up a structure for doing that. A good indicator is the "flush" logic is not doing anything, only returning a success flag.
