Auf einem Atmel Evalution Board habe ich einen Atmega32.
Über Uart sende ich Daten vom Atmega zum PC. (Nicht Angeschlossen sondern über den AZ-Delivery FT232-AZ USB zu TTL Serial Adapter für 3,3V und 5V).
Leider bekomme ich auf dem PC (HTerm) falsche Bytes.
Die ersten beiden Bytes sind ok und dann wird die zweite Byte 5 Mal widerholt.
Auch zeigt hTerm sporadisch an, dass es Fehler in der Übertragung für manche Bytes gibt. Baudrate, Byte und Stoo Bit sind gleich angezeigt.
Ein Blick in die Baudraten-Tabelle im Datenblatt bei 16 MHz verrät mir, dass UBRR = 5 zu keiner typischen Baudrate passt, unabhängig davon wie U2Xn gesetzt wurde. Für die auskommentierten 3.6864 MHz und passt UBBR = 5 bei U2Xn = 0 für die angegebenen 38k4. Fazit: Für das Eval-Board (das wahrscheinlich mit 16 MHz laufen wird) wird der Baudratenfehler schlichtweg zu groß sein.
Ein Blick in die Baudraten-Tabelle im Datenblatt bei 16 MHz verrät mir,
dass UBRR = 5 zu keiner typischen Baudrate passt, unabhängig davon wie
U2Xn gesetzt wurde. Für die auskommentierten 3.6864 MHz und passt UBBR =
5 bei U2Xn = 0 für die angegebenen 38k4. Fazit: Für das Eval-Board (das
wahrscheinlich mit 16 MHz laufen wird) wird der Baudratenfehler
schlichtweg zu groß sein.
Danke für den Hinweis.
Also auf dem Board ist ein 16 Mhz Verbaut.
Werde ich korrigieren und testen wenn ich wieder zu Hause bin.
Auch, wenn es auskommentiert ist: Bitte denk über diese Zeile noch einmal intensiv nach. Die NULL am Ende des Strings setzt der Compiler automatisch. Am Anfang des Strings bewirkt sie ein vorzeitiges Ende.
Korrektur: das muss ein Zwischenstand sein, es entspricht meinem neuen File, mit Ausnahme dieser einen beschriebenen Zeile (und natürlich dem RAMEND (da ATmega16)).
Liegt es vllt an (meiner) Verbindung vom Board (/Atmega) über den
Adapter zum PC ?
Nimm einen Logik Analysator oder ein Oszilloskop und guck dir an, was dein ATmega rausgibt.
Dann ist der Adapter und die PC-Software raus - zwei Baustelle weniger.
Beschaff dir eines. Denn nur mit einem Oszilloskop kannst du die Qualität des Signals bezüglich Pegel, Flankensteilheit, Überschwinger, Timing und Ströungen beurteilen. Wenn das alles passt, dann kann man im Protokoll weitersuchen.
Es ist mir ein völliges Rätsel, wie man serielle Busse ohne Oszilloskop anständig zum Laufen bekommen will.
Es ist mir ein völliges Rätsel, wie man serielle Busse ohne Oszilloskop
anständig zum Laufen bekommen will.
Wie hat man es uns bei der BW beigebracht? Nur ein nicht abgegebener Schuss kann nicht treffen...ich glaube der ein und andere hat dieses Prinzip verinnerlicht und adaptiert es auf alles, was ihm zwischen die Finger kommt. Ich verstehe auch nicht, wie man ohne Oszi bei sowas wirklich effektiv weiter kommen will. In meinen Augen ist das zum Teil viel Stochern im Nebel in der Hoffnung mal nen Treffer zu landen.
die zu "bezweifeln" ist. Ist denn Pin 39 ein echter bzw.
zulässiger Ground-Anschluss?
Wenn wir den TO dann endlich dazu bewegt haben ein Oszilloskop
zu kaufen oder wenigstens auszuleihen kommt dann eventell noch
die Aussage "ich habe alles mit dem Logikanalysator überprüft".
Nein, es muss ein Oszilloskop sein um den Spannungsverlauf
erkennen zu können.
Der VCC-Pin des FT232-Moduls hat - duch Jumper wählbar - entweder
3.3 oder 5V zu bieten. Das ist ein Ausgang, eine kleine
Quelle mit der man externe Controller versorgen kann. Werden
diese 5V an eine andere 5V-Quelle angeschlossen kommt es zu
einem Kampf der Giganten mit unvorhersehbaren Ausgang.
Merke: Ein FT232-Modul braucht keine Versorgung von aussen,
daher kann / sollte man den Vcc-Pin unbeschaltet lassen. Und
ein wie auch immer geartetes Eval-Board wird auch seine eigene
Versorgung mitbringen, einer von beiden Versorgern wird
zumindest irritiert reagieren können.
Was auch immer an der Hardware fehlerhaft sein mag oder nicht - mit dem gestern abend gezeigten HEX-File läuft die UART mit 1.0 MBd, das kann nichts werden.
