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.
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?
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
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
Eine eigene Frage?
Dieser Thread ist über 15 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
dso.png
(2,3 KB)
