[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [avr-gcc-list] Re: ATmega168 FreeRTOS code
From: |
Larsen, Morten ActeNO |
Subject: |
RE: [avr-gcc-list] Re: ATmega168 FreeRTOS code |
Date: |
Thu, 6 Apr 2006 13:10:59 +0200 |
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
> On Behalf Of Vedantam Prasanth-AVP035
> Sent: Thursday, April 06, 2006 12:42 PM
> To: Uwe Fechner; AVR-GCC-list
> Subject: RE: [avr-gcc-list] Re: ATmega168 FreeRTOS code
>
>
>
> We have been facing a random problem where data sent to the
> ATMega128 on one of the UARTs (UART1 multiplexed on ports PD2
> and PD3) gets corrupted. We have verified that the data being
> transmitted on the line by the sending device is correct (we
> can see this on a console terminal) so it is clear that the
> corruption is happening within the ATMega. We also read the
> ATMega UART registers and figured out that Frame Errors were
> occuring. The baud rate was 38400. We brought it down to 9600
> but the problem still persists. One of the suspects is the
> clock stability; we are using the internal RC oscillator of
> the ATMega.
>
> Have UART data corruption issues been seen when using the
> internal oscillator? At what baud rates?
Up to 38,400bps works fine (for me, at least ...) -
above that, corruption starts to occur (BER not measured ...;-)
115,200bps seems unusable without calibration.
>
> We have Atmel's application notes for calibration of the
> internal RC oscillator but we need some time to try that out.
>
> Has anyone tried out calibrating the internal RC oscillator ?
> If so, any tips ?
There are (at least) two appnotes (see: avrfreaks.net or atmel.com)
from Atmel describing calibration in SW -
and also some commandline utilities for doing so on the STK500 platform.
As I can see you already *have* the appnotes, here's a few tips:
- use the 32kHz XTAL (if connected);
it should be highly accurate - even over a considerable temp.range
- if there's *no* XTAL or reference input whatsoever in your design,
then measure the start bit period on the UART's RxD-input.
(f.ex. by routing it to a free T/C-input)
Depending on what system generates the UART input,
this *may* be good enough for operating @115,200bps -
but probably not above:-/
If you have complete control of the other end's UART,
then send a repeating sync pattern as well -
negotiated the first time the ATmega128-system boots up.
(of course, if you communicate with another AVR-based system
*also* using internal RC-osc for clock, this won't work:-(
PC's have typically lousy XTALs for the UART,
but around +/-50ppm tolerance is certainly good enough)
- if pins/money/room allow it, then connect a temp.sensor as well.
This only if the design is supposed to operate in conditions
far out from +25degC, or over a large temp.range.
Then, compensate at certain steps - at least every 10degC.
>
> Operating conditions: 3.3V 25C internal RC oscillator.
>
> Rgds,
> -Ved
>
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden
> On Behalf Of Uwe Fechner
> Sent: Thursday, April 06, 2006 4:55 AM
> To: AVR-GCC-list
> Subject: Re: [avr-gcc-list] Re: ATmega168 FreeRTOS code
>
> David VanHorn wrote:
> > Just for grins, the internal RC isn't all that stable over
> temperature
> > and VCC variations. While you can tweak the osc in at a
> given temp and
> > VCC, it will drift out again as these change. You should at
> least use
> > a resonator if you are doing serial comms.
> Well, this would not be good for my concept reducing power
> supply current.
> Only RC oscillator is fast enough to start, to make it
> possible, to have about 50..100 µs aktive cpu time every 2 ms.
>
> The improvement, that is still missing, is to recalibrate the
> RC oscillator at runtime using the quarz driven rtc.
>
> Regards:
>
> Uwe Fechner
>
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>