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.
:
Bearbeitet durch User
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: > 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.. http://www.ti.com/product/sn65hvd1476 RS485 mit 50MBit http://www.linear.com/product/LTC1688 RS485 mit 100MBit
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.