difference between UART hardware devices and others

[ssaakmnt]

hello guys what the difference between the devices that have UART hardware
and other devices that don't for example using serial port with pic16f877 and pic16f84 .

[temtronic]

some things...
Those with hardware UARTs allow for better,faster 'standard' serial communications to other computers(usually PCs).Better as the UART is a 'stand alone' peripheral NOT dependent on the PIC for timing or formatting,faster as the UART can issue an interrupt on rcv or xmt of characters,standard means compatible with the 'regular world of 8-n-1 UARTs',less code involved, simple read/writes to the UART registers.

If you do not require that function, then no benefit.For almost 3 decades I've used my own serial communications format over 20 miles of solid copper wire and never had a reason to 'upgrade' to PICs with hardware UART.

Unless you're project requires interfacing to the 'common' computer world,the UART is not needed and a minor cost saving might be possible.

[bkamen]

Put perhaps more simply,

If you want to do serial on a PIC, with a UART (or some variation) there's hardware built into the chip that does the work for you. If not, your code has to do the work (and is extremely sensitive to timing).

So ask yourself while you're writing code and what to use software UART's, "could my code" or "do I want my code" or "should my code" be doing something else while the code is servicing sending or receiving this serial data?

If the answer is yes, then get a PIC with a hardware UART. While temtronic is right in that they might save a little -- it's usually pennies and in the long run, probably not worth it -- unless you REALLY have that intended app well defined.

Keep in mind at 9600b/s, it takes about 1.04mS to send/recv a char

If you ran a PIC (PIC18 let's say) at 40MHz (Tcy is now 100nS).

You can execute up to 10,400 instructions while that one byte is coming or going. But not so much if you're using software RS232... (unless you do it in interrupts which is still not as nice as having hardware do the work for you)
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[SherpaDoug]

Also note that if the PIC is doing work while waiting for a command, such as running a PID loop while waiting for the user to change settings, the PIC must poll the input occasionally so characters are not lost. If you have a hardware UART with a serial interrupt driven buffer you must poll before the interrupt buffer overflows, maybe every 10 or 20 characters. If you have a hardware UART and no interrupts you must poll before the UART buffer overflows, every 2 characters. If you have a software UART and use kbhit() to see if a character is comming in you must poll near the start of the first BIT. That is about every 0.031 characters!

Software UARTs may be OK if the PIC is only talking, or only listens at specific well defined times. If a character can come at any time a hardware UART is almost required.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[bkamen]

I just wrote a GPS app that needs to collect strings -- and keeping in mind the PIC18's have the 8x8 multiplier (again, hardware to the rescue).

I have about 25 "buckets" to hold 10chars each.

I know my GPS spews in bursts and the info I want is < 10chars.

With my current ISR, the PIC can collect strings and just buffer away while the main loop just processes at will. It's more of a "string FIFO" than a "byte FIFO".

Works great... and the keeping the number of strings within the prod output of the hardware 8x8, CCS is smart enough to use is allowing me to index strings inside my ISR efficiently.

the rest of my code does a boadload of sorting and printing to a graphics LCD, so the hardware UART really helps.

Again, the right PIC (and code) for the task is an important consideration.

I'm rambling.

Cheers.
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[ssaakmnt]

Yes, I think I need a flexible connection like sending and receiving during run time or interrupt a loops and control functions.
I tried to use a typical pic16f84 to send and receive characters and integers to control some functions and loops but I faced lot of problems. I guess now UART hardware may solve it .