Searching \ for '[PIC]: 18F 8MHz internal oscillators' 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/time.htm?key=oscillator
Search entire site for: '18F 8MHz internal oscillators'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 18F 8MHz internal oscillators'
2005\02\02@124338 by alan smith

picon face
It used to be simple, back in the olden days...you put
a RC network, xtal or oscillator and presto your clock
was done.

Now, with many of the new 18F series (and alot of
ASICs like Nvidea chips) have built in clock
generators.

So, thinking of using the built in 8MHz clock and I
will be using the UART and SPI so the timing is a
little more constrained than if I didnt have to talk
to anything else.  
Just looking for comments on those that have used the
built in, any issues with them? Stabilty been ok?


               
__________________________________ Do you Yahoo!? All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.co

2005\02\02@132945 by Mark Rages

face picon face
I used the built-in oscillator in a 16F688.  I don't know if I did
something wrong, but I had to set the baud rate divisor to a slightly
lower value than calculated from the datasheet to get reliable
communications with my computer.   I set it by tweaking the divisor up
and down while monitoring communications.  Too fast or too slow gave
garbled communications.  I chose a point midway between those,
figuring that gave me the most room for drift.

We've made a few dozen copies of the circuit, and have had no trouble
with communications using that divisor value.

Also, the circuit is watching the sync signal from a stable video
source.  I haven't observed drifting against the video signal.

No experience regarding thermal stability as the circuits always run
at about 25C.

Regards,
Mark
markrages@gmail


On Wed, 2 Feb 2005 09:43:35 -0800 (PST), alan smith
<spam_OUTmicro_eng2TakeThisOuTspamyahoo.com> wrote:
{Quote hidden}

>

2005\02\02@141156 by Shawn Tan Ser Ngiap

flavicon
face
On Wednesday 02 February 2005 17:43, alan smith wrote:
> So, thinking of using the built in 8MHz clock and I
> will be using the UART and SPI so the timing is a
> little more constrained than if I didnt have to talk
> to anything else.

Used internal oscillator on the '628... Never tried the 18Fs yet... You should
be okay for SPI as the maximum you'll get at 8MHz is 2Mbps... As long as your
devices can handle this, it should be okay... as an example, flash cards are
typically rated at 20Mbps...

As for the UART, you'll need to be a little careful with the baudrates... try
to choose one where the error is <3%... That's the typical acceptable
difference.. With short bursts, you will be okay... Things might get out of
sync on sustained comms though...

Besides that, if you do not have any timing critical applications, you should
be okay.. The internal oscillators are supposed to drift depending on
temperature and supply voltage... So, just keep those clean as well.. It's
always good practice to keep a clean supply...

I think that internal oscillators are a neat solution.. Also, you can
configure the CLKOUT pin to generate a Fosc/4 pulse.. But I'm not sure if its
good enough to drive the clock of another device though...

cheers..

--
with metta,
Shawn Tan

2005\02\02@144813 by Wouter van Ooijen

face picon face
> As for the UART, you'll need to be a little careful with the
> baudrates... try
> to choose one where the error is <3%... That's the typical acceptable
> difference..

I dunno how you meant this, but in my opinion 3% is the maximum error I
would accept in the whole chain: sender, electronics, receiver. The
error in the internal oscillator *and* the error listed for the baudrate
divisor add up to the error at the sender, which I would not allocate
more than 1%.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\02@152915 by Jan-Erik Soderholm

face picon face
Shawn Tan Ser Ngiap wrote :

> Used internal oscillator on the '628... Never tried the 18Fs
> yet...

They are quite different. Since Alan talked about "8Mhz", I guess that
he ment the newer INTOSC's, not the older ones. I won't go
into all details here, check the data sheets. The newer
INTOSC's are used in both 16 and 18 PICs, such as 16F88
and 18F1220 (just to name a few) and all new PIC's (well not
the 10F's :-) ) seems to have these newer INTOSC's.

Jan-Erik.



2005\02\02@172925 by Shawn Tan Ser Ngiap

flavicon
face
On Wednesday 02 February 2005 19:48, Wouter van Ooijen wrote:
> > As for the UART, you'll need to be a little careful with the
> > baudrates... try
> > to choose one where the error is <3%... That's the typical acceptable
> > difference..
>
> I dunno how you meant this, but in my opinion 3% is the maximum error I
> would accept in the whole chain: sender, electronics, receiver. The
> error in the internal oscillator *and* the error listed for the baudrate
> divisor add up to the error at the sender, which I would not allocate
> more than 1%.

Well... if you're just interested in transmitting a few bytes of data a few
times a second (short bursts), you don't have to care about the error as
much... for such applications, i've usually used <3% as sort of a
rule-of-thumb.. works okay so far.. but for sustained comms, as i've
indicated, 3% would cause sync problems...

Receivers are made with in built tolerances as well... they'll typically
sample at several times the baud rate.. sampling at 4 times oversample and if
3 of the samples are at the same level on the 4th sample, that level gets
registered... So, this helps at the other end...

But you stressed the point that i left out.. you've got to factor in the
frequency drift as well... i thought this was implicitly understood... my
bad...

cheers..

--
with metta,
Shawn Tan

2005\02\02@173043 by Antonis Iliopoulos

flavicon
face
I am using the 16f627A with an internal 4MHz and I had no problem - I was not running a heavy

duty code though.  At the moment I am using the 16f7x7 that have 8 programmable internals

from 8MHz downwards and a + - 12.5% tuner.  

Jan-Erik Soderholm <.....jan-erik.soderholmKILLspamspam@spam@telia.com> wrote:
Shawn Tan Ser Ngiap wrote :

> Used internal oscillator on the '628... Never tried the 18Fs
> yet...

They are quite different. Since Alan talked about "8Mhz", I guess that
he ment the newer INTOSC's, not the older ones. I won't go
into all details here, check the data sheets. The newer
INTOSC's are used in both 16 and 18 PICs, such as 16F88
and 18F1220 (just to name a few) and all new PIC's (well not
the 10F's :-) ) seems to have these newer INTOSC's.

Jan-Erik.



2005\02\02@174525 by olin_piclist

face picon face
Shawn Tan Ser Ngiap wrote:
> Well... if you're just interested in transmitting a few bytes of data
> a few times a second (short bursts), you don't have to care about the
> error as much...

Huh?  Each byte is an independent event because the receiver timing
synchronizes to the leading edge of the start bit, and each byte has its own
start bit.  Errors don't accumulate over long sequences of bytes.


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

2005\02\02@184731 by Shawn Tan Ser Ngiap

flavicon
face
On Wednesday 02 February 2005 22:45, Olin Lathrop wrote:
> Shawn Tan Ser Ngiap wrote:
> > Well... if you're just interested in transmitting a few bytes of data
> > a few times a second (short bursts), you don't have to care about the
> > error as much...
>
> Huh?  Each byte is an independent event because the receiver timing
> synchronizes to the leading edge of the start bit, and each byte has its
> own start bit.  Errors don't accumulate over long sequences of bytes.

This depends on how the receivers are implemented... they should be edge
triggered and respond to the start bit, but some have a fixed sampling point
synchronized to a clock.. so, more synchronous than asynchronous... So, it's
still possible to get errors... This might not be the normal case but such
things do exist... it depends on how the receivers were constructed...

cheers...

--
with metta,
Shawn Tan

2005\02\02@191203 by olin_piclist

face picon face
Shawn Tan Ser Ngiap wrote:
> This depends on how the receivers are implemented... they should be
> edge triggered and respond to the start bit, but some have a fixed
> sampling point synchronized to a clock..

Actually all current implementations I know of do.  The vast majority of
UARTS sample the input signal at 16x the baud rate.  This introduces an
uncertainty of 1/16 bit time in the sampled stream compared to the sent
stream, but that still doesn't make errors accumulate between bytes.  The
leading edge of the start bit is sampled each byte, and all timing for that
byte is relative to it.  The accumulated error by the end of the previous
byte is irrelevant unless it is so large that the new start bit is missed,
but that is only true if the baud rate mismatch is well into the guaranteed
unreliable region.


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

2005\02\02@204625 by michael brown

picon face
Shawn Tan Ser Ngiap wrote:
> On Wednesday 02 February 2005 22:45, Olin Lathrop wrote:
>> Shawn Tan Ser Ngiap wrote:
>>> Well... if you're just interested in transmitting a few bytes of
>>> data a few times a second (short bursts), you don't have to care
>>> about the error as much...
>>
>> Huh?  Each byte is an independent event because the receiver timing
>> synchronizes to the leading edge of the start bit, and each byte has
>> its own start bit.  Errors don't accumulate over long sequences of
>> bytes.
>
> This depends on how the receivers are implemented... they should be
> edge triggered and respond to the start bit, but some have a fixed
> sampling point synchronized to a clock.. so, more synchronous than
> asynchronous... So, it's still possible to get errors... This might
> not be the normal case but such things do exist... it depends on how
> the receivers were constructed...
>
> cheers...

I don't see how this could be true.  Asynch means asynch, AFAIK there is
nothing specifying the maximum time between bytes.  Certainly not
anything specifying a fixed interval between bytes.  You have to use the
start bit to determine when to sample the bits in the following byte.
You would have to start over (resynch) on each and every new start bit.

2005\02\03@031652 by Wouter van Ooijen

face picon face
> This depends on how the receivers are implemented... they
> should be edge
> triggered and respond to the start bit, but some have a fixed
> sampling point
> synchronized to a clock..

That sounds like synchronous transmission with a separate clock. Can you
point me to one UART that works that way?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\03@094256 by Bob Ammerman

picon face

----- Original Message -----
From: "Wouter van Ooijen" <wouterspamKILLspamvoti.nl>
To: "'Microcontroller discussion list - Public.'" <.....piclistKILLspamspam.....mit.edu>
Sent: Thursday, February 03, 2005 3:16 AM
Subject: RE: [PIC]: 18F 8MHz internal oscillators


{Quote hidden}

The one in each of the 16F628's in all the Wisp 628's you've sold! :-)

Nearly all hardware UARTs work the same way. They sample at 16x the baud
rate and run a state machine to collect the data.


Bob Ammerman
RAm Systems


2005\02\03@100920 by Wouter van Ooijen

face picon face
> >> This depends on how the receivers are implemented... they
> >> should be edge
> >> triggered and respond to the start bit, but some have a fixed
> >> sampling point
> >> synchronized to a clock..
> >
> > That sounds like synchronous transmission with a separate
> clock. Can you
> > point me to one UART that works that way?
> >
> > Wouter van Ooijen
>
> The one in each of the 16F628's in all the Wisp 628's you've sold! :-)
>
> Nearly all hardware UARTs work the same way. They sample at
> 16x the baud
> rate and run a state machine to collect the data.

That's correct, but in the idle state the state machinme of the UARTs in
PICs continuously (ok, at 64x or 16x the baudrate) samples for the start
of the start bit. The OP was talking about a UART that assumed the start
bit at a fixed position relative to the previous character.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\03@102534 by Bob Ammerman

picon face

> That's correct, but in the idle state the state machinme of the UARTs in
> PICs continuously (ok, at 64x or 16x the baudrate) samples for the start
> of the start bit. The OP was talking about a UART that assumed the start
> bit at a fixed position relative to the previous character.
>
> Wouter van Ooijen

Hmmm.....


That is not how I read it.

Bob Ammerman
RAm Systems



2005\02\03@113246 by Wouter van Ooijen

face picon face
> That is not how I read it.

it == how a UART works?
it == OP?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\03@115856 by Shawn Tan Ser Ngiap

flavicon
face
> > of the start bit. The OP was talking about a UART that assumed the start
> > bit at a fixed position relative to the previous character.
> >
> > Wouter van Ooijen
>
> Hmmm.....
>
> That is not how I read it.

I might be making a big mistake taking a dip into this again, but here goes...
I just read the data sheet for the plug-in IP from two major EDA companies...
This is what I gathered from reading it.. But since I do not have the IP in
hand, I cannot verify it.. If someone has it, maybe they can verify it..

The sampling point baud signals (call it baud_clk) are divided from a main
clock... This results in a regular signal... Let's imagine a train of thin
square impulses...

What happens is this.. When a start-bit is detected, it will start the FSM
(which i assume was in an IDLE state before this), and start shifting the
bits into the receiver register.. But the baud_clk train remains constant,
before and after the byte is moved in...

To me, that indicates a fixed sampling period.. whether they use a single
point or multiple voting points, the period is still fixed.. makes sense from
the designer's point of view... easy to implement, works as long as users
stick to the standard baud rates, within a certain error margin..

cheers..

with metta,
shawn tan.





2005\02\03@120153 by Bob Ammerman

picon face
it == OP

----- Original Message -----
From: "Wouter van Ooijen" <EraseMEwouterspam_OUTspamTakeThisOuTvoti.nl>
To: "'Microcontroller discussion list - Public.'" <piclistspamspam_OUTmit.edu>
Sent: Thursday, February 03, 2005 11:32 AM
Subject: RE: [PIC]: 18F 8MHz internal oscillators


{Quote hidden}

> --

2005\02\03@122600 by Bob Axtell

face picon face
No, not quite right, Shawn. You are mixing up sample clock with the
start of an individual
serial frame.  But once you get this, you'll realize that asynch really
does mean asynch

The serial transmitter sends the first edge of a serial frame, which
consists (usually) of a
START bit , 8 data bits, and a STOP bit. As soon as the START bit
begins, from that point
on through the  frame until the end of the STOP bit, timing is precise.
The receiver UART
locks on at the beginning of the START bit and subjects the remaining
bits to a rigid timing
test until the end of the  STOP bit, then the UART is released from its
rigid timing. The 8
data bits are extracted to do whatever needs to be done.

Now, the UART is released, looking for the leading edge of a START bit
again. That leading edge
could begin as soon as the STOP bit ends, or it could begin a second
later, a day later, or a fortnight
later. That's what is meant by asynch communication. Now it can be
readily seen that if the
transmit bit width is slightly different to that expected by the
receiver, the data can still be transferred
reliably, as long as a tiny delay is inserted between serial bytes
(frames). That's all you need to do.

My tests indicate that is a small delay is inserted between serial bytes
going out, an error of as much
as 4% (+/- 4%) will usually still work.

Make sense now?

--Bob

Shawn Tan Ser Ngiap wrote:

{Quote hidden}

--
Note: To protect our network,
attachments must be sent to
@spam@attachKILLspamspamengineer.cotse.net .
1-866-263-5745 USA/Canada
http://beam.to/azengineer

2005\02\03@125528 by Shawn Tan Ser Ngiap

flavicon
face
On Thursday 03 February 2005 17:25, Bob Axtell wrote:
> No, not quite right, Shawn. You are mixing up sample clock with the
> start of an individual
> serial frame.  But once you get this, you'll realize that asynch really
> does mean asynch

I know what you mean... but I don't think that I'm mixing it up... cause I've
just read another one... from another EDA company..

This one says that their baud sample clock, is derived by continuously
sampling the input signal... and mentions that the baud sample clock is
adjusted to be in the middle of the bit.. And this one deliberately draws the
baud sample clock with relation to the falling edge of the start bit.. the
other one doesn't.. So, to me, this means that they will change their baud
sample clock depending on when the start bit happens...

What i'm trying to say here is that not all UART are built the same... and not
all are really asynchronous... some are pseudo-asynchronous...

BTW.. the sample clock that i've mentioned for all these examples is not the
sampling clock... the sampling clocks are usually several times faster than
the baud rate to sample each bit many times.. that's why i used the word baud
sampling clock to imply that it only occurs once in a bit... the shift
registers are shown to change content a little while after the baud sample
clock pulses..

> My tests indicate that is a small delay is inserted between serial bytes
> going out, an error of as much
> as 4% (+/- 4%) will usually still work.

My rule of thumb is 3%...

cheers...

--
with metta,
Shawn Tan

2005\02\03@131848 by William Chops Westfield

face picon face

On Feb 3, 2005, at 9:25 AM, Bob Axtell wrote:

> from [start bit] on through the  frame until the end of the STOP bit,
> timing is precise. The receiver UART locks on at the beginning of the
> START bit and subjects the remaining bits to a rigid timing test until
> the end of the  STOP bit, then the UART is released from its rigid
> timing.

Presumably the "problem" is with software uarts that check the full stop
bit, and don't have time to "unsynchronize" before the next start-bit
starts.

BillW

2005\02\03@132542 by Wouter van Ooijen

face picon face
> What happens is this.. When a start-bit is detected, it will
> start the FSM
> (which i assume was in an IDLE state before this), and start
> shifting the
> bits into the receiver register.. But the baud_clk train
> remains constant,
> before and after the byte is moved in...
>
> To me, that indicates a fixed sampling period.. whether they
> use a single
> point or multiple voting points, the period is still fixed..
> makes sense from
> the designer's point of view... easy to implement, works as
> long as users
> stick to the standard baud rates, within a certain error margin..

I think you are a bit (baud?) confused. The FSM runs at a mutiple of the
baudrate, often 16 (sometimes 3, IIRC sometimes 64). So there is an
error (up to 1/16 of the bit cell) in where the FSM thinks the start of
the start bit and hence the centre of each bit cell is. This remains
constant for the entire character, and eats from the error budget. But
at the (first edge of the) start bit of the next character this error is
effectively reset, so it does not accumulate over characters. So this
error has nothing to do with how fast characters are send (in the sense
of line utilisation). (And neither does it depend on the baudrate.)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\03@132543 by Wouter van Ooijen
face picon face
> it == OP

OK, in that case we agree on how a real UART works :)

Which of us was right as to what the OP meant to say is much less
interesting.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\03@132808 by Wouter van Ooijen

face picon face
> This one says ....

I would not trust the wording used by the manufacturer/supplier/designer
too much (bitte nicht hineininterpretieren). Check the specs and/or the
code.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\03@133714 by Shawn Tan Ser Ngiap

flavicon
face
On Thursday 03 February 2005 18:25, Wouter van Ooijen wrote:
> > To me, that indicates a fixed sampling period.. whether they
> > use a single
>
> I think you are a bit (baud?) confused. The FSM runs at a mutiple of the
> baudrate, often 16 (sometimes 3, IIRC sometimes 64). So there is an

Maybe I am a bit confused... But just in case, maybe someone can read the docs
from Cadence and Synopsys.. to see what the words say and interpret the
timing diagrams for me... vs what I understood from the docs...

cheers..

--
with metta,
Shawn Tan

2005\02\03@133907 by Shawn Tan Ser Ngiap

flavicon
face
On Thursday 03 February 2005 18:28, Wouter van Ooijen wrote:
> I would not trust the wording used by the manufacturer/supplier/designer
> too much (bitte nicht hineininterpretieren). Check the specs and/or the
> code.

Yes... if I can get the RTL codes, i could verify them exactly.. but I don't
so, i just interpret what the timing diagrams and words seem to say on the
data sheet...

cheers..

--
with metta,
Shawn Tan

2005\02\03@135039 by Bob Axtell

face picon face
here is how my software UARTS work, assuming 10-bit frame:

I trigger on the falling edge of the INT pin, so I get an interrupt.
This is serviced immediately  upon entry into the interrupt routine
so that the software delays before the service routine are known.
At that point, I set the bit count for 10 bits, start TIMER1, preset
the value of TIMER1 to a spot that will cause the first trigger to occur
right in the middle of the start BIT, then I turn OFF the INT pin (I only
use it to locate the beginning of the serial frame).

Every time Timer1 interrupts, I immediately capture the data  bit state,
which occurs approx in the dead-center of the  bit. I count down the
bit counter, and when all 10 bits have been captured, I make sure the
FIRST bit is LOW and the LAST bit is high, then extract the 8 bits in
between. I immediately turn off  TIMER1, turn on INT pin.

Because there is a gap from the middle of the stop bit until the next
start bit begins, a small amount of timing error can be easily handled if
a small EXTRA delay is issued. If it is NOT added, I might miss the start
of the next serial frame.

--Bob

William Chops Westfield wrote:

{Quote hidden}

--
Note: To protect our network,
attachments must be sent to
KILLspamattachKILLspamspamengineer.cotse.net .
1-866-263-5745 USA/Canada
http://beam.to/azengineer

2005\02\03@153753 by Bob Ammerman

picon face
> Presumably the "problem" is with software uarts that check the full stop
> bit, and don't have time to "unsynchronize" before the next start-bit
> starts.

>From my experience most UARTs appear to start looking for a new start bit
about 1/2 way through the stop bit time.

Also, if you can set up to transmit two stop bits then you give the receiver
more time to be ready for the start bit of each byte.

Bob Ammerman
RAm Systems


2005\02\03@170511 by olin_piclist

face picon face
Wouter van Ooijen wrote:
> (bitte nicht hineininterpretieren)

Isn't that German, or is this one of those areas where Dutch and German are
the same?


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

2005\02\04@014447 by William Chops Westfield

face picon face

On Feb 3, 2005, at 12:35 PM, Bob Ammerman wrote:
>
>>> Presumably the "problem" is with software uarts that check the full
>>> stop
>>> bit, and don't have time to "unsynchronize" before the next
>>> start-bit starts.
>>
>> From my experience most UARTs appear to start looking for a new start
>> bit
>> about 1/2 way through the stop bit time.
>
> Also, if you can set up to transmit two stop bits then you give the
> receiver more time to be ready for the start bit of each byte.
>
Isn't that where this digression into uart internal operations started?
Someone opined that pauses between characters would help receivers sync
up, and everyone jumped on it as not being needed if the uarts worked
right.  Well, I agree, in principle, but here we are again at "extra
time between characters might help", and I have to agree with that TOO.

I have been contemplating, off and on since I got that good deal on
eBay,
SW uarts on PICs running off a 32kHz crystal, and how fast they might or
might not be coerced into operating.  Two nop's gets you to just before
the middle of the first bit, three nop's to just after the middle of the
second bit...  Not a lot of time to do everything perfect, and extra
time
between characters would probably help A LOT...

BillW

2005\02\04@030018 by Wouter van Ooijen

face picon face
> Isn't that where this digression into uart internal
> operations started?
> Someone opined that pauses between characters would help
> receivers sync
> up, and everyone jumped on it as not being needed if the uarts worked
> right.  Well, I agree, in principle, but here we are again at "extra
> time between characters might help", and I have to agree with
> that TOO.

I don't agree to that, in the sense that IMHO a UART who benefits from
that extra space is badly written. Right after sampling the value of the
stop bit the state machine can start sampling for the start bit.

> Two nop's gets you to just before
> the middle of the first bit, three nop's to just after the
> middle of the second bit...  Not a lot of time to do
> everything perfect, and extra time
> between characters would probably help A LOT...

Why not ignore the stop bit altogether?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\04@030019 by Wouter van Ooijen

face picon face
> Wouter van Ooijen wrote:
> > (bitte nicht hineininterpretieren)
>
> Isn't that German, or is this one of those areas where Dutch
> and German are the same?

It's definitely German. Each language has some words that are just too
lovely to ignore. I love 'hineininterpretieren', roughly 'interpreting
soemthing so deeply (beyond what is realy stated) that you end up a long
long way from the reasonable'.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\04@040359 by Alan B. Pearce

face picon face
>> Two nop's gets you to just before
>> the middle of the first bit, three nop's to just after the
>> middle of the second bit...  Not a lot of time to do
>> everything perfect, and extra time
>> between characters would probably help A LOT...

>Why not ignore the stop bit altogether?

and/or run at a slower baud rate, after all, if the clock frequency is so
low, the PIC isn't exactly going to be doing anything fast, so a fast baud
rate pushing the interface to the limit is not an advantage.

2005\02\04@080055 by olin_piclist

face picon face
Shawn Tan Ser Ngiap wrote:
> The sampling point baud signals (call it baud_clk) are divided from a
> main clock... This results in a regular signal... Let's imagine a train
> of thin square impulses...

The point you seem to be missing is that this clock you call BAUD_CLK is
running at a multiple (usually 16) of the baud rate.

> What happens is this.. When a start-bit is detected, it will start the
> FSM (which i assume was in an IDLE state before this), and start
> shifting the bits into the receiver register.. But the baud_clk train
> remains constant, before and after the byte is moved in...

Note that what you call "start the FSM" is exactly the synchronizing step
we've all be talking about.  This happens at the resolution of your BAUD_CLK
clock, not the actual baud rate.  If BAUD_CLK frequency is 16x the baud
rate, then the FSM is synched to the leading edge of the incoming byte to
within 1/16 bit.

> To me, that indicates a fixed sampling period.. whether they use a
> single point or multiple voting points, the period is still fixed..

The period is fixed with a byte, but the phase is re-adjusted each byte by
synchronizing it with the leading edge of the start bit.  That's what the
start bit is for.  That's why this is call "asynchronous".


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

2005\02\04@081529 by Dave Tweed

face
flavicon
face
"Wouter van Ooijen" <RemoveMEwouterTakeThisOuTspamvoti.nl> wrote:
> Why not ignore the stop bit altogether?

Because it's the only bit (other than the start bit) whose value you
know, which lets you verify that the bit you thought was the start bit
really was one. A missing stop bit is known as a "framing error".

But, after verifying the stop bit, at the center of the nominal bit
"cell", you should immediately be prepared for the leading edge of the
next start bit, because the transmitter may be running faster than you
are. A good asynchronous receiver (8N1) should be capabale of receiving
data that's being transmitted almost 5% faster than its own clock.

-- Dave Tweed

2005\02\04@084742 by olin_piclist

face picon face
Wouter van Ooijen wrote:
> Why not ignore the stop bit altogether?

You can, as long as you understand what you are giving up in return.

Normally the stop bit is used as a check and if it's value is not correct
then a "framing error" is generated.  This is a clue that the received byte
could be wrong.  Usually framing errors are the result of baud rate
mismatches.  Checking the stop bit is also how a break condition is
detected.


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

2005\02\04@085540 by olin_piclist

face picon face
Wouter van Ooijen wrote:
> It's definitely German. Each language has some words that are just too
> lovely to ignore. I love 'hineininterpretieren', roughly 'interpreting
> soemthing so deeply (beyond what is realy stated) that you end up a long
> long way from the reasonable'.

My favorite is Vierzilinderzerknalltreipling, although I've probably
misspelled it.  This was a Hitler-word when the more traditional name for
this item was considered politically incorrect (not German enough).  Can you
figure out the literal translation and what the normal English word for this
item is?

So do speak fluent German?  You obviously know English very well, and I
assume Dutch is your native language and what you speak normally?


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

2005\02\04@100656 by Wouter van Ooijen

face picon face
> > Why not ignore the stop bit altogether?
>
> Because it's the only bit (other than the start bit) whose value you
> know, which lets you verify that the bit you thought was the start bit
> really was one.

When CPU time is as scarce as the original post indicated ignoring (not
checking) the stop bit would still be my first choice. Reliability/error
detection can be added by other means (higher level protocol) or might
not be needed at all.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\04@100726 by Wouter van Ooijen

face picon face
> My favorite is Vierzilinderzerknalltreipling, although I've probably

> Can you
> figure out the literal translation and what the normal
> English word for this item is?

Vier zilinder zerknall treipling
Four cylinder explosion (driver? motor? power source?)

> So do speak fluent German?

By no means, as my various German teachers would confirm! In my country
it is normal to get at least 3 years English, French and German. In my
case only the English stuck, most probably because you can't do without
it in computer and electronics.

When I worked for an ESA project contacts between us Dutch and our
German sub-contractors were mostly in English, which put us on an
exqual-disadvantage base. But is was usefull to at least understand the
Germans when they were talking among each other :)

Germand and Dutch are very alike, up to using the same words for
different things. So it is easy for a Dutch to say something that
probably is well-formed German. But not alwasy what he wanted to say.  I
think I mentioned this one before:

English   Dutch    German
Sea       zee      Meer
Lake      meer     See

My favourite mistake was asking a German farmer for a place to set up my
tent: "Haben Sie ein platz fur mich zum kampfen?" => "Do you have a
place for me to fight?" (Dutch "Kamperen" != German "Kampfen").

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\02\04@104749 by Herbert Graf

flavicon
face
On Fri, 2005-02-04 at 16:06 +0100, Wouter van Ooijen wrote:
> Germand and Dutch are very alike, up to using the same words for
> different things.

I was really surprised by that. On my recent trip to Europe I had a 7
hour stopover at Amsterdam. Hearing the dutch language spoken really was
a delight. While I certainly couldn't understand it fluently, my small
knowledge of German (and ever smaller knowledge of French) let me get
the "gist" of most things. Funny thing is at times I understood the
flight crew's Dutch better then their English (the Dutch accent is very
new to my ears, and I sometimes had trouble picking it up).

> So it is easy for a Dutch to say something that
> probably is well-formed German. But not alwasy what he wanted to say.  I
> think I mentioned this one before:
>
> English   Dutch    German
> Sea       zee      Meer
> Lake      meer     See

Interesting, I never knew there were differences like that. I knew the
dutch PRONOUNCE "germanish" words differently, but I didn't know there
was a crossing of meaning like that! Cool.

> My favourite mistake was asking a German farmer for a place to set up my
> tent: "Haben Sie ein platz fur mich zum kampfen?" => "Do you have a
> place for me to fight?" (Dutch "Kamperen" != German "Kampfen").

Hehe, Wouter, you would have gotten a weird look for me to! :)

Of course, you would probably give ME a weird look if I tried a single
word of Dutch, so I guess it all balances out...

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\02\04@112715 by olin_piclist

face picon face
Wouter van Ooijen wrote:
>> Vierzilinderzerknalltreipling
> Vier zilinder zerknall treipling
> Four cylinder explosion (driver? motor? power source?)

Yup, you've got it.  The normal English name would be "Four cylinder
internal combustion engine".

> English   Dutch    German
> Sea       zee      Meer
> Lake      meer     See

Then there's also the English "moor" which is the same word as "meer", but
means something more like "bog" or "meadow".

> My favourite mistake was asking a German farmer for a place to set up my
> tent: "Haben Sie ein platz fur mich zum kampfen?" => "Do you have a
> place for me to fight?" (Dutch "Kamperen" != German "Kampfen").

Good one!


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

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