Software serial I/O | Piclist | EmbeddedRelated.com

Well, I got the software UART working on my 16F88 along with the hardware UART. I can now flawlessly read GPS data from the software UART and output other stuff on the hardware UART. I made a few changes, one of them was changing from the internal 8MHz oscillator to a 4MHz external, but I think it was the code change that made the difference. And I now understand why a serial UART works, even when you can't guarantee that a falling edge is a true start bit. Aside from accurate bit delays, two things make a serial UART work: 1) the gaps between characters, and 2) a fast enough reading loop. When reading a byte you can assume that the first falling edge is a start bit, even when it may not be. (At first I didn't understand why this part was actually unimportant.) This first character may or may not be accurate, but it doesn't matter. Because as long as the read loop is fast enough you'll get back in time to catch the actual start bit of the next byte. That is, you can't be taking too much time in your main code before you try to read another byte. This isn't a problem with the hardware UART, because it operates as long as the clock is running. When the first falling edge is a true start bit you're in sync. No problem. And when you come back around again to read a byte you'll get the start bit of the next byte. When the first falling edge is a false start bit (an edge of a data bit) then this byte is bad, and you end up in the gap between characters (maybe). Then, as long as the read loop gets back in time, you'll catch the start bit of the next byte. If you detected a false start bit you could also end up in the middle of the next character, depending on the gap between characters. With just the stop bit as the gap and if the first falling edge was actually that of the end of the 1st bit (bit 0) you end up interpreting bit 1 (if it's a zero) as the start bit and then you wind up looking for a start bit 1 bit later in the next byte. Within 8 bytes, however, you will have worked over to a true start bit and you'll be sync'd. Having two stop bits would speed up the sync'ing. And it seems this may be why serial protocol allows for transmitting 1.5 or 2 stop bits, which, with the speed of processors today becomes unnecessary. If this was explained last time and I was too thick to pick it up...my thanks and apologies. Mike

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

At 04:14 AM 22/08/04, you wrote: >Well, I got the software UART working on my 16F88 along with the >And I now understand why a serial UART works, even when you can't <snip> >If this was explained last time and I was too thick to pick it >up...my thanks and apologies. It was, you were, apparently. :-) Apology accepted. Welcome to the world of the enlightened!

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Phil, I went back and read your post. And I was like "Yeah, yeah...I remember reading this". And then I got to your last paragraph and went "Ohh...uhhh, I didn't read this part". Perhaps my stupidity will keep me young. :) Mike --- In , Phil Seakins <pseakins@a...> wrote: > At 04:14 AM 22/08/04, you wrote: > >Well, I got the software UART working on my 16F88 along with the > >And I now understand why a serial UART works, even when you can't > <snip> > >If this was explained last time and I was too thick to pick it > >up...my thanks and apologies. > > It was, you were, apparently. :-) > > Apology accepted. Welcome to the world of the enlightened!

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Sign in

Search piclist

Subscribe to piclist

piclist by Keywords

Discussion Groups

Discussion Groups | Piclist | Software serial I/O

Software serial I/O - upand_at_them - Aug 21 13:14:00 2004

Re: Software serial I/O - Phil Seakins - Aug 21 18:55:00 2004

Re: Software serial I/O - upand_at_them - Aug 21 19:17:00 2004