Help with rs232 buffer

[aruna1]

Hi friends,

I just started doing a project with dspic 30F4013 and need to use its hardware UART.

In the wizard I can see these buffer options (RECEIVE_BUFFER,TRANSMIT_BUFFER) and it can be configured to any value we like. And again it provide this TXISR option where we can enable tx buffer full interrupt.

But in the device data sheet it says tx & rx buffers are only 4 level deep, and we can configure buffer full/empty interrupts based on this depth of 4.

Now I'm confused, how does ccs implement a large value buffer (say TRANSMIT_BUFFER=100) while when hardware only has 4 deep buffer?

MY main requirement is to send and receive data packets with predefined packet size.

So I was hoping to put 4 bytes into tx buffer, do some other work untill I get tx empty interrupt, put another 4 bytes and so on....until I start the picc wizard and saw these options.

My application is time critical, so cannot wait until some software UART to send data byte by byte. Hence need the hardware UART where I can put 4 bytes, (or more if it is anyway possible) and leave hardware to send it in background while I do some other work. And when the hardware notify me it has finished sending 4 bytes (tx buffer empty interrupt) I have add earlier, I can put 4 new bytes, and go back to my other work while UART sends the data in back ground.

Is this a mechanism I can achieve with TRANSMIT_BUFFER or RECEIVE_BUFFER options? or are they simple a software wrapper built around 4 deep buffer where if I set TRANSMIT_BUFFER to 8, and put 8 bytes, then I have to wait until UART finish sending all the 8 bytes before I go to other work?

I went through several examples you guys have already discussed in the forum about these options, but couldn't find any answer that would help me.

Can you guys help me on this? Any help is much appreciated.

Thanks

PS : compiler version I have is 5.025

[Ttelmah]

TXISR, is _not_ a buffer full interrupt.

TXISR, is a hardware transmit buffer _empty_ interrupt routine, called automatically to take data from the software buffer, and transfer it to the hardware buffer.

Look at ex_stisr.c and ex_sisr.c, which are the standard code for software buffers, showing how these can be used to expand the chip's hardware buffering.

The implementation inside #USE RS232, is basically like these, _except_ that CCS elected to implement the 'internal' version, 'naughtily' in one way. The supplied internal code, throws away the buffer contents, if the buffer overflows. The example version, instead throws the _oldest_ data if the buffer overflows. I personally think they should offer three choices:
1) Throw oldest.
2) Throw all.
3) Hold (so the calling code has to wait for space in the buffer).

If these were options (a value #defined before the #USE, or a separate option in the #USE), then the implementation would be good. However as it stands, generally I'd use the external software version instead, particularly for receive if it is at all likely that buffers are going to overflow.

Now on the transmit, it is simple to code round this. Use the tx_buffer_available function, and verify that there is space for what you want to send, before actually sending data. So you can 'encapsulate' the transmission call, to implement 'hold' on buffer full, using this if required.

If you enable the internal RX buffer routine, it automatically always generates a RX ISR. No option for this. On the transmit, it is optional to have the ISR, but since without this it becomes dependant on 'polling', and therefore has to wait for the software buffer to empty before code can proceed, it is relatively pointless not to use this.

If you enable a buffer=64, for the transmit with TXISR, and send 50 bytes of data, your code can proceed, and the TXISR will automatically refill the hardware buffer to keep data continuously sending, till it has all been sent.

If you need to send 8 bytes at a time, so long as you check tx_buffer_available(YOURSTREAM) >8 (note must be '>', not '>='), before you print, your code can return and proceed immediately.

[aruna1]

Thanks Ttelmah. I will go through the examples.

So are you suggesting I should implement my own buffer system instead of CCS provided one? Due to the issues it has?

[Ttelmah]

It depends on the nature of your code, and your data.

On TX, the supplied routines are fine, provided you ensure there is space before sending.
On RX, the supplied routines could result in the loss of significant data, if the buffer overflows. They are fine, if your code always ensures that data will be handled before the buffer can get close to full. As an example, on a recent project with two serials in use, I used the supplied routines with small buffers on one serial (knew that this data always came and went in small packets, and that there was a lot of time available to process any received data). On the other I used the supplied transmit buffer, and a separate receive buffer. In this case I needed to monitor the arriving data for an end of packet marker, so DIY was the way to go.

[aruna1]