Aug 09, 2016
03:15 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 09, 2016
03:15 AM
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
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
- Tags:
- IFX
6 Replies
Aug 09, 2016
05:33 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 09, 2016
05:33 AM
Hi,
You could use XMC_USIC_CH_TXFIFO_IsFull() just before calling transmit to ensure there is space in the FIFO.
Regards,
Jesus
You could use XMC_USIC_CH_TXFIFO_IsFull() just before calling transmit to ensure there is space in the FIFO.
Regards,
Jesus
Aug 09, 2016
06:56 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 09, 2016
06:56 AM
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
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
Not applicable
Aug 09, 2016
07:00 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 09, 2016
07:00 AM
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.
Aug 09, 2016
08:32 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 09, 2016
08:32 AM
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
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
Not applicable
Aug 09, 2016
08:37 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 09, 2016
08:37 AM
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.
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.
Not applicable
Aug 09, 2016
09:02 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Aug 09, 2016
09:02 AM
But you are right. Dropping without noticing (via return value) is bad.