Ich versuche die Genauigkeit von F_CPU - M328p - zu bestimmen und
irgendwie abzuspeichern.
100 x 360000 Timer-ticks (1Stunde) ergeben zur rtc eine Abweichung von
-36 sec. D.h., wenn der Timer bei 8Mhz genau mit 10kHz arbeiten müsste
(?) hätte ich eine tatsächliche cpu von 3564/3600*8000000 = 7920000Mhz.
Wichtig für die serielle Schnittstelle. Idee: im eeprom abspeichern und
in der usart_ini() als Korrekturfaktor berücksichtigen.
Gibt es bessere Lösungen?
Karl K. schrieb:> Idee: im eeprom abspeichern und> in der usart_ini() als Korrekturfaktor berücksichtigen.>> Gibt es bessere Lösungen?
Den richtigen Wert für's OSCCAL-Register bestimmen und dort korrigieren.
Der Kalibrierwert müsste dann aber auch aus dem EEPROM kommen, das
Kalibrierregister ist flüchtig.
Du kannst die Taktfrequenz natürlich messen und irgendwo speichern, aber
nicht in F_CPU.
F_CPU muss konstant sein, weil der Compiler (mit Makros) basierend
darauf Code generiert.
Karl K. schrieb:> Gibt es bessere Lösungen?
Besser vielleicht nicht, aber anders: Eine RTC kann ein 1Hz Signal
liefern. Damit messe ich den CPU-Takt und ändere OSCCAL entsprechend.
Dadurch werden auch Abweichungen durch Temperatur oder VDD korrigiert.
Und ich brauche kein EEPROM und muss die RTC (für den Zweck) nicht
auslesen.
Sherlock 🕵🏽♂️ schrieb:> F_CPU muss konstant sein, weil der Compiler (mit Makros) basierend> darauf Code generiert.
schon klar. Deswegen
i16 calib_korrektur=ee_xx;//aus eeprom auslesen
unsigned int ubrr = (F_CPU+calib_korrektur)/16/baud-1;
statt
unsigned int ubrr = F_CPU/16/baud-1;
Die Frage ist, ob der Rückschluss des Messwerts der Timerfrequenz auf
den realen Takt des Quarzes so richtig ist. Es geht mir im Prinzip nur
um eine Verbesserung der Genauigkeit der baudrate.
Karl K. schrieb:> Wichtig für die serielle Schnittstelle. Idee: im eeprom abspeichern und> in der usart_ini() als Korrekturfaktor berücksichtigen.>> Gibt es bessere Lösungen?
Ein 8 MHz Quarz löst alle Probleme.
Moin,
Mi N. schrieb:> Ein 8 MHz Quarz löst alle Probleme.
Fuer Baudratengenauigkeiten wirds wohl problemloesendere Quarzfrequenzen
geben, als 8MHz. Ausser fuer MIDI.
Gruss
WK
Mi N. schrieb:> Ein 8 MHz Quarz löst alle Probleme.
Ich verwende arduino nanos. Ausgereiftes billiges Massenprodukt. die
haben einen 16MHz-Quartz. Der hat selbstverständlich eine Abweichung.
Umlöten des Quarzes ist keine Option weil zu viel Aufwand. Uart ist
zeitkritisch. Es geht also um den Ausgleich der Abweichung. Dass es
spezielle Quarze für uart gibt weiß ich. Bei der Baudrate von nur 9600
sollte es aber auch mit dem Arduino-Nano_Quartz brauchbar funktionieren.
Karl K. schrieb:> Ich verwende arduino nanos. Ausgereiftes billiges Massenprodukt. die> haben einen 16MHz-Quartz. Der hat selbstverständlich eine Abweichung.> Umlöten des Quarzes ist keine Option weil zu viel Aufwand.
Ich verstehe Dich nicht. Du hast nanos mit 16 MHz Quarz und willst die
mit 8 MHz takten? Damußt Du nicht löten, nichts abgleichen, sondern nu
den Vorteiler auf 1:2 stellen.
Dergute W. schrieb:> Fuer Baudratengenauigkeiten wirds wohl problemloesendere Quarzfrequenzen> geben, als 8MHz.
Für 1 MBd passen 8 MHz bestens.
Karl K. schrieb:> Ich verwende arduino nanos. Ausgereiftes billiges Massenprodukt. die> haben einen 16MHz-Quartz.
Unwahrscheinlich!
Meine haben alle keinen Quarz sondern Keramik Resonatoren
Arduino F. schrieb:> Karl K. schrieb:>> Ich verwende arduino nanos. Ausgereiftes billiges Massenprodukt. die>> haben einen 16MHz-Quartz.>> Unwahrscheinlich!> Meine haben alle keinen Quarz sondern Keramik Resonatoren
Das ist vollkommen unerheblich. Für die UART Kommunikation reicht die
Genauigkeit eines Keramikresonators (und erst Recht die eines Quarzes)
vollkommen aus. Insofern ist fraglich, was der TE mit
Karl K. schrieb:> Uart ist zeitkritisch. Es geht also um den Ausgleich der Abweichung.
eigentlich meint. Die Praxis zeigt sehr deutlich, das die UART
Kommunikation zumindest mit dem USB-CDC auf dem Board funktioniert.
Sonst würden reihenweise Arduino-nanos als "kaputt" gemeldet.
Natürlich kann man aus 16MHz Takt nicht beliebige klassische Baudraten
erzeugen. Aber bei kleinen Baudraten (typisch: 9600Bd) ist der
zusätzliche systematische Fehler klein genug daß es funktioniert.
Allerdings sprach er ja auch von 8MHz also wohl(?) dem internen
RC-Clock. Das wäre dann eine ganz andere Baustelle.
Axel S. schrieb:> Das ist vollkommen unerheblich.
Naja...
Wir haben hier einen Haufen verwirrende/unvollständige Aussagen/Annahmen
in diesem Thread.
Die sollte man mal auf Linie bringen, da macht es schon Sinn mit den
einfach zu beweisenden Fakten anzufangen.
Karl K. schrieb:> die haben einen 16MHz-Quartz. Der hat selbstverständlich eine> Abweichung. Uart ist zeitkritisch.
Die Genauigkeit eines Quarzes (ohne -t-) reicht garantiert für eine
asynchrone serielle Schnitte.
Karl K. schrieb:> 100 x 360000 Timer-ticks (1Stunde) ergeben zur rtc eine Abweichung von> -36 sec. D.h., wenn der Timer bei 8Mhz genau mit 10kHz arbeiten müsste> (?) hätte ich eine tatsächliche cpu von 3564/3600*8000000 = 7920000Mhz.
Also 7,92 THz?
Und diese kommastellenverschobene Rechnung würde auch nur dann stimmen,
wenn deine RTC exakt zu 100% genau wäre. Die verwendet aber auch nur
einen Quarz. Hast du mal die Genauigkeit deiner RTC kontrolliert?
Davon abgesehen ist eine Abweichung von 8/7,92 grade mal 1%, Das reicht
für den UART auch noch locker aus.
> timer_10ms++;//~10khz, 100ns
10kHz sind übrigens 100µs, keine 10ms und auch keine 100ns.
BTW: dieses 1% sieht grade so aus, als ob du bei deiner Rechnung
irgendwie einen "off by one"-Fehler beim Zählen auf 100 hättest...
Lothar M. schrieb:> Die Genauigkeit eines Quarzes (ohne -t-) reicht garantiert für eine> asynchrone serielle Schnitte.
sicher. Irgendwas um die 3% zulässige Toleranz. 1% gemessene Abweichung
bei der Taktfrequenz. Ich habe aber 2avrs, die miteinander kommunizieren
sollen. Klappt manch mal nicht. wenn der eine 1% nach oben und der
andere 1% nach unten geht kommt man schon nahe an die 3%. Dazu kommt die
Ungenauigkeit, weil die cpu-Frequenz kein Vielfaches der Baudrate ist.
Lothar M. schrieb:> RTC exakt zu 100% genau wäre
Eine Rtc, die bei einer Stunde Messdauer eine Abweichung von 1sec hat,
sollte man fachgerecht entsorgen (schwarze Tonne). Spielt im Prinzip
auch keine Rolle ob die Abweichung 36 oder 35 sec pro Stunde ist. Wenn
ich die Abweichung kompensiere wird es auf jeden Fall genauer.
Moin,
Karl K. schrieb:> Ich habe aber 2avrs, die miteinander kommunizieren> sollen. Klappt manch mal nicht.
Da liegt der Hund sicher woanders begraben, bzw. der Hase im Pfeffer.
Nicht bei den Quarzen.
Gruss
WK
Karl K. schrieb:> Irgendwas um die 3% zulässige Toleranz. 1% gemessene Abweichung> bei der Taktfrequenz. Ich habe aber 2avrs, die miteinander kommunizieren> sollen. Klappt manch mal nicht. wenn der eine 1% nach oben und der> andere 1% nach unten geht kommt man schon nahe an die 3%. Dazu kommt die> Ungenauigkeit, weil die cpu-Frequenz kein Vielfaches der Baudrate ist.
Ein Prozent nach unten und ein Prozent nach oben ergibt überschlägig
rund zwei Prozent Differenz. Das geht noch, aber zur Sicherheit kannst
du ja eine sieben Bit Übertragung nehmen, da hast du dann noch etwas
Spielraum. ;-)
Karl K. schrieb:> wenn der eine 1% nach oben und der> andere 1% nach unten geht
Kein Quarz weicht um 1% von seiner Nennfrequenz ab. Wenn doch, ist das
Ausschussware oder falsch bedruckt.
Matthias S. schrieb:> Kein Quarz weicht um 1% von seiner Nennfrequenz ab. Wenn doch, ist das> Ausschussware.
Da gebe ich dir Recht. Allerdings hatte ich mit keinem Wort
vorausgesetzt, dass wir hier von Quarzen reden. Es ging alleinig um
Abweichungen des Taktes. Ob der nun von einem Quarz oder einem
Abreißkalender kommt…
Karl K. schrieb:> Lothar M. schrieb:>> Die Genauigkeit eines Quarzes (ohne -t-) reicht garantiert für eine>> asynchrone serielle Schnitte.>> sicher. Irgendwas um die 3% zulässige Toleranz. 1% gemessene Abweichung> bei der Taktfrequenz.
Naja. Eher "gemessen". Ich glaube das nicht. Bin da eher bei Lothar, der
einen off-by-one Fehler vermutet.
> Ich habe aber 2avrs, die miteinander kommunizieren> sollen. Klappt manch mal nicht. wenn der eine 1% nach oben und der> andere 1% nach unten geht kommt man schon nahe an die 3%.
Nein. Man kommt auf ganz knapp über 2%. Und da ist immer noch reichlich
Luft. Deine Kommunikationsfehler liegen zu 99% nicht am Takt.
> Dazu kommt die> Ungenauigkeit, weil die cpu-Frequenz kein Vielfaches der Baudrate ist.
Wenn das wie zu vermuten ist zwei Arduino nanos sind, dann gleicht sich
dieser Fehler sogar aus.
>> RTC exakt zu 100% genau wäre>> Eine Rtc, die bei einer Stunde Messdauer eine Abweichung von 1sec hat,> sollte man fachgerecht entsorgen
Trotzdem wissen wir immer noch nicht, ob du die Genauigkeit deiner RTC
nun unabhängig gemessen hast. Oder ob du diese Genauigkeit nur
postulierst. Wenn deine RTC nicht mit dem µC-Quarz übereinstimmt, ist
erstmal nicht sicher, wer von beiden falsch liegt.
Axel S. schrieb:> Genauigkeit deiner RTC
//kk_ds1307_setDate(12,1,25);
//kk_ds1307_setTime(15,47,00);
Am 12.1. nach PC-Zeit gestellt. Stand jetzt: Im Minutenbereich keine
Abweichung. => die RTC ist ausreichend genau.
Matthias S. schrieb:> Kein Quarz weicht um 1% von seiner Nennfrequenz ab. Wenn doch, ist das> Ausschussware oder falsch bedruckt.
Weiterhin: Resonator, nicht Quarz.
Sicherlich weicht ein Resonator weiter ab, als ein Quarz.
(zumindest sollte/müsste/könnte das so sein)
Aber bei Zehntausend ppm ist man damit immer noch nicht.
Hallo,
Karl K. schrieb:> Ich habe aber 2avrs, die miteinander kommunizieren> sollen.
und
Karl K. schrieb:> Dazu kommt die Ungenauigkeit, weil die cpu-Frequenz> kein Vielfaches der Baudrate ist.
Wenn beide AVRs die gleiche Taktfrequenz haben, spielt es keine Rolle ob
die Taktfrequenz ein Vielfaches der Baudrate ist.
rhf
Karl K. schrieb:> Am 12.1. nach PC-Zeit gestellt. Stand jetzt: Im Minutenbereich keine> Abweichung. => die RTC ist ausreichend genau.
So ein Quatsch!
Hast Du Dir mal angesehen, wie der interne Oszillator mit der Temperatur
driftet? Dagegen ist die Netzfrequenz schon hochstabil.
Axel S. schrieb:>> Ich habe aber 2avrs, die miteinander kommunizieren>> sollen. Klappt manch mal nicht. wenn der eine 1% nach oben und der>> andere 1% nach unten geht kommt man schon nahe an die 3%.>> Nein. Man kommt auf ganz knapp über 2%. Und da ist immer noch reichlich> Luft. Deine Kommunikationsfehler liegen zu 99% nicht am Takt.
Die Atmega habe ich als recht zickig in Erinnerung. 3% Abweichung hatten
die nie toleriert. Da ich eine Kiste voller Quarze habe ..., würde ich
diese sogar verschenken.
Das Problem des TO habe ich immer noch nicht verstanden. Selbst mit
Abgleich des internen 8 MHz Taktes ist eine stabile UART-Verbindung
nicht sicher.
Karl K. schrieb:> Ich versuche die Genauigkeit von F_CPU - M328p - zu bestimmen und> irgendwie abzuspeichern.
F_CPU steht im Quellcode oder in den Compilervariablen.
Speichere den Wert in einem Headerfile auf deiner SSD.
> Die Frage ist, ob der Rückschluss des Messwerts der Timerfrequenz auf> den realen Takt des Quarzes so richtig ist. Es geht mir im Prinzip nur> um eine Verbesserung der Genauigkeit der baudrate.
Wenn es dir nur darum geht, dann kannst du dich einfach auf die remote
Datenrate synchronisieren und OSCCAL entsprechend setzen.
Entweder du machst das einmalig und speicherst den Wert oder du kannst
das im Prinzip auch dauerhaft im Hintergrund machen.
Ich habe den Wert damals fest im Bootloader gesetzt, das hatte den
Vorteil, dass die Applikationen nichts tun mussten.
Hier findest du ein Beispiel wo ich sowas mal gemacht habe:
https://github.com/nospam2000/Arduino-BlueController/tree/master/bluecontroller/examples/Calibrate_BlueController_OSCCAL_by_UART
Michael
Michael D. schrieb:>> Die Frage ist, ob der Rückschluss des Messwerts der Timerfrequenz auf>> den realen Takt des Quarzes so richtig ist. Es geht mir im Prinzip nur>> um eine Verbesserung der Genauigkeit der baudrate.>> Wenn es dir nur darum geht, dann kannst du dich einfach auf die remote> Datenrate synchronisieren und OSCCAL entsprechend setzen.
Der Hersteller hat dankenswerterweise schon entsprechende
Kalibrationswerte hinterlegt (genaueres steht im Datenblatt). Wenn die
Betriebsspannung konstant ist, reicht einmaliges kalibrieren (bzw. die
Factory-Kalibrierung) aus. Andernfalls nimmt man halt einen Quarz oder
Keramikresonator.
Die ±1% für stabilen UART-Betrieb kriegt man so allemal hin.
Wenn der TO Probleme mit dem UART hat, liegt es fast sicher nicht daran.
Aber es ist halt einfacher, den schwarzen Peter jemand anderem
zuzuschieben. Daß er keine weiteren Details zu seinem eigentlichen
Problem hier preisgibt, wird schon seine Gründe haben ...
Mein Gefühl sagt mir: Der Fehler liegt woanders
Wenn Du Quarze verwendest, die etwas mehr als 1 Cent pro Stück wert sind
und nicht aus der Ausschusstonne stammen sollte es auch immer klappen.
Das serielle Protokoll ist ja selbst-synchronisierend und beginnt bei
JEDEM Datum mit dem Startbit. Dann muss es nur noch die nächsten paar
Bit des aktuellen Datums "durchhalten". Schon das nächste Datum wird mit
dem zugehörigen Startbit resynchronisiert.
Geht das nicht, so ist entweder echter Schrott eingebaut; ein billiger
Resonator drinnen; Deine Teilerfaktorberechnung daneben; die Treiber-ICs
Schrott; ein Problem mit dem "0"-Potential vorhanden.
Ein weiterer Punkt wäre eine Unterbrechung die Dir das Timing versaut
oder eine kräftige Einsteuung.
Ich kenne jedenfalls keine Probleme im Bereich bis 115K Baud mit den
Prozessoren.
Man kann allerdings durch differierende Paritäten und knausrige
Stopp-Bit-Anzahl etwas durcheinanderbringen. Das sieht man oft im Oszi
nicht.
Axel S. schrieb:> Die ±1% für stabilen UART-Betrieb kriegt man so allemal hin.
Oftmals ist das Problem beim UART, dass die gewünschte bps-Rate von der
tatsächlichen stark abweicht, vor allem wenn man die Teiler-Werte bei
der Berechnung nicht korrekt rundet (siehe hier:
https://github.com/nospam2000/ch341-baudrate-calculation?tab=readme-ov-file#rounding-issues).
Beim ATMega328 ergeben sich folgende prinzipellen Abweichungen von der
nominalen bps-Rate laut Tabelle "Examples of UBRRn Settings for Commonly
Used Oscillator Frequencies" aus dem Datenblatt von Atmel:
8 MHz U2Xn=0 UBRRn=12, 38400 bps, Abweichung 0,2%
8 MHz U2Xn=1 UBRRn=25, 38400 bps, Abweichung 0,2%
8 MHz U2Xn=0 UBRRn=3, 115200 bps, Abweichung 8,5%
8 MHz U2Xn=1 UBRRn=8, 115200 bps, Abweichung -3,5%
16 MHz U2Xn=0 UBRRn=8, 115200 bps, Abweichung -3,5%
16 MHz U2Xn=1 UBRRn=16, 115200 bps, Abweichung 2,1%
Solange man auf beiden Seiten diesselbe MCU hat und bei gleicher
Berechnung der Teiler dann dieselbe reale bps-Rate mit dem gleichen
Fehler hat, dann hast du vollkommen recht.
Mit der von mir beschriebenen Methode passt sich die eine Seite an die
andere an. Es geht nicht darum die MCU Taktfrequenz genau auf 8 MHz zu
trimmen sondern die UART Taktrate an die gegnerische Baudrate
anzupassen.
Damit kann man dann auch 115200 bps bei 8 MHz F_CPU mit sehr kleiner
Abweichung betreiben, die reale F_CPU list dann natürlich nicht mehr 8
MHz sondern eher 8 MHz + 3,5% (genauer: 8 / 0.965 = 8.29 MHz) um die
fehlerhafte bps-Rate auszugleichen. Das ist dann sogar genauer als es
mit einem nicht-Baudraten-Quarz möglich wäre. Das muss bei Timing
Berechnungen berücksichtigt werden.
Mit den 8,5% bzw. -3,5% Abweichung kannst du eine serielle Übertragung
nicht stabil betreiben falls der Kommunikationspartner die bps-Rate
exakt einhalten würde. Im DaBla wird empfohlen die Abweichung kleiner
als 1,5% zu halten.
Bei meiner Anwendung lief der Bluecontroller über ein Bluetooth Modul
und damit war es mir möglich den Bootloader über Bluetooth mit 115200
bps stabil zu betrieben bei 8 MHz und unter Verwendung des internen
Oszillators.
Tatsächlich hat der Linux Kernel Fix für den CH341 der die bps-Raten
genauer berechnet in der Realität für Probleme gesorgt. Hier war die
Abhilfe ähnlich, man verwendet als nominelle Baudrate auf der Linux
Seite einfach die reale Baudrate des ATMega328 und nicht die nominelle.
Man sollte die auf vielfachen von 300 bps basierten Baudraten endlich in
den verdienten Ruhestand schicken und z.B. 125000 und 250000 als
Baudrate verwenden, die sich durch Teilung exakt aus den typischerweise
verwendeten Quarzen ableiten lassen.
Michael
Meine Erfahrung mit ATMegas und UART ohne Quarz war bislang immer
Schiffbruch. Ich würde den Arduino auf einen Baudratenquarz umlöten, das
erspart eine Menge Ärger. Alternativ glatte 250kbit probieren, das
sollte mit den "glatten" Quarzen erreichbar sein.
Karl K. schrieb:> Ich versuche die Genauigkeit von F_CPU - M328p - zu bestimmen
Die F_CPU ist ein Wert in der Software und deshalb genau so genau, wie
du sie im Header definierst. Wenn das ein Integerwert ist, dann ist der
völlig abweichungsfrei, weil keine Rundungsfehler möglich sind.
Karl K. schrieb:> Ich verwende arduino nanos ... die haben einen 16MHz-Quartz.
Wenn du sowieso einen Quarz als Taktgeber für die Baudratenerzeugung
verwendest, dann bringt das Herumschrauben am OSCCAL rein überhaupt
nichts, denn das wirkt nur beim internen RC-Oszillator.
Karl K. schrieb:> Eine Rtc, die bei einer Stunde Messdauer eine Abweichung von 1sec hat,> sollte man fachgerecht entsorgen
Richtig. Aber wie gesagt: warum traust du dem Quarz der RTC mehr als dem
Quarz, den du an deinen µC angelötet hast? Denn wenn du einen Quarz
hast, der 10000 ppm Abweichung hat, dann kannst du den gleich mit
entsorgen.
1% Taktabweichung kann jedes Oszilloskop messen. Und das wäre dann
auch mein allererster Ansatz. Einfach mal ein Bitmuster wie 0xAA oder
0x55 senden und die Bitzeit ausmessen, dann spart man sich die Raterei:
-
https://electronics.stackexchange.com/questions/328748/can-we-calculate-the-baud-rate-of-rs232-communication-from-the-tx-output-signal
Wenn da tatsächlich 2 Quarze in RTC und am µC verwendet werden, dann
tippe ich nach wie vor auf einen SW-Fehler.
Ich hab meine auf 7373MHz/922kHz 'ge-osccalt' Damit arbeiten sie sauber
die Standart Baudraten im normalem Temperaturbereich (-10/+40°). Jedoch
bei einem Spannungssprung sollten sie angepasst werden. Bei 3,3V den 5V
Osccal Wert +2, bzw bei einer LiOn 3,5V-4,2V +1.
Bei einem Quarz/Resonator hilft das Osccal nicht, die sind aber
gewöhnlich genau genug. Nur das man damit keine richtigen Baudraten
trifft. Bei 9600 passt das noch gut. Aber die 115,2 sind ca 117,6 bei 16
Mhz oder 111 bei 8Mhz. Am PC kann dem CH340 gesagt werden das er eben
mit 117/111 sprechen soll und untereinander stimmt es ja sowieso. Es sei
denn der Quarz/Resonator hat 'nen Schuss'
Da war Lothar m. schneller. Messen ist generell eine gute Idee. Mir
begegnen Quarze deren Wert erheblich von aufgedrucktem abweicht. Bisher
hab ich das als 'zu billig gekauft' verbucht. Aber vielleicht kommt das
doch öfter vor?
Michael D. schrieb:> Man sollte die auf vielfachen von 300 bps basierten Baudraten endlich in> den verdienten Ruhestand schicken und z.B. 125000 und 250000 als> Baudrate verwenden, die sich durch Teilung exakt aus den typischerweise> verwendeten Quarzen ableiten lassen.
Jeder auch nur halbwegs erwachsene µC bietet mittlerweile die
Möglichkeit der fraktionellen Teilung des Taktes. Damit erübrigt sich
das ängstliche Berechnen der eventuellen Abweichungen, denn man liegt
dann zB. bei 115177 statt 115200 Baud. Entspricht einer 200ppm
Abweichung bei zB. 48MHz und 6bit fraktionalem Teileranteil.
Norbert schrieb:> Jeder auch nur halbwegs erwachsene µC bietet mittlerweile die> Möglichkeit der fraktionellen Teilung des Taktes.
Das ist hier kein gutes Argument, da der TO dem ATmega328P verwenden
möchte. Sein Fehler ist es, den internen RC-Oszillator verwenden zu
wollen, was bei neueren Controllern aber auch kein Problem wäre.
ATmega habe ich bevorzugt mit 18,432 MHz betrieben. Das war immer ein
guter Kompromiß für hohe Geschwindigkeit sowie hohe und 'saubere'
Baudraten.
Mi N. schrieb:> Das ist hier kein gutes Argument, da der TO dem ATmega328P verwenden> möchte.
Meine Antwort bezog sich auch auf die zitierte Aussage von Michael.
Nicht explizit auf den speziellen µC.
Michael D. schrieb:> Mit den 8,5% bzw. -3,5% Abweichung kannst du eine serielle Übertragung> nicht stabil betreiben
Ja, dann sitzt das Problem aber vor der Tastatur. Wenn man eine
bestimmte Baudrate treffen muß und keinen fraktionalen Teiler dafür hat
(wie im AVR) dann muß man halt einen Baudratenquarz verbauen.
Z.B. 7.3728 MHz statt 8.0 MHz. Kostet nicht mehr und ist auch nicht
größer. Man muß sich nur diesen Gedanken wenigstens einmal machen.
Mi N. schrieb:> Sein Fehler ist es, den internen RC-Oszillator verwenden zu> wollen,
Das sehe ich nicht, in diesem Thread.
Ihm möchte F_CPU ins EEPROM stopfen.
(Wie sinnfrei das auch scheinen mag)
Wie gesagt:
Ich sehe hier viele lustige Annahmen, aber wenig Fakten.
Dazu:
> internen RC-Oszillator
Dazu muss der ATMega umgefust werden.
Dann kann man auch den Resonator ablöten und einen beliebigen/passenden
Quarz Oszillator dran fickeln, z.B. einen Uhrenquarz.
Auch stellt sich mir die Frage:
Warum kein nackter ATMega328P, wenn einem die Nano Beschaltung sowieso
nicht passt.
Arduino F. schrieb:> Wie gesagt:> Ich sehe hier viele lustige Annahmen, aber wenig Fakten.
nano mit externem 16Mhz Resonator/Quarz(?). Die Messung ist trotzdem
sinnvoll, da ich ja irgendwie die 36sec Abweichung/h bei der im Programm
verwendeten Uhrzeit berücksichtigen muss.
Vielen Dank für die Antworten, auch wenn viele mein Problem nicht ganz
verstanden haben war es trotzdem hilfreich.
Ich stelle mein Projekt jetzt erstmal auf fleury-uart-software um. Damit
müssten dann sw-Fehler ausgeschlossen sein.
Thread beobachten
Seitenaufteilung abschalten