EmbeddedRelated.com
Forums

UART timing

Started by Ross Marchant September 8, 2005
Ross,

did you have a look at the ATMEGA specification for the IRC? It is
horrible, there is a temperature drift from -40 / 85 C of almost 10%.
If you voltage changes e.g. battery driven the difference between a 5V
supply and 2.7V is more than 10% (without the temperature drift).
Companies that are serious about using the Internal RC with a UART
specify the max. drift over temp e.g. Philips LPC938 which is similar
to the ATMEGA but a 2-clock core has less than 2.5% across the
temperature range and is trimmed to better than 1% at room temp.

We used this one without any problems running a UART.

An Schwob


Ross Marchant wrote:
> On Fri, 09 Sep 2005 15:34:03 +1000, Paul Keinanen <keinanen@sci.fi> wrote: > > > On Fri, 9 Sep 2005 10:26:53 +1000, "Ross Marchant" > > <rossm@NOexcelSPAMtech.com.auSTRALIA> wrote: > > > >> * Embedded device > > > > Are you sure that the embedded device generates true RS-232 voltage > > levels and not some "RS-232" compatible levels from a 5 V inverter ? > > > >> connection to GPRS modem at 9600 baud doesn't work > >> properly. AT commands > > > > Is autobauding enabled at the GPRS end ? Try disabling it. In > > autobauding, the A and T characters are used to determine the speed of > > the line and if the speed is too much away from the standard speed, > > some erratic speed settings might occur. > > > >> have to be sent one byte at a time slowly, and once > >> connected messages sent come out as garbage at server end. > > > > This would suggest that the transmit clock is more than 5 % higher > > than the receiver clock. When the final stop bit is being received, > > the receiver sample pulse should be in the middle of the stop bit. > > After detecting the proper stop bit, the receiver would enable the > > edge trigger (1->0) to wait for the next start bit. However, with a > > too slow receiver clock, the stop bit sample pulse is at the end of > > the stop bit or perhaps after the end of the character. > > > > When sending characters individually, the Mark state remains stable > > long after the stop bit, so it will get a stable detection of the Mark > > state (=equivalent to a stop bit) even if the sample pulse is long > > after the end of the character. > > > > When sending a string of characters, the next start bit is immediately > > after the stop bit of the previous character. If the stop bit sample > > point has been delayed into the next start bit, the Space state is > > detected and the receiver would declare a framing error ("missing stop > > bit") and just the next 1->0 transition (now inside the next > > character) is (incorrectly) interpreted as a start bit. Thus, a long > > string of garbage is received, when the character synch is lost. > > > > Try setting two stop bits when sending a string of characters. If this > > works, this would be a clear indication of this kind of problem. > > > > Are you sure that the embedded transmitter is actually transmitting a > > decent stop bit. For instance in the QUICC coprocessor (in Motorola > > MC68360/MPC860 etc.) there is an option of cutting the stop bit > > shorter or even eliminate it. Make sure that this option has not been > > selected. > > > > Paul > > > > Thanks for your detailed reply Paul, I'm convinced that it is a baud rate > issue too, especially since I have been told that the device uses the > internal clock to generate the UART clock! The RS232 TX voltage is -10V so > its not the driver. The modem has an autobaud feature. I can't do any > repgramming as I have only been given a product to test, but I will pass > on the comments. Thanks heaps. > > Ross
On Sat, 10 Sep 2005 09:40:58 +1000, "Ross Marchant"
<acqua@spammytpg.com.au> wrote:

> The modem has an autobaud feature. I can't do any >repgramming as I have only been given a product to test, but I will pass >on the comments.
Check the AT command set for the GPRS modem, it might contain a command to set a fixed baud rate, thus disabling the autobauding. Paul
On Sat, 10 Sep 2005 09:12:27 +1000, "Ross Marchant"
<acqua@spammytpg.com.au> wrote:

>On Fri, 09 Sep 2005 18:05:35 +1000, <tebbutt@hotmail.com> wrote: > >>> >>> Thanks, I'm trying to solve a problem for someone remotely. >>> Symptoms: >>> * HyperTerminal connection to GPRS modem at 9600 baud works fine. >>> Messages >>> come through fine at server. >>> * Embedded device connection to GPRS modem at 9600 baud doesn't work >>> properly. AT commands have to be sent one byte at a time slowly, and >>> once >>> connected messages sent come out as garbage at server end. >> >> Which GPRS modem are you using? - I have used some GSM/GPRS modems that >> are *very* picky about getting the baud rate spot on. Which embedded >> processor are you using and what's the clock source? >> >> Iain Tebbutt >> www.claritech.co.uk >> > >The modem is the Audiotel industrial plus, the processor is the Atmel >ATMEGA8L using internal clock source. There is an RS232 driver with -10V >on TX. > >I have used the Alphamicro GPRS modem successfully with my own embedded >stuff. I think it *must* be the baud rate in this particular instance. >
The internal clock is voltage and temperature dependant. As a test you can try changing one or the other. As a long term solution, a more accurate and stable clock is a must. Regards Anton Erasmus
On Sat, 10 Sep 2005 15:34:42 +0200, in msg
<1126359097.38a04f151dbeec5d386d9018010aead9@teranews>, Anton Erasmus
<nobody@spam.prevent.net> wrote:

>On Sat, 10 Sep 2005 09:12:27 +1000, "Ross Marchant" ><acqua@spammytpg.com.au> wrote: > >>On Fri, 09 Sep 2005 18:05:35 +1000, <tebbutt@hotmail.com> wrote: >> >>>> >>>> Thanks, I'm trying to solve a problem for someone remotely. >>>> Symptoms: >>>> * HyperTerminal connection to GPRS modem at 9600 baud works fine. >>>> Messages >>>> come through fine at server. >>>> * Embedded device connection to GPRS modem at 9600 baud doesn't work >>>> properly. AT commands have to be sent one byte at a time slowly, and >>>> once >>>> connected messages sent come out as garbage at server end. >>> >>> Which GPRS modem are you using? - I have used some GSM/GPRS modems that >>> are *very* picky about getting the baud rate spot on. Which embedded >>> processor are you using and what's the clock source? >>> >>> Iain Tebbutt >>> www.claritech.co.uk >>> >> >>The modem is the Audiotel industrial plus, the processor is the Atmel >>ATMEGA8L using internal clock source. There is an RS232 driver with -10V >>on TX.
I use the same processor, and RS-232, in many of our products. When using the internal clock source, and RS-232 on the Atmel parts you *must* use the clock calibration byte to properly calibrate the internal clock or your baudrate can be off enough to cause problems. -Zonn -- Zonn Moore Remove the ".AOL" from the Zektor, LLC email address to reply. www.zektor.com
>>>The modem is the Audiotel industrial plus, the processor is the Atmel >>>ATMEGA8L using internal clock source. There is an RS232 driver with -10V >>>on TX. > > I use the same processor, and RS-232, in many of our products. > > When using the internal clock source, and RS-232 on the Atmel parts you > *must* > use the clock calibration byte to properly calibrate the internal clock or > your > baudrate can be off enough to cause problems. >
And you should look at the nominal frequency at your voltage. An 8 MHz device is 8 MHz at 5 Volt. When running at 3.3V it is less. -- A. P. Richelieu com