Compare commits
1 commit
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
8b7d081960 |
3 changed files with 238 additions and 11 deletions
243
README.md
243
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/
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
{
|
||||
"server": {
|
||||
"address": "192.168.178.229",
|
||||
"address": "127.0.0.1",
|
||||
"port": 5000
|
||||
},
|
||||
"virtual_port_range": {
|
||||
|
|
|
|||
|
|
@ -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",
|
||||
|
|
|
|||
Loading…
Reference in a new issue