mikrocontroller.net

Forum: PC-Programmierung RS232 command - Zusammensetzung des Commandblock


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Kai L. (lucky_o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich habe ein Protokoll (Sony 9pin oder BVW75) :

Communication Format
The protocol is based on the EIA RS-422-A signal standard, usually at 
38.4 kBit/s. The data are sent as 1 start bit + 8 data bits + 1 parity 
bit + 1 stop bit. Parity is odd: the bitwise sum of data bits 0 -7 and 
the parity bit is an odd number.

Command Block Format
The controlling device and the controlled device communicate through the 
interchange of command blocks. The bytes in each command block are 
assigned as follows:
•  CMD-1/DATA COUNT. CMD-1 is the upper 4 bits, DATA COUNT is the lower 
4.
•  CMD-2.
•  DATA-1 up to DATA-N, where n is the value in data count
•  CHECKSUM
CMD-1
Indicates the function and direction of the command, according to:
0   System control (Master->Slave)
1   Return for 0,2, or 4 of cmd-1 (Slave->Master)
2   Transport Control (Master->Slave)
4   Preset/Select control (Master->Slave)
6   Sense Request (Master->Slave)
7   Sense Return (Slave->Master)
DATA COUNT
Indicates the number of bytes ( max 15 ) inserted between CMD-2 and 
CHECKSUM
CMD-2
Designates the command. Refer to the command table for definitions. Ex. 
CMD-1=0 and CMD-2=0C means LOCAL DISABLE.
DATA-1 to DATA-N
Data which correspond to those indicated by the command. Refer to the 
command table for data formats.
CHECKSUM
Lower eight bits of the sum of the bytes in the command block.

Beispiele für Steuerbefehle gibts z.B. hier :
https://www.drastic.tv/support-59/legacysoftwarehardware/72-miscellaneous-legacy/158-vvcr-422-serial-protocol

Play wäre demnach hex 20 01 21 (21 ist checksum).

Das ist aber nicht der ganze Befehl, es fehlt die Einleitung, also 
CMD-1.
Und ich weiss nicht, wie ich das definiere.

Vielen Dank

(RS232 auf RS422 Umsetzung wird mit einem Startech Interface mit eigener 
Spannungsversorgung erledigt)

Autor: Theor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zitat: "When the DATA COUNT is 0, no data is transmitted (the CMD1, CMD2 
and checksum data bytes are still transmitted), ..."

hex 20 01 21 ist demnach schon das komplette Kommando. Code ist 2 und 
Anzahl Datenbytes ist 0. Also nur CMD1, CMD2 und Checksumme.

Sieht gut aus.

Autor: Theor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kommst Du darauf, dass Du

> Das ist aber nicht der ganze Befehl, es fehlt die Einleitung,
> also CMD-1.

Woraus leitest Du das ab?

Autor: my2ct (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai L. schrieb:
> ... EIA RS-422-A ...

EIA RS-422-A ≠ RS-232

Autor: Kai L. (lucky_o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Theor schrieb:
> Zitat: "When the DATA COUNT is 0, no data is transmitted (the
> CMD1, CMD2
> and checksum data bytes are still transmitted), ..."
>
> hex 20 01 21 ist demnach schon das komplette Kommando. Code ist 2 und
> Anzahl Datenbytes ist 0. Also nur CMD1, CMD2 und Checksumme.
>
> Sieht gut aus.

Aber 20 01 ist der eigentliche Befehl.
Meiner Meinung fehlt da CMD-1

Und 20 01 21 hab ich schon zur Maschine gesendet, keine Reaktion.
Was mich halt auch wundert, denn im Protokoll steht, dass auf einen 
gültigen Befehl ein ACK zurückgesendet wird.
Ein ungültiger Befehl müsste ein NAK als Antwort haben.
Der Receive Teil ist aber leer.
Ich teste das mit hterm.

Autor: Theor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai L. schrieb:
> Theor schrieb:
>> Zitat: "When the DATA COUNT is 0, no data is transmitted (the
>> CMD1, CMD2
>> and checksum data bytes are still transmitted), ..."
>>
>> hex 20 01 21 ist demnach schon das komplette Kommando. Code ist 2 und
>> Anzahl Datenbytes ist 0. Also nur CMD1, CMD2 und Checksumme.
>>
>> Sieht gut aus.
>
> Aber 20 01 ist der eigentliche Befehl.
> Meiner Meinung fehlt da CMD-1
>
> [...]

Ja. Schon. Lach. :-)
Aber worauf gründet sich Deine Meinung? Das Dokument gibt das nicht her.
Allein darauf, dass keine Reaktion erfolgt?

Autor: Theor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist dann am besten erst mal die Übertragung zu prüfen und die 
Einstellungen von HTerm.
Erst kürzlich hatte ich hier jemanden, der sich auch gewundert hat, das 
ihm die Gegenstelle nicht antwortet. Dabei war das Problem, dass er 
Hardware-Handshake eingestellt hatte.

Autor: Theor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai L. schrieb:
> Theor schrieb:
>> Zitat: "When the DATA COUNT is 0, no data is transmitted (the
>> CMD1, CMD2
>> and checksum data bytes are still transmitted), ..."
>>
>> hex 20 01 21 ist demnach schon das komplette Kommando. Code ist 2 und
>> Anzahl Datenbytes ist 0. Also nur CMD1, CMD2 und Checksumme.
>>
>> Sieht gut aus.
>
> Aber 20 01 ist der eigentliche Befehl.
> Meiner Meinung fehlt da CMD-1
>
> [...]

Komisch irgendwie.

Es scheint mir ganz klar zu sein:
20 ist CMD-1 - Commando ist '2' und Länge ist 0.
01 ist CMD-2
21 ist die Checksumme

Das entspricht völlig der Beschreibung, oder?

Autor: Kai L. (lucky_o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach herrje, dann ist 01 das Play Kommando und 20 ist schon CMD-1.

Verdammt.

OK, dann muss der Fehler in der Config von hterm oder der
Kabelbelegung liegen.

Ich hab hterm nur gestartet, 38400 8N1 parity odd eingestellt
und meine drei Hexzahlen weggeschickt.

Autor: fop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai L. schrieb:
> 8N1

Moep - falsch
8O1 ist gefordert

Autor: Theor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach vielleicht ein Bildschirmfoto von HTerm. Dann können wir auch mal 
einen Blick darauf werfen.

Autor: Theor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai L. schrieb:
> Ach herrje, dann ist 01 das Play Kommando und 20 ist schon CMD-1.
>
> Verdammt.
>
> [...]

Lach. Naja. Deswegen habe ich insistiert, dass Du mal den Grund für 
Deine Vermutung schreibst. Wenn man das untersucht, kommt man meist auf 
den Denkfehler (den wir jetzt so auch nicht kennen).

Aber die Vermutung, dass das schon das komplette Sequenz ist ist 
plausibel.
Entweder Du hattest recht, dann wäre 20 01 21 aber nur ab CMD-2 (oder 
noch später) der Inhalt und 21 wäre nicht die Checksumme, weil man die 
ja noch nicht berechnen kann (oder auch nur wieder aufgrund von 
Vermutungen).
Oder Du hattest unrecht, dann ist 20 01 21 völlig konsistent zur 
Beschreibung, weil die Checksumme stimmt und die Längenangabe in dem 
ersten Byte auch, falls es CMD-1 ist.

Man muss nur (wenn Du mir diese zugegeben etwas überheblich klingende 
aber humorig gemeinte Bemerkung gestattest) mal logisch denken. :-)

Autor: Leuchtungsgango B (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai L. schrieb:
> Ich hab hterm nur gestartet, 38400 8N1 parity odd eingestellt
> und meine drei Hexzahlen weggeschickt.

aber nicht dass Du 0x32 0x30 0x30 0x31 0x32 0x31 sendest, als 
'2'0'0'1'2'1'...
Gelle?

Autor: npn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fop schrieb:
> Kai L. schrieb:
>> 8N1
>
> Moep - falsch
> 8O1 ist gefordert

Kai L. schrieb:
> parity odd eingestellt

Autor: Kai L. (lucky_o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leuchtungsgango B schrieb:
> Kai L. schrieb:
>> Ich hab hterm nur gestartet, 38400 8N1 parity odd eingestellt
>> und meine drei Hexzahlen weggeschickt.
>
> aber nicht dass Du 0x32 0x30 0x30 0x31 0x32 0x31 sendest, als
> '2'0'0'1'2'1'...
> Gelle?

Ich hab die Sendezeile in der Mitte von hterm auf hex umgestellt und
dann 20 01 21 getippt. Sogar die Leerzeichen macht das Programm ja 
selbst.

Das ist ok so, oder ?

Autor: RAc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das heisst Du tippst die Zeichen manuell ein? Das kann von Sicht der 
Gegenstelle aus sehr sehr langsam sein. Wenn da mal nicht ein Timeout 
zuschlägt...

schreib ein kleines DOS Programm, das die Zeichen programmatisch 
rüberschreibt, und nutze HTerm nur zum loggen.

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai L. schrieb:
> Ich hab die Sendezeile in der Mitte von hterm auf hex umgestellt und
> dann 20 01 21 getippt.

Hast Du bei "Send on Enter" auch "None" eingestellt? Sonst sendet HTerm 
noch zusätzliche Bytes.
Eventuell solltest Du auch erstmal "00 11 11" (device type request) 
versuchen.

RAc schrieb:
> Das heisst Du tippst die Zeichen manuell ein? Das kann von Sicht der
> Gegenstelle aus sehr sehr langsam sein. Wenn da mal nicht ein Timeout
> zuschlägt...

HTerm sendet erst, wenn man ihm sagt daß es das tun soll und dann die 
eingegebenen Zeichen/Bytes auch so schnell hintereinander wie es geht. 
Also wenn, dann ist das höchstens zu schnell.

Autor: Kai L. (lucky_o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Send on Enter steht auf None.
Da hab ich auch schon mit CR und LF und CR/LF probiert.

Ich hatte es auch mit Asend getestet und das Kommando 1, 5 und auch 10 
mal
gesendet. Kein Erfolg.

Autor: Kai L. (lucky_o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RAc schrieb:
> Das heisst Du tippst die Zeichen manuell ein? Das kann von Sicht
> der
> Gegenstelle aus sehr sehr langsam sein. Wenn da mal nicht ein Timeout
> zuschlägt...
>
> schreib ein kleines DOS Programm, das die Zeichen programmatisch
> rüberschreibt, und nutze HTerm nur zum loggen.

Dafür gäbe es ja eine Fehlermeldung, NAK Timeout oder so ähnlich.
Ich hab aber bisher noch kein einziges Bit der Maschine empfangen.

Nur als Gedankenmodell, wenn ich 8N1 anstatt 8O1 eingestellt hätte, 
würde das die Kommunikation komplett verhindern ?

Autor: RAc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kai L. schrieb:
> RAc schrieb:
>> Das heisst Du tippst die Zeichen manuell ein? Das kann von Sicht
>> der
>> Gegenstelle aus sehr sehr langsam sein. Wenn da mal nicht ein Timeout
>> zuschlägt...
>>
>> schreib ein kleines DOS Programm, das die Zeichen programmatisch
>> rüberschreibt, und nutze HTerm nur zum loggen.
>
> Dafür gäbe es ja eine Fehlermeldung, NAK Timeout oder so ähnlich.
> Ich hab aber bisher noch kein einziges Bit der Maschine empfangen.
>

Normalerweise nicht. Hängt natürlich vom Protokoll ab, aber 
Timeoutbestätigungen sind nicht die Regel, das würde auch die 
Kommunikation ziemlich durcheinanderwürfeln (auf seriellen 
Schnittstellen können immer mal wieder Zeichen verloren gehen, das wird 
normalerweise durch silen discarding und resync auf das nächste Paket 
gelöst).

Oder sendest Du en bulk wie Kai es geschildert hat?

> Nur als Gedankenmodell, wenn ich 8N1 anstatt 8O1 eingestellt hätte,
> würde das die Kommunikation komplett verhindern ?

Ja.

Autor: Kai L. (lucky_o)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, weiter gehts. Hab jetzt so eine Betamax Maschine vor mir.

Es wird ein Kabel verwendet, was mich verwirrt.
Welche Leitungen braucht man bei RS422 ?
Ich dachte beide Rx und beide Tx und GND.
Das Kabel würde aber beide Rx, GND und RTS+ und CTS+ vom Interface 
nutzen.

Beim Sony wirds noch übler, denn 5 ist ja beim Interface und beim Kabel 
GND,
5 ist aber beim Sony gar nicht genutzt.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hab jetzt so eine Betamax Maschine vor mir.

Oh..backe..ne ich frag jetzt lieber nicht...

> Das Kabel würde aber beide Rx, GND und RTS+ und CTS+ vom Interface
> nutzen.

Ist zwar sehr ungewoehnlich, aber ist ja auch Sony in ihrer besten Zeit. 
Und warum soll man nicht auch noch RTS und CTS nach 422 uebertragen. 
Dann brauchst du halt noch einen Pegelwandler mehr.

> 5 ist aber beim Sony gar nicht genutzt.

Irgendwo musst du aber GND haben, vielleicht der Kabelschirm? Die 
Information ist zwar in der differenziellen Uebertragung, aber GND ist 
notwendig damit deine Signale innerhalb des Bezugsfenster der Treiber 
bleiben.

Olaf

Autor: Kai L. (lucky_o)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GND bei der Sony Buchse ist ja im Foto zu sehen.
Es gibt Common je Senderichtung und 1 und 9 sind Frame GND.

Ich werd mir jetzt erstmal ein Kabel bauen, was
nur Rx und Tx und GND berücksichtigt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.