Post by thread:[PIC]: 18F 8MHz internal oscillators

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

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_eng2TakeThisOuTyahoo.com> wrote: {Quote hidden}> 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.com >

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

> 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

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

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.soderholmKILLspam@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.

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

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

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.

----- Original Message ----- From: "Wouter van Ooijen" <wouterKILLspamvoti.nl> To: "'Microcontroller discussion list - Public.'" <.....piclistKILLspam.....mit.edu> Sent: Thursday, February 03, 2005 3:16 AM Subject: RE: [PIC]: 18F 8MHz internal oscillators {Quote hidden}>> 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. Bob Ammerman RAm Systems

> >> 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

> > 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.

it == OP ----- Original Message ----- From: "Wouter van Ooijen" <EraseMEwouterspam_OUTTakeThisOuTvoti.nl> To: "'Microcontroller discussion list - Public.'" <piclistspam_OUTmit.edu> Sent: Thursday, February 03, 2005 11:32 AM Subject: RE: [PIC]: 18F 8MHz internal oscillators {Quote hidden}>> 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 > > > --

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}>>>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. > > > > > > > -- Note: To protect our network, attachments must be sent to @spam@attachKILLspamengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

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

> 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

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}> 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 -- Note: To protect our network, attachments must be sent to KILLspamattachKILLspamengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

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

> 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

> 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

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

"Wouter van Ooijen" <RemoveMEwouterTakeThisOuTvoti.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

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

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

> > 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

> 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

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/

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