Searching \ for '[EE]: General Serial Tips' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=serial
Search entire site for: 'General Serial Tips'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: General Serial Tips'
2002\10\09@193824 by William Chops Westfield

face picon face
   Sorry this is late; I wanted to run it by another engineer as a double-
   check, but I'm so busy lately, I guess I'll just post what I drafted...

Added [EE] tag...


   1. Familiarize yourself with the normal, 25-pin, RS-232 signalling set.

Useless, IMO.  The reason that PCs use 9 pin connectors, and a lot of comm
equipment uses 8pin RJ45 jacks for "rs232" is that most of the 25 pins
defined in "the standard" are nearly useless and hardly ever used or
implemented.  DB25s in general are dissappearing as well - they're just
too BIG for the seven or less signals used by most scenarios.



   2. Decide whether your device is Data Communications Equipment (DCE),
      or Data Terminal Equipment (DTE).

Unimportant.  Little beyond pinout and connector sex survives from the
actual definitions (and I don't think that sex was part of the standard.)

  If in doubt, if you are going to talk to a PC, I would strongly lean
  towards DCE to reduce cabling headaches later.

Assuming you mean "DCE sex and pinout", this is good advice.


   3. Decide what type of flow control you would like to use: software or
      hardware.  If you are building DCE, I strongly recommend CTS/RTS
      flow control

Yes.  Software flow control has way too many variables to deal with
reliably, especially on small microcontrollers (high-delay communications
paths and/or deep fifos may require that you buffer substantial quantities
(128+ bytes) of data even after you send an XOFF.)


      (you will assert CTS to tell the PC that it may send you data; your
      device can check the RTS line to see if it is ready to send data, or,
      more typically on PIC-based projects, just ignore it).

In the usual RTS/CTS Hardware flow control, the DCE asserts CTS to indicate
that it is ready to receive data, and the DTE asserts RTS to indicate that
IT is ready to receive data.  The SPEC, where RTS is actually used by the
DTE to indicate that it HAS data, is more of a half duplex
modem-control/turnaround sort of thing, and is rarely implemented,
especially not for async stuff.


   DTR/DSR flow control is really intended for when the DTE is
   not likely to be able to keep up with the DCE, and that just doesn't
   tend to be the case these days, because the buffers on PCs tend to
   be huge compared to the devices they are talking to.

DTR/DSR flow control is just like the RTS/CTS flow control I describe
above, except using different pins.  It IS rare.  Some UART chips support
a hardware flow control in hardware, and they may vary the names that they
give the pins that are involved.  The comment about big buffers on PCs
being common is true, and is what allows you to ignore RTS most of the time
in RTS/CTS flow control...


   4. Pretend that both the PC (or other device) and your device are RS232
      spec-compliant, 25-pin devices.

Don't.  They aren't.  Nor are most modern modems.  DO use standard pinouts
and connectors, of course.

>>   If you have TWO pesky pieces of DTE that won't talk, try

Get (or make) a breakout box.  Really.  Stop trying to guess what the
designed might have had in mind and LOOK at which device is driving which
signals, and which signals change when transmitting data.  DO make sure
(somehow) that GROUND is in the right place (usually you can tell by
checking on the breakout box whether the signals shown match what the
transmitter thinks it is doing, and for "even brightness" on what should
be signals at identical states.  You can get ... REALLY odd behaviors if
you have DTR on one side connected to GND on the other, for instance.)


   6. Use standard connectors to save your users some headaches.
   7. Whatever you do, BE CONSISTENT.

Yes.  For instance, our standard was that all rs232 cables would be
mail to female, straight-through (pin 2 to pin 2, etc) cables, and that
any inversions of sex or DCE-ness would be done with gender-changers and
"null modems."  Very useful.

Beware RJ cables, cause there are two standard cables (one reverses all the
pins, and one doesn't.)



Added stuff:

There are three common serial scenarios that cover most usage:

1) three wires:  TxD, RxD, GND.
2) five wires: (1) plus CTS/RTS for hw flow control.
3) seven wires: (2) plus DTR/DSR for modem control.

Be aware of PC "quirks" - the PC serial port really want to see DSR from
the connected "DCE" equipment, at a HARDWARE level.  On most devices, such
behavior is configurable in software, but not PCs.

The easiest way to connect to a PC is to use a connector that tricks the PC
into seeing all of the appropriate signals (short (db25) 4,5,6: RTS out
looped back to DSR and CTS), but this is a non-standard connector.  You can
do the same thing on your actual device (but then you need a thicker
cable.)

BillW

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


2002\10\10@034307 by Rob Hamerling

flavicon
face
William,
The original post of Matt Heck is a very valuable contribution to
(more or less) beginners with RS232. In my opinion most of your
comments destroy its effect and beginners better forget most of
it, because I think these may cause more problems than solve. Even
your recommendation for a breakout box is doubtful, because if you
don't have a good one it may introduce (more) problems!
Rob.
--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\10\10@092700 by Olin Lathrop

face picon face
part 1 3013 bytes content-type:text/plain; (decoded 7bit)

> Yes.  Software flow control has way too many variables to deal with
> reliably, especially on small microcontrollers (high-delay communications
> paths and/or deep fifos may require that you buffer substantial quantities
> (128+ bytes) of data even after you send an XOFF.)

Note that flow control doesn't have to be done at the lowest layer.  It can
often be convenient to have no low level flow control at all (RTS/CTS not
used, XON/XOFF no special meaning).  This allows arbitrary 8 bit bytes to be
transfered over simple three wire cables (RX, TX, GND).  Flow control, or
more precisely overrun prevention, is guaranteed by the protocol.  I have
done this sort of thing many times for a PIC communicating with a PC.

One simple scheme is send all information from the PC to the PIC in commands
that have a finite length.  The PIC input buffer is big enough to handle the
largest possible command, and the PC must wait for an ACK from one command
before sending the next.  This is easy and effective, although it does not
make full use of the potential bandwidth and introduces some latency.  I
tend to run all RS-232 communication at 115.2Kbaud, and for most projects
this bandwidth is far more than needed and the latency isn't an issue.

In one recent project I didn't want the latency from the ACK to receiving
the next command, although the 115.2Kbaud bandwidth was several times higher
than needed.  This was a PIC programmer where I wanted to program a 16F877
about as fast as possible.  In this case I made the input FIFO large enough
to accept two maximum length commands and allowed the host to stay one
command ahead.  Each command packet started with a command opcode followed
by whatever data bytes specific for that command.  The PIC sent the ACK
immediately on processing the command opcode instead of after the whole
command was processed.  The final burn time for the entire program memory of
a 16F77 was 36 seconds, with the theoretical minimum being 33 seconds.  The
extra 3 seconds had to do with the serial communication speed to the target
chip, not the communication to the host PC.

> Yes.  For instance, our standard was that all rs232 cables would be
> mail to female, straight-through (pin 2 to pin 2, etc) cables, and that
> any inversions of sex or DCE-ness would be done with gender-changers and
> "null modems."  Very useful.

I agree.  I like to think of the PIC gizmo connecting directly to the PC
serial port, with the cable merely being an extension to make it
mechanically possible.  Almost all modern PCs and other computers use male
DB-9 connectors for the serial ports that transmit on pin 3, receive on pin
2 and ground on pin 5.  This means I put a female DB-9 on the PIC device
that receives on pin 3, transmits on pin 2, with pin 5 tied to ground.  The
attached schematic is the RS-232 driver circuit I've used often for this
purpose.  The TX and RX lines connect directly to the PIC UART pins.


part 2 14867 bytes content-type:image/gif; (decode)


part 3 318 bytes

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\10\10@100529 by llile

flavicon
face
Matt,

That was a really useful doc!


-- Lawrence Lile

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\10\10@114339 by William Chops Westfield

face picon face
   The original post of Matt Heck is a very valuable contribution to
   (more or less) beginners with RS232. In my opinion most of your
   comments destroy its effect and beginners better forget most of
   it, because I think these may cause more problems than solve.

My message was intended as "comments on" the original post, hopefully to be
considered and incorporated in some sense. moderating some of the
(misplaced, IMO) enthusiasm for "the standard."  There's certainly no reason
to understand the details of synchronous communication over old-fashioned
half-duplex modems (which is fully supported on the full DB25 rs232 spec) if
what you want to do is communicate with the average PC serial port.
My message certainly wasn't intended to be a "user-friendly" replacement for
the original message, and probably sounded a lor harsher than it should
have...


   Even your recommendation for a breakout box is doubtful, because
   if you don't have a good one it may introduce (more) problems!

I disagree.  You use the breakout box for debugging CABLE problems, not for
debugging communications problems.  Used this way, even an awful breakout
box is useful.  (and no, this wasn't that clear in my message.)  There's no
way a couple of LEDs in the data path are going to be useful with data
moving at 1000 bytes/second or more, but it's very useful for confirming
that the correct signals ARE wiggling...

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\10\10@144753 by Matt Heck

flavicon
face
Hang on, now; I'd asked for commentary, and I want to get pretty
much ALL of it before I compile another revision of that document.
(Oh jeez... this is how FAQs are born, isn't it? =])

So pretty much anything anybody has to say on the matter is welcome.
I'm glad you think it'll come in handy for folks, though.

{Original Message removed}

2002\10\10@150657 by Wouter van Ooijen

face picon face
> Hang on, now; I'd asked for commentary, and I want to get pretty
> much ALL of it before I compile another revision of that document.
> (Oh jeez... this is how FAQs are born, isn't it? =])

For a FAQ: how much (percent) can the baudrates of the sender and
receiver differ before the communication fails (ignoring all electrical
aspects).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\10\10@153814 by Russell McMahon

face
flavicon
face
OK. FOR A FAQ.
I just KNOW someone can cut this down in length and add clarity, but here's
my straw man:

______________

In RS232 ( also ~= V24) asynchronous transmission, end to end
synchronisation occurs on a character by character basis. When the receiver
"sees" the start bit it waits 1.5 bit times (until the middle of the first
data bit), samples the value of the data bit and then continues to sample
until all data bits have been input. It then waits another bit time and
samples once more to confirm that a valid stop bit is present. If the
transmit and receive speeds are consistently slightly different the sampling
point will "drift" further away from the middle of the bit on each
subsequent bit. If there is too much difference the sampling point will fall
outside the intended bit and received data will be incorrect. Limiting
acceptable difference in send and receive data rates occurs when the
sampling of the stop bit JUST occurs at either the leading or trailing edge
of the stop bit. This occurs when the error is enough for the sampling point
to have "drifted" half a bit during transmission. If there are S start bits,
D data bits, P parity bits  and E stop (end ) bits then the error involved
is about 0.5 / [S+D+ P + (E-0.5) ] x 100%. (The bottom line is the distance
in bits from the leading edge of the start bit to the middle of the last
stop bit). For 1 start bit, 8 data bits, 0 parity bits and  1 stop bit the
allowable error is
0.5 / (1 + 8 + 0 + 1 - 0.5) x 100% = 0.5/ 9.5 x 100% = 1/19 x 100% = 5.26%.
Usually said to be 5% error for standard N81 transmission.

Note that this error speed is the maximum net error allowed for BOTH
transmit and receive clocks. If both transmit and receive clocks are 5%
maximum error (e.g. typical internal RC oscillator worst case spec) the
worst possible net error is about 10% and 'there will be trouble". Such an
arrangement will often work due to error often not being worst case and some
components of error sources often (but not always ) being shared by
transmitter and receiver (e.g. both at about the  same temperature if in the
same location or both in human accommodation.)

A ceramic resonator has ample accuracy to guarantee the required accuracy if
used at both ends. A crystal even more so. Use of a ceramic resonator or
crystal at one end and a good RC oscillator at the other will often result
in good operation. "Clever" schemes can be devised which determine the
minimum time between received bit edges "on the fly" and use this as 1 bit
time and adjust the clock speed accordingly. This allows the use of very
inaccurate clocks as long as the clock can be adjusted by the system. Bit
length measurement is also the basis for some auto-baud rate detect schemes
which determine the correct link speed by having the user enter a
predetermined character at start up.


       RM



{Original Message removed}

2002\10\10@155230 by hard Prosser

flavicon
face
Based on a 10 bit char. ( startbit + 8*data + stopbit) the limit is about
5% error before the last bit slips by more than 50% of a bit period. Seems
to work out about this value but presumably depends on the detection
arrangement (sampling rate etc.) also.


Richard P





For a FAQ: how much (percent) can the baudrates of the sender and
receiver differ before the communication fails (ignoring all electrical
aspects).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\10\10@162142 by Wagner Lipnharski

flavicon
face
Russell McMahon wrote:
{Quote hidden}

I made a graphic representation of such
allowed frequency shift, with some little
study about it. You can see it at the middle
of this page;
http://www.ustr.net/8051pc/starting.shtml

VV46NER

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\10\10@163150 by Matt Heck

flavicon
face
Wagner, Russell, that's fantastic-- do you mind if throw this stuff in
the FAQ?  Wagner, may we use the diagrams you created, or would a link
be okay?

It's amazing how fast a group effort can produce a result!

Cheers,
  Matt Heck

{Original Message removed}

2002\10\10@171718 by Olin Lathrop

face picon face
> For a FAQ: how much (percent) can the baudrates of the sender and
> receiver differ before the communication fails (ignoring all electrical
> aspects).

For 1 stop bit and 8 data bits, the receiver must be within 5.88% of the
transmitter.  For a real system I'd want to be off by no more than half
that, or about 3%.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\10\10@173342 by Wagner Lipnharski

flavicon
face
Matt Heck wrote:
> Wagner, Russell, that's fantastic-- do you mind if throw this stuff in
> the FAQ?  Wagner, may we use the diagrams you created, or would a link
> be okay?

Make a link, since it will always reflect the last possible update, and
will save few kilobytes of duplicated data at your site. We intend to keep
the website alive for at least next 50 years... :)

VV46NER

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\10\11@035431 by Vasile Surducan

flavicon
face
On Fri, 11 Oct 2002, Russell McMahon wrote:

>
> A ceramic resonator has ample accuracy to guarantee the required accuracy if
> used at both ends.

 I'll retranslate a little this phrase:

 A ceramic resonator *might* have the accuracy to guarantee if used at
both ends. Is much better if slow rate are used.
 In my practice 4% is the maximum error allowed, even better Olin's 3%.

best, Vasile

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\10\11@041508 by David Duffy

flavicon
face
>Russell McMahon wrote:
> > A ceramic resonator has ample accuracy to guarantee the required
> accuracy if
> > used at both ends.

Vasile:
>   I'll retranslate a little this phrase:
>
>   A ceramic resonator *might* have the accuracy to guarantee if used at
>both ends. Is much better if slow rate are used.

As has been said many times before, the accuracy is NOT dependent
on the baud rate. Its a percentage thing. I use ceramic resonators all
the time, from 4MHz & 1200 baud to 20MHz & 115200 baud without
any problems. Sometimes from PC<->PIC and sometimes PIC<->PIC.
I all comes down to the starting error percentage & variations caused
by temperature. Most of my equipment operates in the 10-60 degrees
(Celcius) range so my results may be better than some. :-)
David...

___________________________________________
David Duffy        Audio Visual Devices P/L
U8, 9-11 Trade St, Cleveland 4163 Australia
Ph: +61 7 38210362   Fax: +61 7 38210281
New Web: http://www.audiovisualdevices.com.au
___________________________________________

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\10\11@043018 by Vasile Surducan

flavicon
face
On Fri, 11 Oct 2002, David Duffy wrote:

> >Russell McMahon wrote:
> > > A ceramic resonator has ample accuracy to guarantee the required
> > accuracy if
> > > used at both ends.
>
> Vasile:
> >   I'll retranslate a little this phrase:
> >
> >   A ceramic resonator *might* have the accuracy to guarantee if used at
> >both ends. Is much better if slow rate are used.
>
> As has been said many times before, the accuracy is NOT dependent
> on the baud rate. Its a percentage thing.

 Ok, maybe I misunderstand the translation of "accuracy" which according
to my Webster's is:
 -- the condition or quality of being true,
    correct, or exact; precision; exactness.
I had yesterday a problem with choosing an "accurate" ceramic resonators
and I can assure you, in my PIC-PC connection, a slow rate may work with a
"wrong value" resonator and a high rate not, using the same basic code
which is working perfectly with a Xtal.
Everything depends if the samples are or not taken at the middle of the
receptioned bit value. And I'm not talking about using USART but
bit-banged.


I use ceramic resonators all
{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\10\11@055124 by Wouter van Ooijen

face picon face
> http://www.ustr.net/8051pc/starting.shtml

Nice explanation. IIRC my ASR33 teletype ran at 110 baud, but maybe 120
baud models did exist.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\10\11@060410 by David Duffy

flavicon
face
> > >Russell McMahon wrote:
> > > > A ceramic resonator has ample accuracy to guarantee the required
> > > > accuracy if  used at both ends.
>
> > Vasile:
> > >   I'll retranslate a little this phrase:
> > >
> > >   A ceramic resonator *might* have the accuracy to guarantee if used at
> > >both ends. Is much better if slow rate are used.

David:
> > As has been said many times before, the accuracy is NOT dependent
> > on the baud rate. Its a percentage thing.

Vasile:
{Quote hidden}

I assume by "wrong value" resonator you mean not exactly on-frequency?
But at the slower baud rate & the correspondingly longer bit period, the PIC
will still sample in the same position within that bit won't it?  Sure, the
bits
are longer at lower baud rates, but the clock error is multiplied time-wise &
makes it the same timing error percentage-wise anyway. To put it another
way, the error amount (time) is more with a lower baud rate but the bits are
also longer making it the same percentage of the bit time. Where it comes
into play however is when you don't have enough clock cycle resolution to
generate exact delays when doing bit-bang comms. When using the UART
this makes that much less of a problem. It's important to carefully calculate
the loop delays when bit-banging to get it as close as you can so that you
don't contribute to the overall error percentage. Does this make sense? :-)
I'm not trying to criticise, just clear up the confusion.
David...
___________________________________________
David Duffy Audio Visual Devices P/L
U8, 9-11 Trade St, Cleveland 4163 Australia
Ph: +61 7 38210362 Fax: +61 7 38210281
New Web: http://www.audiovisualdevices.com.au
___________________________________________

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\10\11@072544 by Olin Lathrop

face picon face
>   A ceramic resonator *might* have the accuracy to guarantee if used at
> both ends. Is much better if slow rate are used.

The relative accuracy required is independent of the baud rate, so unless
low frequency ceramic resonators are inherently more accurate (I don't thing
so) this statement is incorrect.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\10\11@072807 by Olin Lathrop

face picon face
> Nice explanation. IIRC my ASR33 teletype ran at 110 baud, but maybe 120
> baud models did exist.

All the ASR33 and ASR35 I ever saw ran at 110 baud.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\10\11@081046 by mike

flavicon
face
At low rates,  the baudrate is a lower proportion of the clock rate,
so sampling jitter (+/- 1 clock, or variable int latency for soft
uarts) is less of an issue, allowing marginally more leeway on
frequency. However this is only likely to be a significant issue at
the very highest of practical baudrates

On Fri, 11 Oct 2002 07:24:08 -0400, you wrote:

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\10\11@090552 by Russell McMahon

face
flavicon
face
> > > >Russell McMahon wrote:
> > > > > A ceramic resonator has ample accuracy to guarantee the required
> > > > > accuracy if  used at both ends.

> > > >   A ceramic resonator *might* have the accuracy to guarantee if used
at
> > > >both ends. Is much better if slow rate are used.

SUMMARY:        Ceramic resonators from reputable manufacturers are very
easily able to meet the timing requirements typical of asynchronous
communications.

DETAIL:                As I showed previously, the required timing accuracy
for a typical single byte in asynchronous communications is slightly over
5%. This is the sum of the errors allowed at both ends. If each end has a
worst case timing error below +/- 2.5% the link will work. This applies to a
single byte sent at ANY communications speed, be it 110 baud or 38400 or
higher. As the link is resynchronised on a character by character basis a
+/- 2.5% accuracy is adequate although higher accuracy is not at all
harmful.

Typical lifetime accuracies of ceramic resonators from reputable
manufacturers are in the order of 1% worst case including initial,
temperature and lifetime drift errors. This is assuming that the worst case
occurs in the same direction for each error source. Even then such a
resonator would be about 2.5 times more stable than necessary for proper
asynchronous connection timing.

Conceivably one may be able to obtain suitably inferior no-name resonators
that do not meet the requisite +/- 2.5% requirements.


               Russell McMahon

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\10\11@134438 by Peter L. Peres

picon face
On Fri, 11 Oct 2002, Vasile Surducan wrote:

*>On Fri, 11 Oct 2002, Russell McMahon wrote:
*>
*>>
*>> A ceramic resonator has ample accuracy to guarantee the required accuracy if
*>> used at both ends.
*>
*>  I'll retranslate a little this phrase:
*>
*>  A ceramic resonator *might* have the accuracy to guarantee if used at
*>both ends. Is much better if slow rate are used.
*>  In my practice 4% is the maximum error allowed, even better Olin's 3%.

A ceramic resonator is usually under 1% and is sufficient. The total
tolerance allowed is 5.xx% so for both endss to be safe each should be
better than this (<2.5% each).

OTOH, it is possible to implement serial t/r with RC clock on PICs if the
temperature range is limited because they are at better than 2% for
constant voltage and temperature.

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\10\12@004236 by Wagner Lipnharski

flavicon
face
Peter L. Peres wrote:
> A ceramic resonator is usually under 1% and is sufficient. The total
> tolerance allowed is 5.xx% so for both endss to be safe each should be
> better than this (<2.5% each).
>
> OTOH, it is possible to implement serial t/r with RC clock on PICs if
> the temperature range is limited because they are at better than 2%
> for constant voltage and temperature.
>
> Peter


Ok, ok, what about to use your own bitbang protocol, the stuppid bitwise
transmission.
Start bit, bit, stop bit - you reduce your ressonator accuracy required
from 5 to almost 20%...
Ok, I know, you reduced throughput ratio from 8/11 to 1/3.

Perhaps, this is why somebody invented synchronous communication,
manchester coding, etc, ahh? well, still Serial, right?

;)

VV46NER

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


2002\10\12@040514 by Peter L. Peres

picon face
On Sat, 12 Oct 2002, Wagner Lipnharski wrote:

*>Peter L. Peres wrote:
*>> A ceramic resonator is usually under 1% and is sufficient. The total
*>> tolerance allowed is 5.xx% so for both endss to be safe each should be
*>> better than this (<2.5% each).
*>>
*>> OTOH, it is possible to implement serial t/r with RC clock on PICs if
*>> the temperature range is limited because they are at better than 2%
*>> for constant voltage and temperature.
*>>
*>> Peter
*>
*>
*>Ok, ok, what about to use your own bitbang protocol, the stuppid bitwise
*>transmission.
*>Start bit, bit, stop bit - you reduce your ressonator accuracy required
*>from 5 to almost 20%...
*>Ok, I know, you reduced throughput ratio from 8/11 to 1/3.
*>
*>Perhaps, this is why somebody invented synchronous communication,
*>manchester coding, etc, ahh? well, still Serial, right?

Actually many infrared protocols could work without a crystal since they
do 2:1 or so modulation in PWM or PPM and this can be considered to be
self synchronising. I wrote code for decoding several commercial IR
protocols using 12C508 internal RC and this property of the codes. No
problems. I also made transmitters like this and they work well with
commercial receivers at room temperature (15-45C). Some protocols are more
robust than others.

Peter

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


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