#use RS232(TRANSMIT_BUFFER= Behavior

jonnewbill · Joined: 29 Jul 2015 Posts: 10

I'm trying to use the TRANSMIT_BUFFER feature in the #use RS232 command. Without TRANSMIT_BUFFER field my application transmits all printf strings correctly. When I use TRANSMIT_BUFFER=32 as shown here,

Ttelmah · Joined: 11 Mar 2010 Posts: 19515

Yes.

You have to check the space is in the buffer before sending. The buffered routines are designed to be 'non hanging' so if there is not space the characters are just lost.

tx_buffer_available(STREAM) returns how much space is currently available.

Personally I wish there was an option to select the behaviour. By default it throws the new characters, I'd prefer it to throw the old.

If you want to add checking and hold, then just encapsulate the putc:

jonnewbill · Joined: 29 Jul 2015 Posts: 10

I was not aware of the non-standard

Ttelmah · Joined: 11 Mar 2010 Posts: 19515

Realistically for embedded applications, it is important to not pause the flow of code. Hence, non blocking is the way to go. As you see, if you need blocking, then it is easy to add,

jonnewbill · Joined: 29 Jul 2015 Posts: 10

In my experience blocking is an important element of embedded processing and certainly blocking is much preferred over randomly losing transmission data without any error return to the caller. I have written many FIFO serial buffer implementations for embedded applications over the past 30+ years and they all provided for blocking on transmit buffer full. I can't imagine any application where this "randomly discard data" method would be acceptable.

I tried your code above. What I'm seeing is that tx_buffer_available() never returns a value less than 1. In the manual there's a cryptic reference in the description of tx_buffer_available()

"Transmit buffer is implemented has [SIC] a circular buffer, so be sure to check to make sure there is room for at least one more then[SIC] what is actually needed"

I think this is saying the implementation of their FIFO doesn't allow the last available character to be used. This often happens when FIFO's are implemented with head and tail pointers instead of head and length. With head and tail pointers it's not possible to distinguish between an empty or full FIFO.

The code that seems to work is

Ttelmah · Joined: 11 Mar 2010 Posts: 19515

If you need to ensure data is not lost, then you need to ensure you buffer is big enough.

Loss of a time 'slot' is more important than loss of data. The transmission protocol should be designed to handle the latter....

Yes, I had seen there comment about needing two characters. It is actually perfectly possible for a circular buffer to use all available characters, but CCS have obviously used the simpler coding that makes this difficult.

I must admit I always use my own buffering, but that's because I want to lose the oldest data rather than the new data, on an overflow.

RF_Developer · Joined: 07 Feb 2011 Posts: 839

newguy · Joined: 24 Jun 2004 Posts: 1908

jonnewbill · Joined: 29 Jul 2015 Posts: 10

The problem is that selecting TRANSMIT_BUFFER= in the #use RS232 directive changes the behavior of putc and printf routines. It is very non-intuitive that adding a transmit buffer causes the loss of data. Without it these routines wait for the transmitter to be ready and there is no loss of data and the calling routine is automatically made to wait for character transmission to complete before writing the next character but with TRANSMIT_BUFFER= these same routines simply discard data with no error return which is unexpected behavior. This behavior is compounded by there being no explanation of this in the documentation for TRANSMIT-BUFFER=n. A simple line like

"WARNING when TRANSMIT_BUFFER is used the caller is responsible for insuring there is space in the buffer by calling tx_buffer_available() or data is lost."

This would have saved several hours of investigation and frustration.
Here was my response to support@ccsinfo.com

And users on your forum have confirmed that when transmit buffering is selected there is no handling of overflow in your FIFO routines. Characters are simply discarded. This seems like a very poor design decision as I can see no application where this "randomly discard data" method would be useful. Also it means that by adding TRANSMIT_BUFFER= the behavior of printf and putc changes from waiting on transmitter available to "do not wait and discard data". Given that this is the rather unexpected behavior of the FIFO routines it would be most useful to include a description of it in the TRANSMIT_BUFFER= section of #use RS232 in the manual.

Also I have discovered that tx_buffer_available() always returns 1 and never 0. Such that if a putc() is done when tx_buffer_available() is 1 the character is lost. Meaning that one must test for tx_buffer_available() >= 2 before sending a character. So tx_buffer_available() doesn't actually return the number of buffer characters available since when it returns a value of 1 sending one more character causes it to be discarded due to overflow and the tx_buffer_available() function continues to return a value of 1
_________________
I remember the days before OPS (Other Peoples Software) when all the bytes in my computer were written by me.

Ttelmah · Joined: 11 Mar 2010 Posts: 19515

The manual says almost exactly this under the tx_buffer_available entry.

Several comments.

First, I agree that there should be an option to allow the behaviour to be changed. An option in #use rs232, something like 'HOLD_ON_BUFFERFULL', to allow the behaviour to be changed from losing data to holding when the buffer is full, would be great. So _ask CCS_. Put in a request for this.
Then there has been a new instruction added to the latest compiler releases. They now have a function 'tx_buffer_full' that returns 'true' when there is no space in the buffer. This makes the overload: