Searching \ for 'Software UARTs (was Zilog Encore series microproc' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=software+uarts+was
Search entire site for: 'Software UARTs (was Zilog Encore series microproc'.

Truncated match.
PICList Thread
'Software UARTs (was Zilog Encore series microproc'
2003\06\04@115626 by Alan B. Pearce

face picon face
>Any more thoughts?  Have I missed some good tricks?

Well your 8x clock may be higher than you need. In a previous incarnation as
a computer service engineer, and the only full duplex dedicated line modems
we could get with any reasonable speed were synchronous ones, we would have
the occasional customer who would not buy async/sync converters, so we would
hook the async terminals to the sync modem, and run them at a quarter the
sync baud rate. This ensured a reliable communication to the host end. On
this basis I suggest you could use a 4x sample in the same code, and get
correct communication.

Now convert your code to an 18F family running with a 4x PLL, and you should
have plenty of processing speed to get your 19200 full duplex :))) You were
running a 4MHz clock, and I maintain that at this it should be possible to
do 2400 baud (seeing you had 1200 B). Now factor in a 4x PLL, that takes us
to 9600 baud, you only need to make sure you have another factor of 2 in the
picture.

In reality I suspect that you can get away with sampling at 3x baud rate,
but this may get messy on the transmit side. Should be OK when receiving
though.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spam_OUTlistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2003\06\04@134840 by David VanHorn

flavicon
face
>
>In reality I suspect that you can get away with sampling at 3x baud rate, but this may get messy on the transmit side. Should be OK when receiving though.

I've done 1X at 9600 transmit and receive, in an F84.
When I got the start bit int, I delayed half a bit time, then sampled every bit time.  Worked fine.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

2003\06\05@044956 by Alan B. Pearce

face picon face
>I've done 1X at 9600 transmit and receive, in an F84.
>When I got the start bit int, I delayed half a bit
>time, then sampled every bit time.  Worked fine.

Which is what I was suggesting he do earlier in this discussion. Others seem
to think that it may not be a robust implementation.

However it does have a problem when attempting to do full duplex
communication unless you have separate timers available. Consider what
happens when you are transmitting, and a character appears where the bit
edges are not synchronous with your timing because of baud rate differences.
This is where having the timer running all the time may be an advantage.

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu>

2003\06\05@045619 by hael Rigby-Jones

picon face
> -----Original Message-----
> From: Alan B. Pearce [SMTP:.....A.B.PearceKILLspamspam.....RL.AC.UK]
> Sent: Thursday, June 05, 2003 9:49 AM
> To:   EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU
> Subject:      Re: Software UARTs (was Zilog Encore series microprocessors)
>
> >I've done 1X at 9600 transmit and receive, in an F84.
> >When I got the start bit int, I delayed half a bit
> >time, then sampled every bit time.  Worked fine.
>
> Which is what I was suggesting he do earlier in this discussion. Others
> seem
> to think that it may not be a robust implementation.
>
I wouldn't say it wasn't robust, it depends entirely on it's intended use.
An implementation that samples multiple times through the bit will generaly
give better results under adverse condtions.  For simple PC to PIC comms
over a short cable it's likely to be very satisfactory.

Mike


=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to postmasterspamspam_OUTbookham.com.

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu>

2003\06\05@110830 by David VanHorn

flavicon
face
At 09:49 AM 6/5/2003 +0100, Alan B. Pearce wrote:

>>I've done 1X at 9600 transmit and receive, in an F84.
>>When I got the start bit int, I delayed half a bit
>>time, then sampled every bit time.  Worked fine.
>
>Which is what I was suggesting he do earlier in this discussion. Others seem
>to think that it may not be a robust implementation.
>
>However it does have a problem when attempting to do full duplex
>communication unless you have separate timers available.

Absolutely. However, the app was half-duplex.
Many times, you are doing query-response, which is inherently half duplex.

--
http://www.piclist.com hint: To leave the PICList
KILLspampiclist-unsubscribe-requestKILLspamspammitvma.mit.edu>

2003\06\05@161324 by Tim McDonough

flavicon
face
On Thu, 05 Jun 2003 10:07:27 -0500, David VanHorn wrote:
>At 09:49 AM 6/5/2003 +0100, Alan B. Pearce wrote:
>
>>>I've done 1X at 9600 transmit and receive, in an F84. When I got
>>>the start bit int, I delayed half a bit time, then sampled every
>>>bit time.  Worked fine.

>Absolutely. However, the app was half-duplex. Many times, you are
>doing query-response, which is inherently half duplex.

1) So, in this application, you are only using the external interrupt to
sense the start of an incoming byte and then you poll for the level changes
afterwards?

2) If you did not have an external interrupt available to sense the start of
a byte, how many times the bit rate would you need to sample/poll for
reliable receive? 4X?

Tim

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu>

2003\06\05@162118 by David VanHorn

flavicon
face
>
>1) So, in this application, you are only using the external interrupt to
>sense the start of an incoming byte and then you poll for the level changes
>afterwards?

Yes. Catch the start bit, delay 1/2 bit (or 1.5 bit to skip the start bit) then sample only once, in the middle of each following bit.

In this app, this int, and the timer tick int, were the only things happening.
So I wasn't concerned about int latency.


>2) If you did not have an external interrupt available to sense the start of
>a byte, how many times the bit rate would you need to sample/poll for
>reliable receive? 4X?

Hmm.. I'd really not want to do it without an int.
You could be anywhere in the bit, and not know it.

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-requestspamBeGonespammitvma.mit.edu>

2003\06\05@170259 by Ian Chapman

flavicon
picon face
David VanHorn <TakeThisOuTdvanhornEraseMEspamspam_OUTCEDAR.NET> wrote:
>Hmm.. I'd really not want to do it without an int.
>You could be anywhere in the bit, and not know it.

With regular sampling at N x baud rate, you can look out for a high-to-
low change, then delay for (N / 2) sample periods to get roughly in the
middle of the start bit.

This isn't as precise as interrupting on the start bit edge, but will
work okay with suitably high values of N.  I've used N = 8 before, and
Alan Pearce has good reason to believe that N = 4 is okay in many cases
(see his earlier posting).

However, I'd be nervous about the timing uncertainty for smaller values
of N if there is a possible difference of more than a couple of percent
in the baud rate clock frequencies at each end.  This shouldn't occur if
both ends run from crystals which divide down exactly, but I know from
experience that some designs take liberties with this (inexact divisors
leading to frequency offset, RC oscillators with poor accuracy etc.).

All the best.
--
Ian Chapman
Chapmip Technology, UK

--
http://www.piclist.com hint: To leave the PICList
RemoveMEpiclist-unsubscribe-requestspamTakeThisOuTmitvma.mit.edu>

2003\06\06@125941 by M. Adam Davis

flavicon
face
Tim McDonough wrote:

>2) If you did not have an external interrupt available to sense the start of
>a byte, how many times the bit rate would you need to sample/poll for
>reliable receive? 4X?
>
As with nearly everything else, the correct answer is "It depends".  On
my last stint in bit banging a full duplex rs-232 port I used 4.  It is
possible to do it with three, but I ran the numbers and found that my
maximum bit rate error coupled with the maximum error introduced by
using three may result in missing the last bit (stop bit - reading too
early or too late).

I'm certian that with a crystal that could be divided down correctly you
could get great reliability with three.  You would receive the start
bit, wait four cycles for the first read, and then read every three
cycles thereafter.  The earliest the reads would occur is 1/3 into each
bit, and the latest is 2/3 into each bit.

So the correct answer is - run a simulation at the maximum possible
error and see how much error there is at your given N.

-Adam

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\07@105058 by Bob Ammerman

picon face
I have had no trouble with 3 samples per bit when the baud rate error is
nominally zero and the communication link is clean.

I require two consecutive samples to detect the start bit.
I then sample the other bits every three samples after the second start bit
detection sample.

Bob Ammerman
RAm Systems

{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...