Neuimplementierung von i-Telex

[detlef]

Ich hätte hierzu auch schon eine Vorschlag wie das gelingen könnte. Die Anbindung zum TWI Bus könnte man mit einem RPI Pico erledigen, durch den Header ließe sich dann auch was anders aufstecken wenn es diesen nicht mehr geben würde. Aber bei der Popularität würde ich von ausgehen das das nachfolgende Board Pin kompatible sein wird. Die Anbindung erfolgt per SPI auf einen RPI4 oder CM4, auch hier kann man von Ausgehen das man was anderes drauf stecken könnte.

Bei solchen Konstrukten mit Coprozessoren auch immer gleich bedenken, wie Anwender das nachher updatet. Der Pico muss dann automatisch vom Hauptprozessor aktualisert werden können. Ich wüsste nicht, wie das 95% der i-Telex-Teilnehmer sonst hinbekommen sollten.

Das muss von Anfang an mit eindesignt werden, denn gerade am Anfang wird es die meisten Updates geben.

Also auch das Thema Update sollte man in den Anforderungen für ein neues System mit aufnehmen.

[damarco]

Das geht mit dem Pico Bootloader sehr einfach, dieser emuliert ein Laufwerk da schiebst du das File einfach rauf -> fertig. Per SPI kann man diesen auch in den Bootloader schicken. Auch vom der SPI Seite kann man den Flash beschreiben, also auch kein Problem.

Der Vorteil von Pico ist es das diese leicht beschaffbar ist und als Board fällt das Bestückungsproblem. Zudem besitzt dieser von der Peripherie Eigenschaften das TWI Protokoll von Timing stabil zu erzeugen. Für die Karten wäre dieser aber auch einsetzbar und für die doppel Karten wäre auch nur einer nötig.

[FredSonnenrein]

Ich verliere gerade gedanklich den Anschluss...

Ich hätte hierzu auch schon eine Vorschlag wie das gelingen könnte. Die Anbindung zum TWI Bus könnte man mit einem RPI Pico erledigen, durch den Header ließe sich dann auch was anders aufstecken wenn es diesen nicht mehr geben würde. Aber bei der Popularität würde ich von ausgehen das das nachfolgende Board Pin kompatible sein wird. Die Anbindung erfolgt per SPI auf einen RPI4 oder CM4, auch hier kann man von Ausgehen das man was anderes drauf stecken könnte.

Ich gehe davon aus, dass in einem ersten Schritt der Implementierung die Schnittstellenkarten des i-Telex (also TW39, ED1000, Seriell) unverändert bleiben. Denn das "Protokoll" mit dem sich diese Karten untereinander unterhalten (und auch mit der Ethernet-Karte) ist derart simpel, dass ein Update im ersten Schritt mehr Stress als Vorteile bringt.

Allerdings hat diese einen kleinen aber wesentlichen Haken: Das Timing der Datenübertragung auf dem TWI-Bus ist kritisch, damit meine ich nicht, dass die Bit-Längen der TWI-Bits passen müssen, sondern dass der Zeitpunkt einer Übertragung eines TWI-Datenworts passen muss. Als Erleichterung dieser Problematik werden auf dem TWI-Bus aber (fast) nur Daten-Telegramme aus 2 Bytes übertragen. Danach ist Pause.

So würde man das in der Industrie nie bauen, man würde einen ARM nehmen mit der Peripherie und das war es dann. Nur weis niemand ob dieser noch in 10 Jahren lieferbar ist und da wäre dann das Bestückungsproblem. Mit der Header Variante bleibt es ein selbst Bastelprojekt . Möglich wäre auch ein ESP32...

Und dann für jede Schnittstelle einen eigenen ARM-Prozessor? In meinem System daheim würden dann 8 Stück von werkeln mit entsprechendem Energieverbrauch. Ich finde, das muss nicht sein.

Der i-Telex Code ist wirklich grausam, ich habe mir das verkniffen zu erwähnen , aber so ist das eben wenn man aus einer Idee heraus etwas entwickelt. Man will so schnell wie möglich erfolge sehen...

Das ist nicht der einzige Grund für das aktuelle Design: Der viel relevantere Hintergrund ist, dass es zu Anfang gar keine Ethernet-Karte gab, sondern eine Modem-Karte, die per V21 eine Verbindung zum Kommunikationspartner hergestellt hat.
Das damals aber in Echtzeit, d.h. mit maximal (geschätzt) 5 Millisekunden Verzögerung von Ende zu Ende. D.h. das Anschlagen einer Taste kam wirklich ohne Verzögerung am anderen Ende an.
Das wird vermutlich mit Verschlüsselungstechnik dann wohl auch nicht machbar sein, oder kann mit Verschlüselung ein Byte nach dem anderen übertragen werden?

Das mit der Verschlüsslung meinte ich auch so das es möglich ist sich zu authentisieren, das Netz ist gegen Missbrauch nicht geschützt und mit der jetzigen Hardware hat man wenig in der Hand irgend etwas zu unterbinden wenn die Papierrollen durchrauschen. Außer abschalten

Und wenn die Verbindung verschlüsselt ist, dann kann man es leichter Unterbinden? Die Argumentation würde ich gerne mal fortgesetzt sehen.
Dass etwas gegen Missbrauch getan werden sollte, ist unbestritten.
Ich denke da aber eher an einfache Algorithmen die "Durchrattern" oder "Löcher in die Walze stanzen" vermeiden.

[damarco]

Ich denke auch das man das Design der Karten nicht fasst, die Implementierung des TWI Protokolls wird aber auch für die Ethernetkarte nötig, diese muss ja mit den Schnittstellen kommunizieren. Es bleibt also nicht aus sich am ende auch damit befassen zu müssen.

Ein Prozessor pro Karte, mit 200MHZ Takt sind was anderes wie 16MHZ, da kann ein Prozessor mehrere Kanäle bedienen. Zumal auch DMA Controller und weitere Hardware mit dran sind die den Prozessor entlasten und ein stabiles timing ermöglichen.

Hast du eigentlich schon damals den CAN Bus als alternative nachgedacht? Schon vor 10 Jahren waren auf dem Markt günstige ICs verfügbar die sich mit einen AVR leicht ansteuern ließen. Atmel hatte sogar AVR mit CAN Bus. Wenn ja weshalb hast du dich dann für den TWI Bus entschieden?

[FredSonnenrein]

Die "neue" Ethernetkarte muss natürlich erstmal designt werden.
Ich kann dabei auch nur DRINGEND empfehlen, nicht nur WLAN zu verwenden, da dann wieder Latenzprobleme auftreten werden und ein flüsiges Schreiben schwierig wird.

Ich denke auch das man das Design der Karten nicht fasst, die Implementierung des TWI Protokolls wird aber auch für die Ethernetkarte nötig, diese muss ja mit den Schnittstellen kommunizieren. Es bleibt also nicht aus sich am ende auch damit befassen zu müssen.

Ich habe wieder Schwierigkeiten dieser Aussage zu folgen...
Ich verstehe es so:
Das Design der Schittstellenkarten (also alles außer Ethernet-Karte) bleibt unverändert, Hard- und Software.
Neu kommt "etwas", das zum bestehenden Design direkt kompatibel ist. Somit also auch die bestehenden TWI-Protokolle der Schnittstellen benutzt.
Habe ich das richtig verstanden?

Ein Prozessor pro Karte, mit 200MHZ Takt sind was anderes wie 16MHZ, da kann ein Prozessor mehrere Kanäle bedienen. Zumal auch DMA Controller und weitere Hardware mit dran sind die den Prozessor entlasten und ein stabiles timing ermöglichen.

Welche Hardware-Platform meinst du damit? 200 MHz erscheint mir für aktuelle Hardware-Platformen langsam zu sein.
Damit will ich nicht sagen, dass man mehr braucht...

Hast du eigentlich schon damals den CAN Bus als alternative nachgedacht? Schon vor 10 Jahren waren auf dem Markt günstige ICs verfügbar die sich mit einen AVR leicht ansteuern ließen. Atmel hatte sogar AVR mit CAN Bus. Wenn ja weshalb hast du dich dann für den TWI Bus entschieden?

TWI-Bus habe ich seit etwa 30 Jahren in Verwendung und bin stets gut damit gefahren.
Daher habe ich das auch beim vorläufer des i-Telex, also dem "TelexPhone 2" benutzt.
Und das i-Telex sollte Hardwareseitig eine Ergänzung des TelexPhone 2 sein, somit war TWI "gesetzt".
Ich habe mit CAN z.B. keine Erfahrung, ich weiß nicht wie Multi-Master Konzepte beim CAN-Bus funktionieren...
TWI kann man auch beliebig "ausbremsen" um langsame Bus-Teilnehmer zu erlauben.
Soviel nur zur Erklärung.

Wenn überhaupt über die Struktur des i-Telex neu nachgedacht wird, dann ist der erste Schritt die Beantwortung der Frage, welche Struktur überhaupt sinnvoll ist. Eher modularisiert wie beim aktuellen i-Telex oder eher "Einheitsmodule" wie beim piTelex.

Viele Grüße

Fred

[detlef]

oder eher "Einheitsmodule" wie beim piTelex.

Mit Einheitsmodul meinst du jeweils immer nur einen Fernschreiber pro i-Telex - so wie beim piTelex?

Also zum Beispiel im technikum29: 10 x Netzteil, 10 x Netzwerkanbindung, einen großen Switch, einen Haufen Ethernetkabel.
Das erfordert dann einen kleinen Schaltschrank, um das alles unterzubringen. Die Kosten und der Aufwand würden explodieren.
Das mit der Linienstromversorgung könnte man noch mit einem gemeinsamen Netzteil lösen, aber die Netzwerkverkabelung bleibt.

Außerdem gibt es ja genau das schon und nennt sich piTelex. Man müsste dafür nur eine standardisierte Hardware entwickeln mit Netzteil und Linieninterface bzw. ED1000. Und eine einfachere Installation (fertige Images?) und eine einfachere Konfiguration (Webserver).
Und die Software kann man sicher auch verbessern, so dass zum Beispiel weniger Latenzen auftreten.
Also wenn man den Aufwand für ein komplett neues System stattdessen ins piTelex stecken würde, dann könnte da schon was tolles draus werden.
Aber eben immer für einen Fernschreiber.

Das beste am i-Telex ist die Modularität. Jeder Laie kann da eine zusätzliche Schnittstellenkarte dazustecken und konfigurieren.

Falls ich, wie geplant, in 2,5 Jahren in den Ruhestand gehe, dann kann ich da auch was tun. Vorher leider nicht.

[damarco]

Die "neue" Ethernetkarte muss natürlich erstmal designt werden.
Ich kann dabei auch nur DRINGEND empfehlen, nicht nur WLAN zu verwenden, da dann wieder Latenzprobleme auftreten werden und ein flüsiges Schreiben schwierig wird.

Deswegen fällt ein ESP32 schon einmal raus, denn nur die ersten Versionen hatten eine 100Mbit PHY, die jetzigen ESP Modell nur noch WLAN

Ich habe wieder Schwierigkeiten dieser Aussage zu folgen...
Ich verstehe es so:
Das Design der Schittstellenkarten (also alles außer Ethernet-Karte) bleibt unverändert, Hard- und Software.
Neu kommt "etwas", das zum bestehenden Design direkt kompatibel ist. Somit also auch die bestehenden TWI-Protokolle der Schnittstellen benutzt.
Habe ich das richtig verstanden?

Korrekt keine neuen Anpassung 100% kompertible zur alten Hardware. Ich meine man kann ja die AVR Sockel auslöten und mit Header zum Entwickeln einen Pico oder was man dafür verwenden mag anbinden. Wenn es dann stabil läuft und sich Vorteile ergeben kann man an ein neues Hardwaredesign nachdenken. Diese wäre auch das man bei der TW39 Karte den Stromwert von einem ADC einließt, auch ED1000 lässt sich mit einfachen DSP Funktionen decodieren. Der Vorteil ist das man Leitungsfehler erkennen kann und ausblendet. Zukunftsmusik !

Welche Hardware-Platform meinst du damit? 200 MHz erscheint mir für aktuelle Hardware-Platformen langsam zu sein.
Damit will ich nicht sagen, dass man mehr braucht...

Der Pico läuft intern mit 133MHZ, hat Clock Teiler und man kann die Peripherie auch anders Takten. Das Pico Board hat 2MB Flashmemory ein völlig andere Liga wie ein AVR. Durch die Statemaschine lässt sich auch ein HDMI Signal erzeugen -> 125MHZ Clock und vom Timing wirklich kritisch. Um ein OS laufen zu lassen benötigt man eine Memory Protection Unit auf der Hardware. Es gab schon vor über 10 Jahren kleine ARM Boards mit Linux die mit 133MHZ oder weniger liefen. Je nach Anwendung war das sogar brauchbar... Man könnte auch für alles einen TEENSY nehmen, aber der aber noch in 10 Jahren lieferbar ist mag ich bezweifeln.

Als ersten Schritt würde ich vorschlagen das i-telex Protokoll als eine Bibliothek zum laufen zu bekommen. Ich versuche das so zu bauen das man es auch mit der IDF vom ESP32 zum laufen bekommt. Dann schauen wie gut das läuft, Zeitrahmen so nebenbei würde ich so 3 Monate veranschlagen bis was brauchbares da wäre. Danach kann man sich an das TWI Interface kümmern und ist beides Vorhanden kann man über die Eigentliche Applikation nachdenken.

[detlef]

Die "neue" Ethernetkarte muss natürlich erstmal designt werden.
Ich kann dabei auch nur DRINGEND empfehlen, nicht nur WLAN zu verwenden, da dann wieder Latenzprobleme auftreten werden und ein flüsiges Schreiben schwierig wird.

Deswegen fällt ein ESP32 schon einmal raus, denn nur die ersten Versionen hatten eine 100Mbit PHY, die jetzigen ESP Modell nur noch WLAN

Könnte man den ESP32 nicht einfach noch zusätzlich mit einer externen Ethernet-Schnittstelle ausstatten? Zum Beispiel mit so einem Wiznet-Chip?

EDIT: Ok, scheint zumindest prinzipiell kein Problem zu sein:
https://mischianti.org/esp32-ethernet-w ... ssl-https/

Es gibt übrigens auch Einsatzgebiete, da geht überhaupt nur WLAN, weil gar kein Ethernetanschluss in der Nähe ist (zum Beispiel im MfK in Frankfurt). Da muss im Moment sehr umständlich mit einem WLAN-Client-Modul gearbeitet werden. Und davon gibt es nicht viele, die man verwenden kann.

Als ersten Schritt würde ich vorschlagen das i-telex Protokoll als eine Bibliothek zum laufen zu bekommen. Ich versuche das so zu bauen das man es auch mit der IDF vom ESP32 zum laufen bekommt. Dann schauen wie gut das läuft, Zeitrahmen so nebenbei würde ich so 3 Monate veranschlagen bis was brauchbares da wäre. Danach kann man sich an das TWI Interface kümmern und ist beides Vorhanden kann man über die Eigentliche Applikation nachdenken.

Ich bin gespannt.

[damarco]

Natürlich könnte man und der W5500 lässt sich per SPI mit 30MHZ ansteuern. Aber ich bin kein Fan von dem Ding. Das Teil wird heiß wie eine Bratpfanne und braucht richtig Strom. Es gibt noch andere ähnliche ICs, aber eine PHY am Mikrocontroller ist einfach schneller und ohne Overhead ansteuerbar. Zumal anzumerken ist das sowie so kaum ein Mikrocontroller wirklich in der Lage ist 1Gbit/s zu verarbeiten und beim w5500 ist bei 10Mbit/s Schluss. Das hängt man den erwähnten Protokolloverhead zusammen. Außerdem ist ein 1Gbit Design eine nicht einfache Aufgabe vom Layout, 100Mbit/s bekommt man mit etwas Erfahrung noch hin.

Über die Plattform muss man dann nochmal Diskutieren, so ein RPI mit Linux hat Vorteile aber auch Nachteile. Ein Teensy zu verwenden ist auch eine Erwägung. Der 4.1 hat auch einen 100Mbit PHY.

Weshalb sich Espressif entschieden hat keine PHY mehr im ESP32 zu verbauen weis ich nicht. Ich habe noch welche hier mit PHY und auch Boards mit Ethernet Port. TLS Verschlüsslung ging zwei mit dem ESP32 aber der brauche 2-3 Sekunden dafür und das wart hart grenzwertig.

[FredSonnenrein]

Bei einem Punkt habe ich Verständnis-Probleme:

Korrekt keine neuen Anpassung 100% kompertible zur alten Hardware. Ich meine man kann ja die AVR Sockel auslöten und mit Header zum Entwickeln einen Pico oder was man dafür verwenden mag anbinden.

Also wenn du die ATmega328 der Schnittstellenkarten durch irgendwas ersetzen willst (oder was meinst du mit "AVR Sockel auslöten"?), dann doch gleich eine andere Hardware. Denn von den Interface-Platinen bleibt ohne AVR dann eh nur das "Hühnerfutter" übrig.
Das kann natürlich auch weiterverwendet werden, aber auf einem Steckbrett ist die TW39 Schnittstelle schneller aufgebaut.

Es gibt noch andere ähnliche ICs, aber eine PHY am Mikrocontroller ist einfach schneller und ohne Overhead ansteuerbar.

Was ist eine PHY?