Asynchronous UART send

[gip_mad]

Hello,
I am writing a program and I'm quite short of processing time; I need to send a byte on the serial port and then do something else, but from what I understand the putc() function waits for the byte to be completely sent. I need to put the byte in the buffer and go ahead with the rest of the code, quite like when I do a "read_adc(ADC_START_ONLY);".
Is it possible? I tried to search around on the forum, but I don't even know what terms to use to search... The CCS manual doesn't help either! :(
Thank you!

[gip_mad]

Nevermind, found it on http://www.ccsinfo.com/forum/viewtopic.php?t=47139&highlight=txreg

[SherpaDoug]

When you use a hardware UART the standard putc() simply stuffs the byte into the TX register and returns to the program, while the UART does its own thing at its own speed.

Putc() only waits for the byte to be sent when using a software UART.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Ttelmah]

_Or_ if the hardware register is already full.
Stuffing directly to TXREG, without checking that there is space, risks losing data. Putc checks there is space, and if there is, puts it into the register and returns immediately.
If you need to send more than one byte, look at ex_stisr.c, which shows how to implement an interrupt driven serial transmit using a larger software buffer.

Best Wishes

[gip_mad]

Wow, thank you very much! That was very fast and helpful.
I think I will still use the TXREG, because I have to receive a byte at 2400bps from a software UART and then forward it to the HW UART at 57600bps, so I'm sure that the HW UART has sent the byte before I receive another one from the slower UART.

Thank you again!!!
Best regards!

[asmboy]

[temtronic]

I just got some samples of those 18F46K22s today only to find out my Picstartplus programmer doesn't support them,sigh...after almost 20 years uChip has dropped support for my favorite PC peripheral......

[gip_mad]

Yeah, I know about dual UART port PICs, but I'm stuck with a board with a PIC18F2480, and to be honest I have 2 slow SW UARTs to read from and one fast UART to write to.. Plus CAN bus! Thanks anyway!

[bkamen]

[asmboy]

[gip_mad]

Well, I'm not "forced"... It's just that I like that PIC A LOT!!! For one main reason: I work on the automotive industry, and there's this AWESOME product that I found http://www.dealextreme.com/p/obdii-bluetooth-car-diagnostic-cable-black-blue-orange-dc-12v-42825 , you can find it anywhere even on EBAY, and it has a PIC18f2480, an MCP2551 CAN transceiver, 12V supply with 5V and 3.3V regulators, 4 LEDs, integrated Bluetooth, a really nice case and an included OBD2 connector, all that for 21$ shipped!!! This thing is so versatile that I use it in almost every one-off project and patches and improvised tools and prototypes, the only downside is that you have to solder in a programming header and lift the MCLR pin. I order 10 of them every time! I swear, it's not an ad!
It comes with the ELM327 firmware out of the box (I even found an unprotected one and I have the hex if anyone's interested) so it's already useful!

About the sw UARTs, yes, I hate them too, but I have clearly in mind what my code will do and I know that it won't be a problem, so while a bit disgusting, I think it will work good.

[Ttelmah]

Seriously, since you are talking about 'slow' software use, consider not using the standard library. Some time ago, I published some basic code here for doing doing async using a timer interrupt, and in the past have done both TX and RX this way, it avoids the problems of other interrupts affecting the timing (provided their handlers are reasonably quick), and allows other jobs to be going on while the character is transmitted or received....

Best Wishes