Fast UART transmission

[stoyanoff]

Greetings! I'm using CCS v5.024, MPLab v 8.91 and dsPIC30F5015. I want to use UART interface, but normally if I have baudrate=9600 and this code:

[temtronic]

Use an ISR for the transmit. Either it's in the examples or one was posted here. You just load up a buffer and when the xmit section of the UART says I'm empty, it'll grab a character from the buffer and send it.

Jay
BTW 1ms for 9600 baud is correct.

[stoyanoff]

Just a second! If I use IRS am I going to decrease the transmition time to a few cycles or I`ll have 1ms in the interrupt?!
Thanks!

[Ttelmah]

As Jay says, 1mSec/byte is roughly correct.

9600bps = 0.10416mSec/bit

8bit byte, involves 1 start bit, 8 data bits, 1 stop bit.

So 10 bits/byte transmitted.

1.04mSec/byte.

ex_stisr.c shows how to use a interrupt driven serial transmit.

Or on any recent compiler, you can add a transmit ISR to the #use rs232

#use rs232(UART1, BAUD=9600, TRANSMIT_BUFFER=64, TXISR, STREAM=RS232)

Then in the 'main', just enable_interrupts(GLOBAL); and you can fputc/fprintf directly to this buffered UART. Use tx_buffer_available(RS232) to find how much space is available in the buffer.

So if you want to send twenty characters, provided tx_buffer_available is greater than 21, you can print and it will all be buffered almost immediately.

[gaugeguy]

I am not sure about that particular processor, but typically putc or fputc will only wait if the buffer is full. If the buffer is not full it will place the byte into the buffer and return without waiting for the transmit to complete.
This assumes there is no flow control or enable line set up.

[Ttelmah]

Yes.

The hardware transmission buffer though is very small. On PIC18's, just two characters (one 'in transmission', and one extra). On the PIC30, just four characters.
The only reason it'd wait for a single character, is either using a software UART, or that the hardware buffer is full.
The point about using the transmit interrupt is it allows you to 'extend' the transmission buffer size.

[newguy]

If you use a dsPIC that has DMA, you can then employ the DMA to automatically send your message for you, with no processor involvement required beyond the initial setup.

[Ttelmah]

Not actually that easy or advantageous for simple data transmission.
It's great for 'packet based' transmission (if you have a packet of fixed size, that is transmitted), but gains you little or nothing for more basic data.
Where DMA is great, is when you can set up a linear block of data to send. Then program the UART interrupt to occur every four bytes, and the DMA interrupt to occur when you reach the end of the block. It then handles automatically re-filling the UART buffer, and sends the whole block without processor intervention. However for normal transmissions involving data of variable size, it doesn't gain you anything.

[Ttelmah]

[newguy]

[Ttelmah]

It still requires the buffer to be linear, and with known blocks to transmit.

I've used it on known 'pre-prepared' packets, and it is great for this, but for normal UART I/O, using single byte, or normal printf I/O, it is very hard indeed to handle adding characters dynamically.
It's the difference between things that are suited to a linear buffer, and a circular buffer. 90% of standard UART comms is better suited to the latter....

[temtronic]

Have to ask an obvious question..
Can you increase the baudrate or is it fixed on the other device at 9600?
I know 9600 seems to a defacto standard these days, but modern chips can easily push 38400, even 115K200 without errors.

Maybe an option ?

Jay

[avatarengineer]

@temtronic
You can any baud rate you wish (within reason);
i.e. a software UART version or hardware version can be described

#DEFINE SWUART FORCE_SW,xmit=Tx2,rcv=Rx2,BRGH1OK,bits=8,parity=n,Stop=1
#USE rs232(SWUART,baud=200000,DISABLE_INTS,stream=COMport)

Looking at the PIC in mind, the UART clock divider, per spec, has pre & post scalers that if you create a spreadsheet, like I do,
will calculate actual versus programmed baud with an error rate based on packet size.
Helps to know drift and offset of Fosc, too.

The old increments of Baud such as 9600 or 115.2K aren't the only choices.
You can use 400Kbaud (it divides evenly from an 8 or 16MHz clock) as long as your receiver is the same or using AutoBaud.

[Ttelmah]

Temtronic knows full well what baud rates can be done. He was asking the _thread poster_ whether he could use a higher baud rate, if he was worried by how long a byte takes to send at 9600bps.