www.mikrocontroller.net

Forum: Compiler & IDEs UART mit atmega32


Autor: Günni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich bin gerade dabei ein Projekt von einem atmage16 auf einem atmega32
umzubauen.
Dabei sollten sich eigentlich keine großen Probleme stellen.
Scheint auch alles zu gehen, bis auf die serielle Schnittstelle.
Ich benutze die lib von fleury. Auf dem mega16 hat alles perferkt
funktioniert, aber auf dem mega32 kommt nur Müll raus. Im Makefile hab
ich die neue MCU eingetragen, ansonsten keine weiteren Änderungen
durchgeführt.
Wie gesagt, klappt alles bis auf die Schnittstelle für den Drucker. Hat
Jemand eine Idee was anzupassen ist?

Grüße
Günni

Autor: ElMachel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus,

überprüfe mal ob der atmega32 den gleichen Quarz hat wie
der atmega16.

gruß
Christian

Autor: Günni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Christian,

ja, ich benutze den internen mit 4MHz.
Darin liegt scheinbar auch das Problem.

Beim MEGA16 funktioniert die Übertragung mit 9600 Baud.
Beim MEGA32 kommen bei 9600 nur Schmierzeichen am Drucker an.

Mit 8MHz funktioniert die Übertragung jetzt mit 9600 Baud auch beim
MEGA32.

Ich weiß, dass 4 bzw. 8 MHz nicht die optionale Vorraussetzung zur
Erzeugung vom Takt für den UART sind, aber dass sich die MCU
unterschiedlich verhält ist neu für mich.

Grüße
Günni

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OSCCAL ordentlich benutzt?

Autor: Günni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg,

nein, hab ich nicht.
Kannst Du kurz erklären wie das geht?

Danke
Günni

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der interne RC-Oszillator ist prinzipiell für die UART zu ungenau.

Da brauchts entweder einen Quarz oder Keramikschwinger.

Sonst ist es reiner Zufall, wenns klappt.


Peter

Autor: Günni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hab mal selbst nachgelesen.
Ist es richtig, z.B. bei 8 MHz das Calibration Byte mit dem AVR Studio
auszulesen um es dann bei Programmstart in das OSCCAL Register (z.B.
hardcodiert, u.U. unterschiedlich je ATMEGA) zu schreiben?
Vielleicht eine blöde Frage, aber das habe ich bisher völlig
übergangen!

Grüße
Günni

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist richtig , aber trotzdem werden nur 3% Genauigkeit garantiert und
das ist für ne UART hart an der Grenze bis ungenügend.


Peter

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atmel schreibt, dass sie bei 5 V und 25 °C ±1 % angeben (sofern die
Kalibrierung über OSCCAL erfolgte -- automatisch ist sie nur für den
Standard-Takt gegeben, ohne Veränderung der Fuses).  Auf Seminaren
empfehlen sie wohl den internen RC-Oszillator auch als (mittlerweile)
tauglich für RS-232-Anwendungen.  Vorteil des RC-Oszillators ist, dass
er schnell anschwingt, sodass man die Startzeit kurz halten kann, wenn
man den Prozessor häufig schlafen legen will.  In der Reihenfolge
kommen danach dann Keramikschwinger, Quarze brauchen (aufgrund ihrer
hohen Güte, die für die Stabilität zuständig ist) am längsten, sind
also für Anwendungen, die sich häufig (zum Strom Sparen) schlafen
legen wollen, am schlechtesten geeignet.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich die Atmel application Note richtig interpretiere sind die 1%
nur bei den allerneuesten gültig, also ATMega48, 88, 168 usw.

Und bei 2 AVRs sind das im Worst case schon 2%, bei unterschiedlicher
VCC und Temperatur noch mehr.
Das hat dann schon erheblichen Einfluß auf die Stabilität der
Verbindung.


Ich verstehe nicht, warum man sich künstlich Probleme schaffen muß, nur
um die 44 Cent (Reichelt) für einen Quarz zu sparen.


Und die regelmäßigen Klagen, daß es nicht läuft, hier und bei AVRFreaks
geben mir doch Recht.


Peter

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, die 44 Cent sind ja viel zu viel, ein Keramikschwinger mit
eingebauten Cs kostet nur 24 Cent.


Peter

Autor: Günni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

sicherlich ist die Abweichung nicht dienlich für die serielle
Kommunikation, aber mit entsprechend niedriger Baudrate sollten die
Singale eine ausreichende Länge haben, um auch mit diesen Toleranzen
anzukommen.
Für mein Beispiel: Seit der Benutzung des korrekten OSCCAL Wetes läuft
alles prima -> mit 9600 Baud.
Bei 57600 Baud oder schneller sieht es sicherlich anders aus.

Grüße
Günni

Autor: OldBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1200 Baud funktioniert sogar unkalibriert!

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Prozente sind Verhältnisse. Ist der Taks 3% falsch, wird's bei jeder
Taktfrequenz knapp, egal ob 110bd oder 115200bd. Nach dem 10. Bit liegt
die Phase nämlich bis zu 34% dabenen, was die auf mehreren Samples
basierende Datenerkennung schon irritieren kann. Die Samples wiederum
basieren auf Baud*16, auch hier hilft die niedrige Frequenz nicht.
Einziger Vorteil nierdriger Frequenzen: schnarchlangsame
Schnittstellentreiber stören nicht.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da der Fehler relativ ist, spielt es keine Rolle, ob 9600 oder 300
Baud.

Allerdings kann bei hohen Baudraten ein weiterer Fehler hinzukommen,
wenn der benötigte Teilerfaktor nicht mehr ganzzahlig ist.


Es ist natürlich auch ein Unterschied, ob es nur für den Hobbybereich
bei Zimmertemperatur oder für Industrie- und Außeneinsatz ist.
Da wäre schon ein einziger Reparaturfall teuerer als 10.000
Keramikresonatoren.


Peter

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter, es ging doch ohnehin nicht um den Preis (wenngleich du
natürlich den Preis für die Platinenfläche großzügig vernachlässigt
hast, der dürfte bei einer industriellen Fertigung mindestens nochmal
so hoch sein).  Wenn du das Teil schlafen legst, um Strom zu sparen,
kommt's aber auf schnelles Anschwingen an, ansonsten verplemperst du
sehr viel Strom (und Reaktionszeit) in der Anlaufphase.

Die ±1 % werden übrigens schon für den ATmega128 angegeben, der dürfte
der älteste AVR sein, der einen kalibrierten RC-Oszillator hat.

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
0,02 Euro: Der Stichprobenumfang ist klein (=1), aber ein Mega16 bei
8MHz intern und entsprechenden Kalibrierungswert im OSCCAL gab
keinerlei Fehler bei 19200 sowohl bei Erwaermung mir Haartrockner als
auch wenn Platine draussen auf dem Fensterbrett (<0Grad
Umgebungstemp.). Das Testprogramm war allerdings recht primitiv.
Alternativ: OSCCAL mit 32kHz-XTAL kalibrieren, evtl. noch billiger als
Schwinger und fuer sleep-modes eh praktisch (async timer). Gibt's ja
auch ein AppNote zu. Oder aber ein paar Dummy-Bytes von PC-Seite
senden, der uC misst die "Bitzeit" und synchronisiert OSCCAL
entsprechend ("Autobauding"). Nicht ganz sicher ob's da eine Atmel
AppNote zu gibt, aber irgendwo gesehen (TI, Freescale...) - noch nie
selbst implementiert. Im Vergl. zu Quarz/Schwinger fuer Systemtakt mehr
zu programmieren, aber wenn die Kostenschraube straff angezogen wird,
mag es sinnvoll sein.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atmel Application Note AVR054:

In production the internal RC is calibrated at either 5V or 3.3V. Refer
to the datasheet
of the individual devices for information about the operating voltage
used during
calibration. The accuracy of the factory calibration is within +/-3 or
+/-10% (refer to the
datasheet). If a design’s need for accuracy is beyond what can be
offered by the
standard calibration in factory by Atmel, it is possible to perform a
secondary
calibration of the RC oscillator. By doing this it is possible to
obtain a frequency
accuracy within +/-1 (+/-2% for those with an 10% accuracy from factory
calibration).


Im Klartext:

Nur 3% werden garantiert und für 1% ist eine Nachkalibration notwendig
!


Ich hab ja auch nichts dagegen, wenn jemand im Hobbybereich so
arbeitet. Bloß dann soll er sich eben nicht beschweren, daß es der eine
AVR tut und der andere nicht.


@Jörg,

es ging ja um den Betrieb der RS-232 und da ist schon die Stromaufnahme
eines MAX232 viel größer als die eines schlafenden AVR, egal ob mit 16ms
Resetzeit oder weniger.

Und wie Thomas sagte, es geht natürlich auch ein Uhrenquarz an T2, mit
dem man dann entweder die Kalibration korrigiert oder den
Baudratenteiler.

Oder eben die AVR054.


Peter

Autor: Günni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter
Falls Du mit beschweren mich meintest, dann lies bitte mein Posting
nochmal durch. Von einer Beschwerde ist nicht die Rede. Lediglich von
Fragen, und das ist doch erlaubt, oder?
Außerdem ist mein Projekt nicht im Hobbybereich angesiedelt.
Diesbezüglich solltest Du es dem Entwickler überlassen, welche
Komponenten er wo und wie einsetzt, auch wenn Du was dagegen hast ;-)

Grüße
Günni

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Günni,

Du hast recht, es ist jedem selbst überlassen wie er Pleite macht.

Mein Chef würde mich jedenfalls hochkant feuern, wenn ich mich darauf
verlassen würde, daß eine Toleranz max 1% beträgt, der Hersteller
jedoch in seinen Applikationsschriften 3% (10%) angibt.

Nur aus Jux und Dollerei werden sie jedenfalls nicht extra diese
Applikationsschrift verfaßt haben. D.h. sie bestätigen dadurch doch,
daß die Factory-Calibration allein für eine stabile UART-Verbindung
nicht ausreicht.


Ich habe aber schon was dagegen, wenn man zunehmend elektronische
Geräte zu kaufen kriegt, wo nur noch der Henkel zum Wegschmeißen dran
fehlt. Und das nicht so genau nehmen mit den Herstellerangaben ist der
erste Schritt dazu.


Peter

Autor: Günni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter
Gut, dass ich in unserer Firma der Chef bin :-)
Wegschmeißen mußte man unsere Produkte bisher noch nicht.

Nichts für Ungut. War auch nicht als persönlicher Angriff gemeint!

Grüße
Günni

Autor: Jörg Wunsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja Peter, wer hat hier wohl Recht?  Die AppNote verweist auf das
Datenblatt als exakte Angabe, und das nennt (zumindest für alle die,
wo ich jetzt nachgeguckt habe) ±1 %, wohlgemerkt als voreingestellte
Toleranz für den Standard-OSCCAL-Wert, wie er von der Hardware geladen
wird (meist für 1 MHz dimensioniert).  Für die anderen OSCCAL-Werte,
die man via Programmer auslesen kann (für andere Taktfrequenzen)
gibt's leider keine Angaben.

Ob wohl die AppNote einfach mal zu alt ist und aus einer Zeit stammt,
da der interne RC-Oszillator noch viel schlechter war?  Zumindest
finde ich auf die Schnelle kein Datenblatt, das entweder 3 oder 10 %
behaupten würde.

Die Kurven in den Datenblättern zeigen auch ziemlich gut, wogegen der
Oszillator empfindsam ist.  Wenn man die 5 V stabilisiert hat, kann
man schon einen recht großen Temperaturbereich abdecken, bevor man an
die Toleranzgrenzen der RS-232 gelangt...  Wenn man natürlich
unstabilisierten Batteriebetrieb möchte, fällt die Variante aus (eine
Ausnahme wäre vielleicht der Betrieb der L-Variante mit einer
Lithiumzelle, da die eine recht flache Entladekurve haben, aber dann
kommt man bei den meisten AVRs natürlich nicht um eine eigene
Kalibrierung umhin, da die Vorgabe nur für 5 V taugt).

MAX232-Derivate gibt's ja auch mit Standby-Funktion.  Denke einfach
mal an irgendwelche Datenlogger, die alle Sekunde aufwachen wollen,
etwas messen, sich den Wert merken, die RS-232 aber erst zum Auslesen
brauchen.

Wie gesagt, Atmel preist auf seinen Seminaren die Stabilität des
kalibrierten RC-Oszillators als unter normalen Umständen ausreichend
für RS-232-Betrieb an.  Ob das dann für jeden in dieser Form in der
Praxis zutrifft, muss man wohl selbst entscheiden, keine Frage.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gebe zu, die 24 Cent Einsparung waren für mich bisher nie ein Grund,
über dieses Thema überhaupt nachzudenken.

Die Geräte, die ich entwickle, sind doch eher hochpreisig und für den
hochzuverlässigen Industrieeinsatz.

Deshalb lasse ich jeden Gedanken, der auch nur einen Hauch von
verringerter Zuverlässigkeit ahnen lassen könnte, sofort wieder
fallen.


Ich benutze den RC-Oszillator z.B. in Modulen mit I2C-Bus, da spielt es
überhaupt keine Rolle.


Peter

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.