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
Servus, überprüfe mal ob der atmega32 den gleichen Quarz hat wie der atmega16. gruß Christian
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
Hallo Jörg, nein, hab ich nicht. Kannst Du kurz erklären wie das geht? Danke Günni
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
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
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
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.
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
Sorry, die 44 Cent sind ja viel zu viel, ein Keramikschwinger mit eingebauten Cs kostet nur 24 Cent. Peter
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
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.
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
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.
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.
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 designs 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
@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
@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
@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
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.