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
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.
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
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.
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
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.
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.
