We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I am using LPC2132 (by NXP), in my project i need 4 uart, out of this 3 should be at 19,200 bps and one at 38,400bps. So i am planning to make 2 softrware uart with 19,200bps. Is there is any chance for performance issue. i am using 11.0592MHz crystal.
Take a look at this article: www.embedded.com/showArticle.jhtml;jsessionid=ONTTSY4E4YZBAQSNDLRCKH0CJUNN2JVN
That article says,
"When receiving a character, the UART begins its activity on the first falling edge. After this point, the UART only needs to sample the receive line state once in the middle of each bit timeslot."
This is true if you have a clean, noise-free line - but real UARTs will take several samples near the assumed centre of each bit timeslot, and do some majority decision to avoid glitches. Clearly, this makes the makes the job far more intensive - so you need to clearly understand exactly what performance you need from your UART when considering the hardware/software option...
It is quite common that the baud rate clock is 16 times the actual baud-rate, just to let the UART take many samples/bit. A modest 9600 baud would then require 153600 samples/second.
You can probably manage with 4 samples/bit as long as you are careful about detecting the leading edge of the start bit with a reasonable precision, and the sender has a reasonably correct baud-rate..
With some jitter, that would give you 3, 4 or 5 samples for each bit.
With too much baud-rate error (end flank of stop bit not at expected location) you might have to readjust the expected bit windows. It is mainly to better handle jitter on start bit or baud-rate errors that real UARTs uses more than 4 samples/bit.
Software UARTs should really be avoided, unless for school assignments and where existing hardware needs to be pushed beyond specification.
Ive used sw-uarts with 3 sample/bit in real embedded projects and worked perfectly with a simple protocol with checksum.