Hallo liebe Leute Vielleicht könnt ihr mir helfen ?! Ich habe da ein Temperatur Problem mit meinen ATMEGA8 Ich habe da eine Platine mit einem ATMEGA8 mit internen 8Mhz Takt (RC) Der Mega8 gibt mir über die Serielle Schnittstelle (9600Baud) Daten an den PC weiter. Es trat jetzt bei einer Platine das Problem auf, dass die Datenübertragung manchmal abreißt. Mit dem OSCI sieht man jedoch immer eine Datenübertragung. Habe dann mal meinen Logikanalyzer dran gehängt und gemerkt, dass es Timing Probleme im Sende Signal (vom AVR) gibt. Wenn der AVR warm ist, funktioniert alles gut. (22°C) Wenn der AVR kühler ist, gibt es im Datenstrom Timing Probleme. Habe jetzt den AVR durch einen neuen AVR ersetzt. Jetzt funktioniert es soweit normal. Wenn ich aber den AVR mit Kältespray leicht kühle, tritt das Timing Problem noch immer auf. Ist jetzt nicht mehr so krass wie zuerst, aber noch immer vorhanden. :-( Das hat mir jetzt keine Ruhe gelassen und ich habe ein gleiche Platine genommen, die ich schon vor 2 Jahren gebaut habe. Mit einem ATMEGA8, den ich vor 2 Jahren verbaut habe. Mit gleichen Programm probiert. Da gibt es keine Timing Probleme ! Ich kann dort den AVR extrem mit Kältespray runterkühlen und die Datenverbindung funktioniert noch immer. Der 2 Jahre alte AVR hat die Bezeichnung:(der funktioniert) ATMEGA8 16AU 0628I Die neueren AVR haben die Bezeichnung: (der ausgelötet wurde) ATMEGA8 16AU 1637 bzw. der neu eingelötete ATMEGA8A AU 1538 Habt Ihr vielleicht einen Tipp, was da schuld sein kann ? Danke für Antworten. l.G. Robert
Robert schrieb: > Habt Ihr vielleicht einen Tipp, was da schuld sein kann ? Race-Conditions im Code^^ Vlt verwendest du Interrupts unsauber ... Vermutlich ein Software-Problem, da es über mehrere AVRs hinweg mitgewandert ist. Schaltplan mit Anschlussbelegung und Source-Code wäre hilfreich.
:
Bearbeitet durch User
Entweder externen Quarz nutzen oder eine Kalibrierroutine einbauen, wenn du selbst Daten von außen schicken kannst. Die Atmegas sind halt nicht so genau. Du könntest auch den internen Takt selbst nochmal nachjustieren. Wenn es temperaturstabil sein soll, ist ein externer Takt das einfachste.
Hallo,
>Habt Ihr vielleicht einen Tipp, was da schuld sein kann ?
Ich vermute mal:
a) int. Oszillator ist für Datenübertragung oftmals ungeeignet
b) Du hast beim Programmieren den falschen OSCCAL-Wert benutzt
c) unsaubere Lötstellen (vor allem bei den Power-Pins)
d) Sagt das Datenblatt etwas über die RC-Osc Toleranz über den
Temperaturbereich aus?
e) falsche Baudrateparametrierung und damit von Haus aus zu hohe
Toleranz
Wenn ich mir die Daten der Chips ansehe, ist der "neue" aber älter, da
Datecode 1538 (=> KW38 aus 2015)
Eine Frage => mehrere Antworten
(Schaltplan?? Source-Code??)
Gruß
TK
Robert schrieb: > Mit dem OSCI sieht man jedoch immer eine Datenübertragung. Und welche Bitzeit zeigt das Oszi an? Bei 9600Baud: 1.04ms, max 1% Fehler
Hallo Danke für die schnellen Antworten :-) Wenn nicht der alte AVR funktionieren würde, würde ich ja an einen Programmierfehler, oder an eine falsche Konfiguration denken. Aber der alte AVR, funktioniert ja auch bei tiefen Temperaturen ohne Probleme. (mit gleicher Software) Werde heute am Abend mal die Abweichungen messen und die Software durchgehen... l.G. Robert
Vielleicht, hast du es überlesen.... Also nochmal Klarer: Oszillator kalibrieren! OSCAL nutzen!! Viele AVR haben einen Temperatursensor eingebaut, den kann man gut dabei verwenden Alternativ, den WDT Takt für den Abgleich nutzen, der hat einen umgekehrten Temperaturkoeffizienten.
Robert schrieb: > Habt Ihr vielleicht einen Tipp, was da schuld sein kann ? Kein Quartz verwendet sondern internen Oszillator überschätzt ? Robert schrieb: > Wenn nicht der alte AVR funktionieren würde Beide werden sich im Temperaturdrift des internen Oszillators nach Datenblatt verhalten, wenn man Schaltungen nicht nach Datenblatt sondern nach "funktionier 1 mal" auslegt, dann darf man sich nicht wundern, wenn sie auch wirklich nur mit dem Einen mal funktionieren.
Das sind Parameterschwankungen zwischen den verschiedenen Chargen. Nach den Angangen im Datenblatt liegt das Verhalten ALLER Deiner Chips trotzdem noch innerhalb der Spec: "At 5V, 25°C and 1.0MHz Oscillator frequency selected, this calibration gives a frequency within ±3% of the nominal frequency." (2503Q–AVR–02/11, Calibrated Internal RC Oscillator, Seite 29) Du kannst versuchen, bei den Chips, die Probleme verursachen, das OSCCAL Register etwas zu tunen. Es kann aber sein, dass Deine Schaltung dann zwar bi tiefen Temperaturen gut funktioniert, aber bei hohen Temperaturen Übertragungsprobleme bekommt. Modernere ATmegas haben zu diesem Zweck einen groben Temperatursensor. damit kann der mc das OSCCAL Register an seine Temperatur angleichen. Übrigens reagiert der interne RC nicht nur auf Temperatur, sondern auch auf Spannungsänderungen sehr empfindlich. Die einfachste Lösung ist immer noch die Verwendung eines externen Quarzes. Viele Grüße, Stefan
Hallo
Hallo @Arduino Fanboy
Ja, ich werde mich da rantasten...
Habe mal versucht ein kleines Testprogramm zu machen, dass mir einen
Takt ausgibt.
mit :
int main (void)
{
DDRD = 255;
PORTD = 0;
Loop:
PORTD ^= (1<<PD2);
goto Loop;
}
(ich weiß, Goto wird nicht so gerne gesehen... ;-) )
Jetzt bekomme ich bei 8MHz einen Takt von 820kHz (23°C)
Wenn der AVR heiß ist, geht es zu 810 kHz (Heißluft)
Wenn es kalt ist zu 830 kHz (Kältespräy)
Bei 4MHz Takt habe ich 411kHz
Bei 1MHz Takt, habe ich 99kHz
Kann mir jemand sagen, wie viele Takte mein Programm für die Schritte
verwendet ?
(so gut kenne ich mich mit dem AVR doch nicht aus....)
Dann könnte ich mir eine Formel basteln, welchen Takt der RC-Generator
jetzt wirklich hat.
---
Als nächstes werde ich mir mal die Abweichung im RS232 Signal ausmessen
und versuchen beim OSCCAL Register was zu verändern...
Danke für die Geduld :-)
l.G. Robert
Hi Du kannst Dir die .LST Datei ansehen, Die der Compiler ausspuckt (ausspucken kann), dort ist zu sehen, wie das Programm in Assembler aussieht und die einzelnen Befehle siehst Du Da auch. Die Taktzyklen dazu stehen im Datenblatt des µC. Etwas einfacher wird Es wohl, wenn Du einen Timer alle paar Takte (egal welchen Vorteiler) einen Pin wackeln lässt - Dessen Frequenz/Laufzeit messen und Du hast schon die Taktzeit eines Tick, da Du ja weißt, alle wie vielen Takte der Pin wackelt. Da ist dann auch egal, was der Compiler daraus macht, da die ISR, egal wie aufgebaut, immer gleich lang ist. MfG
Robert schrieb: > Kann mir jemand sagen, wie viele Takte mein Programm für die Schritte > verwendet ? Es werden fünf Takte benötigt (rjmp benötigt zwei Takte):
1 | 40: 82 b3 in r24, 0x12 ; 18 1 |
2 | 42: 89 27 eor r24, r25 1 |
3 | 44: 82 bb out 0x12, r24 ; 18 1 |
4 | 46: fc cf rjmp .-8 ; 0x40 <__SREG__+0x1> 2 |
Damit ergibt sich für den externen Takt in etwa F_CPU/10, was sich auch mit deinen Messungen deckt.
Hi @Der Pointler Danke.. Habe mich gerade mit dem Simulator gespielt (schon lange her....) Ja, ich komme auch auf 5 Schritte :-) Also 10 Schritte für eine ganze Welle ;-) Das müssten dann 8,2 MHz sein ..
mmhh.. Habe mich jetzt durch das Netz gelesen. unter anderem auch hier: Beitrag "AVR Studio, Atmel ICE und die unsägliche Oszillatorkalibrierung" Habe jetzt mit dem OSCCAL experimentiert Einfach im Programm mit: OSCCAL = 164; Wenn ich den OSCCAL Wert per AVR Studio auslese, bekomme ich bei einer Einstellung von 8MHz einen Wert von 0x9F (159)raus Wenn ich diesen Wert aber direckt in das OSCCAL Register schreibe: OSCCAL = 159; Dann kommt eine andere gemessene Frequenz raus (ca. 7,8MHz) (statt org. 8,2MHz) Durch experimentieren komme ich jetzt mit einen Wert von 164, auf meine 8Mhz (gemesssen mit obiger Portausgabe und DSO) l.G. Robert
Dilettanten an der Front! Was ist das für ein elendes Gepfriemel mit RC-Oszillator und Temperaturdrift. Meistens ärgert man sich ewig weil am Ende die schönste Kalibrierung nix hilft wenn der Temperaturdrift einem alles zunichte macht. Und die Kalibrierung ist ein richtig schönes Gebastel (oder hätte ich Gepfusche schreiben sollen?) und braucht ja auch überhaupt keinen Zusatzaufwand. Ein Quarz und 2 Kondensatoren, und alle Probleme der (dieser kleinen) Welt sind wie weggeblasen. Oh ich vergass: da handelt es sich um eine Gross-Serie von vermutlich 100.000 Stück, da muss man natürlich auf jeden Cent achten der zuviel ausgegeben werden könnte.
Auh Weia schrieb: > Meistens ärgert man sich ewig weil am Ende > die schönste Kalibrierung nix hilft wenn der Temperaturdrift > einem alles zunichte macht. Und die Kalibrierung ist ein > richtig schönes Gebastel (oder hätte ich Gepfusche schreiben > sollen?) und braucht ja auch überhaupt keinen Zusatzaufwand. Geb ich dir recht ... Hatte den internen RC mal für vUSB verwendet ... Das war auch trotz Kalibrierung ein Trauerspiel. Gab noch eine andere Möglichkeit ... Der Code konnte zur Kalibrierung die Paket-Längen noch messen, aber das hat es auch nicht besser gemacht.
:
Bearbeitet durch User
> Hatte den internen RC mal für vUSB verwendet Bei STM32F1xx Controllern steht sogar klar im Datenblatt drin, daß der R/C Oszillator nicht für USB geeignet ist. Und ich meine, bei AVR gibt es einen ganz ähnlichen Kommentar bezüglich der seriellen Schnittstelle. Ich hatte auch schon öfters erwägt, den R/C Oszillator mittels OSCCAL zu kalibrieren, es dann aber gelassen. Der Aufwand ist einfach zu hoch. Du müsstest die Zielschaltung komplett fertig bauen (mitsamt Gehäuse) und dann sowohl im Sommer als auch im Winter am Ziel-Standort kalibrieren. Das bedeutet in letzter Konsequenz, daß der Aufbau deines Gerätes mindestens 1 Jahr dauert. Wenn du Pech hast, läuft die danach entweder nur im Sommer oder nur im Winter. Und selbst es prima geklappt hat, bist du immer noch nicht sicher, ob sie denn im kommenden Mai (zwischen Sommer und Winter) ordentlich laufen wird.
Stefan U. schrieb: > Bei STM32F1xx Controllern steht sogar klar im Datenblatt drin, daß der > R/C Oszillator nicht für USB geeignet ist. Und ich meine, bei AVR gibt > es einen ganz ähnlichen Kommentar bezüglich der seriellen Schnittstelle. Das Kuriose daran ist - bei meinem STM32L1 funktioniert USB wunderbar mit dem internen HSI8. Es wird zwar nicht empfohlen, den HSI8 in die PLL zu füttern und daraus den 48MHz USB-Clock zu generieren, aber es klappt. Allerdings würde ich keine Produkte verkaufen, die das so machen. Andere STM32 haben einen HSI48 eingebaut und ein (Hardware-) Clock-Recovery-Feature, wo anhand der USB-Frames der HSI48 ständig neu rekalibriert wird.
Stefan U. schrieb: > Du > müsstest die Zielschaltung komplett fertig bauen (mitsamt Gehäuse) und > dann sowohl im Sommer als auch im Winter am Ziel-Standort kalibrieren. Ich glaube, das siehst du etwas zu extrem..... Sommer und Winter, kann man gut im Gefrierschrank und Backofen simulieren. Irgendein Gehäuse ist dabei eher hinderlich. Der µC alleine recht fast. Drei Drähtchen in die Außenwelt sind genug. 2 für die Versorgung, und einer für den Sekundentakt der RTC, oder sonstigen Referenztaktgeber Es ist wahr, dass es etwas Zeit braucht. Aber 1 Jahr? Ganz sicher nicht! Typischer Fall von: > wer will findet Wege, > und wer nicht will, Gründe. Stefan U. schrieb: > Wenn du Pech hast, läuft die danach entweder nur im Sommer oder nur im > Winter. Und selbst es prima geklappt hat, bist du immer noch nicht > sicher, ob sie denn im kommenden Mai (zwischen Sommer und Winter) > ordentlich laufen wird. Dann haste aber derbe Mist gebaut. Nein! Das Argument zählt nicht. Auh Weia schrieb: > Oh ich vergass: Ja du vergaßest! Die Liebhaber der Tinys hast du vergessen. z.B.: die der Tiny85 Ohne Kalibrierung/Temperaturkompensation ist mit dem schlecht Kirschen essen, im Außenbereich. Gerne haben sie mal zuwenig Beine für einen Quarz. Mochten aber doch mit WS2811 oder DS18B20 quatschen. Nicht falsch verstehen... Ich sage nichts gegen einen Quarz. Gerne da, wo es möglich ist. Aber manchmal möchte man/ich ihn nicht verwenden. Alleine die mangelnde Rüttelfestigkeit verbietet manchmal den Einsatz. Alles kann man eingießen, aber dem Quarz hilft das nicht.
Arduino F. schrieb: > Die Liebhaber der Tinys hast du vergessen. > z.B.: die der Tiny85 Ahaaaaa! Der ATMEGA8 gehören also zu den Mikrokontollern der Tiny-Familie. Gut dass du uns das jetzt durch die Blume mitteilst. Robert schrieb: > Ich habe da eine Platine mit einem ATMEGA8 mit internen 8Mhz Takt (RC)
Auh Weia schrieb: > Ahaaaaa! Der ATMEGA8 gehören also zu den Mikrokontollern der > Tiny-Familie. Gut dass du uns das jetzt durch die Blume mitteilst. Ach so... Da gehen dir die Argumente aus, und dann musst du mir Lügen andichten.... Das nennt man dann "Aktiver Rückzug", oder? Eine feine Schwäche zeigst du da.
Hallo OK, ihr habt mich überzeugt! In Zukunft mache ich einen Quarz rein! Aber in diesem Fall, muss ich bei der bestehenden Schaltung bleiben und das beste daraus machen. Bitte bleiben wir deshalb beim Thema ;-) ---------- Kann sich das jemand erklären, warum der ausgelesene Wert (OSCCAL) (mit dem Programmer),von 0x9F, nicht übereinstimmt, wenn ich den Wert direkt per Programm in das OSCCAL Register schreibe ? (Dann bekomme ich 780hHz, satt original 820kHz) -- Kann mir jemand sagen, wie viel Abweichung ich bei einem 8MHZ RC-Takt und bei einer Baudrate von 9600, maximal haben darf ?! Danke :-) l.G. Robert
Hi Auh Weia schrieb: > Ahaaaaa! Der ATMEGA8 gehören also zu den Mikrokontollern der > Tiny-Familie. Gut dass du uns das jetzt durch die Blume mitteilst. Hier hast Du einen Lolli, geht draußen weiter flennen. Ja, eigentlich geht es hier um einen ATmega, wo das Anpassen von OSCAL empfohlen wurde, um damit trotzdem glücklich zu werden - Das funktioniert dann auch bei 'den Kleinen'. Dann kam das Üblich: Geht nicht, steht doch drin, seid Ihr alle blöd, ... nimm einen Quarz, dann ich Alles gut Worauf die Antwort, daß halt nicht überall Platz (Anzahl Beinchen, nur für Dich) ist und die Anwendung teilweise einem Quarz nicht zuträglich ist, nicht lange auf sich warten ließ. Und dann kommst Du, Erbsenzähler, Krümmelkacker, wie man diese Art Leute auch nennen mag, Jeder kennt und mag Sie. Ich mag Dich MfG Robert schrieb: > Kann mir jemand sagen, wie viel Abweichung ich bei einem 8MHZ RC-Takt > und bei einer Baudrate von 9600, maximal haben darf ?! Die zulässige Abweichung ist von der Taktquelle unabhängig - wenn Du zu weit weg bist, versteht Dich der Gegenüber halt nicht mehr. Wie weit Du genau weg sein darfst, damit Dich Dein Gegenüber noch verstehen MUSS, sollte sich in Datenblättern finden lassen - bin Da aber auch eher der Try&Eror-Typ ... und stelle an OSCAL rum ... ;)
:
Bearbeitet durch User
Hallo Robert, > Kann mir jemand sagen, wie viel Abweichung ich bei einem 8MHZ RC-Takt > und bei einer Baudrate von 9600, maximal haben darf ?! http://rn-wissen.de/wiki/index.php?title=UART: Zitat: Damit eine asynchrone Übertragung funktioniert, müssen Sender und Empfänger die gleiche (oder wenigstens fast) Geschwindigkeit benutzen. Für die üblichen Datenpakete von 10 (Roh-)Bits kann eine Abweichung bis etwa 4% gerade noch gehen. Für eine sichere Übertragung sollte die Geschwindigkeit aber besser (2%) stimmen, damit etwas Reserve für Laufzeitfehler und ähnliches da ist. Die Anforderungen sind so, dass es mit dem internen Takt der meisten µCs oft geht, aber nicht immer zuverlässig. Um die RS232-Standart Baudraten (besonders die höheren) genau zu erreichen, gibt es spezielle Quarze mit krummen Frequenzen wie: 3.6864 MHz, 7.3728 MHz, 11.0592 MHz. Zitat Ende rhf P.S. Wenn ich die serielle Schnittstelle nutze, verwende ich immer einen dieser krummen Quarze.
Robert schrieb: > Kann sich das jemand erklären, warum der ausgelesene Wert (OSCCAL) > (mit dem Programmer),von 0x9F, nicht übereinstimmt, > wenn ich den Wert direkt per Programm in das OSCCAL Register schreibe ? > (Dann bekomme ich 780hHz, satt original 820kHz) Dir ist schon klar, dass der AVR selber nur den Wert für 1MHz da rein schreibt.... Um die anderen Frequenzen musst du dich schon selber kümmern.. Siehe: "The ATmega8 stores four different calibration values for the internal RC Oscillator. These bytesresides in the signature row High byte of the ddresses 0x0000, 0x0001, 0x0002, and 0x0003 for 1MHz, 2MHz, 4MHz, and 8Mhz respectively. During Reset, the 1MHz value is automatically loaded into the OSCCAL Register. If other frequencies are used, the calibration value has to be loaded manually, see “Oscillator Calibration Register – OSCCAL” on page 31 for details."
Eigentlich kann ich mir nicht vorstellen, dass es am Taktgeber liegt. Würden die hohen Baudraten (115K oder so) verwendet, so sähe das schon ganz anders aus. Aber bei 9600 Baud?
:
Bearbeitet durch User
Sebastian S. schrieb: > Eigentlich kann ich mir nicht vorstellen, dass es am Taktgeber > liegt. > Würden die hohen Baudraten (115K oder so) verwendet, so sähe das schon > ganz anders aus. Aber bei 9600 Baud? 2% sind 2% Prozent. Da macht die Baudrate nichts dran. Wird nicht besser, durch langsamer.
Die Empfänger von seriellen Schnittstellen warten auf das Start-Bit. Danach warten sie eine halbe Bitlänge ab und lesen von da an 10 Bits ein (Start, 8x Daten, Stopp). Dabei darf die Länge jedes einzelnen Bits maximal 5% vom Soll abweichen, denn 10x 5% sind zusammen 50%. Da das Signal im idealfall in der Mitte abgetastet wird, muss es weniger als 50% verschoben sein. Wenn Sender das Signal um 3% zu langsam sendet und der Empfänger um 2% zu schnell abtastet, hat man die kritischen 5% schon erreicht. Quarz Oszillatoren sind so genau, daß man vereinfacht mit 0% Abweichung rechnen kann. Bei Keramik Resonatoren rechne ich mit 1%. Da die elektrischen Signale niemals perfekt übertragen werden, wird der Empfänger das Startbit typischerweise etwas später erkennen. Selbst wenn die Bitrate exakt stimmt. Alle Bits werden etwas später als genau in der Mitte abgetastet. Auderdem wird der Wechsel von High nach Low nicht abrupt stattfinden, sondern mit abgeflachter Flanke. Es ist unbedingt zu vermeiden, daß das Signal genau in dem Moment abgetastet wird, wo es weder eideutig High noch eindeutig Low ist. Deswegen kann man in der Praxis nicht mit maximal 5% Abweichung rechnen, sondern deutlich weniger nämlich 4%. Und das auch nur bei guten kurzen Kabeln. Es ist hilfreich, Daten mit 2 StoppBits zu senden, aber den Empfänger so einstellen, daß er nur 1 Stoppbit verlangt (bei AVR ergibt sich das von selbst, wenn man 2 Stopp-Bits einstellt). Dann hat man eine kleine Pause zwischen den bytes die dem Empfänger helfen, das nächste Startbit korrekt zu erkennen. Ein weiterer Aspekt ist der Timer, der die Baudraten generiert. Wenn er die Bitrate nicht exakt erzeugt, muss dessen Abweichung auch noch berücksichtigt werden. Wenn Sender und Empfänger nicht von der gleichen Bauart sind (zum Beispiel ein ATmega <--> USB-UART Adapter) können diese Abweichungen in umgekehrte Richtung gehen und sich somit addieren. Der AVR sendet zum Beispiel mit 9655 Baud, während der Empfänger auf 9560 Baud eingestellt ist. Alles Abweichungen zusammen betrachtet führen zu der sinnvollen Empfehlung, daß der Baudraten-Generator + Taktquelle zusammen maximal 2% abweichen sollen. Mit dem R/C Oszillator eines ATmegas ist das kaum zuverlässig machbar. Auf jeden Fall sind beim R/C Oszillator Baudraten zu bevorzugen, die der AVR mit rein rechnerisch ganz ohne Abweichung erzeugen kann. Also zum Beispiel 250.000 baud. Allerdings unterstützt nicht jede Gegenstelle diese Baudrate.
Robert schrieb: > Aber in diesem Fall, muss ich bei der bestehenden Schaltung bleiben > und das beste daraus machen. Lieber mal über den Tellerrand hinausschauen. Selbst bei einer bestehenden Schaltung ist es meist ein Leichtes nachträglich noch einen Quarz und zwei Kondensatoren einzubringen, zumal die Frequenz keine Ansprüche an ein extrem pingeliges Layout stellt. Die Quarze sind heute so klein dass Platzprobleme keine sein sollten.
Das nützt alles nichts, wenn die beiden Pins schon belegt sind und man nicht auf andere Pins ausweichen kann.
Wenn es nur um das Senden geht, kann evtl. eine Soft-UART vorteilhaft sein. Da fällt zwar die Nebenläufigkeit weg, aber ebenso das DIV8 des txclk.
Hallo @Arduino Fanboy mmmhh.. (kann leider nicht gut englisch :-( ) Also schreibt der AVR immer die Korrekturwerte von einem 1MHZ RC-Takt in das OSCCAL Register ?! Egal ob man per Programmer den 8 MHz Takt einstellt oder einen anderen ?! Sehr sinnvoll :-( Wenn ich die Korrekturwerte auslese bekomme ich: für : 1MHz = 0xA9 (169) 2MHz = 0xA8 (168) 4MHz = 0xA0 (160) 8MHz = 0x9F (159) Eperimentell ermittelt brauche ich für genau 8MHz einen Wert von 164 Also läuft bei mir der 8Mhz Takt, eigentlich mit den 8,2MHz, weil der AVR immer die Korrekturwerte von dem 1MHz Takt reinschreibt... Habe mal die Messungen bei der RS232 gemacht. (Kabel ist kurz) Normal müsste ein BIT bei 9600Baud, 104µs lang sein. (http://www.sprut.de/electronic/interfaces/rs232/rs232.htm) Bei RT habe ich jetzt 101µs Bei kälte zwischen 99 und 98,5µs wobei bei 98,5µs habe ich schon Fehler bei Wärme zwischen 101 und 104µs mein Fazit: Mein Takt ist einfach zu hoch! Wen ich den Takt mit OSCCAL auf 8MHz bringe, habe ich vermutlich genug Luft nach oben und unten (wärme/kälte)
Robert schrieb: > Also schreibt der AVR immer die Korrekturwerte von einem 1MHZ RC-Takt in > das OSCCAL Register ?! > Egal ob man per Programmer den 8 MHz Takt einstellt oder einen anderen > ?! Das hast du gut erkannt. Robert schrieb: > Sehr sinnvoll :-( Bei der Bewertung halte ich mich raus. Das überlasse ich gerne dir.
Angehängte Dateien:
-
stop_next_start.png
19 KB
Wieso eigentlich der olle mega8? Die RC-Oszillatoren der neueren mega48/88/168/328 sind stabiler! Stefan U. schrieb: > Es ist hilfreich, Daten mit 2 StoppBits zu senden Empfänger warten in der Regel nicht die volle Zeit des Stopbits ab, bevor sie das nächste Startbit empfangen können. (Siehe Bild) Gruß Jobst
:
Bearbeitet durch User
Robert schrieb: > Aber in diesem Fall, muss ich bei der bestehenden Schaltung bleiben > und das beste daraus machen. Dann mußt Du damit leben, daß es nicht zuverlässig funktioniert. Wo ist das Problem?
Robert schrieb: > @Arduino Fanboy > mmmhh.. (kann leider nicht gut englisch :-( ) Mmhh - also spontan hätte ich das mit "von Arduino begeisterter Knabe" übersetzt ...
@Arduino Fanboy mmhh.. Siehst Du das anders ? --- Mit meinen Wert von 164 (OSCCAL)mit dem ich genau auf 8 MHz Takt komme, habe ich jetzt bei RT eine Bit Zeit von 104µs Bei Kälte 101-100,5µs Bei Wärme 106,5 - 107,5µs Sind damit ca. 3% Abweichung und funktioniert alles mit dem RC-Generator Also ist es möglich, mit dem RC-Generator auch gut zu Arbeiten. Vorrausgesetzt, er ist gut Kalibriert. (Natürlich ist der Quarz besser und werde ich nächstes mal auch einplanen ;-) Danke für den Tipp mit dem OSCCAL Register :-) l.G. Robert
S. Landolt schrieb: > Mmhh - also spontan hätte ich das mit "von Arduino begeisterter Knabe" > übersetzt ... Wie ich solche Sprüche übersetzen würde, kann und darf ich hier nicht schreiben. Das empfinde ich als Manko. Herbert Robert schrieb: > Mit meinen Wert von 164 (OSCCAL)mit dem ich genau auf 8 MHz Takt komme, > habe ich jetzt bei RT eine Bit Zeit von 104µs > Bei Kälte 101-100,5µs > Bei Wärme 106,5 - 107,5µs > > Sind damit ca. 3% Abweichung und funktioniert alles mit dem RC-Generator > > Also ist es möglich, mit dem RC-Generator auch gut zu Arbeiten. > Vorrausgesetzt, er ist gut Kalibriert. Richtig. Laß Dich nicht beirren. Hier sitzt seit Jahren ein Mega 8 mit internem Takt und mit Ds1820 (Temperatusensor) dran in einer Abzweigdose an der westlichen Hauswand und sendet unverdrossen und fehlerfrei per Uart seine Daten.
:
Bearbeitet durch User
Ein Quarz kostet um die 24 cents, was soll der Aufwand ? Geht's um 1000 Stueck ? Dann kostet der Quarz noch 21 cents. Auch fuer die 210 euro wuerd ich mir keinen Aufwand machen. Vielleicht mit Keramikresonatoren, 6 cents das Stueck ?
Schick ihm ein "HALLO_TEST" auf der seriellen und stelle im Programm am OSCCAL-Register, bis im RX-Puffer "HALLO_TEST" steht. dann einen zurück (oder zwei hoch) und fertig.
mmmh.. Das wäre wohl zu ungenau..?! Wenn ich das bei RT mache, läuft das vielleicht. Läuft dann aber vielleicht nicht, wenn es heiß oder kalt ist. Eventuell diesen Test bei kälte und bei Hitze machen und dann einen Mittelwert bilden. Aber ich denke da ist das Messen mit dem Testprogramm (Frequenz) und dann den optimalen OSCCAL-Wert reinscheiben, sicherer.. ?!
mmmhh.. vielleicht die Prozessortakte zählen, die bei einem Bit von einem kommenenden RS232, reinpassen. (Steigende Flanke, bis zur fallenden Flanke) Dann das OSCCAL Register so lange verstellen, bis die richtige Anzahl der Takte (für ein Bit) rauskommen. Dann müsste man die Takte für die 104µs kennen ?!?!
ROFL wenn ich lese wie hier herumgefrickelt wird. Auh Weia schrieb: > Und die Kalibrierung ist ein > richtig schönes Gebastel (oder hätte ich Gepfusche schreiben > sollen?) und braucht ja auch überhaupt keinen Zusatzaufwand. Der Aufwand treibt sich so in die Höhe dass die Kreation eines neuen Designs wohl das sicherere und einfachere Vorgehen darstellt. Auch eine nachträgliche Befreiung der Oszillator-Pins wäre wohl noch eine bessere Alternative. Aber ich glaube es handelt sich um eine Gross-Serie von 11 Stück, da macht man solche Kleinigkeiten nicht ....
Robert schrieb: > int main (void) > { > DDRD = 255; > PORTD = 0; > > Loop: > PORTD ^= (1<<PD2); > goto Loop; > } > > (ich weiß, Goto wird nicht so gerne gesehen... ;-) ) Hättest du mit
1 | int main (void) |
2 | {
|
3 | DDRD = 255; |
4 | PORTD = 0; |
5 | |
6 | for(;;){ |
7 | PORTD ^= (1<<PD2); |
8 | }
|
9 | return 0; |
10 | }
|
sogar noch besser (und ohne goto) lösen können da das nicht mal ein Warning gibt (dein fehlendes "return" müsste eigentlich im Warning münden). ;) Zum Thema selbst: Würde das Gezumpel auch mit einem Quarz lösen, ist stressfreier ;)
:
Bearbeitet durch User
M. K. schrieb: > Würde das Gezumpel auch mit einem Quarz lösen, ist stressfreier ;) Ich habe gerade bei Gezumpel das Wort Stümperei gelesen.
Auh Weia schrieb: > Ich habe gerade bei Gezumpel das Wort Stümperei gelesen. Da musst du noch mal die Mustererkennung im Oberstübchen nachjustieren, die beiden Worte sehen sich jetzt ja mal so gar nicht ähnlich :D
M. K. schrieb: > die beiden Worte sehen sich jetzt ja mal so gar nicht ähnlich Das lief nicht über Mustererkennung sondern über Assoziationen.
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.