Ich suche für ein Batteriebetriebenes Schaltungsprojekt den "richtigen" µC. Ich habe bisher den Atmega 164PA verwendet. Dieser hat die Pins XTAL und TOSC getrennt ausgeführt und man kann den Systemtakt und den Sleep Takt extern voneinander unabhängig erzeugen. Hintergrund war der, das ich immer wieder gelesen habe, dass bei Verwendung von UART der interne Takt nicht ausreicht. Stimmt das bei neueren µCs immer noch? Oder ist es Baudrateabhängig? Ich nutze lahme 9600Baud und von der Temperatur wird es sich zwischen 5-40 °C bewegen (Innenraum).
Tino Kühn schrieb: > Ich nutze lahme 9600Baud Die absolute Höhe der Baudrate spielt hier keine Rolle, selbst wenn es nur 300 Baud wären, sie müssen relativ genau eingehalten werden (wenige Prozent) oder es gibt Übertragungsfehler. Wenn Du mal ein paar hundert fabrikneue Exemplare auf Abweichung der Taktfrequenz gemessen hast wirst Du erschreckt feststellen daß es nicht ratsam wäre sich für rs232 ohne weitere Maßnahmen auf den internen Oszillator zu verlassen, Ärger wäre vorprogrammiert. Abhilfe schafft das Kalibrierbyte OSCCAL, damit kann man den internen Oszillator halbwegs (genau genug) hinziehen, musst halt jedes Exemplar einzeln kalibrieren.
Bernd K. schrieb: > Tino Kühn schrieb: >> Ich nutze lahme 9600Baud > > Die absolute Höhe der Baudrate spielt hier keine Rolle, selbst wenn es > nur 300 Baud wären, sie müssen relativ genau eingehalten werden (wenige > Prozent) oder es gibt Übertragungsfehler. Ich habe es geahnt... > Abhilfe schafft das Kalibrierbyte OSCCAL, damit kann man den internen > Oszillator halbwegs (genau genug) hinziehen, musst halt jedes Exemplar > einzeln kalibrieren. Hier wäre ich an einer kurzen Einweisung interessiert... (Link?)
Tino Kühn schrieb: > es sich zwischen 5-40 °C bewegen (Innenraum). Das ist ein Problem. Bei jeder Geschwindigkeit. Mit Hilfe des Uhrenquarzes kann der interne Oszillator aber auf eine Baudratenfrequenz kalibriert werden. Hierfür habe ich vor einiger Zeit eine Anleitung geschrieben: http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Die_Timer_und_Z%C3%A4hler_des_AVR#Kalibrieren_des_internen_Oszillators_mit_Timer2_als_Zeitbasis Damit sind Baudraten bis 115K2 fehlerfrei möglich. mfg.
Bernd K. schrieb: > Abhilfe schafft das Kalibrierbyte OSCCAL, damit kann man den internen > Oszillator halbwegs (genau genug) hinziehen, musst halt jedes Exemplar > einzeln kalibrieren. Man könnte sich auch an der Gegenstelle Orientieren, in dem man die Bitlänge misst und damit die Kalibrierung vornimmt. Geht aber nur wenn die Gegenstelle nicht die gleiche "blöde" Idee hat.
Ich hab vor einiger Zeit aus der Not heraus mal sowas implementiert, ein spezieller Kalibriermodus: Die Gegenstelle (PC mit quarzgenauem rs252 Adapter) sendet ein "Kalibriersignal" von 0b1000000 alle 50 ms und der AVR fährt seine Taktfrequenz langsam hoch während er UDR0 liest. zuerst interpretiert er es als 0b1111000, dann 0b1110000, dann 0b11000000, dann wenn er zum ersten mal 0b1000000 liest merkt er sich den momentanen Wert von OSCCAL, dann langsam weiter erhöhen, wenn er zum ersten mal 0b00000000 liest bildet er den Mittelwert zwischen dem momentanen und dem gemerkten, das wäre der optimale Wert für OSCCAL, danach passt die Baudrate +-1%. Vorsicht Stolperfalle: bei manchen Typen hat OSCCAL eine Unstetigkeit zwischen 0x7f und 0x80, also beide Bereiche separat durchfahren.
:
Bearbeitet durch User
Bernd K. schrieb: > Die Gegenstelle (PC mit quarzgenauem rs252 > Adapter) Die Genauigkeit ist vollkommen egal. Selbst wenn der 397% Abweichung hat. Nach der Kalibrierung hat das Gegenüber sie auch und beide verstehen sich zu 100%. Bernd K. schrieb: > sendet ein "Kalibriersignal" von 0b1000000 Ist auf Dauer aber eine teure Angelegenheit. mfg.
:
Bearbeitet durch User
Thomas Eckmann schrieb: > Bernd K. schrieb: >> sendet ein "Kalibriersignal" von 0b1000000 > Das ist auf Dauer aber eine teure Angelegenheit. Nicht auf Dauer. Du startest den Kalibriermodus am PC und dann schaltest Du das Gerät mit dem AVR an. Er beginnt den Kalibriermodus und wenn er irgendwas empfängt was nicht zum Kalibriersignal passt oder wenn er 200ms nichts empfängt bricht er die Kalibrierung sofort ab und startet normal. Nach erfolgreicher Kalibrierung wirds im EEPROM gespeichert. Findet er kein Kalibriersignal wird der Wert aus dem EEPROM verwendet. Das mach ich einmal bei Inbetriebnahme, danach nie wieder.
Du kannst den (mit einem Uhrenquarz erzeugten) "Sleep-Takt zum kalibrieren des internen Takts benutzen. Siehe dazu auch App-Note AVR055.
>Ich nutze lahme 9600Baud und von der Temperatur wird >es sich zwischen 5-40 °C bewegen (Innenraum). Ich frag mich immer warum die Leute einen 20Cent teuren Qurz einsparen wollen und dann Klimmzüge machen die im Endeffekt erheblich teurer werden. Ich verstehe es einfach nicht.
>Qurz
Upps;) Machen wir einfach Furz draus. Passt irgendwie zum Thema.
Ich hab das schon gemacht, aber nicht aus Geiz sondern weil an einen 28er-DIP AVR nicht Haupt und rtc Quarz passen.
holger schrieb: >>Ich nutze lahme 9600Baud und von der Temperatur wird >>es sich zwischen 5-40 °C bewegen (Innenraum). > > und dann Klimmzüge machen Die nächste Version wird einen Quarz haben und auch andere Fehler werden behoben sein, wie immer bei Version 2.0 ;-)
Bernd K. schrieb: > Ich hab vor einiger Zeit aus der Not heraus mal sowas implementiert, ein > spezieller Kalibriermodus: Die Gegenstelle (PC mit quarzgenauem rs252 > Adapter) sendet ein "Kalibriersignal" von 0b1000000 alle 50 ms und der > AVR fährt seine Taktfrequenz langsam hoch während er UDR0 liest. zuerst > interpretiert er es als 0b1111000, dann 0b1110000, dann 0b11000000, dann > wenn er zum ersten mal 0b1000000 liest merkt er sich den momentanen Wert > von OSCCAL, dann langsam weiter erhöhen, wenn er zum ersten mal > 0b00000000 liest bildet er den Mittelwert zwischen dem momentanen und > dem gemerkten, das wäre der optimale Wert für OSCCAL, danach passt die > Baudrate +-1%. ist das nicht etwas umständlich? Ich würde einfach die Bitzeit messen und dann den passenden Kalibierungswert ausrechnen. Habe das zwar bis jetzt noch nicht gemacht, sollte aber funktionieren.
Auch andere Leute haben dieses Problem, und dieses erfolgreich gelöst. Schau Dir LIN an. http://ess.cs.tu-dortmund.de/Teaching/PGs/autolab/seminarfolien/Meier-LIN.pdf LIN ist ein paketorientierter Bus aus der Automobilindustrie wie CAN, wobei es Master und Slave gibt. Jedes Paket beginnt mit einem BREAK (>=13 Startbits), darauf kommt ein Sync-Byte (abwechselnd 0 und 1) und dann der Rest des Paketes. Die Slaves messen das Sync-Byte aus und errechnen daraus ihre Bitrate. Da sie das vor jedem Paket tun und die Pakete nur eine begrenzte Länge haben, brauchen sie keine stabilen Oszillatoren. Die Automobilindustrie ist Meister im Kostendrücken, und ein minimaler Hardwareaufwand war Teil des Designziels. Die normalen UARTs der AVRs unterstützen leider LIN nicht vollständig in Hardware, zB fehlt eine dedizierte BREAK-Erkennung. Es gibt aber einige Automotive-Typen wie Tiny87/167, die eine LIN-Schnittstelle haben. Bei den PICs haben die meisten PIC18F und alle PIC24/dsPIC und PIC32 LIN-fähige UARTs. Der Master muss gemäß LIN-Spezifikation einen Quarz-Oszillator haben, um den Slaves das Timing vorgeben zu können. Wie gesagt: dieses Problem ist erfolgreich gelöst und millionenfach in KFZ verbaut. fchk
Peter II schrieb: > ist das nicht etwas umständlich? Ich würde einfach die Bitzeit messen > und dann den passenden Kalibierungswert ausrechnen. > Habe das zwar bis jetzt noch nicht gemacht, sollte aber funktionieren. Hab ich mir auch überlegt, aber der Zusammenhang zwischen OSCCAL und Taktfrequenz wird wohl weder linear noch bei allen Exemplaren gleich sein (und dann ist da noch diese hässliche Unstetigkeit bei 0x7f). Eine pragmatische for-schleife jedoch wie oben beschrieben ist schnell hingeschrieben, keineswegs umständlich (im Gegenteil) und funktioniert ohne weitere wackelige Grundannahmen zuverlässig.
:
Bearbeitet durch User
Peter II schrieb: > ist das nicht etwas umständlich? Ich würde einfach die Bitzeit messen > und dann den passenden Kalibierungswert ausrechnen. > Habe das zwar bis jetzt noch nicht gemacht, sollte aber funktionieren. So mache ich das auch. Das mit dem Ausrechnen scheitert allerdings daran, dass die Einstellung des OSCCAL nicht "linear" ist. Deswegen ist Rantasten einfacher. Aber mit der Zeitmessung klappt das auch sehr gut. holger schrieb: > Ich verstehe es einfach nicht. Hat auch keiner erwartet. mfg.
:
Bearbeitet durch User
Mensch, da gibt es ja etliche Möglichkeiten...! Wie wäre es, wenn ich (also nicht so kompliziert) den Systemquarz nehme und dann eine RTC an einen Interrupteingang hänge? Dann habe ich richtigen Systemtakt und bekomme den Controller zur richtigen Zeit aufgeweckt. Mir geht es ja weder um die ausgeklügelste Lösung noch um Geld zu sparen. Funktionieren soll es (und die Batterei möglichst lange halten)
Tino Kühn schrieb: > Wie wäre es, wenn ich (also nicht so kompliziert) den Systemquarz nehme > und dann eine RTC an einen Interrupteingang hänge? Bei den RTCs schreckt mich einfach diese Bitgefriggelei ab. Ausserdem ist es ein unnötiges Bauteil mehr, da ein Atmega48..328 alles von Haus aus mitbringt. Interner Oszillator mit Uhrenquarz an Timer2 ist die stromsparendste Lösung und das Kalibrieren mit Timer2 ist auch nicht kompliziert. Die Pins, die die externe RTC benötigte, hätte man für wichtigeres frei. mfg.
Bernd K. schrieb: > Die absolute Höhe der Baudrate spielt hier keine Rolle, selbst wenn es > nur 300 Baud wären, sie müssen relativ genau eingehalten werden (wenige > Prozent) oder es gibt Übertragungsfehler. Das ist im Prinzip richtig, bei niedrigen Baudraten ist aber der Prescaler ziemlich groß und damit kann auch bei "krummen" Quarzen die Baudrate ziemlich exakt eingestellt werden. holger schrieb: > Ich frag mich immer warum die Leute einen 20Cent teuren > Qurz einsparen wollen und dann Klimmzüge machen die > im Endeffekt erheblich teurer werden. Den internen Oszillator zu verwenden hat auch Vorteile: weniger Verbrauch und schelleres Anschwingen, was gerade bei Batterieanwendungen interessant ist. Der interne Oszillator ist gut für UART-Anwendungen geeignet, ggf. noch Nachkallibrieren.
Thomas Eckmann schrieb: > Die Pins, die die externe RTC benötigte, hätte man für > wichtigeres frei. Externe RTC kommt mit 2 I/O aus, ein externer Quarz braucht auch 2.
Max D. schrieb: > Du kannst den (mit einem Uhrenquarz erzeugten) "Sleep-Takt zum > kalibrieren des internen Takts benutzen. Siehe dazu auch App-Note > AVR055. Das war was ich gesucht hatte...
biker schrieb: > Externe RTC kommt mit 2 I/O aus, ein externer Quarz braucht auch 2. Macht zusammen 4. Externer Uhrenquarz ohne externe RTC braucht 2 Pins, du Rechenkünstler. mfg.
Thomas Eckmann schrieb: > Macht zusammen 4. Externer Uhrenquarz ohne externe RTC braucht 2 Pins, > du Rechenkünstler. Externer Uhrenquarz braucht zwei Pins, externe RTC braucht zwei Pins, wer kann hier nicht rechnen?
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.