Hallo zusammen, ich bräuchte mal bitte eure Hilfe bei einem Projekt. Habe einen ATmega328P-PU mit einem Arduino Bootloader gebrannt. (Die Breadboard 8Mhz Variante) Hat auch soweit funktioniert und der Chip macht, was er soll. Ich hab allerdings ein Problem mit der seriellen Schnittstelle. Ich kann den Chip mit internem 8Mhz Takt nicht mit UART ansprechen. Der Chip reagiert überhaupt nicht. Mein erster Gedanke war, dass mit den 8Mhz die Standard-Baudrate (Uno Bootloader standardmäßig bei 115200) nicht mehr funktioniert. Hab ein Weilchen rumprobiert, andere Baudraten gehen aber leider auch nicht. (Falls die 8Mhz Bootloader-Variante eine andere Baudrate hätte) Habe daraufhin den Chip umgefused auf externe Clock. Mit 16Mhz Oszillator funktioniert die Kommunikation mit 115200 ohne irgendwelche anderen Softwareänderungen problemlos. Gegencheck: Zurückgestellt auf 8Mhz internal Clock -> keine Reaktion über UART. Jetzt meine Frage, wie ich den Chip dazu bekomme auch mit 8Mhz eine serielle Kommunikation zuwege zu bringen. (Brauche die Taktpins, also externer Takt ist keine Alternative) Ich nehme an, mit 8Mhz (der interne Takt soll ja auch relativ ungenau sein) schafft der einfach nicht die Standard-Baudrate von 115200. Aber wie kann ich das ändern? Geht das im Bootloader? Und wenn ja, wie? Die Baudrate ist mir fast egal, kann auch eine 1200er sein, da hab ich keine Ansprüche. Das sollte dann ja auch mit 8Mhz funktionieren. Danke schon mal:)
Hallo Hugo 0x0B, gezielt zu Deinem Problem kann ich wegen mangelnder Kenntnis des verwendeten Cotrollers nichts sagen. Was aber generell gilt ist, dass die interne Taktrate (in Deinem Fall die 8MHz) zum Einen nicht besonders stabil und zum Anderen nicht passend zu den typischen Baudraten ist. Empfehlung ist hier definitiv einen ext. Quarz zu nehmen (siehe Atmel Handbuch Deines Controllers) der mit möglichst wenig/keinem Fehler zu der später verwendete Baudrate passt. Typisch ist hier in aller Regel ein 14.7456MHz Quarz Gruß Christian
Hugo0x0B schrieb: > Brauche die Taktpins, also > externer Takt ist keine Alternative Dann lässt du das mit dem UART besser sein. Mit dem internen Takt gibt das nur ständigen Ärger. Georg
Hi Bei 8MHz bekommt man bei 115200Bd einen Baudratenfehler von 8,5%. Damit bekommst du keine Kommunikation hin. MfG Spess
Der Arduino Bootloader ist natürlich auf die Konfiguration mit dem 16MHz Quarz konfiguriert. Wenn du jetzt mit 8Mhz taktest, ohne etwas umzuschreiben, ist die Baudrate nur halb so hoch. Du könntest also mit 57600 Baud Erfolg haben. So schlecht ist der interne Oszillator auch nicht, funktioniert aber mit niedrigen Baudraten deutlich besser als nun gerade mit den hohen. Am besten schreibst du den Bootloader also um.
:
Bearbeitet durch User
Hugo0x0B schrieb: > Jetzt meine Frage, wie ich den Chip dazu bekomme auch mit 8Mhz eine > serielle Kommunikation zuwege zu bringen. (Brauche die Taktpins, also > externer Takt ist keine Alternative) > Ich nehme an, mit 8Mhz (der interne Takt soll ja auch relativ ungenau > sein) schafft der einfach nicht die Standard-Baudrate von 115200. klaro 1. wegen der ungenauen internen 8MHz 2. weil bei 8MHz der Fehler rechnerisch zu groß wird, Baudraten Rechner http://www.gjlay.de/helferlein/avr-uart-rechner.html 16MHz je nach U2X Einstellung 115.2k -3.5% 2.1% (geht vielleicht deswegen noch) 8MHz je nach U2X Einstellung 115.2k 8.5% -3.5% (sieht absolut raus aus) kannst du deinen Atmel nicht intern trimmen? http://www.atmel.com/images/doc2555.pdf und dabei gleich den geringsten Baudratenfehler einbauen, also die F_CPU auf irgendwas ungleich 8MHz trimmen 7.3728 Mhz 9.216 Mhz
:
Bearbeitet durch User
Georg schrieb: > Mit dem internen Takt gibt das nur ständigen Ärger. Das stimmt so nicht. Unter Bürobedingungen (konstante Versorgungsspannungen und einigermaßen stabile Temperatur) genügt der durchaus für die einfachen Anforderungen, die eine RS-232 so stellt. Die Schwankungen dürfen ja nur nicht so groß werden, dass nach den 10 Bit dann mehr als die Hälfte der Bitzeit Versatz aufgelaufen ist; mit dem nächsten Startbit synchronisieren sich beide Partner ohnehin neu. Matthias Sch. schrieb: > funktioniert aber mit niedrigen Baudraten deutlich besser als nun gerade > mit den hohen. Mit der Höhe der Baudrate selbst hat das gar nicht so viel zu tun: der Fehler darf 2 % sein, völlig unabhängig von der Höhe der Baudrate. Allerdings lassen sich die „krummen“ typischen Baudratenwerte aus den glatten 8 MHz halt immer nur mit einem systematischen Fehler erzeugen, der sich zu den Frequenzschwankungen des Oszillators addiert. Daher kommt man bei 8 MHz nur sinnvoll bis 38400 Bd. Was jedoch völlig problemlos geht ist, entweder den Oszillator per OSCCAL auf 7,37 MHz zu ziehen (der Wert liegt im garantierten Ziehbereich), oder aber mit einer Baudrate von 500 kbit/s oder 1 Mbit/s zu arbeiten, die beispielsweise ein FT232 als Gegenstelle akzeptiert.
:
Bearbeitet durch Moderator
Jörg Wunsch schrieb: > Was jedoch völlig problemlos geht ist, entweder den Oszillator per > OSCCAL auf 7,37 MHz zu ziehen (der Wert liegt im garantierten > Ziehbereich), oder aber mit einer Baudrate von 500 kbit/s oder 1 Mbit/s > zu arbeiten, cool wusste ich nicht, damit könnte man mit Optiboot arbeiten bei 1M dachte ich ... aber widerspricht 1M nicht baud 1/16 von F_CPU? wobei 500k auch nett ist zum Programmieren aber beim 328 mit nur 32k flash eher weniger nötig als beim 1284p oder 2560
Joachim B. schrieb: > aber widerspricht 1M nicht baud 1/16 von F_CPU? 1MBit entspricht 1/8 bei gesetzem U2X-Bit. mfg.
Wow, so eine schnelle Reaktion habe ich garnicht erwartet^^ Die 115200 brauche ich auch absolut nicht. Mir würde auch 9600 oder sogar 1200 reichen. Laut dem verlinkten Rechner läge der Fehler bei 0,2 bzw. -0,1% (@8Mhz). Ich bin kein UART-Spezialist, klingt für mich aber sehr akzeptabel. Die 115200 habe ich nur benutzt, weils die Standardeinstellung ist und ich nicht weiß, wie ich das ändern soll^^ Bootloader ist Neuland für mich. Ich hab da nen Quellcode gefunden. https://code.google.com/p/arduino/source/browse/tags/0005/bootloader/ATmegaBOOT.c Kann aber nicht wirklich beurteilen, ob das der Uno-Bootloader ist. Bzw. ob ich den für meinen ATmega328p nutzen kann. Da ist auch eine Baudrate von 9600 definiert (Z.46) wenn ich das richtig interpretiere. Der Standardbootloader aus der Arduino IDE verwendet eben die 115200. Es geht mir grad hauptsächlich darum, wie ich im Bootloader die Baudrate verringern kann. Der Grundtenor scheint ja zu sein, dass mit internem Takt auch UART möglich ist, nur eben langsamer. Dazu brauch ich aber erst mal nen brauchbaren Quellcode.
Thomas Eckmann schrieb: > 1MBit entspricht 1/8 bei gesetzem U2X-Bit. > > mfg. danke, mir war aber so das es hiess F_CPU muss 16 x Baud sein .... grübel.
Thomas Eckmann schrieb: > 1MBit entspricht 1/8 bei gesetzem U2X-Bit. > > mfg. danke, mir war aber so das es hiess F_CPU muss 16 x Baud sein .... grübel. Hugo0x0B schrieb: > Dazu brauch ich aber erst mal nen brauchbaren Quellcode. optiboot https://code.google.com/p/optiboot/
Joachim B. schrieb: > F_CPU muss 16 x Baud Nö, bei U2X genügen 8 x. Steht auch so in den typischen Tabellen in den AVR-Datenblättern, bspw.:
1 | fosc = 8.0000MHz |
2 | Baud |
3 | U2X = 0 U2X = 1 |
4 | Rate |
5 | (bps) UBRR Error UBRR Error |
6 | 2400 207 0.2% 416 -0.1% |
7 | 4800 103 0.2% 207 0.2% |
8 | 9600 51 0.2% 103 0.2% |
9 | 14.4k 34 -0.8% 68 0.6% |
10 | 19.2k 25 0.2% 51 0.2% |
11 | 28.8k 16 2.1% 34 -0.8% |
12 | 38.4k 12 0.2% 25 0.2% |
13 | 57.6k 8 -3.5% 16 2.1% |
14 | 76.8k 6 -7.0% 12 0.2% |
15 | 115.2k 3 8.5% 8 -3.5% |
16 | 230.4k 1 8.5% 3 8.5% |
17 | 250k 1 0.0% 3 0.0% |
18 | 0.5M 0 0.0% 1 0.0% |
19 | 1M – – 0 0.0% |
20 | Max (1) 0.5Mbps 1Mbps |
Jörg Wunsch schrieb: > Nö, bei U2X genügen 8 x oh, stimmt, galt das damals baud x 16 = F_CPU nur für Atmel die das UX2 Reg nicht haben?
Das gilt auch für Mega, die das U2X haben, solange das nicht gesetzt ist. Oliver
Moin zusammen, war die letzten Tage unabkömmlich. Hab jetzt aber mal den OPtiboot Bootloader ausprobiert. Hab die Baudrate zuerst auf 38400 geändert. Damit war eine stabile Kommunikation möglich. Der Controller hat sich gemeldet. Signatur ok etc. Aber ich kann keine Programme aufspielen. Daraufhin die Baudrate auf 4800 geändert -> selbes Problem. Ich glaub aber nicht, dass es jetzt noch an der seriellen Kommunikation liegt. MIt avrdude kann ich den Chip problemlos ansprechen. Nur bei Verifizieren ist immer ein Fehler in Bit 0x0006 Auch Chip erase bringt nix, da steht immer derselbe Wert drin. Eine kaputte Flashzelle halte ich für unwahrscheinlich. Ist ein neuer Chip und bisher hats ja funktioniert mit besagten 115200Baud @16Mhz external. Hat der optiboot Bootloader irgendwelche Eigenarten, die ich wissen muss? (Freigaben, protokolle, etc?) Der ist für mich völlig neu.
Hugo0x0B schrieb: > MIt avrdude kann ich den Chip problemlos ansprechen. > Nur bei Verifizieren ist immer ein Fehler in Bit 0x0006 > Auch Chip erase bringt nix, da steht immer derselbe Wert drin. > Eine kaputte Flashzelle halte ich für unwahrscheinlich. Was bringt dich angesichts der Fakten zu dieser Einschätzung? Nur weil nicht sein kann, was nicht sein darf, oder gibt es auch irgendwelche objektiven Gründe, die du uns verschwiegen hast?
Hugo0x0B schrieb: > Eine kaputte Flashzelle halte ich für unwahrscheinlich. Nicht so unwahrscheinlich, wie du im Moment annimmst. Ich habe hier eine Charge Mega8 aus einer Billigquelle aus Bayern, die sich weigern, auch nur 100 Bytes zu flashen. Signatur auslesen geht aber. Sind wahrscheinlich vom Shenzen Basar. Bevor du jatzt da noch Stunden verbringst, hol dir erstmal einen anderen MC und stopf ihn in die Schaltung. Hugo0x0B schrieb: > Nur bei Verifizieren ist immer ein Fehler in Bit 0x0006 Du meinst ein Bit auf Adresse 0x0006?
Hallo Hugo0x0B, könnte es sein, dass bei deinem atMega die FuseBits für den Colckvorteiler noch auf 1/8 steht ? Bitte poste mal deine gesamten Einstellungen dazu.
Moinsen, so, habe mal wieder Zeit gefunden weiter zu basteln. Leider hat man für soetwas natürlich nie so viel Zeit wie man gerne hätte^^ Die kaputte Flashzelle hielt ich für unwahrscheinlich, weil ich ja die ganze Zeit mit dem Controller gearbeitet habe und der völlig iO war. Habs jetzt auch bewiesen: der ist iO. Hab nen anderen Bootloader drauf gespielt, diesmal mit 57600er Baud und: Tada^^ Funktioniert einwandfrei. Keine Ahnung, wieso der optiboot da so Mucken macht. Der hat irgendwie nicht ordentlich in den Flash geschrieben. Vielleicht sollte ich mich mal ausführlicher mit Bootloader beschäftigen, irgendwie finde ich das sehr unbefriedigend. Die meisten Loader findet man nur als .hex file. So auch mit dem aktuellen. Hab den irgendwo aus dem aurduino project host (code.google) gefischt und einfach ausprobiert. Der Quellcode dazu war leider nicht mit dabei... Wenn ich mal Zeit hab, schreib ich selber einen. Aber will mich damit jetzt nicht weiter aufhalten. Mein Fuse Einstellungen sind übrigens wie folgt: Was macht das denn für einen Unterschied, ob der Chip auf 1Mhz oder auf 8Mhz läuft? Sollte den Flash doch eigentlich nicht jucken, oder? BODLEVEL = 2V7 RSTDISBL = [ ] DWEN = [ ] SPIEN = [X] WDTON = [ ] EESAVE = [ ] BOOTSZ = 1024W_3C00 BOOTRST = [X] CKDIV8 = [ ] CKOUT = [ ] SUT_CKSEL = INTRCOSC_8MHZ_6CK_14CK_65MS EXTENDED = 0xFD (valid) HIGH = 0xDA (valid) LOW = 0xE2 (valid) Danke auf jeden Fall für die Hilfe :)
Hugo0x0B schrieb: > Was macht das denn für einen Unterschied, ob der Chip auf 1Mhz oder auf > 8Mhz läuft? Sollte den Flash doch eigentlich nicht jucken, oder? Den nicht, aber die maximale ISP-Taktfrequenz, wenn du mit ISP programmierst. Die muss kleiner als ¼ davon sein.
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.