diff --git a/README.md b/README.md index f133379..6b16cf6 100644 --- a/README.md +++ b/README.md @@ -159,11 +159,13 @@ Die gemeinsame Client-Architektur ist bereits auf eine plattformabhängige Implementierung der virtuellen seriellen Schnittstelle vorbereitet. -Die Windows-Implementierung der virtuellen seriellen Schnittstelle ist -noch nicht vollständig implementiert. +Unter Windows wird dieselbe gemeinsame Client- und Konfigurationslogik +verwendet. Für Tests können vorhandene virtuelle COM-Port-Verbindungen +verwendet werden. -Der spätere Windows-Client soll dieselbe gemeinsame Client- und -Konfigurationslogik verwenden. +Mit Version `v0.0.11` wurde der Windows-Client mit funktionierender +Fyne-GUI sowie der automatischen Übertragung der konfigurierten Rotor- +Startbytes praktisch getestet. ## Server @@ -414,6 +416,227 @@ vollständigen Bytebereich von `0x00` bis `0xFF` geprüft. Dabei wurde die bidirektionale Übertragung aller 256 möglichen Bytewerte erfolgreich getestet. +## Vollständiger Simulationsaufbau auf einem Ubuntu-PC + +Der komplette Datenweg kann für Entwicklung und Tests auf einem einzigen +Ubuntu-PC ausgeführt werden. Dazu laufen gleichzeitig drei Programme: + +1. `rs2322tcp-pty-test` als simuliertes Rotorgerät +2. `rs2322tcp-server` mit `configs/server-test.json` +3. `rs2322tcp-client` + +Der Datenweg ist: + +```text +Testprogramm oder Hersteller-Software + │ + ▼ + /dev/ttyUSB100 + │ + ▼ + rs2322tcp-client + │ TCP + ▼ + rs2322tcp-server + │ + ▼ + /dev/pts/N + │ + ▼ + rs2322tcp-pty-test + simuliertes Rotorgerät +``` + +### 1. PTY-Simulator starten + +In einem ersten Terminal: + +```bash +cd ~/rs2322tcp +go run ./cmd/rs2322tcp-pty-test +``` + +Beispiel: + +```text +rs2322tcp-pty-test +Port: /dev/pts/1 +Modus: Rotor-Simulation mit Echo-Fallback +Warte auf Daten ... +``` + +Der ausgegebene PTY-Pfad wird im nächsten Schritt benötigt. + +Der Simulator hält Master und Slave während seiner gesamten Laufzeit geöffnet. +Bei der bekannten Rotor-Anfrage wird automatisch die konfigurierte Rotor-Antwort +gesendet. Alle anderen Daten werden als Echo zurückgegeben. + +### 2. Testkonfiguration des Servers anpassen + +In `configs/server-test.json` wird der Rotor auf den aktuell vom Simulator +ausgegebenen PTY-Slave gesetzt. + +Beispiel: + +```json +{ + "id": "rotor", + "name": "Antennenrotor", + "serial_port": "/dev/pts/1", + "baud_rate": 600, + "data_bits": 8, + "parity": "none", + "stop_bits": 1 +} +``` + +Die PTY-Nummer ist nicht dauerhaft fest. Nach jedem neuen Start des +PTY-Simulators muss der tatsächlich ausgegebene `/dev/pts/N`-Pfad geprüft und +gegebenenfalls manuell in `server-test.json` eingetragen werden. + +Im Echtbetrieb wird hier wieder ein fester Hardware-Port verwendet, zum Beispiel: + +```text +/dev/ttyUSB0 +``` + +Die serverseitige Zuordnung bleibt bewusst manuell und fest konfiguriert, weil +mehrere unterschiedliche Hardwaregeräte gleichzeitig am Server angeschlossen +sein können. + +### 3. Server starten + +In einem zweiten Terminal: + +```bash +cd ~/rs2322tcp +go run ./cmd/rs2322tcp-server -config ./configs/server-test.json +``` + +Beispiel: + +```text +rs2322tcp-server dev +Control-Server gestartet auf [::]:5000 +Geräte: 3 +``` + +### 4. Server-Monitor als Sniffer + +Ist in der Server-Konfiguration + +```json +"serial_monitor": true +``` + +gesetzt, protokolliert der Server den übertragenen Datenverkehr. Im +Simulationsaufbau werden dadurch unter anderem die Richtungen + +```text +TCP RX +SERIAL TX +SERIAL RX +TCP TX +``` + +sichtbar. + +Ein typischer Ablauf ist: + +```text +TCP RX 57 00 00 00 00 00 00 00 00 00 00 1F 20 +SERIAL TX 57 00 00 00 00 00 00 00 00 00 00 1F 20 +SERIAL RX 57 07 01 06 00 01 03 06 02 00 01 20 +TCP TX 57 07 01 06 00 01 03 06 02 00 01 20 +``` + +Der Server arbeitet damit gleichzeitig als Monitor beziehungsweise Sniffer für +den übertragenen seriellen Datenverkehr. + +### 5. Client-Konfiguration für den lokalen Test + +Für den lokalen Test kann `configs/client.json` beispielsweise so aussehen: + +```json +{ + "server": { + "address": "127.0.0.1", + "port": 5000 + }, + "virtual_port_range": { + "first": 100, + "last": 199 + }, + "virtual_ports": [ + { + "port": "/dev/ttyUSB100", + "remote_device": "rotor", + "startup_bytes": "57 00 00 00 00 00 00 00 00 00 00 1F 20" + } + ] +} +``` + +Der öffentliche virtuelle Port `/dev/ttyUSB100` muss vorher wie im Abschnitt +zur manuellen Einrichtung der virtuellen Ports einmalig angelegt worden sein. + +### 6. Client starten + +In einem dritten Terminal: + +```bash +cd ~/rs2322tcp +go run ./cmd/rs2322tcp-client +``` + +Nach erfolgreichem Verbindungsaufbau werden die konfigurierten `startup_bytes` +automatisch zum zugeordneten Rotor übertragen. + +Der Server-Monitor muss dann den vollständigen Ablauf + +```text +TCP RX -> SERIAL TX -> SERIAL RX -> TCP TX +``` + +zeigen. + +Damit ist der gesamte Datenweg vom virtuellen Client-Port über TCP zum +simulierten Rotor und wieder zurück geprüft. + +### 7. Virtuellen Port direkt testen + +Eine Antwort kann beispielsweise mit + +```bash +cat /dev/ttyUSB100 | xxd -g 1 +``` + +beobachtet werden. + +In einem zweiten Terminal kann eine Rotor-Anfrage gesendet werden: + +```bash +printf '\x57\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x1f\x20' > /dev/ttyUSB100 +``` + +Der Rückweg erfolgt über denselben vollständigen Datenpfad zurück zu +`/dev/ttyUSB100`. + +### Hinweis zu `/dev/pts/N` + +`/dev/pts/N` wird in diesem Aufbau ausschließlich als temporärer Test-Port +für den PTY-Simulator verwendet. Die Nummer ist nicht dauerhaft und kann sich +nach einem Neustart des Simulators ändern. + +Im produktiven Betrieb sind die serverseitigen Geräte dagegen echte, +fest angeschlossene Hardware-Schnittstellen, beispielsweise: + +```text +/dev/ttyUSB0 +/dev/ttyUSB1 +/dev/ttyUSB3 +``` + ## Diagnose und Logging Für Debugging und Diagnose soll eine Protokollierung des übertragenen @@ -423,8 +646,9 @@ Insbesondere soll eine Darstellung der übertragenen Bytes möglich sein, um Probleme bei der Kommunikation zwischen Hersteller-Software und Gerät analysieren zu können. -Während der Entwicklung kann `socat` als zusätzliches Werkzeug für Tests -und Diagnose eingesetzt werden. +Für die Linux-PTY-Funktion und den beschriebenen Simulationsaufbau wird +`rs2322tcp` ohne `socat` betrieben. Die benötigten PTYs werden direkt aus Go +erzeugt. ## Hardwaretest mit SPID Rot2Prog @@ -659,8 +883,8 @@ Für die Entwicklung existiert zusätzlich das separate Testprogramm: ~/rs2322tcp-pty-test ``` -Es erzeugt unter Linux ein PTY, setzt den Slave in den Raw Mode und zeigt -den Namen des Slave-Gerätes an. +Es erzeugt unter Linux ein PTY, setzt den Slave in den Raw Mode und stellt +eine simulierte serielle Gegenstelle bereit. Beispiel: @@ -782,8 +1006,11 @@ git status ```text rs2322tcp/ ├── cmd/ +│ ├── com0com-test/ │ ├── rs2322tcp-client/ +│ ├── rs2322tcp-client-test/ │ ├── rs2322tcp-device-sim/ +│ ├── rs2322tcp-pty-test/ │ └── rs2322tcp-server/ ├── configs/ ├── docs/ diff --git a/configs/client.json b/configs/client.json index 5983adf..8b4547e 100644 --- a/configs/client.json +++ b/configs/client.json @@ -1,6 +1,6 @@ { "server": { - "address": "192.168.178.229", + "address": "127.0.0.1", "port": 5000 }, "virtual_port_range": { diff --git a/configs/server-test.json b/configs/server-test.json index 5bff734..fdbfc60 100644 --- a/configs/server-test.json +++ b/configs/server-test.json @@ -6,7 +6,7 @@ "hardware_error_response": "ERROR - HARDWARE NOT AVAILABLE", - "serial_monitor": true, + "serial_monitor": false, "devices": [ { @@ -21,7 +21,7 @@ { "id": "rotor", "name": "Antennenrotor", - "serial_port": "/dev/pts/0", + "serial_port": "/dev/pts/1", "baud_rate": 600, "data_bits": 8, "parity": "none",