Ich habe da ein kleines Problem mit einer RS232 als Softwarevariante.
Gegeben ist ein ATmega328p welcher mit Baudratenquarz 11.0592MHz und natürlich korrekter Angabe im Programm betrieben wird.
Davon wird die HW-RS232 verwendet um via TTL-USB-Adapter mit einem PC zu kommunizieren und eine SW-RS232 um mit einem Modul welches mittels seriellen Befehlen kommuniziert zu "sprechen".
Beide Schnittstellen sind mit 9600,8,N,1 konfiguriert, die HW-Schnittstelle ist zudem gepuffert.
Es zeigt sich, dass mindestens das erste selten auch noch das zweite Zeichen vom µC falsch eingelesen wird (vom Modul wird aber korrekt gesendet wie ein parallel angeschlossener zweiter TTL-USB Adapter zeigt).
So werden vom Modul die folgenden Bytes AA 0C 02 01 47 00 gesendet aber vom µC öfters aber nicht immer als D5 0C 02 01 47 00 empfangen (selten aber doch auch D5 8C 02 01 47 00).
AA= BIN-10101010
D5= BIN-11010101
0C= BIN-00001100
8C= BIN 10001100
Die SW-Schnittstelle wird mit
Open "COMD.3:9600,8,n,1" For Output As #255
Open "COMD.4:9600,8,n,1" For Input As #254
geöffnet
Eingelesen wird über die Funktion Inputbin #254 , Receive(0) (unter Verwendung von $timeout weil es auch Modul-Antworten mit einer vorerst unbekannten Länge gibt).
Die zum Modul gesendeten Befehle funktionieren einwandfrei. Wäre da ein "Verschlucker" würde nämlich nichts geantwortet werden weil der Befehlsstring Checksum-gesichert ist und wenn die CS nicht stimmen würde, eben keine Antwort vom Modul kommt.
Ich bin zwar in der glücklichen Lage, die ersten beiden Bytes nicht zu benötigen, hätte es aber schon gerne, dass auch die ersten beiden Bytes korrekt erkannt werden.
Was könnte die Ursache für dieses "Fehlverhalten" sein?
Der µC wurde übrigens schon durch einen anderen ersetzt, auch die Interrupts (da wird aber aktuell nur eine LED gesteuert) wurden schon deaktiviert was aber auch zu keinem Erfolg führte.
Würde die Frequenz nicht stimmen, würde doch die gesamte Kommunikation nicht funktionieren und nicht nur immer reproduzierbar die ersten beiden empfangenen Bytes der SW-Schnittstelle.
Gegeben ist ein ATmega328p welcher mit Baudratenquarz 11.0592MHz und natürlich korrekter Angabe im Programm betrieben wird.
Davon wird die HW-RS232 verwendet um via TTL-USB-Adapter mit einem PC zu kommunizieren und eine SW-RS232 um mit einem Modul welches mittels seriellen Befehlen kommuniziert zu "sprechen".
Beide Schnittstellen sind mit 9600,8,N,1 konfiguriert, die HW-Schnittstelle ist zudem gepuffert.
Es zeigt sich, dass mindestens das erste selten auch noch das zweite Zeichen vom µC falsch eingelesen wird (vom Modul wird aber korrekt gesendet wie ein parallel angeschlossener zweiter TTL-USB Adapter zeigt).
So werden vom Modul die folgenden Bytes AA 0C 02 01 47 00 gesendet aber vom µC öfters aber nicht immer als D5 0C 02 01 47 00 empfangen (selten aber doch auch D5 8C 02 01 47 00).
AA= BIN-10101010
D5= BIN-11010101
0C= BIN-00001100
8C= BIN 10001100
Die SW-Schnittstelle wird mit
Open "COMD.3:9600,8,n,1" For Output As #255
Open "COMD.4:9600,8,n,1" For Input As #254
geöffnet
Eingelesen wird über die Funktion Inputbin #254 , Receive(0) (unter Verwendung von $timeout weil es auch Modul-Antworten mit einer vorerst unbekannten Länge gibt).
Die zum Modul gesendeten Befehle funktionieren einwandfrei. Wäre da ein "Verschlucker" würde nämlich nichts geantwortet werden weil der Befehlsstring Checksum-gesichert ist und wenn die CS nicht stimmen würde, eben keine Antwort vom Modul kommt.
Ich bin zwar in der glücklichen Lage, die ersten beiden Bytes nicht zu benötigen, hätte es aber schon gerne, dass auch die ersten beiden Bytes korrekt erkannt werden.
Was könnte die Ursache für dieses "Fehlverhalten" sein?
Der µC wurde übrigens schon durch einen anderen ersetzt, auch die Interrupts (da wird aber aktuell nur eine LED gesteuert) wurden schon deaktiviert was aber auch zu keinem Erfolg führte.
Würde die Frequenz nicht stimmen, würde doch die gesamte Kommunikation nicht funktionieren und nicht nur immer reproduzierbar die ersten beiden empfangenen Bytes der SW-Schnittstelle.