XMC1100 UART library doesn't wait for FIFO not full!?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User7804
Level 4
Level 4
Hi All,

as far as I see, the (convoluted) library code for the XMC1100 UART just writes a new character to the FIFO (if the FIFO is active at all) without checking whether the FIFO is full.

If you write a long sequence of characters with FIFO activated, the last characters are dropped silently.

Is this by intention?

I would expect that with active FIFO, XMC_UART_CH_Transmit() waits until the FIFO can take the new character.

Oliver
0 Likes
6 Replies
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

You could use XMC_USIC_CH_TXFIFO_IsFull() just before calling transmit to ensure there is space in the FIFO.

Regards,
Jesus
0 Likes
User7804
Level 4
Level 4
Hi Jesus,

I have no problem to find a correct solution, just wanted to discuss whether the current library code does what a user expects.

Why did the library designers decide not to check for FIFO overflow?

Oliver
0 Likes
Not applicable
Because it is bad if a library function blocks (and if there is no nonblocking equivalent). Explicit blocking functions or explifcit functions to check states are more flexible.
0 Likes
User7804
Level 4
Level 4
Hi Holger,

so you think that silently (!) dropping characters is to be expected?

I see it vice versa, keeping the characters shall have priority. If someone wants to avoid the delay, he has to check the FIFO before. That's how standard I/O libraries work.

Oliver
0 Likes
Not applicable
Yes it is ok, but it should be noticed in the documentation with an extra note on how to check for an full fifo.

No. Blocking is evil. What if someone wants to use the library function in an IRQ-handler?

Three possibilities:

1) Two functions, one blocking, one not blocking.
2) One function with an parameter to change blocking behaviour.
3) One function which does not block and a helper to check if a call will succeed.
0 Likes
Not applicable
But you are right. Dropping without noticing (via return value) is bad.
0 Likes