piTelex Setup: grundlegende Überlegungen

[WolfHenk]

Ein Gerät am piTelex, das Setup per Fernschreiber durchführt...
txDevSetup.py

Aber hier haben wir ein kleines Problem: Die Katze beißt sich in den Schwanz.

Ohne Setup läuft der FS nicht, ohne FS kann ich den Setup nicht machen.
Wie lösen wir das auf?

Schauen wir bei i-Telex: Feste Karte, die definierte Zustände hat und ausschließlich eins kann...

Hmm. Warum nicht?

Warum kann das piTelex nicht? Weil keiner soweit gedacht hat.

Wir belegen einfach drei Eingänge:
000 Keiner belegt, Bastelzeug mit Handarbeit
00I heißt SEU-M oder piSEU-A. Der FS ist also immer ein piTTY-Gerät
0I0 belegt, heißt ED1000 über Soundkarte.
0II ist PiTelex über SEU-M oder -A ohne Vorschaltgerät
I00 ist per Serial-Port angebunden
I0I Reserve
II0 Reserve
III Reserve
Die fertigen Platinen bekommen in den folgenden Ausbaustufen einfach eine Brücke von GND oder 3v3 (ganz nach gusto) nach den Eingängen und schon ist die Vorauswahl automatisch erledigt, weil ich programmtechnisch nun sehen kann, was am pi dranhängt.

Habe ich also ne SEU-M mit nem TW39 Fernschreiber, bin ich nun in 98% aller Fälle schon richtig und die Konfiguration kann automatisch erfolgen.
Dito mit der neuen piSEU-A für ED1000 Fernschreiber.
ED1000 über Soundkarte wird in geschätzt 80% sofort gehen....

Damit sind die allermeisten Anwendungsfälle erledigt. Wer jetzt noch Sondergeräte hat, der kommt nicht umhin, zu basteln. das ist aber überall so.

Ich schlage die PIO 13, 19 und 26 vor. (Pin21 kann für Shutdown konfiguriert werden, den also nicht)
"pin_type1":26
"pin_type2":19
"pin_type4":13

rpizero2w.png

Ich gehe auch nicht auf die 26-poligen Uralt-RPis ein. Wer basteln will darf das. und die alten Dinger sind nur noch Bastelkram.

[WolfHenk]

Zusätzlich könnte man folgende Textdatei in /boot ablegen (das ist auch für Windows beschreibbar)

piTelex – Konfigurationsfragebogen Fernschreiber-Anschluss
==========================================================

Bitte die passenden Zeilen mit "x" markieren.

1) Welcher Fernschreiber-Typ wird eingesetzt?
[ ] TW39-Fernschreiber
    (z.B. Siemens T34 und früher, T37, T68D, T100, Lorenz Lo15 und früher, Lo133, RFT T51)
[ ] ED1000-Fernschreiber
    (z.B. Siemens T1000, T1200, T4200, Lorenz Lo200x, Lo3000, RFT F1x00, F2000, F2500)
[ ] Fernschreiber über CH340-USB-Wandler (TeKaDe und ähnliche)
[ ] Sonstiger / unbekannter Typ (bitte Handkonfiguration vornehmen)

2) Wie ist der Fernschreiber elektrisch angebunden?
[ ] TW39 mit SEU-M im Fernschreiber
    (z.B. statt SEU-B im T1000 oder LO2xxx eingebaut)
[ ] TW39 mit Oe-AGT und SEU-M
[ ] ED1000-Anschluss mit piSEU-A
[ ] CH340-USB-Wandler
[ ] USB-Soundkarte für ED1000
[ ] V10 über rpiTTY
[ ] andere / Eigenbau (Handkonfiguration erforderlich)

3) Mit welcher Baudrate arbeitet der Fernschreiber?

[ ] 45 Baud
[ ] 50 Baud
[ ] 75 Baud
[ ] 100 Baud
[ ] 200 Baud
[ ] 300 Baud

Hinweis: Die Baudrate steht meist auf dem Typenschild des Fernschreibers
oder auf separaten Schildern / Aufklebern an der Front des Geräts.

Hinweis:
- Diese Datei wird unterstützend gelesen. Sie muss auf der SD-Karte in /boot 
  abgelegt werden (für Windows-User). Der Dateiname darf nicht geändert werden.
- Fehlerhafte Angaben können nicht ausgewertet werden. 
  Das macht die Datei zwecklos und führt dazu, dass doch per Hand konfiguriert werden muss.
  

Und jetzt bitte ich jeden, der damit nicht klarkommen würde, sich zu melden....

Beim Ersten Einschalten wird diese Datei gelesen. Damit wird Grundkonfiguration gemacht.

Ohne sie gehts zu den Pins...
Das mit den obengenannten Pins werde ich auf vier Pins (16 Möglichkeiten) erweitern.
Wer also dann auf seiner SEU-M oder seinem Pi Brücken legt, der hat beim Ersten Einschalten (und nur dann) automatisch eine funktionierende Grundkonfiguration und die Hardware läuft.

Anschließend kann man dann mit 008 das eigentliche Setup aufrufen um I-Telex und weiteres am FS zu konfigurieren....

[WolfHenk]

Systematisch angesehen finde ich nicht mehr als 9 Konfigurationen:

0: Handkonfiguriert
1: SEU-M im OeAGT -> RPiTTY, Mode AGT-TW39, OeAGT-Profil
2: SEU-M im FS (T1000, Lo2000) -> RPiTTY, Mode TW39, SEU-M-im-Gerät
3: SEU-M im OeAGT ohne Fernschaltgerät -> RPiTTY, Mode TW39, SEU-M „direkt“
4: ED1000 via Soundkarte -> ED1000-Device, Soundkarten-Profil
5: RPiTTY mit TW39-Karte -> RPiTTY, Mode TW39, „nackte TW39-Karte“
6: RPiTTY im Modus V10 (TeKaDe) -> RPiTTY, Mode V10
7: piSEU-A – RPiTTY für direkten ED1000-Anschl. -> RPiTTY, Mode TW39, noch in Entwicklung
8: CH340 -> CH340TTY

Meinungen dazu?

[obrecht]

Ich würde eine softwarebasierte Lösung bevorzugen. Das ist leichter anpassbar als Platinen wegen der Pins ändern zu müssen, und man ist nicht in der Anzahl und Auswahl der unterstützten HW beschränkt.

Wenn man von einem Autostart-pitelex ausgeht (fertig vorbereitetes image) hätte ich einen Vorschlag:
Für alle unterstützten Hardware-Varianten gibt es eine vorbereitete telex.json, die zumindest screen und die passenden Hardwaremodule enthält. Mit einer einfachen Erstkonfigurationsabfrage nach dem Booten des frischen Systems

"Welche Hardware ist angechlossen? 
1 - SEU-M
2 - TW39 von piTelex github
3 - TW39 Version2 von Rolfs github  
4 - V.10 von piTelex github
5 - ....

erfolgt die Grundauswahl.
Damit wird die passende telex,json automatisiert nach piTelex rüberkopiert und der RPi neu gebootet. Danach funktioniert der FS und man kann das CLI benutzen für die Feinkonfiguration (das kann man sogar auch vorher schon über screen tun ohne funktonierenden FS, z.B. um abweichende Baudraten o.ä. anzupassen )

[WolfHenk]

...und wie gibst du ein, welche Hardware dranhängt?
Denk an die Windowsleute, die putty nicht bedienen können/wollen und Tastatur/Bildschirm nicht am Pi anschliessen.
Zuerst muss also der Telex anspringen, damit die dann 008 wählen können um die Konfig zu vervollständigen.
nach weiterer Überlegerei komm ich zu folgenden Möglichkeiten:

dec	bin	Beschreibung
0	0000	keine automatische Auswahl, Fragebogen/Handkonfiguration
1	0001	TW39 mit FSG – SEU-M im OeAGT
2	0010	TW39 mit FSG – TW39 Version2 von Rolfs github 
3	0011	TW39 mit FSG – TW39 Karte (alt)
----
4	0100	TW39 ohne FSG – SEU-M im Fernschreiber (T1000, Lo2000, …)
5	0101	TW39 ohne FSG – TW39 Version2 von Rolfs github
6	0110	TW39 ohne FSG – TW39 Karte (alt)
7	0111	TW39 ohne FSG – piSEU-A / direkter ED1000-Anschluss am FS, aus Pi-Sicht Tastaturwahl-Profil
----
8	1000	ED1000 über USB-Soundkarte (eigenes ED1000-Device)
9	1001	CH340-USB-Adapter (serieller Fernschreiberanschluss, CH340TTY)
10	1010	RPiTTY im Modus V.10 (TeKaDe & ähnliche)
11	1011	Reserve für weiteres Nicht-TW39-Profil
----
12	1100	Reserve 
13	1101	Reserve
14	1110	Reserve
15	1111	Reserve

Je länger man denkt, desto einfacher stellt es sich dar...

Ich hatte jetzt schon den Gedanken, einer vollautomatischen Erkennung: Einfach eins nach dem anderen durchprobieren und nach Kennungsgeber fragen...
Kommt irgendwas, ändern wir nur noch die Geschwindigkeit und wenn wir das auch noch haben, braucht der User gar nix mehr außer seinen I-Telex-Daten....

[obrecht]

...und wie gibst du ein, welche Hardware dranhängt?

Natürlich mit den erwähnten vorbereiteten telex.json Varianten. Da ist dann z.B. RPiTTY drin mit den passenden Pins und Einstellungen wie modes z.B. TW39 oder V.10.

dec	bin	Beschreibung
0	0000	keine automatische Auswahl, Fragebogen/Handkonfiguration
1	0001	TW39 mit FSG – SEU-M im OeAGT
2	0010	TW39 mit FSG – TW39 Version2 von Rolfs github 
3	0011	TW39 mit FSG – TW39 Karte (alt)
----
4	0100	TW39 ohne FSG – SEU-M im Fernschreiber (T1000, Lo2000, …)
5	0101	TW39 ohne FSG – TW39 Version2 von Rolfs github
6	0110	TW39 ohne FSG – TW39 Karte (alt)
7	0111	TW39 ohne FSG – piSEU-A / direkter ED1000-Anschluss am FS, aus Pi-Sicht Tastaturwahl-Profil
----
8	1000	ED1000 über USB-Soundkarte (eigenes ED1000-Device)
9	1001	CH340-USB-Adapter (serieller Fernschreiberanschluss, CH340TTY)
10	1010	RPiTTY im Modus V.10 (TeKaDe & ähnliche)
11	1011	Reserve für weiteres Nicht-TW39-Profil

11  1011   RPiTTY V.10 von Rolfs github 

bitte

[WolfHenk]

Code: Alles auswählen

dec  bin   name    		Beschreibung
0    0000  null             	Keine Brücke gesetzt → Fragebogen/Handkonfiguration/nix Automat!
1    0001  SEU-M-OeAGT		TW39 mit FSG – SEU-M im OeAGT
2    0010  TW39Card-ver2	TW39 mit FSG – TW39 Version2 von Rolfs github
3    0011  TW39Card		TW39 mit FSG – TW39 Karte (alt)
4    0100  SEU-M-internal	TW39 ohne FSG – SEU-M im Fernschreiber (T1000, Lo2000, …)
5    0101  TW39V2-noFSG		TW39 ohne FSG – TW39 Version2 von Rolfs github
6    0110  TW39-noFSG		TW39 ohne FSG – TW39 Karte (alt)
7    0111  piSEU-A          	TW39 ohne FSG – piSEU-A / direkter ED1000-Anschluss am FS, aus Pi-Sicht Tastaturwahl-Profil
8    1000  ED1000-USB       	ED1000 über USB-Soundkarte (eigenes ED1000-Device)
9    1001  CH340-USB        	CH340-USB-Adapter (serieller Fernschreiberanschluss, CH340TTY)
10   1010  V.10			RPiTTY im Modus V.10 (generisches V.10-Profil)
11   1011  V.10-ver2		RPiTTY V.10 – spezielle Implementierung/Schaltung von Rolfs github
12   1100  Reserve          	Reserve
13   1101  Reserve          	Reserve
14   1110  Reserve          	Reserve
15   1111  Reserve          	Reserve

Und wenn man diese Namen nun noch durchgängig verwendet, z.B. in der telex.json...

        # SEU-M - TW39-teletype with FSG using an Austrian AGT (OeAGT) with SEU-M-card as controller
        # Note: SEU-M-card (with aRPi) is a replacement of a SEU-B ord SES-B-card
        # Autoconfiguration profile number 01
        "SEU-M-OeAGT": {
          "type": "RPiTTY",
          "enable": true,
          "mode": "AGT-TW39",
          "pin_txd": 17,
          "pin_rxd": 27,
          "pin_relay": 22,
          "inv_relay": true,
          "pin_power": 9,
          "inv_power": false,
          "pin_number_switch": 10,
          "inv_number_switch": true,
          "WB_pulse_length": 60,
          "baudrate": 50,
          "coding": 0,                 # 0=ITA2
          "loopback": false
        },

[WolfHenk]

man sehe sich das vorläufige ergebnis an...

piTelex_autosetup_TO_TEST.zip

Beim ERSTEN Hochfahren von telex.py schaut es in die telex.json.
Wenn dort der Anfang so aussieht:

Code: Alles auswählen

{
"first_run": true,
  "devices": {........

wird das txFirstRun.py ausgeführt (noch bevor irgendetwas anderes passiert!)
Es liest aus dem Fragebogen in der Windowslesbaren Partition /boot die angekreuzten Werte.
Wenn da nix ist, oder Quatsch drin ist, fragts vier Pins ab, die dafur genutzt werden KÖNNEN, (nicht müssen)
Und wenn da auch nix ist, dan gehts altmodisch weiter...
Wenn wir aber nun wissen, was der User will, setzen wir alle Beispiele in der telex.json auf "enabled"=false, schieben das eine passende rein, setzen enable auf true, setzen first_run auf false und speichern die telex.json.
Nun gehts erst mit dem eigentlichen telex los....

Wenn wir telex.py jetzt neu starten, lesen wir telex.json, stellen fest, first_run ist false oder ganz weg.
Wir laden NICHT das firstrun.py-modul und telex wird gestartet...

Im weiteren folgt dann später noch eine txDevSetup.py, die wir mit 008 anwählen können, und die uns per Fernschreiber alle nötigen Konfigurationen machen lässt.... aber das kommt nich heute oder morgen... da lass ich mir noch zeit.

[obrecht]

Viel einfacher:
piTelex guckt beim Start, ob die aktive Konfigurationsdatei existiert (das ist zwar meistens, muss aber nicht telex.json sein (-c Cmdline Parameter).

Fehlt sie, wird first_run=true gesetzt und eine Minimalkonfiguration aus Screen und Log aktiviert und, falls sie existiert, aus der Datei in /boot die Info zur TTY Anbindung gelesen. Diese Info kann auch lauten, lies die GPIO Pins. Ohne entsprechende Direktive aus der /Boot Datei ist das aber nicht sinnvoll, da die Pins ja auch anderweitig verwendet sein können und dann beliebige Fakschinfo liefern.
Fehlt also die /Boot Datei oder schlägt sonst wie alles fehl, geht's "zu Fuß" weiter.

Gibt's aber Hardware-konfig Info, wird sie in die Konfigdatei für PiTelex aufgenommen und piTelex neu gestartet (oder rebootet), so dass dann der FS für weitere Konfiguration verfügbar ist.

piTelex kann die aktuelle Konfiguration, ermittelt aus Konfigdatei und zusätzlichen Cmdline Parametern mit dem Cmdline Parameter -s zurück in die Konfigdatei schreiben für den nächsten Start. Vllt kann man das ja mit benutzen ...

[WolfHenk]

Kurzantwort:
-- cmdline-Parameter. Kommtr, wenn telex.py läuft. Und die erfordern einen User mit Terminalprogramm. Und ein User ist ein Mensch. Der will/kann (in einigen Fällen) kein Terminal benutzen.
Die vier Pins sind physisch am ende der Kontaktleiste, direkt bei einem Massepunkt. Und wir haben noch mehr als genug pins frei.

Langantwort:
Zum Ablauf des Programmstarts:
Lieferantenseitig: Wenn das ins Testing geht, (wenn...) dann wird defaultmässig in die telex.json die first_run reingeschrieben. Damit werden dann alle neuen versionen ausgeliefert.
-
Sobald das System einmal gelaufen ist, ist first_run false und das Szenario wird nie mehr aufgerufen.
Es wird keine weitere Konfigurationsdatei erstellt oder geführt. Alles strikt abwärtskompatibel. Minimaler Eingriff in bestehende Dateien.

Programmablauf:
- Erststart. Wir sitzen VOR allen bisher bekannten Funktionen der telex.py. Wir lesen auch noch nicht die CMD-Parameter. Wir starten noch gar nichts an den eigentlich bekannten Routinen und Funktionen.
-- telex.json wird gelesen
-- first_run true? Ok, wir laden das Programm zum Erststart und bauen eine Grundkonfiguration in die vorhandene telex.json (die schon Sachen enthalten kann und darf).
-- Wir suchen und lesen die Textdatei im /boot. Was da steht gilt. Pins egal....
-- Wir finden keine Textdatei oder sie ist Blödsinn? Dann lesen wir die Pins (und nur dann)...
--Keine Pins belegt? Auch gut.
-- Wie war das? Kein Text, keine Pins? Okay. Dann Handkonfiguration.
-- wir deaktivieren first_run und fahren weiter im telex.py
Nun werden die cmd-Parameter auch gelesen, wir laden die verschiedensten Pins und Konfigurationen, wir starten das Log und Screen, wir lesen Geräte...

Zwei mögliche Wege, die Hardware zu erkennen, die auch noch strikte Prioritäten haben: Erst Text und NUR wenn das schiefgeht, Hardwareabfrage...

- jeder weitere Start:
-- first-run false oder fehlt? Wir machen nix. Laden nichtmal das Konfigurationsprogramm. Nix wird gemacht....
wir fahren weiter und starten telex.py, wie es seit Jahren läuft...

Das sorgt dafür, dass wirklich nur beim first_run überhaupt was passiert.

Alte Versionen laden telex.py, lesen telex.json, sehen first_run oder auch nicht und ignorieren das weil sie es nicht brauchen...
Neue Versionen laden telex.py, lesen telex.json, sehen first_run oder auch nicht und nur wenn first_run=true, dann passiert was...