RE: [avr-gcc-list] Re: ATmega168 FreeRTOS code

[Larsen, Morten ActeNO]

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