Telexforum.de

https://de.wikipedia.org/wiki/PHY

Da wie schon erwähnt durch den Protokoll Overhead per SPI es viel zu langsam wäre. Die Controller haben trotzdem noch SPI aber nur um sie zu konfigurieren oder Status Informationen zu bekommen.

Es gibt sogar Mikrocontroller da ist solch eine PHY schon drauf und man muss nur noch den RJ45 anbinden.

damarco hat geschrieben: ↑Fr 15. Mär 2024, 10:52 https://de.wikipedia.org/wiki/PHY
Da wie schon erwähnt durch den Protokoll Overhead per SPI es viel zu langsam wäre. Die Controller haben trotzdem noch SPI aber nur um sie zu konfigurieren oder Status Informationen zu bekommen.

Ich kann da auch nur schwer folgen. Wieso ist SPI zu langsam für i-Telex?
Und du hattest den W5500 ins Spiel gebracht und dann ist er plötzlich doch nicht geeignet?

Ich denke, es ist einfacher einem ESP32 eine Ethernet-Schnittstelle zu verpassen als einen Controller mit Ethernet zusätzlich mit WLAN auszustatten.

Schon bei der jetzigen Hardware hast du zwar einen 10Mbit Connect aber der AVR ist nicht in der Lage 10Mbits zu verarbeiten. Bei TCP/IP gibt es eine Flusskontrolle, mit UDP fallen Pakete hinten herunter. Die jetzige Hardware packt gerade einmal ein Connect und ist in der Lage den Datenstrom vom Protokoll zu verarbeiten. 50Baud sind ja lächerlich in Bezug auf Ethernet und wenn man die Daten komprimiert in eine Payload packt ist die Datenrate noch geringer.

Schon wenn zufiel Broadcast im Netz ist kann diese dazu führen das das System gestört wird. Da der AVR mit dem Verarbeiten jener beschäftigt wird.

Der W5500 hat nicht so ganz das Problem da dieser vieles im Stack erledigt ohne die CPU zu beschäftigen. Ins besondere Ethernet Dienste wie Ping,ARP usw. Beim ARP gibt es allerdings ein Problem mit dem W5500, das Register kann nur eine MAC Adresse speichern. Jeder Connect zu einen anderen Ziel löst einen ARP request aus. Bei UDP nervig und man muss sich ein eigenes Table mit den MAC Adressen bauen und diese in Register schreiben.

Der W5500 hat auch mehrere Macken und wer weiß ob diese noch in 10 Jahren Produziert wird.

Beim ESP32 wird das WLAN in der Software gelöst also ein ARM Kern macht nur das WLAN und das Teil ist auch sehr seltsam. Mir ist es passiert das sich Projekte die 5 Jahre alt werden nicht mehr übersetzen lassen, da man massiv in der IDF eingegriffen hat. Das will niemand ein Projekt praktisch 5 Jahre später neu zu bauen.

Wenn man ein Linux Board benutzt stellen sich solche Entwicklerfragen nicht und die PHY hat meist auch 1Gbit/s. Es ist schon heute so das bei Switches keine 10Mbit/s links mehr zu stand kommen können. Zudem kann es schon sein das ein 10Mbit Link durch Broadcast im Netz zugestopft wird. Die sollte man im Heimnetz auch nicht unterschätzen der ganze IOT Kram macht sich großzügig im Netz bekannt und Video oder Musikstreams können mit alter Hardware auch als Broadcast auf den i-telex Port landen.

Das Thema Hardware sollte klar in zwei Bereiche getrennt werden:

1. die Hardware, die Platform für die Implementierung der Ethernet-bezogenen Kommunikation und der Systemverwaltung usw. ist. Da ist es unstrittig, dass neue Hardware unabdingbar für ein zukunftsfähiges System ist.

2. die Hardware, die letztendlich nah an der i-Telex-internen Kommunikation beteiligt ist, also alles was letztendlich nur 50 Baud benötigt.
Diese Hardware kann m.E. auch künftig (bzw. in der aktuellen Neuentwicklungs-Phase) mit 8-bit-AVR laufen.
Die "Beantspruchung" dieser Hardware-Teile ist momentan relativ geriing: Das Maximum ist, dass für jeden Pegelwechsel auf der 50 Baud Seite (also alle 20 ms) ein Telegramm aus 2 Byte von TWI-Busteilnehmer A zu TWI-Busteilnehmer B gesendet wird.
Die Bitrate des Telegramms selbst ist aktuell auf 100 kHz "definiert" um eine gute Störsicherheit zu haben.
Somit benötigt jedes TWI-Telegramm 0,1 ms "Platz" auf dem TWI-Bus, somit können einige Verbindungen gleichzeitig auf dem TWI-Bus gleichzeitig bestehen.

damarco hat geschrieben: ↑Fr 15. Mär 2024, 16:40 Schon bei der jetzigen Hardware hast du zwar einen 10Mbit Connect aber der AVR ist nicht in der Lage 10Mbits zu verarbeiten. Bei TCP/IP gibt es eine Flusskontrolle, mit UDP fallen Pakete hinten herunter. Die jetzige Hardware packt gerade einmal ein Connect und ist in der Lage den Datenstrom vom Protokoll zu verarbeiten. 50Baud sind ja lächerlich in Bezug auf Ethernet und wenn man die Daten komprimiert in eine Payload packt ist die Datenrate noch geringer.

Schon wenn zufiel Broadcast im Netz ist kann diese dazu führen das das System gestört wird. Da der AVR mit dem Verarbeiten jener beschäftigt wird.

Der W5500 hat nicht so ganz das Problem da dieser vieles im Stack erledigt ohne die CPU zu beschäftigen. Ins besondere Ethernet Dienste wie Ping,ARP usw. Beim ARP gibt es allerdings ein Problem mit dem W5500, das Register kann nur eine MAC Adresse speichern. Jeder Connect zu einen anderen Ziel löst einen ARP request aus. Bei UDP nervig und man muss sich ein eigenes Table mit den MAC Adressen bauen und diese in Register schreiben.

Der W5500 hat auch mehrere Macken und wer weiß ob diese noch in 10 Jahren Produziert wird.

Beim ESP32 wird das WLAN in der Software gelöst also ein ARM Kern macht nur das WLAN und das Teil ist auch sehr seltsam. Mir ist es passiert das sich Projekte die 5 Jahre alt werden nicht mehr übersetzen lassen, da man massiv in der IDF eingegriffen hat. Das will niemand ein Projekt praktisch 5 Jahre später neu zu bauen.

Wenn man ein Linux Board benutzt stellen sich solche Entwicklerfragen nicht und die PHY hat meist auch 1Gbit/s. Es ist schon heute so das bei Switches keine 10Mbit/s links mehr zu stand kommen können. Zudem kann es schon sein das ein 10Mbit Link durch Broadcast im Netz zugestopft wird. Die sollte man im Heimnetz auch nicht unterschätzen der ganze IOT Kram macht sich großzügig im Netz bekannt und Video oder Musikstreams können mit alter Hardware auch als Broadcast auf den i-telex Port landen.

Mag alles sein, begründet aber nicht unmittelbar den Bedarf für neue Hardware MIT AUSNAHME der CPU und Peripherie für die Ethernet-Kommunikation.

Oder übersehe ich etwas?

Viele Grüße,

Fred

damarco hat geschrieben: ↑Fr 15. Mär 2024, 16:40 Wenn man ein Linux Board benutzt stellen sich solche Entwicklerfragen nicht und die PHY hat meist auch 1Gbit/s.

Bei Linux bitte noch berücksichtigen, dass man das System jederzeit abschalten können muss, ohne dass es das Filesystem zerhaut.
Beim piTelex wird das einfach gemacht (das Abschalten), aber bei einem Einsatz von Werner und Franz im MfK in Frankfurt hat es möglicherweise die Config zerhauen - die genau Ursache ist aber unklar. Bei uns in der Firma zebröselt es auch öfter mal das Filesystem von Raspis, die öfter ein- und ausgeschaltet werden.

Beim Raspi löst man das meines Wissens mit einem Readonly-Filesystem - kein Ahnung, wie das funktioniert.

Aber das sollte als Anforderung klar sein, dass sich niemand jedesmal mit SSH auf den Controller verbindet um ihn runterzufahren.
Selbst ein Taster zum Runterfahren wird in der Praxis sicher eher selten benutzt werden. Bei Museen und auch bei Veranstaltungen wird einfach zentral abgeschaltet.

Deswegen werden die RPIs ungern in Museen gesehen, in vielen Ausschreibungen steht drin "Kein Raspberry Pi", es zerhaut auch SD-Karten nur vom Lesen. Bei Playern oft ein Problem, mit SD Karten aus der Industrie gab es dann keine Probleme mehr. Sonst war mal 1 Jahr die Karte defekt, es fehlten den Frames oder etc.

Aber dein Einwand ist schon richtig, aber rein Read only geht nie. Aber es gibt schon Möglichkeiten bzw. Dateisystem die da sehr tolerant sind. Auch bei i-telex kann dir es passieren wenn du beim schreiben in den externen RAM ausschaltest das dort Murks drin steht. Man muss dann schauen das beim einbrechen der Spannung noch soviel zeit bleibt das schreiben das Dateisystem ordentlich zu schließen. Dazu gibt es ja den brownout detector...

Ohnehin aber wir ein Problem mit der Spannungsversorgung, denn mit 5V und 1A wird das mit einem RPI nichts. Wenn es Hart kommt muss das Netzteil angepasst werden und da kann man auch gleich ein Signal bilden wenn die Spannung einbricht. Dann bleibt noch soviel Restenergie das System zu sichern.

Das wäre ein Punkt wo es sich lohnt ohne einem RPI als Hauptrechner auszukommen oder die Karte muss ein Netzteil enthalten. Aber auch 5V und 3A werden über den Bus er grenzwertig sein.

FredSonnenrein hat geschrieben: ↑Fr 15. Mär 2024, 17:17 Oder übersehe ich etwas?
Fred

Erstmal nicht man kann die TWI Kommunikation auch mit dem RPI machen, aber das wäre sehr speziell für den dort verbauten ARM. Das klappt nicht aus dem Userspace mit einem Kernelmodul schon. Um das aber zu vermeiden und die Plattform des Hauptrechners offen zu halten würde ich es genau so vorschlagen wie du.

Man könnte auch den AVR mit dem TWI Code belassen und per SPI eine Brücke zum Hautrechner bauen. Den TWI Code müsste man nur aus dem Projekt extrahieren.

Aber lass mich erst mal den Grundlagen basteln

Das Ziel ist ja die Bibliothek als der Code des i-Telex Protokolls soll für alles nutzbar sein. So das andere diese verwenden können und andere Applikationen basteln können. Vielleicht macht auch noch jemand eine arduino Bibliothek draus...

Hallo zusammen,

damarco hat geschrieben: ↑Fr 15. Mär 2024, 23:18
FredSonnenrein hat geschrieben: ↑Fr 15. Mär 2024, 17:17 Oder übersehe ich etwas?
Fred
Erstmal nicht man kann die TWI Kommunikation auch mit dem RPI machen, aber das wäre sehr speziell für den dort verbauten ARM. Das klappt nicht aus dem Userspace mit einem Kernelmodul schon. Um das aber zu vermeiden und die Plattform des Hauptrechners offen zu halten würde ich es genau so vorschlagen wie du.

Dann sind wir uns ja einig, dass die Schnittstellen-Baugruppen (ED1000, TW39, RS232) erstmal so bleiben wie sie sind.
Die benutzen narürlich TWI, aber da diese nicht an Ethernet-Kommunikation beteiligt sind, ist performance kein Thema.

damarco hat geschrieben: ↑Fr 15. Mär 2024, 23:18 Man könnte auch den AVR mit dem TWI Code belassen und per SPI eine Brücke zum Hautrechner bauen. Den TWI Code müsste man nur aus dem Projekt extrahieren.

Was ist der "Hauptrechner"? Das Modul dass die Ethernet-Kommunikation macht, vermute ich.
Ja, sowas schwebt mir vor. Ein kleines Stück Hardware, das auf der einen Seite direkt kompatibel zum TWI-Protokoll auf dem i-Telex-Bus ist und auf der anderen Seite der "neuen" Hardware des i-Telex ist (meinetwegen SPI, aber ich sehe keine wesentlichen Unterschiede zwischen SPI und TWI).

damarco hat geschrieben: ↑Fr 15. Mär 2024, 23:18 Aber lass mich erst mal den Grundlagen basteln Das Ziel ist ja die Bibliothek als der Code des i-Telex Protokolls soll für alles nutzbar sein. So das andere diese verwenden können und andere Applikationen basteln können. Vielleicht macht auch noch jemand eine arduino Bibliothek draus...

Mach mal, hast du auch schon mal mit Jochen Kontakt gehabt?

Hi,

Jochen habe ich die die Tage privat angeschrieben und auf diesen Thread hingewiesen. Er scheint gerade sehr eingespannt zu sein und leider wenig Zeit für Telex-Angelegenheiten zu haben.
mWn hatte er bereits seit einiger Zeit schon Gedanken zu einer "generellen" Neuimplementierung angestellt - das soll er jedoch selbst vortragen, so er möchte.

LG,
Simon

Also physikalische Schnittstelle zwischen dem Hauptrechner und dem TWI Controller ist relativ egal. Es muss nicht einmal SPI sein sondern könnte auch aus einer Seriellen Schnittstelle bestehen. 250kbit/s sind ja mit 16MHZ nicht das Problem, aber später ein neuer Flaschenhals.

Ob der Hauptrechner nun mit oder ohne OS funktioniert muss man noch mal diskutieren. Ich bin ja für ein OS wie Linux, ohne OS ist der Code nur auf dem Prozessor lauffähig. ARM verkauf ja nur die Lizenz und die Hersteller bauen die Hardware herum und was den RPI betrifft dessen Dokumentation vom Prozessor steht unter NDA. Man bekommt also keine Informationen über die Register und ist auf andere angewiesen die Treiber implementieren.

Der Code vom AVR ist relativ portable zwischen den Prozessoren, ewt. sind Register anderes definiert.

Also wenn es da schon Ideen gibt bin ich dafür sehr offen mich dort einzuklinken. Sowie so ist es besser dies auf mehren Schultern zu verteilen und ich bin bereit meinen Teil dazu beizutragen.

Telexforum.de

Neuimplementierung von i-Telex

Neuimplementierung von i-Telex

Neuimplementierung von i-Telex

Neuimplementierung von i-Telex

Neuimplementierung von i-Telex

Neuimplementierung von i-Telex

Neuimplementierung von i-Telex

Neuimplementierung von i-Telex

Neuimplementierung von i-Telex

Neuimplementierung von i-Telex

Neuimplementierung von i-Telex