Hallo,
einmal kurze Frage:
Es gibt beim STM32 in der HAL-Lib ja den "Eth Generic Driver".
Auf den setzt normalerweise das IP-Stack dann auf für
Netzwerkkommunikation.
Habe das schonmal genutzt, aber das war damals so "Out of the box" von
ST welches direkt lief ohne tieferes Wissen haben zu müssen.
Ich bräuchte nun eine schnelle bidirektionale Verbindung zwischen zwei
STMs und bin am überlegen das über Ethernet zu machen.
Ist es möglich mithilfe des Treibers in die Mac Hardware einfach "Bytes
reinzusenden" ähnlich wie bei Uart und diese ebenfalls so zu empfangen
ohne den Overhead mit dem IP-Stack haben zu müssen?
Danke.
Ja. sicher. Das TCP/IP ist ein relativ aufwendiges Protokoll. Man kann's
einfacher machen. Ich wuerd man das Manual zu den Meglichkeiten des Chip
bezueglich diesem Interface anschauen. Igendwelch grosse Bloecke in
einen Buffer und Go!. Die Blockgroesse muss glaub kleiner wie 1500 byte
sein, das kann aber geaendert haben. Die kommen dann bei einer
Punkt-zu-punkt verbindung auf der anderen Seite an, ergeben einen
Interrupt und koennen gelesen werden.
Das ist dann ohne Switch, nur 1 Kabel.
Ethernet schrieb:> Ich bräuchte nun eine schnelle bidirektionale Verbindung zwischen zwei> STMs und bin am überlegen das über Ethernet zu machen.
Du brauchst Phys und Trafos (naja, die nicht zwingend), abe allein ein
Phy kostet fast soviel wie ein STM32. Das lohnt sich doch nicht.
Ich schlag mal eine SPI vor. Hab sowas mal mit PICs mit 20MHz
realisiert, das ist schon sehr schnell und full duplex. Ein STM32 kann
vermutlich noch mehr. Die Latenzen sind besser als Ethernet, soviel ist
sicher.
Wenns nicht ganz so schnell sein muss:
Für 2MBd oder so tuts eine normale UART noch.
Wenns ganz schnell sein muss:
Ein paralleles Interface wäre dann je nach Ausbau noch schneller als
Ethernet.
All das (also SPI, UART, Parallel) ist vom Aufwand DEUTLICH einfacher
als Ethernet.
SPI ist leider Schrott. Der Master ist trivial, der Slave ist es nicht.
Zudem ist ueblicherweise SPI nur einfach gebuffert. Der Slave muss also
innerhalb eines Bytes reagieren, sonst ist der Inhalt ueberschrieben.
Dampf T. schrieb:> SPI ist leider Schrott. Der Master ist trivial, der Slave ist es> nicht.> Zudem ist ueblicherweise SPI nur einfach gebuffert. Der Slave muss also> innerhalb eines Bytes reagieren, sonst ist der Inhalt ueberschrieben.
Dir ist schon klar, dass SPI einer der häufigsten "Busse" in der µC-Welt
ist?
Und das Mittel der Wahl, wenn es um große Datenmengen mit wenigen
Leitungen geht, wie bei ADC oder dicken Speichern über kurze Strecken.
Also Schrott... Mit der Meinung dürftest du recht einsam dastehen.
Was den Buffer angeht:
Der DMA schafft das immer. >20MHz SPI ohne DMA ist eh sportlich. Und mit
DMA kannst du den Buffer so groß machen wie du willst. Selbst mit DMA
ist das um Größenordnungen einfacher als Ethernet.
Der ST32 wird mit >20MBIt ohne DMA eh so seine liebe Not haben.
Das der Slave nicht ganz untrivial ist, ändert daran wenig. I2C ist auch
nicht untrivial, trotzdem ist es verbreitet.
Hurra schrieb:> Du brauchst Phys und Trafos (naja, die nicht zwingend), abe allein ein> Phy kostet fast soviel wie ein STM32. Das lohnt sich doch nicht.
Das stimmt schon, aber in einem STM32 findest du nichts, womit man
größere Datenmengen vernünftig und störsicher über größere Distanzen
übertagen kann. Du wirst dir immer Gedanken über externe Treiber machen
müssen.
UART mit TTL Pegel? Wohl kaum. Da braucht es mindestens mal einen RS232
Treiber, besser vielleicht RS485? Und damit schafft man dann 1-2 MBaud..
SPI? Auf kurze Distanz ganz nett. Dummerweise aber halt synchron. Schon
mal was von Signallaufzeit gehört. Bei 10 MHz hast 100ns für den Weg der
Taktflanke hin bis Signal vom Slave zurück. Selbst ohne Setup- und
Hold-Time ist da (von ein paar Tricks abgesehen) bei 15m Schluss.
Ethernet ist da gar keine so schlechte Idee.
stefan schrieb:> Das stimmt schon, aber in einem STM32 findest du nichts, womit man> größere Datenmengen vernünftig und störsicher über größere Distanzen> übertagen kann. Du wirst dir immer Gedanken über externe Treiber machen> müssen.
Von größeren Längen war nicht die Rede, aber da hast du recht, da ist
Ethernet in Punkto Geschwindigkeit und Robustheit recht gut.
Drum gibts da ja auch µCs damit.
Nur ist Ethernet leider auch technisch aufwändig und teuer, weshalb es
für kurze Strecken nicht so prickelnd ist.
Eine nennenswerte Alternative ist UART über RS485. So bis 10MBit kommt
man damit auch über 100m.
Ohne TCP/IP hast du auch kein ARP. Ob in den letzten 20 Jahren irgendein
Hersteller getestet hat, ob sein Switch auch ohne ARP-Broadcasts
funktioniert?
Ethernet schrieb:> Hallo,>> einmal kurze Frage:>> Es gibt beim STM32 in der HAL-Lib ja den "Eth Generic Driver".> Auf den setzt normalerweise das IP-Stack dann auf für> Netzwerkkommunikation.> Habe das schonmal genutzt, aber das war damals so "Out of the box" von> ST welches direkt lief ohne tieferes Wissen haben zu müssen.>> Ich bräuchte nun eine schnelle bidirektionale Verbindung zwischen zwei> STMs und bin am überlegen das über Ethernet zu machen.>> Ist es möglich mithilfe des Treibers in die Mac Hardware einfach "Bytes> reinzusenden" ähnlich wie bei Uart und diese ebenfalls so zu empfangen> ohne den Overhead mit dem IP-Stack haben zu müssen?>>> Danke.
Naja, so ganz trivial ist es nicht. Selbst wenn Du die Schicht 1
komplett zur Verfügung stehen hast (also PHY, passender PHY Treiber
incl. MII/RMII/ Phy Adresse etc), mußt Du auch noch eine MAC Adresse
haben (im reinen Point-to-Point Betrieb kannst Du Dir die auch
ausdenken) und über die ETH Initialisierung in den MAC programmieren.
Wenn das Alles klappen sollte, kannst Du theoretisch die Pakete direkt
an der ETH Schnittstelle abfangen. Du mußt dann noch Ziel-und Start MAC
Adresse an den Anfang jedes Paketes setzen, das Du schickst (oder den
MAC im promiscuous Mode benutzen).
Du brauchst aber gar nicht erst auf die Idee zu kommen, das außerhalb
einer reinen Punkt-zu-Punkt Verbindung zu nutzen (jeder Switch wird beim
Versuch, deine Pakete irgendwie zuzuordnen, mit einer hohen
statistischen Wahrscheinlichkeit irgendwann denken, es sei ein
halblebiges "gültiges" Paket der TCP/IP Suite und das Netz damit
ordentlich durcheinander wirbeln. Umgekehrt müßte deine Software
zuverlässig jedes "gültige" Paket aus der IP Suite ausfiltern, denn
davon flutschen in jedem Netz etliche durch die Gegend). Da die meisten
Switches heutzutage eine zumindestens rudimentäre Form der Intelligenz
implementieren, in deren Rahmen sie sich jedes Paket auf dem Netz
irgendwie ansehen, wird vermutlich auch ein Switch als Verlängerung der
Strecke deiner proprietären Pakete ausfallen (da ginge höchstens nur ein
strunzdummer repeater).
Das Einbinden eines TCP stacks in einen Cortex ist nicht so wild
(Vorsicht Eingenwerbung: ich widme in meinem Buch ein Kapitel der
Hostkommunikationsstrategie, und da ist auch ein Kochbuch zum Einbinden
von Netzwerkmiddleware am Beispiel ST drin).
Falls die Leitung doch mal etwas länger werden sollte:
stefan schrieb:> SPI? Auf kurze Distanz ganz nett. Dummerweise aber halt synchron. Schon> mal was von Signallaufzeit gehört. Bei 10 MHz hast 100ns für den Weg der> Taktflanke hin bis Signal vom Slave zurück. Selbst ohne Setup- und> Hold-Time ist da (von ein paar Tricks abgesehen) bei 15m Schluss.
Die Signallaufzeit ist nur ein Problem für den empfangenden Master.
Ein Multimastersystem hätte diese Probleme nicht, die Busumschaltung
muss ein Protokoll regeln.
Das weitverbreitete SSI hat dieselben Probleme. Deswegen kann man bei
vielen Mastern eine Kompensationszeit einstellen.
Ethernet schrieb:> Ich bräuchte nun eine schnelle bidirektionale Verbindung zwischen zwei> STMs und bin am überlegen das über Ethernet zu machen.
Was spricht gegen RS485 oder RS422? Da kannste mit 'nem UART einfach
Bytes raussenden und empfangen. Vieeel preiswerter als Ethernet - falls
beide Seiten auf demselben Massepotential liegen.
Die Ultra-high-speed RS485 Treiber von Hermann Mustermann würde ich aber
nicht unbedingt einsetzen wenn es geht. Langsame Flanken produzieren
weniger störendes HF, und so hoch bekommt man die UARTs auch
normalerweise nicht getaktet.
Ethernet würde ich nur dann einsetzen wenn ich vorhandene Verkabelung
mit Switchen nutzen muss. Dann musst Du zumindest den IP Teil von TCP/IP
einbauen.
Vorschlag: 2* SPI, auf einem F7 geht das mit 54 MBit/s pro SPI. Dazu
schnelle RS4xx Treiber oder wenn die Leitungen laenger werden sollen,
LVDS. Kopplung mit TP Kabel, wie 2 mal Ethernet Kabel oder TP Flachband.
Noch einer schrieb:> Ohne TCP/IP hast du auch kein ARP.
Richtig.
> Ob in den letzten 20 Jahren irgendein> Hersteller getestet hat, ob sein Switch auch ohne ARP-Broadcasts> funktioniert?
Ganz sicher. Da ein gut Teil der Switche sowieso nur auf Layer2 arbeitet
und somit keinerlei Ahnung von TCP/IP im Allgemeinen und ARP im
Besonderen hat, ist den Teilen einfach mal vollkommen scheißegal,
welchen inneren Inhalt höherer Protokolle ein eingehendes Layer2-Paket
hat. Es hat eine gültige Quell-MAC und eine gültige Ziel-MAC zu haben
und genau nur dafür interessiert sich der Switch, mehr weiß er nicht und
mehr braucht er auch nicht zu wissen, um seinen Job machen zu können.
Und bei den Layer3-Switches sieht das nur theoretisch anders aus. Auch
die handeln praktisch immer auf so niedrigem Protokoll-Level, wie
irgendwie möglich, d.h.: was sich rein auf Layer2 abhandeln läßt, wird
natürlich auch auf Layer2 behandelt. Warum? Weil man immer mehr rechnen
muss, je weiter man im Protokollstack aufsteigt. Und Rechenzeit kostet
letztlich Geld in Form von Hardware und der Energie dafür...
