UART question. Topic is solved

[rew]

Code: Select all

/**
 * @brief   Stops any ongoing receive operation.
 * @note    Stopping a receive operation also suppresses the receive callbacks.
 *
 * @param[in] uartp     pointer to the @p UARTDriver object
 *
 * @return              The number of data frames not received by the
 *                      stopped receive operation.
 * @retval 0            There was no receive operation in progress.
 *
 * @api
 */

What happens when I start calling "uartStopReceive" and right at that moment, the buffer fills, i.e. 0 bytes remain to be put into the buffer?

[Giovanni]

It reads the DMA counter register, so you get zero.

Giovanni

[rew]

Which is the same zero you would get when no operation was started. Wouldn't it be much better to have the return value be -1 when no operation was started? Choosing an "error code" from the range of valid "normal" return values is not such a good idea.

[Giovanni]

Moving in "change request".

Giovanni

[rew]

FYI,

As with an example I found somewhere, (probably in haltest), my mainloop simply first stops the ongoing transfer, starts a new transfer in the "double buffer", and then processes whatever it got. So the first time around the loop, I get a "0" (no transfer started), which to the processing code means "got a full buffer!".

You might say: well first start the transfer then! Yeah. I can copy the code to start the first transfer. But then I've duplicated code leading to the real possibility of fixing a bug in one of them and not in the other.

When I started this thread, this was a bug, waiting to happen. It happened. My logfile now has:

Code: Select all

...
001f0 00 00 00 00 00 00 00 00   00 00 00 00 00 00 00 00 
00200 67 45 23 01 46 3d 36 0b   fa ff ff ff 00 00 00 00 
.. my data... 

[Giovanni]

Hi,

I fixed it as bug #925 in trunk and 18.2.x.

Giovanni