Searching \ for '[PIC] Using RC Clock for "simple" parallel-serial' 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/microchip/ios.htm?key=serial
Search entire site for: 'Using RC Clock for "simple" parallel-serial'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Using RC Clock for "simple" parallel-serial '
2010\07\27@102828 by jimf

flavicon
face



         BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }
Just a quick one guys,

       I am making a parallel to serial converter
(a pic, a max232 and discretes),
I intend to output the data on the serial at about 9600/19200,
would you think an RC clock or internal clcok would be accurate
enough for this simple task?
-Jim
On Tue 27/07/10 9:29 AM , Tamas Rudnai spam_OUTtamas.rudnaiTakeThisOuTspamgmail.com sent:
 On Thu, Jul 22, 2010 at 8:43 PM, Isaac Marino Bavaresco <
.....isaacbavarescoKILLspamspam@spam@yahoo.com.br [1]> wrote:
> No, automatic variables are not cleared upon function entry, they
may
> contain garbage.
>
That's why you need to initialize all variables you have. Not sure
about C18
but some compilers throws warnings at compilation time about using
uninitialized variables. As a practise I found it easier to write
"int myVar
= 0;" as opposed to "int myVar;" so the initialization will not be
forgotten
-- however, sometimes it is only a way to suppress those warnings...
Tamas
Global variables are cleared to zero at program start, but some
> tool-chains support a switch
> to disable this feature.
>
> __________________________________________________
> Fale com seus amigos de graça com o novo Yahoo! Messenger
> http://br.messenger.yahoo.com/ [2]
>
> --
> http://www.piclist.com [3] PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist [4]
>
--
int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
q=""",s,q,q,a="\",q,q,q,a,a,q); }
--
http://www.piclist.com [5] PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist [6]


Links:
------
[1] isaacbavarescospamKILLspamyahoo.com.br
[2]
webmail.webstudios.co.uk/parse.php?redirect=http%3A%2F%2Fbr.messenger.yahoo.com%2F
[3]
http://webmail.webstudios.co.uk/parse.php?redirect=http%3A%2F%2Fhttp://www.piclist.com
[4]
webmail.webstudios.co.uk/parse.php?redirect=http%3A%2F%2Fmailman.mit.edu%2Fmailman%2Flistinfo%2Fpiclist
[5] http://www.piclist.com
[6] http://mailman.mit.edu/mailman/listinfo/piclist

2010\07\27@104913 by Harold Hallikainen

face
flavicon
face

>        I am making a parallel to serial converter
>  (a pic, a max232 and discretes),
>  I intend to output the data on the serial at about 9600/19200,
> would you think an RC clock or internal clcok would be accurate
> enough for this simple task?
>  -Jim


Yes, I've found the internal RC to be fine for uart communications. There
may be a problem under temperature extremes, but I have not experienced
it.

Harold



-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2010\07\27@110539 by Olin Lathrop

face picon face

.....jimfKILLspamspam.....webstudios.co.uk wrote:
>   BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }
> Just a quick one guys,
>
> I am making a parallel to serial converter
>  (a pic, a max232 and discretes),
>  I intend to output the data on the serial at about 9600/19200,
> would you think an RC clock or internal clcok would be accurate
> enough for this simple task?

Some newer PICs have internal clock accurate enough to get away with it in
some cases when you know the other end is right on.  Otherwise, this is not
a good idea.  The early PIC internal RC oscillators are too inaccurate for
this.

Look up the accuracy of the internal oscillator in the datasheet for the
operating range you will be using.

{Quote hidden}

webmail.webstudios.co.uk/parse.php?redirect=http%3A%2F%2Fbr.messenger.yahoo.com%2F
> [3]
>
http://webmail.webstudios.co.uk/parse.php?redirect=http%3A%2F%2Fhttp://www.piclist.com
> [4]
>
webmail.webstudios.co.uk/parse.php?redirect=http%3A%2F%2Fmailman.mit.edu%2Fmailman%2Flistinfo%2Fpiclist
> [5] http://www.piclist.com
> [6] http://mailman.mit.edu/mailman/listinfo/piclist

Please trim all the crap that has nothing to do with your post, especially
since you seem to be starting a new thread and the previous message is
therefore particularly irrelevant.

You also might want to look into your mail settings as it looks like you may
have sent this as HTML or something.  As always, if you want the most people
to see the message the most clearly, stick to plain text wrapped to no more
than 80 colums.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2010\07\27@182623 by RussellMc

face picon face
> >  I intend to output the data on the serial at about 9600/19200,
> > would you think an RC clock or internal clcok would be accurate
> > enough for this simple task?

> Some newer PICs have internal clock accurate enough to get away with it in
> some cases when you know the other end is right on.  Otherwise, this is not
> a good idea.  The early PIC internal RC oscillators are too inaccurate for
> this.
>
> Look up the accuracy of the internal oscillator in the datasheet for the
> operating range you will be using.

Guide.

As Olin says, older PICs were generally not stable enough and as he
and Harold say, newer ones often are. Appreciating what the
requirement is and how to tell from the spec sheet is useful.

Worst case your timing is allowed to be out by half a bit time if it
is synchronised in the middle of the start bit at the start of
transmission.
Close enough, to avoid missampling  you are allowed a drift of 1/2 bit
in (1/2 start + N data bits + stop bit) = 1/2 /(9.5) for 8 bits + 1
start + 1 stop ~= 5%
You can argue over whether you can save 1/2 a bit if the drift is
towards missampling the stop bit late etc but that's close enough.
Given that worst case the transmit clock can drift one way and the
receive clock the other, the worst case where you can guarantee
accuracy is 5%/2 = +/- 2.5%

You can decide from the spec sheet how much error you can expect.
Drift across full temperature range will usually be greater than
across limited temperature range and if both your devices are in the
same thermal environment then the relative drift will probably be
less.

With older parts and restricted environments eg office temperature
range and both devices in same thermal environment., asynchronous coms
would probably work with RC clocks.

Grabbing a random data sheet - 16F877, dated 2008 they specify

+/-1% AT 25C, 3.5 V Vdd
+/- 2% 0-85C and 2.5 - 5.5 Volt Vdd (almost all applications)
+/- 5% -25 to +125C and 2 - 5.5 V Vdd. (overnight in snow to auto
firewall mounting)

ie it will work OK for 1st and 2nd ranges and will very probably fail
at the extremes of the 3rd range unless devices are tortured
similarly.



              Russell

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