UART question. Topic is solved

Report here problems in any of ChibiOS components. This forum is NOT for support.
rew
Posts: 380
Joined: Sat Jul 19, 2014 12:59 pm
Has thanked: 2 times
Been thanked: 13 times

UART question.  Topic is solved

Postby rew » Fri Mar 02, 2018 1:11 pm

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?

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: UART question.

Postby Giovanni » Fri Mar 02, 2018 1:44 pm

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

Giovanni

rew
Posts: 380
Joined: Sat Jul 19, 2014 12:59 pm
Has thanked: 2 times
Been thanked: 13 times

Re: UART question.

Postby rew » Sun Mar 04, 2018 1:18 pm

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.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: UART question.

Postby Giovanni » Sun Mar 04, 2018 3:59 pm

Moving in "change request".

Giovanni

rew
Posts: 380
Joined: Sat Jul 19, 2014 12:59 pm
Has thanked: 2 times
Been thanked: 13 times

Re: UART question.

Postby rew » Tue Mar 06, 2018 3:21 pm

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...

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: UART question.

Postby Giovanni » Wed Mar 07, 2018 10:53 am

Hi,

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

Giovanni


Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 4 guests