Neuimplementierung von i-Telex

[damarco]

Ja ich habe mir schon überlegt das i-telex Protokoll in C zu implementieren. Kein großer Aufwand, an sich nur das Protokoll hat aus heutiger Sicht einige Stolpersteine. Gerade was variable BAUD Rates und andere dinge angeht ist der Header im Telegram etwas Unglück gebaut für mögliche Erweiterungen. Abwärtskompatibilität ist nur schwer zu erreichen, man muss immer mit mehren Versionen hantieren.

So etwas passiert eben wenn man aus einer Idee heraus etwas Entwickelt, sehr spät stellt sich dann heraus das man im untersten Stockwerk die Tür vergessen hat. Diese einzubauen gestaltet sich dann als sehr schwierig, da man dann auch alles oberhalb anpassen muss. Grundlegende Erfahrungen von Fehlern die man dann später nicht mehr macht

Ist denn das TWI Protokoll vom Bus beschrieben? Mir ist es auch nicht gelungen in Atmel Studio ein lauffähiges Projekt zu bauen vom i-telex. In der Struktur vom Code ist auch der Code der die Hardware bedient nicht ausgelagert. Das macht ein Portieren schwierig, wenn im eigentlichen Code Hardware bezogene dinge vorhanden sind -> Portregister gesetzt werden etc.

Besser ist es man packt diese in Hardwarehandler ->

Code: Alles auswählen

set_pin(uint8_t port,uint8_t pin)

hinter der Funktion steht dann der Code bezogen zur Hardware. Der Vorteil ist das man dann nur den Hardware Code auf die Zielplattform anpassen muss und diese dann inkludiert. Macros gehen auch...

Außerhalb eines AVR Compilers kann ein anderer Compiler nichts mit den Anweisungen anfangen und dieser sind weit in dem gerammten Code verstreut.

[MKeuer1959]

Hallo Marco,

bist Du hauptberuflicher Programmierer?
Ich bin einer, allerdings im Bereich kfm. Anwendungsprogrammierung.

Und ich kann Dir sagen, daß wir Programmierer eben etwas spezielle Wesen sind.
Unsere Projekte sind wie unsere Babys.
Wir kennen die Schwachstellen genau, würden auch im Nachhinein so manches anders machen.

Wir freuen uns immer über Fehlermeldungen (macht die Software besser) und konstruktive Änderungswünsche (dito).

Aber das Schlimmste sind für uns diese "Man müsste nur..."-Aussagen.
Wie Detlef schon sagte, Du bist doch herzlich eingeladen, Deinen eigenen Dienst wunschgemäß zu programmieren.

mfg Michael

[FredSonnenrein]

Hallo Marco,

Ja ich habe mir schon überlegt das i-telex Protokoll in C zu implementieren. Kein großer Aufwand, an sich nur das Protokoll hat aus heutiger Sicht einige Stolpersteine.

Stimmt. Heute würde ich manches anders machen.
Manches aber genau so wie es ist.

Gerade was variable BAUD Rates und andere dinge angeht ist der Header im Telegram etwas Unglück gebaut für mögliche Erweiterungen.

Diese Aussage verstehe ich nicht ganz.
Was hat die "variable Baudrate" (gibt es nicht, die i-Telex-Daten werden ja quasi parallel übertragen) mit dem "Header" zu tun?
Welchen Header meinst du, den Header jedes Datenblocks?

Abwärtskompatibilität ist nur schwer zu erreichen, man muss immer mit mehren Versionen hantieren.

Das ist aber bei allen langfristigen Projekten so.

So etwas passiert eben wenn man aus einer Idee heraus etwas Entwickelt, sehr spät stellt sich dann heraus das man im untersten Stockwerk die Tür vergessen hat. Diese einzubauen gestaltet sich dann als sehr schwierig, da man dann auch alles oberhalb anpassen muss. Grundlegende Erfahrungen von Fehlern die man dann später nicht mehr macht

100% richtig.

Ist denn das TWI Protokoll vom Bus beschrieben?

Ja hier:
https://svn.code.sf.net/p/itelex/misc-c ... cation.doc
Das wollte ich allerdings längst ins Wiki überführen.

Mir ist es auch nicht gelungen in Atmel Studio ein lauffähiges Projekt zu bauen vom i-telex. In der Struktur vom Code ist auch der Code der die Hardware bedient nicht ausgelagert. Das macht ein Portieren schwierig, wenn im eigentlichen Code Hardware bezogene dinge vorhanden sind -> Portregister gesetzt werden etc.

Das Projekt ist auch sehr eng an die Hardware angeleht, daher ist ein Portieren ohnehin extrem problematisch.
Wichtig: Die TWI-Kommunikation ist zeitkritisch, es werden nämlich keine "5->Bit-Gruppen" übertragen, sondern jeder Pegelwechsel! Somit ist das Hardware-Protokoll tatsächlichh unabhängig von der Geschwidigkeit der seriellen Übertragung.

Außerhalb eines AVR Compilers kann ein anderer Compiler nichts mit den Anweisungen anfangen und dieser sind weit in dem gerammten Code verstreut.

Ja. Siehe "Hardwarenahe Implementierung".

Viele Grüße,

Fred

[damarco]

Erstmal seit mir mit der Kritik nicht böse, man muss ja hier vorsichtig sein habe ich schon gelernt. Der Anstoß war eigentlich die Ethernetkarte, denn diese ist mit der Hardware mittlerweile eine Einbahnstraße. Die Idee war den Code zu portieren auf eine andere Hardware, zuerst habe ich am ESP32 gedacht. Nur haben nur die ersten Modelle eine PHY mit 100Mbit, bleibt nur noch WIFI. Man muss ja bei der Hardware schon schauen ob diese in 10 Jahren noch erhältlich ist, deswegen verstehe ich auch das er altbackene Konzept. Die Schnittellenkarten kann man zunächst so belassen aber eine neue Ethernetkarte hätte sehr viele Vorteile.

• mehre Verbindungen mit einer Karte
• Ordentliches Webinterface und bessere Konfiguration
• Verschlüsslung
• API json basierend
• AB mit massiv mehr Speicher und Sonderfunktionen

Die Flusskontrolle ist etwas seltsam, begründet mit den geringen Speicher im AVR. Neue Hardware könnte auch das Buffer Problem bei unterschiedlichen Baudrates lösen. Der Header im Telegramm ist etwas Unglücklich wenn man diesen erweitern möchte haben alte Implementierungen ein Problem. Das lässt sich so nicht mehr ändern ohne alle AVR Versionen anzupassen oder mit zwei Versionen zu arbeiten.

[380170JFK]

Chi vuole migliorare il mondo, farebbe bene a cominciare con se stesso ..... (Konfuzius)

[detlef]

Erstmal seit mir mit der Kritik nicht böse, man muss ja hier vorsichtig sein habe ich schon gelernt.

Kritik ist nicht das Problem, es kommt nur darauf an, wie sie geäußert wird. Wenn du mir mal eben jegliche Softwarekompetenz absprichst, mir erklärst, was Libraries sind und Git und wie man Software strukturiert, dann bin ich als hauptberuflicher Softwareentwickler gleich deutlich weniger offen für Kritik. Auf diesem Niveau brauchen wir nicht diskutieren.

Aber Fakt ist, weil ich den ganze Tag Softwarekonzepte mache, mich mit komplexen Softwarearchitekturen beschäftige, Codereview und ähnlichen Kram mache, habe ich in meiner Freizeit genau darauf keinen Bock. Da setze ich mich Abends hin und code einfach mal was - und will am Ende ein schnelles Ergebnis und nicht nur ein Konzept. So ist WinTlx entstanden und auch die Dienste. Und wenn ich nicht mehr durchblicke, dann wird konsoliert. So wie ich das gerade bei den Diensten gemacht habe. Also ich mit den Diensten begonnen habe, war das Ziel nicht das Konzept für zehn Dienste sondern für einen.

Da du ja nach wie vor deinen Erfahrungshintergrund nicht preisgegeben hast, kann man auch gar nicht einschätzen, ob da fundiertes Wissen dahintersteht oder ob es einfach nur Gerede ist. Deswegen darfst du dich auch nicht wundern, wenn Vorschläge erst mal abprallen.

[detlef]

Die Schnittellenkarten kann man zunächst so belassen aber eine neue Ethernetkarte hätte sehr viele Vorteile.

• mehre Verbindungen mit einer Karte
• Ordentliches Webinterface und bessere Konfiguration
• Verschlüsslung
• API json basierend
• AB mit massiv mehr Speicher und Sonderfunktionen

Aber eine wichtige Anforderung hast du vergessen. Das ist die Synchronität. Ich habe das selbst letztens wieder bei der Vorführung im Bunker bemerkt, als ich mit WinTlx den frisch installierten Fernschreiber getestet und vorgeführt habe.

Wenn ich in WinTlx (oder auf einem echten Fernschreiber) ein Zeichen tippe, dann wird das fast synchron (minimale Verzögerung) auf dem angerufenen Fernschreiber ausgegeben. Und das funktioniert nicht nur lokal (da ist es perfekt) sondern auch noch sehr gut über TCP/IP. Und nur da kommt echte Freude auf bei den Liebhabern der alten mechanischen Geräte.
piTelex mit seiner großzügigen Pufferverwaltung leistet das leider auch nicht. Jedenfalls ist das bei meinen Testsystemen so.

Also nimm das am besten gleich in die Anforderungsliste auf, sonst gibt's vermutlich hinterher Akzeptanzprobleme.

Ob jemand ein "ordentliches" Webinterface, Verschlüsselung, eine json API oder einen AB mit noch mehr Speicher braucht, das weiß ich nicht. Das sind jetzt erstmal deine persönlichen Anforderungen. Mehrere Verbindungen über eine Ethernetkarte wären wünschenswert. Aber letzteres liegt ja nicht an der Ethernetkarte sondern am internen Protokol. Das muss man dann alles neu machen. Und damit auch die Firmware der bestehenden Schnittstellenkarten.

[damarco]

piTelex läuft auf Python das ist einer Interpretersprache die Laufzeiten sind höher, ganz so schlimm wie mit dem damaligen Basic ist es nun auch wieder nicht. Da müsste man schauen wie der Buffer umgesetzt wurde, die Latenz hängt mit der Größe und der Baudrate zusammen, auch kann die Python TCP/IP Implementierung dafür sorgen das kleine Pakete nicht sofort gesendet werden.

Es ist schon ein Problem mit dem AVR mehre Verbindungen aufzubauen, es ist ein schlichtes Speicherproblem. Jede TCP/IP Verbindung erfordert Speicher und der ist im Mega328 nicht gerade groß. Der Knackpunkt ist der TCP/IP IC denn jener hat leider die Eigenschaft das der ganze TCP/IP Overhead vom AVR erledigt werden muss. Beim W5500 ist dies anderes, der bringt eignen Speicher mit und die TCP/IP Stack ist im W5500. Per SPI muss man die Daten lediglich holen und die Flusskontrolle erledigt dieser auch noch..

Genau deswegen dauert der Zugriff auf den Webserver so lange, der AVR hat nur wenig Zeit den Webserver zu bedienen. Große Elemente wie ein javascript usw. sind eine große Belastung und die Rechnenzeit/Speicher reicht nicht aus das Content auch noch von langsamen externen Speicher zu laden. Eine SD-Card ist schlicht weg nicht möglich da alleine die FAT16 implementieren den Speicher mit dem Projektcode vom AVR sprengt. Man könnte nur RAW reinschreiben oder lesen. Zumal läuft der AVR mit einen niedrigen Takt, bedingt sicherlich für das Timing der Hardware. Für zukünftige Erweiterungen ist der AVR ein Problem und somit nicht zukunftssicherer.

Mein Ansatz ist auch jener das wenn Fred oder detlef keine Zeit oder Lust mehr hat das Projekt weitergeführt werden kann. Es sollte so sein das sich jemand in den Code einarbeiten kann und auch in der Lage ist Problemen nachzugehen. Mir ist das leider nicht gelungen eine lauffähige Version zu erzeugen, eigentlich kopiert Atmel Studio alles in das Projektverzeichnis ein make im Projektverzeichnis sollte sich das Projekt übersetzen lassen. Nur ich habe keine Quelle gefunden wo nicht Dateien fehlten .

Das Projekt ist super und ich respektiere natürlich eure Arbeit, ich bin auch ehrlich eine komplette Lösung werde ich auch nicht liefern können.

[FredSonnenrein]

Hallo zusammen,

ich hänge mich bei diesem Beitrag ein, weil es der aktuelle sein.

piTelex läuft auf Python das ist einer Interpretersprache die Laufzeiten sind höher, ganz so schlimm wie mit dem damaligen Basic ist es nun auch wieder nicht. Da müsste man schauen wie der Buffer umgesetzt wurde, die Latenz hängt mit der Größe und der Baudrate zusammen, auch kann die Python TCP/IP Implementierung dafür sorgen das kleine Pakete nicht sofort gesendet werden.

Ich bin doch ein Freund von "schlanken Hochsprachen", da diese den Aufgaben die zu erfüllen sind am ehesten nachkommen.
Für eine Anwendung wie i-Telex braucht es keine objektorientierte Sprache, aber es funktioniert auch.

Es ist schon ein Problem mit dem AVR mehre Verbindungen aufzubauen, es ist ein schlichtes Speicherproblem. Jede TCP/IP Verbindung erfordert Speicher und der ist im Mega328 nicht gerade groß. Der Knackpunkt ist der TCP/IP IC denn jener hat leider die Eigenschaft das der ganze TCP/IP Overhead vom AVR erledigt werden muss. Beim W5500 ist dies anderes, der bringt eignen Speicher mit und die TCP/IP Stack ist im W5500. Per SPI muss man die Daten lediglich holen und die Flusskontrolle erledigt dieser auch noch..

Zuerst eine kleine Berichtigung: Die Ethernet-Software läuft schon auf einem wesentlich "dickeren" Prozessor als dem Mega328.

Daher habe ich im Design der i-Telex Software vorgesehen, dass der Overhead so gering wie möglich ist.
Natürlich kann man jede 5-Bit-Kombination in einem TCP-Frame übertragen.
Aber ich mag solche ineffiziente Lösungen nicht.
Das i-Telex kann auch bis zu 50 x 5 bit in einem Rutsch übertragen, praktiziert wird maximal 16 x 5 bit, das ist klar schnell genug, um ggf. auch noch was "zwischendurch" zu erledigen.

Genau deswegen dauert der Zugriff auf den Webserver so lange, der AVR hat nur wenig Zeit den Webserver zu bedienen. Große Elemente wie ein javascript usw. sind eine große Belastung und die Rechnenzeit/Speicher reicht nicht aus das Content auch noch von langsamen externen Speicher zu laden.

Richtig. Daher wird SSL beispielsweise Utopie im i-Tekex sein (jedenfalls mit der aktuellen Hardware).

Eine SD-Card ist schlicht weg nicht möglich da alleine die FAT16 implementieren den Speicher mit dem Projektcode vom AVR sprengt. Man könnte nur RAW reinschreiben oder lesen.

Das stimmt nicht ganz. In der Testphase war ein SD-Speicher implementiert, der viele Aktivitäten mitgeloggt hat.

Zumal läuft der AVR mit einen niedrigen Takt, bedingt sicherlich für das Timing der Hardware.

Hm, 16 MHz werden genutzt, 20 MHz wären möglich. Aktuellen Software-Design langweilt sich der Prozessor in den meisten Fällen.
Und wenn ich lese, dass das Raspi-System mit x-Facher Taktfreqenz nicht "geschmeidig" läuft, dann sollte man an den passenden Stellschrauben drehen.

Für zukünftige Erweiterungen ist der AVR ein Problem und somit nicht zukunftssicherer.

Nun ja, es ist eher so dass mit den Möglichkeiten auch die Ansprüche steigen. Und klar ist, auf 8 Bit würde ich auch kein neues Design beginnen.

Mein Ansatz ist auch jener das wenn Fred oder detlef keine Zeit oder Lust mehr hat das Projekt weitergeführt werden kann.

Ich werde tatsächlich aus persönlichen Gründen fast nichts mehr am Projekt i-Telex machen können.
Das einzige was ich noch tun kann, ist soweit möglich Erläuterungen zum Funktionsprinzip zu geben.
Ich finde allerdings, dass ich die grundsätzliche Funktionsweise schon relativ gut dokumentiert habe, also Protokoll-Spezifikation usw.
Der Code des i-Telex selbst ist grauenvoll.

Es sollte so sein das sich jemand in den Code einarbeiten kann und auch in der Lage ist Problemen nachzugehen. Mir ist das leider nicht gelungen eine lauffähige Version zu erzeugen, eigentlich kopiert Atmel Studio alles in das Projektverzeichnis ein make im Projektverzeichnis sollte sich das Projekt übersetzen lassen. Nur ich habe keine Quelle gefunden wo nicht Dateien fehlten .

Wenn du es wirklich möchtest, dann versuche ich mal eine Funktionierende Anleitung zum "Build from scratch" zu schreiben.
Das halte ich aber für ziemlich zwecklos, weil (wie erkannt) Sackgassse...

Das Projekt ist super und ich respektiere natürlich eure Arbeit, ich bin auch ehrlich eine komplette Lösung werde ich auch nicht liefern können.

Schade. Muss ja nicht heute und nicht morgen sein und vor allem nicht allein...
Es gibt schon Konzepte für mehr oder weniger neue Hardware-Platformen.

Ich habe auch ein "halb-fertiges" Design, um die bestehende Hardware des i-Telex mit einer neuen Hardware für die Ethernet-Kommunikation zu verknüpfen. Das heißt, dass die Bus-Struktur des jetzigen i-Telex und damit die Schnittstellenkarten beibehalten werden können und "nur" was Neues für die Ethernet-Karte gebraucht wird.

[damarco]

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.

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...

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 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