Hallo, ich habe gerade ein Phänomen bei einem ATtiny841 bei dem ich nicht weiter komme. Ich habe eine Elektronik mit einem ATtiny841 und angeschlossenem Quarz. Auf diesen habe ich Optiboot gespielt um Firmwareupgrades über USB (mit FTDI-Brücke) machen zu können. Die RTS Leitung hängt über einen Kondensator am RESET-Pin so dass darüber ein Reset getriggert werden kann. Die letzte Version hatte ein 16 MHz Quarz und damit lief alles wunderbar. Weil ich mit weniger Betriebsspannung auskommen muss, habe ich das ganze System auf 8 MHz umgestellt. Wenn ich dafür die Fuses so einstelle, dass er den Quarz gar nicht nutzt sonderen seinen internen RC-Oszillator funktioniert alles Prima. Wenn ich aber den 8-Mhz Quarz nutze, geht es nicht und ich kriege immer "avrdude.exe: stk500_recv(): programmer is not responding". Der Quarz selbst funktioniert aber, denn wenn ich das Programm über den ISP-Programmer aufspiele geht alles exakt wie mit dem internen Oszillator und auch der UART funktioniert offensichtlich mit der gewünschten Baudrate. Der UART zum FTDI ist übrigens der einzige Grund warum ich bei 8 MHz überhaupt ein Quarz brauche. Bei allem anderen kommt es auf die +/- 2% nicht an. Auch das Optiboot ist das richtige, denn sonst würde es ja mit dem internen 8MHz R/C Oszillator auch nicht funktionieren. Hat irgend jemand eine Idee was das sein könnte? Ich habe auch schon an den Fuses mit den Startup-Zeiten rumgespielt. Wobei die laut Datenblatt nur die Power-Down Startup-Zeit beeinflussen und ich habe es ja mit einem Externen Reset zu tun.
Zeig mal alle aktuellen Fuse settings (nicht in Prosa).
Philipp M. schrieb: > Wenn ich dafür die Fuses so einstelle, dass er den Quarz gar nicht nutzt > sonderen seinen internen RC-Oszillator funktioniert alles Prima. Wenn > ich aber den 8-Mhz Quarz nutze, geht es nicht Eventuell "external clock" anstelle von "external crystal" eingestellt? LG, Sebastian
Die Einstellung die geht ist: LowFuse: 0xE2 (Interner RC 8MHz ohne CLKDIV) HighFuse: 0xDF (nur SPIEN) ExtFuse: 0x00 Was nicht geht ist wenn ich in der LowFuse z.B. 0xEE eintrage was für Crystal Oscillator > 8MHz steht. Auch 0xEC (Crystal Oscillator 3-8 MHz) geht nicht. Wie gesagt der Quarz und die Einstellungen tun prinzipiell weil das Programm damit läuft und auch das richtige Timing hat.
0 bei ext fuse ist fast überall "Reserved"
Läuft denn der Prozessor prinzipiell mit dem 8MHz-Quarz? Oliver
Oliver S. schrieb: > Läuft denn der Prozessor prinzipiell mit dem 8MHz-Quarz? Philipp M. schrieb: > Der Quarz selbst funktioniert aber, denn wenn ich das Programm über den > ISP-Programmer aufspiele geht alles exakt wie mit dem internen > Oszillator und auch der UART funktioniert offensichtlich mit der > gewünschten Baudrate.
>>0 bei ext fuse ist fast überall "Reserved" Ist mir auch aufgefallen. Habe gerade 0xFE probiert (alles aus außer SELFPGM) und das macht keinen Unterschied. >>Läuft denn der Prozessor prinzipiell mit dem 8MHz-Quarz? Wie gesagt problemlos. Wenn ich das Programm aufgespielt habe (Bootloader oder ISP). Kann ich durch 0xEC in der LowFuse auf den Quarz umschalten und alles funktioniert prima.
Philipp M. schrieb: > Was nicht geht ist wenn ich in der LowFuse z.B. 0xEE eintrage was für > Crystal Oscillator > 8MHz steht. Im meinen Unterlagen steht nix von Crystal bei 0xFE. Da steht Ceramic Resonator Philipp M. schrieb: > Kann ich durch 0xEC Jetzt plötzlich EC ? Aber der ist auch ein Ceramic Resonator.
:
Bearbeitet durch User
Das 0xFE bezog sich auf die EXT Fuse (Weil 0x00 ein paar Reserved Zustände bei den Brown-Out-Konfigs enthielt). Ich habe bei der LowFuse 0xEC und 0xEE probiert und bei beiden steht im Datenblatt: "Crystal Oscillator / Ceramic Resonator". Ist also für beides. Einmal 3-8Mhz und einmal >8Mhz. Da 8Mhz genau an der Grenze liegt habe ich beides probiert. Mit beidem läuft der Chip prinzipiell (Programm läuft) aber der Bootloader weigert sich. Ich habe den Takt jetzt auch mal mit dem Oszi direkt am Quarz gemessen (Probe in der 10x Einstellung) und der sieht für mich ok aus. Wie bei anderen µC-Projekten auch.
Hast Du mal versucht die halbe Baudrate einzustellen ("-b57600" bei
avrdude)?
Der Bootloader kann ja ohne neu kompilieren nicht wissen das da ein 8MHz
Quarz läuft.
:
Bearbeitet durch User
Jim M. schrieb: > Der Bootloader kann ja ohne neu kompilieren nicht wissen das da ein 8MHz > Quarz läuft. Der läuft auch mit 8MHz RC. Darum geht es ja. TO: Also Du stellst nur Low fuse von EE nach E2 und dann geht es wieder?
:
Bearbeitet durch User
>>Also Du stellst nur Low fuse von EE nach E2 und dann geht es wieder? Genau ich änder nur das und dann läuft es. >>Der Bootloader kann ja ohne neu kompilieren nicht wissen das da ein 8MHz Quarz läuft. Ich habe schon den korrekten 8 MHz Bootloader benutzt. Ich habe den von hier:https://github.com/SpenceKonde/arduino-tiny-841/tree/master/avr/bootloaders/optiboot Ich nutze die "optiboot_attiny841at8noLED.hex" und beim 16 MHz System habe ich die "optiboot_attiny841at16noLED.hex". Also nicht selbst neu kompiliert aber den passenden Vorcompilierten genommen. Bei grundsätzlichen Probleme in meinem Aufbau müssten meiner ansicht nach weder mit interner RC noch Quarz tun. Bei Problemen mit dem Quarz dürfte das Programm auch nach dem Aufspielen mit dem ISP-Programmer nicht gehen. >>Hast Du mal versucht die halbe Baudrate einzustellen ("-b57600" bei avrdude)? Hab ich jetzt auch mal gemacht - kein Erfolg.
> Der Quarz selbst funktioniert ... und auch der UART funktioniert > offensichtlich mit der gewünschten Baudrate ... Wie hoch ist die Baudrate, und wird sie mit U2Xn erreicht?
0xEE müsste eigentlich schon passen... siehe zum Beispiel https://github.com/SpenceKonde/ATTinyCore/blob/c0b7e78f750111bbfeeb36088ef9be3d5728a927/avr/boards.txt#L1724C1-L1724C58 Baudrate sollte sowieso 57600 sein, siehe https://github.com/SpenceKonde/arduino-tiny-841/blob/64a8b046995fa1b632bf846855cdd32a4c0f1e00/avr/bootloaders/optiboot/Makefile#L427C1-L433C42
:
Bearbeitet durch User
Philipp M. schrieb: > Was nicht geht ist wenn ich in der LowFuse z.B. 0xEE eintrage was für > Crystal Oscillator > 8MHz steht. Auch 0xEC (Crystal Oscillator 3-8 MHz) > geht nicht. Richtig wäre 0xEC oder 0xFC oder 0xED. Geht nix davon, aber der Quarz schwingt nachweislich, ist er gerade so am schwingen. Da fallen immer mal wieder einzelne Takte aus. Sprich: die Bürdekapazitäten passen wohl nicht gut genug. Einen Normwert höher oder tiefer verwenden. Bei einer der beiden Tests wird er wahrscheinlich gar nicht mehr schwingen, beim anderen hingegen stabil laufen. Was du dann daran merkst, dass dann auch die UART-Kommunikation funktioniert.
Der UART in meinem Programm funktioniert einwandfrei. Der läuft aber auch nur 19,200 Baud (ohne U2Xn). Die Kapazitäten sind 22pF. Zumindest sollten die das sein - das Board wurde von JLC-PCB bestückt.
Dann schraub doch mal die Kommunikation in deinem Programm auf 57600 hoch und schau, ob das noch tut
Angehängte Dateien:
-
Baudrate_8MHz.png
53 KB
> Der UART in meinem Programm funktioniert einwandfrei. > Der läuft aber auch nur 19,200 Baud (ohne U2Xn). Ist ja auch problemlos, bei einem Fehler von 0.2 % - aber wie schnell läuft Optiboot?
S. L. schrieb: >> Der UART in meinem Programm funktioniert einwandfrei. >> Der läuft aber auch nur 19,200 Baud (ohne U2Xn). > > Ist ja auch problemlos, bei einem Fehler von 0.2 % - aber wie schnell > läuft Optiboot? Wie ich oben schon geschrieben habe, bei 8MHz mit 57600
Philipp M. schrieb: > Der UART in meinem Programm funktioniert einwandfrei. Der läuft aber > auch nur 19,200 Baud (ohne U2Xn). Ist damit (wegen 16x-Sampling statt nur 8x) auch deutlich fehlertoleranter. Sagt also wenig bis nix aus bezüglich deines Problems. > Die Kapazitäten sind 22pF. Zumindest > sollten die das sein - das Board wurde von JLC-PCB bestückt. So what? 22pf können falsch sein (bzw. hier: gerade so an der Grenze zum geht nicht). Das hängt vom Quarz und den parasitären Kapazitäten ab. Nicht von JCLPCB oder wer immer die Dinger auf's Board genagelt hat.
> Wie ich oben schon geschrieben habe, bei 8MHz mit 57600
Dann ist es eng; und es liegt die Vermutung nahe, dass der Fehler des
internen RC-Oszillators in die richtige Richtung zieht - mit einem
Frequenzzähler wüsste man Genaueres.
Hallo, ich kann leider nichts zum Thema sagen warum das Board mit Quarz Takt nicht funktioniert obwohl es selbst funktioniert. Ich kann aber sagen das ein Quarz nicht zwingend notwendig ist, wenn man den internen RC nachjustiert. Dafür dient das OSCCAL0 Register. Dafür kann man CKOUT vermessen.
Eduard I. schrieb: > Wie ich oben schon geschrieben habe, bei 8MHz mit 57600 Schreib dir ein kleines Testprogramm für den µC das auf 57600 "Hello World" oder sowas sendet. Und dann testest du mit dem Quarz.
Veit D. schrieb: > ich kann leider nichts zum Thema sagen warum das Board mit Quarz Takt > nicht funktioniert obwohl es selbst funktioniert. Ich kann aber sagen > das ein Quarz nicht zwingend notwendig ist, wenn man den internen RC > nachjustiert. Dafür dient das OSCCAL0 Register. Dafür kann man CKOUT > vermessen. Ja, das ist tatsächlich möglich. Geht man aber im Winter mit dem Teil auf die Straße oder grillt im Sommer die liebe Sonne die Wohnung auf 35°C ist Ende Gelände. Ja, kann man auch wieder umgehen, indem man den internen Temperatursensor benutzt, um die Fehlerkompensation auch noch entsprechend der Umgebungstemeparatur zu gestalten. Aber all diese Frickelei tut man sich einfach nur dann an, wenn sehr gute Gründe gegen die Verwendung eines Quarzes sprechen. Und: "ich bin zu doof, ihn vernünftig zum Laufen zu bringen", ist kein sehr guter Grund.
>>Dann schraub doch mal die Kommunikation in deinem Programm auf 57600 hoch und schau, ob das noch tut Guter Hinweis, das tut nicht sonderlich gut. Allerdings weder mit Quarz noch mit RC. Ich habe UBBR=8 ohne U2X=0 (-3,5% Abweichung) und UBBR=16 U2X=1 (2,1% Abweichung) probiert. In beiden Fällen scheint das Senden gut zu gehen (Statusmeldungen kommen immer am PC an) aber das Empfangen macht dem µC wohl Probleme weil er Befehle nicht versteht und auch falsch zurückspiegelt. Aber auch hier habe ich keinen echten Unterschied zwischen Quarz und RC feststellen können. Kann man Optiboot mit weniger Baud nutzen? Also z.B. auch 19200. Weil wenn es wegen der Taktrate prinzipiell nicht ginge gäbe es doch keine Version für 8MHz - oder? Ich benutze dieses Quarz https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2403291504_YXC-X50328MSB2GI_C115962.pdf Da steht tatsächlich als Kondensator 10pF oder 20pF. Ich werde also mal bei einem Board 15pF einlöten und schauen ob das besser läuft.
Hallo, vor einer Temperaturschwankung sollte man keine Angst haben mit internen RC. Ich lasse meine ATtinys 841 über die Serielle automatisch Einjustieren. Als das lief habe ich den ATtiny mit Eis und Fön strapaziert. Es gab keine seriellen Probleme und damit keine weitere Nachjustierung. Oszi hatte ich auch dran, war alles gut. Die Baudrate beträgt 250k. Ich würde generell empfehlen, wenn immer möglich keine krummen Standard Baudraten zu verwenden, sondern Ganzzahlige Vielfache vom µC Takt. Damit ist der Hausgemachte Fehler immer 0,0%. Dann hat man automatisch jede Reserve für die Übertragung bzw. Drift vom RC zur Verfügung.
Philipp M. schrieb: > Aber auch hier habe ich keinen echten Unterschied zwischen Quarz und RC > feststellen können. Spätestens das sollt dir doch definitiv zu denken geben...
>>Spätestens das sollt dir doch definitiv zu denken geben... Wieso in der Theorie sind doch beide 8-Mhz.Takte gleich ungenau. >>Ich lasse meine ATtinys 841 über die Serielle automatisch Einjustieren. Hast du dafür Code? Ich überlege auch die Quarze ganz weg zu lassen und das so zu machen. Eigentlich würde ich ja gerne einen der angekündigten neuen USB-AVRs nehmen dann brauch ich auch keinen FTDI. Der ist der teuerste Chip derzeit. Ich überlege ob ich auf einen der PICs umschwenke die angeblich USB ohne Quarz können.
Philipp M. schrieb: >>>Spätestens das sollt dir doch definitiv zu denken geben... > Wieso in der Theorie sind doch beide 8-Mhz.Takte gleich ungenau. Damit ist die Sache ja wohl endgültig klar: Du bist ein Troll. Alles was gleich ist, ist der systematische Baudratenfehler bei 8MHz Takt. Nur sind diese 8MHz eben entweder einigermaßen genau (bei einem korrekt laufenden 8MHz Quarz) oder eben schrecklich ungenau (bei Verwendung des internen RC-Oszillators). >>>Ich lasse meine ATtinys 841 über die Serielle automatisch > Einjustieren. > Hast du dafür Code? Ich überlege auch die Quarze ganz weg zu lassen und > das so zu machen. Das ist Bullshit. Funktioniert nur dann zuverlässig, wenn das über die serielle Schnittstelle laufende Protokoll den Austausch von Synchronisationsinfos vorsieht. Kritisch ist hier vor allem die Situation der ersten Kontaktaufnahme. Später kann man das locker nebenbei abhandeln und nachjustieren. Ist aber auch nur eine relativ aufwendige Frickel-Lösung. Es ist viel einfacher, einen Quarz als verlässliche Taktbasis zu verwenden. Man muss ihn halt nur als solche laufen lassen. Das ist ja nun wirklich kein Hexenwerk, die Zahl der Freiheitsgrade für Fehler ist doch recht beschränkt...
Hallo, ich denke mit internen RC funktioniert alles? Ich kann das Problem aktuell leider wirklich nicht nachvollziehen. Ich würde erstmal am CKOUT messen was wie wirklich taktet. Oszi haste? Ein Quarz mit etwas schiefen Last-Kondensator taktet dennoch ziemlich genau auf Zielfrequenz. Jedenfalls für die Serielle vollkommen ausreichend genau. Der interne RC vom Attiny841 ist ab Werk für 3,3V eingestellt. Mit 5V taktet er höher. Wegen Einmessen. Man sendet Serial ein 'U' und erzeugt damit ein Taktsignal. Das hat für dich eine bekannte Frequenz bzw. Periodendauer, man kennt ja die Baudrate. Mit einem Timer vermisst du diesen externen Takt und stellst die Abweichung fest, ob dein Timer zu schnell oder zu langsam taktet. Damit ziehst den Rückschluss das dein RC zu langsam oder zu schnell taktet und justierst das OSCCAL0 Register nach. Ich hatte das gemacht weil ich dann doch alle Pins benötigte. Ich konfiguriere nur die USART Pins um, entweder für serielle Übertragung oder zum Einmessen. Bei Fehlerhafter Übertragung gehen beide in den Fehlermodus. Der Master sendet 'U' (mehrere) und der Slave misst sich ein. Nach definierten Einmesszyklen schaltet Master in normale Übertragung um. Wenn okay hat sich der Slave eingemessen und alles läuft. Wenn nicht okay erfolgt neuer Einmesstakt. Ich habe auf gute Defaultwerte verzichtet diese in der Software zu hinterlegen. Es sind bei mir nie mehr wie 7 Counts in der Korrektur. Um ein "festhängen" im Sync Mode zu verhindern, hat der Master noch einen Übertragungsfehlerzähler, er wiederholt die Übertragung paarmal, wenn dann nichts klappt wird neu eingemessen. Danach wird die alte fällige Übertragung nachgeholt. Diesen Fall der nachträglichen Neueinmessung konnte ich bisher aber nur provozieren. Im normalen Betrieb im Kämmerlein kommt es nie dazu. Ich würde an deiner Stelle, wenn ich du wäre, dennoch erstmal wissen wollen was schief läuft. Sonst bauste das nächste Board und wieder geht es nicht wie gewünscht. Es kann ja nicht sein das mit bspw. 9600 Baud gar nichts geht. Also Oszi ran und nachmessen.
Veit D. schrieb: > Ein Quarz mit etwas schiefen Last-Kondensator taktet dennoch ziemlich > genau auf Zielfrequenz. Nein, das ist definitiv nicht so. Der Quarz selber schwingt zwar näherungsweise mit seiner Sollfrequenz, insofern stimmt das. Aber die Oszillatorschaltung "erkennt" nicht mehr jede Schwingung des Quarzes und stellt sie als einen Takt für die daran hängende digitale Elektronik bereit. Mit eine Frequenzzähler an CLKO kann man diese Situation sehr gut und und völlig problemlos nachweisen. der 841 hat diese Möglichkeit. Wenn also PB2 nicht anderweitig verwendet wird, kostet es nur ein kühles Arschrunzeln, das zu beweisen. Einfach die CKOUT-Fuse programmieren und einen Frequenzzähler an PB2 hängen. Fertig. Aber nach allem, was der TO bisher geäußert hat, kann er sich diesen Aufwand aber shr wahrscheinlich sparen. Er sollte statt dessen einfach endlich die verschissenen Bürdekondensatoren tauschen und dieser Thread könnte unmittelbar beendet werden.
Also ich habe mal 15pF rein gelötet. Das Programm lief damit auch aber das Signal am Oszi war eher schwächer von der Amplitude weshalb ich jetzt wieder 22pF drin habe. Wenn ich CKOUT aktiviere und mit dem Oszi nachmesse: R/C: Schwankend zwischen 8,08 MHz und 8,14 MHz Quarz: Konstant 8,00023 Mhz Sollte es wirklich daran liegen, dass man mit 8 Mhz die 56.700 Baud nicht genau genug erreichen kann und die Abweichung des RC Oszillators in dem Fall gerade hilft dann bleibt ja eigentlich nichts anders Übrig als Optiboot irgendwie mit niedrigerer Baudrate zu betreiben. Allerdings müsste das doch dann eigentlich jeden AVR mit Optiboot betreffen. 8 MHz ist jetzt ja auch nicht selten.
Philipp M. schrieb: > R/C: Schwankend zwischen 8,08 MHz und 8,14 MHz Schwankend? OK, er darf einige Prozent daneben stehen... Aber "schwankend"? Nur schwankend mit Temperatur oder Spannungsschwankungen. Abblockkondensatoren vergessen?
:
Bearbeitet durch User
Philipp M. schrieb: > Wenn ich CKOUT aktiviere und mit dem Oszi nachmesse: > R/C: Schwankend zwischen 8,08 MHz und 8,14 MHz > Quarz: Konstant 8,00023 Mhz Das sieht doch schon mal gut aus. > Sollte es wirklich daran liegen, dass man mit 8 Mhz die 56.700 Baud > nicht genau genug erreichen kann Nicht genau genug für die konkrete Gegenstelle, ja. Mit einer anderen könnte das anders aussehen. Die muss halt nur in die Gegenrichtung der Toleranz abdriften. > in dem Fall gerade hilft dann bleibt ja eigentlich nichts anders Übrig > als Optiboot irgendwie mit niedrigerer Baudrate zu betreiben. Nö, nicht unbedingt. Du könntest einfach einen "Baudratenquarz" mit 7,3728 MHz verwenden. Der eleminiert die systematische Abweichung bei Standard-Baudraten und erlaubt deshalb auch weit höhere Baudraten. Oder du könntest einen anderen (neuzeitlicheren) AVR verwenden. Die haben fraktionale Baudratenteiler, mit denen sich der systematische Fehler um den Faktor 64 reduzieren läßt.
Arduino F. schrieb: > Schwankend? > OK, er darf einige Prozent daneben stehen... > > Aber "schwankend"? > Nur schwankend mit Temperatur oder Spannungsschwankungen. Da ist absolut was dran. So Scheiße kann die Frequenzmessung eines Oszi eigentlich garnicht sein, dass da bei konstanten Umweltbedingungen etwas in dem Bereich schwankendes herauskommen könnte. Also (merken): nächster Hinweis auf einen Troll.
Hallo, nimm einmal für alles eine Baudrate von 38400. Die weicht mit 8MHz deutlich geringer vom Sollwert ab. Oder wenn möglich Ganzzahlige Vielfache von 8MHz. Kommt auf deine Gegenstelle an.
:
Bearbeitet durch User
Veit D. schrieb: > nimm einmal für alles eine Baudrate von 38400. Die weicht mit 8MHz > deutlich geringer vom Sollwert ab Genau. Das ist die höchste Standard-Baudrate, bei der Classic-AVRs bei 8Mhz Systemtakt noch einen systematischen Fehler unterhalb dessen produzierenn, was der Standard (und die Physik) als Maximum des Zulässigen vorgeben.
Philipp M. schrieb: > Also ich habe mal 15pF rein gelötet. Das Programm lief damit auch aber > das Signal am Oszi war eher schwächer von der Amplitude weshalb ich > jetzt wieder 22pF drin habe. Interessanter Fall. Die Messung mit dem Oszi erhöht die Bürde um die Meßspitzenkapazität. Das ist besonders am Oszillatoreingang nicht unkritisch. Wie sieht das Platinenlayout zwischen Kristall und Attiny841 aus? Wieviel pF Bürde liefern die Leiterbahnen schon? Ich sehe auch, dass der Quarz kein Metallgehäuse hat, und also auch keinen GND-Anschluß. Sind solche Kristalle eventuell empfindlicher gegen Einkopplung von Störungen? LG. Sebastian
:
Bearbeitet durch User
Warum das Schwankt weiß ich auch nicht, aber das Ozi zeigt es an.
Eventuell trifft der Trigger einfach nicht. Das Signal ist auch kein
schönes Sinus-Signal was aber vermutlich auch daran liegt, dass der
CKOUT Pin bei mir nicht frei ist sondern eine Last dran hat. Der Steuert
eigentlich eine Halbbrücke an die da noch dran hängt.
>>nimm einmal für alles eine Baudrate von 38400. Die weicht mit 8MHz
deutlich geringer vom Sollwert ab.
Genau das war jetzt meine letzte Hoffnung. 19200 ist ja genauso gut was
die Abweichung angeht. Ich hatte nur gehofft Optiboot eben nicht selbst
kompilieren zu müssen. Das Optiboot was ich nutzte behauptet ja bei 8
MHz zu gehen und da bin ich mit 8,00023 doch gut genug dran.
Hallo allerseits, ich glaube das Problem gelöst zu haben: Es war wie vermutet die schlecht passende Baudrate die sich mit 8MHz einfach nicht gut erreichen lässt. Das ganze ist wohl bekannt weil ich auf GitHub folgendes gefunden habe: https://github.com/SpenceKonde/ATTinyCore/tree/v2.0.0-devThis-is-the-head-submit-PRs-against-this Moneyqote: "The baud rates used for uploading in 1.x were chosen poorly. 57600 baud at 8 MHz - and 115200 baud at 16 MHz - already has 2% baud rate error before accounting for any oscillator error - and it's in the direction that makes the most common oscillator error with the 841, 1634, and 828 worse rather than counteracting it. Those baud rates were not appropriate - they increased the chance that an internal oscillator would be too far off of the nominal frequency for serial communication, and this posed repeated headaches for users." Auf Deutsch: Die gewählten Baudraten von 115200/57600 sind für 16MHz/8Mhz wegen der großen Abweichung schlecht geeignet. Die neue Version von deren Core-Framework nutzt daher bei 8 MHz ein Optiboot mit einer Baudrate von 76800. Ich musste auch nichts selbst kompilieren denn die haben da eine gute Auswahl an Vorkompiliertem: https://github.com/SpenceKonde/ATTinyCore/tree/v2.0.0-devThis-is-the-head-submit-PRs-against-this/avr/bootloaders/optiboot/hex Ich habe mich da für die "optiboot_attiny841_8000000UL.hex" entschieden und mir der geht es wenn ich im AVRDudeDess "76800" im Baudraten Feld einfüge. Wenn jemand weiß was die anderen Varianten machen wäre das interessant. *ser1.hex nutzt vermutlich den anderen UART(1). aber was "*serR*" macht und _int weiß ich nicht. Auch nicht was "*8sec" bedeutet. Vermutlich verweilt er länger im Bootloader aber wissen tue ich es nicht. Auf der Seite habe ich kein Kommentar dazu gefunden. Warum bin ich nicht früher drauf gekommen? Weil ich ursprünglich den Bootloader von hier habe: https://github.com/SpenceKonde/arduino-tiny-841/tree/master/avr/bootloaders/optiboot Die Dateien da sind 9 Jahre alt und auf der Master-Seite von dem Repository steht dass das inzwischen mit dem ATTiny-Core zusammengelegt wurde. Und nur dort wurde die Änderung auf die andere Baudrate gemacht. Die Hex-Dateien da sind auch nur 2 jahre alt. Ich habe insgesammt 15 von den Boards und werde wenn die alle verbaut sind berichten ob der neue Bootloader bei allen funktioniert. Danke an die Community für die Ideen.
Philipp M. schrieb: > Wenn jemand weiß was die anderen Varianten machen wäre das interessant. > *ser1.hex nutzt vermutlich den anderen UART(1). aber was "*serR*" macht > und _int weiß ich nicht. Auch nicht was "*8sec" bedeutet. Vermutlich > verweilt er länger im Bootloader aber wissen tue ich es nicht. Auf der > Seite habe ich kein Kommentar dazu gefunden. IIRC stehen die 8sec für den Watchdog auf 8 Sekunden. Zu den anderen beiden weiss ich leider auch nix.
Philipp M. schrieb: > Auf Deutsch: Die gewählten Baudraten von 115200/57600 sind für > 16MHz/8Mhz wegen der großen Abweichung schlecht geeignet. Anders formuliert: diese Frequenzen sind für die Standard-Baudraten schlecht geeignet. https://en.wikipedia.org/wiki/Crystal_oscillator_frequencies
> R/C: Schwankend zwischen 8,08 MHz und 8,14 MHz > Warum das Schwankt weiß ich auch nicht ... Ich halte das für normal, mit rund 0.7 %. Eine schnelle Messung an einem ATtiny84A zeigt hier auch eine Schwankung von 0.5 % (Abblockkondensator direkt an die Versorgungsanschlüsse gelötet).
S. L. schrieb: > Ich halte das für normal, mit rund 0.7 %. Ist es definitiv nicht. > Eine schnelle Messung an einem > ATtiny84A zeigt hier auch eine Schwankung von 0.5 % (Abblockkondensator > direkt an die Versorgungsanschlüsse gelötet). Und der bypass war sicher OK? Und die Versorgung sicher hinreichend niederohmig? Und keiner der GPIOs aktiv und gegen GND oder VDD kurzgeschlossen? Weil: auch 0,5% ist noch mindestens eine Größenordnung zu viel.
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.