Moin, ich versuche Grade eine Kommunikation zwischen einem ATMega32 und einem PC per RS232 aufzubauen. Es gibt dort jedoch einen merkwürdiges Verhalten. Sende ich 2 oder mehr Byte hintereinander, und ein Byte ist 0x00, wird das folgende Byte falsch empfangen. Ist beim ersten Byte ein beliebiges Bit gesetzt, wird das zweite Byte korrekt empfangen. Ich muss mindestens 6 ms warten, um das zweite Byte erfolgreich zu senden. Das Problem konnte ich auf das angehängte Minimalbeispiel eindampfen. Infos zum Aufbau: Ein ATmega32 (TQFP) mit 5V und 16 MHz betrieben sitzt auf einer selbst entwickelten Platine. Er wird über eine Ethernetbuchse mit 9V (2 Adern Plus; 2 Minus; 7805 auf Platine) versorgt und sendet seine Daten ebenfalls über diese Buchse. Daran angeschlossen ein Cat5 Kabel mit 0,5 Metern. Von dort aus geht es über einen MAX3232 und knapp zwei Metern Kabel in den PC. Baudrate: 9600 Terminal-Programm: GtkTerm (Debian/Linux) Auf dem Auszug vom Oszi (angehängt) sieht alles in Ordnung aus (bis auf den Sägezahn durch den MAX3232). Die mit dem Oszi gemessene Baudrate beträgt 9612. Das zweite Byte sieht man auf dem Auszug nicht komplett, aber ist ebenfalls in Ordnung. Weitere Messungen kann ich bei Bedarf einreichen. Kanal 1 vom Oszi ist nach dem Ethernetkabel aufgenommen worden. Kanal zwei direkt hinter den MAX3232. Meine Lösungsversuche (ohne Erfolg): - Ich habe bereits den RS232 Pegelwandler getauscht (MAX232N DIP gegen MAX3232 SMD) - Ich habe einen RS232-Usb-Dongle verwendet und diesen direkt hinter dem MAX232 angeschlossen, so dass das 2 Meter RS232 Kabel zum PC entfielen. Kennt jemand das Problem, hatte es selbst und konnte es Lösen? Grüße emperor PS: Das Errata vom ATMega32 enthält keine Punkte zum USART.
Angehängte Dateien:
-
dso.png
2,3 KB
Wie wärs mit einem Oszi Screenshot wo der Fehler zu sehen ist? Kann gtkterm die Daten in Binär-, Hex- oder Dezimaldarstellung anzeigen? 0x00 wirst du als char nicht sehen. Edit: 8N1 überall eingestellt?
Angehängte Dateien:
-
dso.png
4,3 KB
Hier nochmal der Screenshot vom 2. Byte. Habe ein paar Markierungen eingefügt Klar, 0x00 sieht man nicht, jedenfalls nicht als String, deshalb ist GtkTerm auf Hex eingestellt, 8N1 ist auch eingestellt. Der Fehler muss irgendwo Richtung PC liegen: - Habe einen zweiten AVR genommen, das selbe Programme eingespielt -> gleicher Fehler. - Habe den zweiten AVR mit einem kleinen Programm zum Empfangen ausgestattet und dieser zeigt die übertragenen Daten auf einem Display an und zwar korrekt.
Mit einem anderen PC testen. Ich wollte nicht den Oszi Screenshot vom zweiten Byte sondern eines wo man den Fehler in den +/- 15 V Signalen sieht. Da die Signale jedoch immer korrekt sind muss es am PC liegen.
Es gibt keine falschen Oszi Bilder, das Oszi zeigt immer 0xAA als zweites Byte an. Bestätigt ja auch der zweite AVR + LCD, welchen ich zum Empfangen genutzt habe. Der PC empfängt immer falsch, wenn das erste Byte 0x00 ist. Wie gesagt hatte auch schon nen USB-Dongle statt der Onboard RS232-Schnittstelle benutzt, werde jetzt aber nochmal nen Laptop samt Windows probieren. Muss aber leider den selben USB-Dongle einsetzen, da ich nichts anderes zur Verfügung habe
Punkt 1: Der USB-Dongle funktioniert unter Windows 7 (64Bit) nicht, Windows findet online keine Treiber und von Hand vorgesetzte Treiber von FTDI akzeptiert Windows nicht... Auf dem Dongle steht natürlich kein Hersteller oder sonst irgendwas drauf. Punkt 2: GtkTerm ist schuld. Das von mir seit langem eingesetzte Programm baut Mist. Ich habe eben die serielle Schnittstelle auf dem PC richtig eingestellt (BAUD 9600 8N1) und mit "cat /dev/ttyS0 > dump" nen paar Daten aufgenommen. Anschließend habe ich die Datei "dump" mit nem Hex-Editor geöffnet und siehe da, in der Datei ist alles korrekt... Jetzt such nen neues brauchbares Terminal-Programm für Linux. juhu 2 Tage Arbeit wegen nicht funktionierender Software
probier mal putty. Das ist zwar Windows-Software, läuft aber normalerweise mit wine (zumindest bei meinem Ubuntu 10.4). Gibt es auch als Source für Unix bei http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
Es gibt auch eine hterm Version für Linux.
emperorl0ser schrieb: > Punkt 1: Der USB-Dongle funktioniert unter Windows 7 (64Bit) nicht, > Windows findet online keine Treiber und von Hand vorgesetzte Treiber von > FTDI akzeptiert Windows nicht... Auf dem Dongle steht natürlich kein > Hersteller oder sonst irgendwas drauf. Im Gerätemanager die Eigenschaften ansehen, da gibt es dann die Möglichkeit Details anzeigen zu lassen, und so VID/PID bestimmen. Wenn das Ding nicht von FTDI ist, funktioniert ein FTDI-Treiber natürlich nicht. Mit VID/PID lässt sich über Google der korrekte Hersteller bestimmen und natürlich auch ein Devicetreiber lokalisieren.
N'abend nochmal, verwende jetzt Cutecom. @forget Kann putty Daten in Hex ausgeben und ermöglicht auch eine Hex-Eingabe? Wundert mich etwas, das Ziel von Putty liegt doch definitiv woanders. @Christopher G. Das würde ich mit glatt nochmal ansehen. HTerm finde ich nicht schlecht. @Rufus Τ. Firefly Joa, ein Vorgehen in der Art hatte ich mir gedacht, hatte aber gerade nicht so viel Lust mich damit rum zu schlagen. Dachte immer man muss sich nur unter Linux mit solchen Problemen prügeln. Werde ich mir aber merken, sofern es nochmal nötig sein sollte. Aber jetzt wie gesagt nicht nötig, das Problem hat sich zum Glück endlich erledigt. Grüße emperor
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.