Has anyone ever tried RS232/485 comms using software and the internal RC occillator on this chip...if so what speeds did you achieve before accuracy becomes a problem...if it works at all...
> Has anyone ever tried RS232/485 comms using software and the internal RC
> occillator on this chip...if so what speeds did you achieve before accuracy
> becomes a problem...if it works at all...
We do this on production basis using 9600bps. BUT we are only sending
two bytes at a time. The receiving end is a 'real' UART that syncs up on
each start bit.
> Has anyone ever tried RS232/485 comms using software
> and the internal RC occillator on this chip...if so what speeds
> did you achieve before accuracy becomes a problem...if it works at all...
(Note: not from experience) speed has nothing to do with it, the same
problem will bite you at every speed. It will probably work at 20 C, 5 V +/
1 % and on every day except friday 13th.
Wouter
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's
Well let me tell you just in case you are interested that speed does play an
important part in it...when you increase the speed the +/- error leeway for
sampling bits in the rx'ed byte diminishes whereas at slow speeds you have a
greater window in which to acurately sample the bits...
In case anyone is interested l have found that you synchronise at 1/4 bit
time for sampling and leave a 1/2 bit window in which to sample you get much
better results than trying to sample at 1/2 bit time...
I use this in my RTOS system and it works a gem at all speeds (limited by
xtal freq of course) . becuase of the errors in processing time used in
multitasking without interupts (ie. undeterminable task times) it leaves me
room for this error but always gets there in the centre half of the bit
somewhere...
l actually stole the idea from michochip RTOS application notes...they call
it the Fudge Factor...which l quite liked as it sounded quite warm and
sqishy...hehe...thanks
Does anyone have any luck downloading the IDE for C2C...it justs hangs
forever when l try to download it...if someone can make or knows of another
available spot to dowload it please let me know...
The original question deals with clock error vs. reliability of the link.
I chose to ignore the inherent sampling error due to a non-commensurate
baudrate/clock rate specifically because the clock rate is no longer
accurately specified.
Again, assuming you have a fast enough (nominal) clock to sample the signal
appropriately, and assuming that you actually sample when you should (ie:
you're not buried in some other code at the sample point), then the RC clock
error vs. baud rate will cause exactly the same problems at any baud rate.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
> In case anyone is interested l have found that you synchronise at 1/4 bit
> time for sampling and leave a 1/2 bit window in which to sample you get
much
> better results than trying to sample at 1/2 bit time...
I don't follow what your are trying to say. If you are going to take a
single sample per bit, why would you not want to center your sampling window
at wherever you think the center of the bit is?
*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, olinKILLspamcognivis.com,http://www.cognivis.com
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's
Olin
I think this refers to how accurately you detect the start bit, therefore
how accurately you can locate the center of subsequent bits. Testing for
start with even 1 bit time would work sometimes, 1/2 bit time (i.e. polling
for start at twice baud rate) gives 1/2 bit uncertainty, 1/4 is probably a
good compromise. Hardware UARTs frequently use 1/16 bit sampling.
well l run all my projets under a Real Time Operating System l am developing
on the PIC chips...I may have one chip with 2 asynchronous serial ports,
three pwm outputs, a keypad, a couple of software pot readers, and numerous
timers. They all run simultaneously...ie l dont have to wait for one to
finish before l start another...they can all run independantly. I also have
a few controll processes running to control all the bits and pieces...
It is very similar to the Scenix Virtual Peripheral setup if you know about
that...
anyway each process is broken up into tiny tasks that run very quickly one
after the other. Each has its own little amount of time to do something
then the others must be processed. It may take up to 50 clock cycles to get
back to the start of the loop. So in that case there is a 50 cycle +/-
error...
now at 4mhz...(l actually use 3.579 just to be difficult and because l have
about 10,000 of the bloody things) and with a baud rate of 9600 each bit is
spaced at 103 cycles or so. so if l have a maximum error (time it takes
for the longest loop through the processes) l must allow for this.
say l sample at the dead centre of a bit time...for all l know the timers
waiting for this event might be up to 50 cycles late...by sampling 25 cycles
earlier with the timer l know l will be at most 25 cycles early or 25 late.
This means l hit within the centre half of the bit.
So l give the system the oportunity to get it right by sampling at between
1/4 and 3/4 or the bit...l take two quick samples one after the other as
there isnt time to muck around too much. it works like a gem anyway.
I have it working over 1 km of wire, feeding 240v with a electric drill down
the same cable (different wires of course) on two pair. the drill simulates
some pretty bad noise and you have to really grab hold of the chuck and try
and stop it (get the current flowing) to disturb it...
under normal conditions it never skips a beat...no error correction yet just
a simple master slave protocol with error detection...it runs on one wire so
it feeds back into itself...tx into rx which can see if what it is sending
is what it is recieving...if it is different it just resends it...
by the way l use no line drivers what so ever but it is totally
un-blowup-able. well 240v might do it but l'll have to check that out...l
have had a maximum of about 50 nodes on a network so far and am planning for
a maximum of 256 so l hope it can handle it...anyway l hope that cleared
things up...maybe it confused you more...but anyway...
will release the code at a future date so you can have a look...
> > In case anyone is interested l have found that you synchronise at 1/4
bit
> > time for sampling and leave a 1/2 bit window in which to sample you get
> much
> > better results than trying to sample at 1/2 bit time...
>
> I don't follow what your are trying to say. If you are going to take a
> single sample per bit, why would you not want to center your sampling
window
> at wherever you think the center of the bit is?
Because, as he stated (perhaps in another message), he is actually defining
the _starting_ point of where he will look for the bit. He may be off
handling something else when the time comes up, and this gives him about 1/2
of a bit time to get to actually checking the incoming bit.
Not the way I'd do it (I much prefer synchronous interrupt driven sampling)
but it makes a lot of sense.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's
> good compromise. Hardware UARTs frequently use 1/16 bit sampling.
Busy-wait software receive can sample as fast as the processor allows, for
instance once every 3 instructions, almost 1Msamples/sec, ~ to 1/16 for 60
kbaud, but much better for lower baudrates.
Wouter
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's
At 09:21 AM 9/24/00 -0400, you wrote:
>The original question deals with clock error vs. reliability of the link.
>
>I chose to ignore the inherent sampling error due to a non-commensurate
>baudrate/clock rate specifically because the clock rate is no longer
>accurately specified.
>
>Again, assuming you have a fast enough (nominal) clock to sample the signal
>appropriately, and assuming that you actually sample when you should (ie:
>you're not buried in some other code at the sample point), then the RC clock
>error vs. baud rate will cause exactly the same problems at any baud rate.
And the "characterized" not guaranteed clock frequency can be off by almost
8.75% (low) or 7% (high) over the temperature range at 5V (worse at 2.5V).
(page 87, table 13-3).
So, in 10 bit times (at the beginning of the 11th bit) you can be off by
almost
the entire bit. Well, if you only want to communicate with a PC or other
accurate UART, only do it on a workbench at 5V supply, and don't care much
about reliability, you can probably get away with it for a few units or a few
hundred units.
Personally, I think it to be irresponsible design, since some units will very
likely fail to work when used over any reasonable temperature range.
I say- put in the fifteen cent 3-pin resonator, lose the two port pins and
make
a reliable product!
Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..." "The Journey is the reward" speffspam_OUTinterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
There is one technique that can result in reliable serial comms with an RC
oscillator: Use the receive bit timing to establish the transmit bit timing.
Assume that the device is polled by a PC. Make the poll command start with
0xAA or 0x55 (ie: lots of bit transitions). The target PIC simply determines
the high-to-high or low-to-low time and divides it by two to compute the bit
time. I suggest using high-to-high or low-to-low rather than high-to-low or
low-to-high because there may be unequal rise and fall times depending on
the hardware implemention.
If the target recomputes the timing on every poll it can handle any
reasonable swing of RC clock frequency with Vdd, temperature, day of the
week or the phase of the moon.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
l need rock solid performance though so l am going to xtal now anyway...but
l really need those two pins...anyone know the prices on 16c663 (l think) l
am after a one-time 18 pin chip with eeprom 1k memory...l think l got the
right one...it has to be cheap anyway whatever l use or the project will
never get off the ground...its amazing that a dollar or two can do ...
I used this exact method for doing a radio link, except that a 1 was
trasmitted as 10 and a 0 was transmitted as 01, basically it just
transmitted lots of 10 sequences to estblish the clock, then sent a
zero to signify start of data. Samples were taken in both halves of
the data transmission with a best of three method, and it was
checked that one was a 1 and one a 0. If there was an error it
aborted the transmission. This was used to transmit sections of
about 64 bytes at a time, and given that the system knows each bit
of data will contain a transition in the middle it makes clock
recovery easy.
>
>
> > There is one technique that can result in reliable serial comms with an RC
> > oscillator: Use the receive bit timing to establish the transmit bit
> timing.
> >
> > Assume that the device is polled by a PC. Make the poll command start with
> > 0xAA or 0x55 (ie: lots of bit transitions). The target PIC simply
> determines
> > the high-to-high or low-to-low time and divides it by two to compute the
> bit
> > time. I suggest using high-to-high or low-to-low rather than high-to-low
> or
> > low-to-high because there may be unequal rise and fall times depending on
> > the hardware implemention.
> >
> > If the target recomputes the timing on every poll it can handle any
> > reasonable swing of RC clock frequency with Vdd, temperature, day of the
> > week or the phase of the moon.
> >
> > Bob Ammerman
> > RAm Systems
> > (contract development of high performance, high function, low-level
> > software)
> >
At 11:36 PM 9/26/00 -0400, you wrote:
>There is one technique that can result in reliable serial comms with an RC
>oscillator: Use the receive bit timing to establish the transmit bit timing.
Very clever, a modification of the autobaudrate function that used to be
popular. I suppose you'd be limited to fairly low bit rates (relative to
clock speed) to get some resolution on the capture. In some apps (distributed
polled sensors perhaps) it could work well (retry in case the slave gets
the baud rate measurement wrong due to noise).
Have you actually tried this?
Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..." "The Journey is the reward" @spam@speffKILLspaminterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Subject: Re: [PIC]: Asynchronous comms on PIC 12ce519
There is one technique that can result in reliable serial comms with an RC
oscillator: Use the receive bit timing to establish the transmit bit timing.
Assume that the device is polled by a PC. Make the poll command start with
0xAA or 0x55 (ie: lots of bit transitions). The target PIC simply determines
the high-to-high or low-to-low time and divides it by two to compute the bit
time. I suggest using high-to-high or low-to-low rather than high-to-low or
low-to-high because there may be unequal rise and fall times depending on
the hardware implemention.
If the target recomputes the timing on every poll it can handle any
reasonable swing of RC clock frequency with Vdd, temperature, day of the
week or the phase of the moon.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
> And the "characterized" not guaranteed clock frequency can be off by almost
> 8.75% (low) or 7% (high) over the temperature range at 5V (worse at 2.5V).
> (page 87, table 13-3).
> I say- put in the fifteen cent 3-pin resonator, lose the two port pins and
> make
> a reliable product!
Another solution is to send a "training" character from the PC to the PIC, to
measure the timing error. The PIC can then adjust its bit timing.
It's funny, even without a crystal you have access to a very good timing
reference.
If the aim is to communicate with a device of known timing integrity (PC)
why not use bytes from the PC to calibrate the PIC, use a known start
character with a run of bits so you can time it reasonably accurately. Use
this value to set the bit sampling interval for subsequent bits and for
transmit timing.
If the aim is to communicate between PICs you might use the above but add a
synchronisation scheme where the PIC might adjust it's OSCAL to approach
that of the other. A number of devices might pull themselves into line
eventually.
Consider using 4 or less bit words for greater error tolerance.
Artificially insert a bit flip half way through, say at 5th bit.
> Thats a good idea bob,
>
> l need rock solid performance though so l am going to xtal now
anyway...but
> l really need those two pins...anyone know the prices on 16c663 (l think)
l
> am after a one-time 18 pin chip with eeprom 1k memory...l think l got the
> right one...it has to be cheap anyway whatever l use or the project will
> never get off the ground...its amazing that a dollar or two can do ...
FWIW: I expect you would get rock solid performance using this trick,
assuming careful coding and a not-too-high baud rate. I certainly wouldn't
give up on it quite so easily, especially if dealing with a very cost
sensitive application.
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
> ----- Original Message -----
> From: "Bob Ammerman" <RemoveMERAMMERMANspam_OUTKILLspamPRODIGY.NET>
> To: <RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU>
> Sent: Wednesday, September 27, 2000 1:36 PM
> Subject: Re: [PIC]: Asynchronous comms on PIC 12ce519
>
>
> > There is one technique that can result in reliable serial comms with an
RC
> > oscillator: Use the receive bit timing to establish the transmit bit
> timing.
> >
> > Assume that the device is polled by a PC. Make the poll command start
with
> > 0xAA or 0x55 (ie: lots of bit transitions). The target PIC simply
> determines
> > the high-to-high or low-to-low time and divides it by two to compute the
> bit
> > time. I suggest using high-to-high or low-to-low rather than high-to-low
> or
> > low-to-high because there may be unequal rise and fall times depending
on {Quote hidden}
> > the hardware implemention.
> >
> > If the target recomputes the timing on every poll it can handle any
> > reasonable swing of RC clock frequency with Vdd, temperature, day of the
> > week or the phase of the moon.
> >
> > Bob Ammerman
> > RAm Systems
> > (contract development of high performance, high function, low-level
> > software)
> >
> > ----- Original Message -----
> > From: Spehro Pefhany <EraseMEspeffspamspamBeGoneINTERLOG.COM>
> > To: <RemoveMEPICLISTKILLspamMITVMA.MIT.EDU>
> > Sent: Tuesday, September 26, 2000 3:10 PM
> > Subject: Re: [PIC]: Asynchronous comms on PIC 12ce519
> >
> >
> > > At 09:21 AM 9/24/00 -0400, you wrote:
> > > >The original question deals with clock error vs. reliability of the
> link.
> > > >
> > > >I chose to ignore the inherent sampling error due to a
non-commensurate
> > > >baudrate/clock rate specifically because the clock rate is no longer
> > > >accurately specified.
> > > >
> > > >Again, assuming you have a fast enough (nominal) clock to sample the
> > signal
> > > >appropriately, and assuming that you actually sample when you should
> (ie:
> > > >you're not buried in some other code at the sample point), then the
RC {Quote hidden}
> > clock
> > > >error vs. baud rate will cause exactly the same problems at any baud
> > rate.
> > >
> > > And the "characterized" not guaranteed clock frequency can be off by
> > almost
> > > 8.75% (low) or 7% (high) over the temperature range at 5V (worse at
> 2.5V).
> > > (page 87, table 13-3).
> > >
> > > So, in 10 bit times (at the beginning of the 11th bit) you can be off
by
> > > almost
> > > the entire bit. Well, if you only want to communicate with a PC or
> other
> > > accurate UART, only do it on a workbench at 5V supply, and don't care
> much
> > > about reliability, you can probably get away with it for a few units
or
> a
> > few
> > > hundred units.
> > >
> > > Personally, I think it to be irresponsible design, since some units
will {Quote hidden}
> > very
> > > likely fail to work when used over any reasonable temperature range.
> > >
> > > I say- put in the fifteen cent 3-pin resonator, lose the two port pins
> and
> > > make
> > > a reliable product!
> > >
> > > Best regards,
> > >
> >
>
What is different here is that we are using the recovered _receive_ clock to
set up the timing constants for our transmission. Actually, in this case the
timing constants are timing variables :-)
Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)
> >There is one technique that can result in reliable serial comms with an RC
> >oscillator: Use the receive bit timing to establish the transmit bit timing.
>
> Very clever, a modification of the autobaudrate function that used to be
> popular. I suppose you'd be limited to fairly low bit rates (relative to
> clock speed) to get some resolution on the capture. In some apps (distributed
> polled sensors perhaps) it could work well (retry in case the slave gets
> the baud rate measurement wrong due to noise).
>
> Have you actually tried this?
I use this method (to 9k6) and it is very reliable and noise immune.
I would expect 19k2 to work OK too. I just haven't needed to try it.
For reliable operation, you need to know what the first character is
going to be so it suits message packets well. If you choose wisely,
you can set the baud rate and make several checks on the character at
the same time. I did run some noise immunity tests on it and never
got a wrong baud rate. It either rejected the rate setting character
or set it correctly and rejected the packet (16 bytes) based on the
checksum.
The down side is that it does consume quite a bit of code space and
needs to be the highest priority.
It works really well for simple distributed I/O where everything is
in responce to a command from a master. ie. Get message, check ID, do
task, send reply, wait for next command.
Steve.
======================================================
Steve Baldwin Electronic Product Design
TLA Microsystems Ltd Microcontroller Specialists
PO Box 15-680, New Lynn http://www.tla.co.nz
Auckland, New Zealand ph +64 9 820-2221
email: @spam@steveb@spam@spam_OUTtla.co.nz fax +64 9 820-1929
======================================================
> Very clever, a modification of the autobaudrate function that used to be
> popular. I suppose you'd be limited to fairly low bit rates (relative to
> clock speed) to get some resolution on the capture.
You can train on a 0x00 byte, which offers factor 9 (8N1) for capture quality.
mitvma.mit.edu
