es gibt hier ein Thread von vor 11 Jahren... Mittlerweile hat sich da ja recht viel getan, hat schon jemand was in die Richtung gemacht? Gibt es Empfehlungen welcher Hersteller auch brauchbare Frameworks mitliefert? Gebraucht wird nur UDP und der Rest der Logik dürfte recht überschaubar sein. Bischen was mit Timern und jede Menge Daten von einem 16-fach SPI zu Ethernet schaufeln. Oder doch besser in die CPLD/FPGA Schublade greifen?
Kommt drauf an, was du machen willst. Vor zehn Jahren hatte Keil ein rtOS, was mit dem STM32 sauber TCP/IP. Konnte. Ob das dann 10/100/1000Mbit wurden entschied der PHY. Wenn du selber deinen Switch bauen möchtest, wird ein MuC nicht reichen um GBit auszulasten.
Klingt so, als ob du sowas besser mit einem FPGA machen solltest eigentlich. Grad so basic MAC/UDP frames lassen sich relativ einfach handhaben in purer HDL Logik. Da ist die Hürde im Regefall größer, den uc-proprietären Ethernet-Mac Treiber zu verstehen.
Markus W. schrieb: > Da ist die Hürde im Regefall größer, den uc-proprietären Ethernet-Mac > Treiber zu verstehen. Deswegen die Frage nach einem brauchbaren Framework vom Hersteller ;)
Noob A. schrieb: > Roland E. schrieb: >> Kommt drauf an, was du machen willst. > wie gesagt nur UDP Es wurde nicht nach dem "wie" gefragt, sondern nach dem "was". Noob A. schrieb: > Oder doch besser ... einfach mal beschreiben, was du denn mit den UDP Paketen überhaupt machen möchtest. Welche Informationen willst du denn da wie schnell ins Netz reinkippen?
GigE und uC beisst sich schon mal. 100MBit echtzeit und abrissfrei am theoretischen Limit zu streamen ist schon knifflig genug, typischerweise schreibst du deinen eigenen angepassten Stack auf der Basis einer gut funktionierenden Scatter-Gather-DMA-Architektur, bei der die CPU nur noch die Header der RTP-Pakete anpassen muss und die Buffer-Queue managt. Was willst du fuer Daten streamen? Anstatt per Durchsatz am Limit kommt man meistens mit Hardware-Kompression auch auf ganz gute Loesungen. Fuer ADC nach 100 MBit habe ich sowas aufm FPGA gemacht, allerdings performt da i2s besser als SPI.
Lothar M. schrieb: > Es wurde nicht nach dem "wie" gefragt, sondern nach dem "was". Wie gesagt bekomme ich über eine hexa-SPI Messdaten: 32 16bit-Werte grob alle 500ns (ist "bauartbedingt" etwas unregelmässig mit Pausen zwischendrin). Etwas über 1000 davon ergeben eine Messreihe und ca. alle 830µs wir eine neue Messreihe getriggert. Auch hier können Schwankungen auftreten. Mit noch ein paar Prozessdaten dazu, und dem UDP-Geraffel landen wir dann bei knapp 90Mbyte/s. An Komprimierung habe ich noch gar nicht gedacht, aber wenn, dann nur losless.
aufgeblasener SPI mit 16 Datenleitungen der neuste STM32 z.Bsp. hat sowas: https://www.st.com/en/microcontrollers-microprocessors/stm32n6-series.html
Das ganze schreit doch nach einem Zynq o.ä.. Dort gibt es mittels Linux, Zephyr usw. einen ordentlichen Netzwerkstack. Dann den ganzen SPI-Teil als eigenen Block in die PL, so dass die Daten dort schon richtig angeordnet werden, ohne dass das PS noch irgendetwas umsortieren muss. Die Applikation kann dann sehr minimalistisch zwischen UIO-Device und Netzwerksocket umschaufeln.
STM32MP und STM32N6 haben auch GBit Ethernet, STM32N6 ist eher ein uC. STM32MP ohne Linux etc duerfte schwieriger sein.
Ja, Zynq geht bestimmt auch super für so etwas. Ich persönlich würde es vermutlich komplett in HDL umsetzen. Ethernet low-level zu machen ist wie gesagt nicht super schwierig solange es nur basic mac/udp frames sind. Ansonsten würde mir jetzt noch XMOS als sinnvolle Alternative einfallen. Die haben recht flexible IO-blocks, die sich je nach Konfiguration auch als 16-Bit shift-port nutzen lassen würden. Die kommen da auch vom Timing bei so schnellen Sachen gut mit. Und sie supporten auch offiziell RGMII / GBit Ethernet.
Andreas S. schrieb: > Das ganze schreit doch nach einem Zynq o.ä.. Dort gibt es mittels Linux, > Zephyr usw. einen ordentlichen Netzwerkstack Mit dem OS-Overhead von Linux brockt man sich u.U. eine gehoerige Latte anderer Probleme ein und verliert die Echtzeitkontrolle. Und ja, ich kenne RTLinux/Xenomai, usw, da gibt es die Stolperfallen immer noch, schlimmstenfalls entwickelt man Kerneltreiber neu, dieses Risiko sollte man im Hinterkopf behalten. Das SPI-Subsystem ist nicht auf Echtzeit ausgelegt, muss man andernfalls komplett in HW machen und sich abermals mit Kernelkram herumschlagen. BTDT, mit einem ollen Spartan6 geht's auch bare-metal. Das groesste Problem ist, dass man die Zynq-Geschichte nicht effektiv oder nur sehr nondeterministisch in die Cosimulation stecken kann, um Probleme zu identifizieren.
Uwe B. schrieb: > STM32MP und STM32N6 haben auch GBit Ethernet, STM32N6 ist eher ein uC. > STM32MP ohne Linux etc duerfte schwieriger sein. OK, hatte bisher noch keine Berührungspunkte mit den MPUs... Was ist denn daran so besonders/anders, dass das schwierig wird?
Markus W. schrieb: > Da ist die Hürde im Regefall größer, den uc-proprietären Ethernet-Mac > Treiber zu verstehen. OK, ich hab mal spasseshalber ein Projekt in der Cube-IDe mit dem STM32N65xx angelegt... Da gehts dann los dass es vorgefertigt schonmal in 3 verschiedene Unterprojekte gibt: einen First Stage Boot Loader, die Application und dann noch einen external memory loader https://www.st.com/resource/en/user_manual/um3249-getting-started-with-stm32cuben6-for-stm32n6-series-stmicroelectronics.pdf Scheint mir alles sehr stark darauf ausgelegt zu sein einen vorgetrampelten Pfad bei der Entwicklung einzuschlagen Und ich habe SEHR schlechte Erfahrungen mit der HAL von STM gemacht
Moin, Ich wuerde auch in Richtung FPGA tendieren, aber wenns eines ohne CPU/Linuxgedoens ist, vorher noch mal stark in mich gehen, was ich noch ausser UDP brauche. So'n bisschen Beiwerk wie ARP, DHCP, ICMP kann manchmal nicht schaden, koennte aber im FPGA dann doch schnell ausufern... Gruss WK
Martin S. schrieb: > Das SPI-Subsystem ist nicht auf Echtzeit > ausgelegt, Weswegen schrieb ich wohl "den ganzen SPI-Teil als eigenen Block in die PL"?
Der erwähnte STM32MP ist eine teure jedoch einfache Lösung. SPI, Timer und der gleichen auf dem ARM M4 laufen lassen und über den internen bus die Daten zum ARM A7 "transferieren" auf dem ein Linux läuft und sich um die Netzwerkkommunikation kümmert. Bei Gigabit ethernet als reiner MCU fällt mir noch sowas wie den HPmicro HPM6E ein mit RISC-V.
N. B. schrieb: > Der erwähnte STM32MP ist eine teure jedoch einfache Lösung. > SPI, Timer und der gleichen auf dem ARM M4 laufen lassen und über den > internen bus die Daten zum ARM A7 "transferieren" auf dem ein Linux > läuft und sich um die Netzwerkkommunikation kümmert. Klingt gut... wenn es jetzt noch ein demo-board gäbe wo die 2 8xSPI rausgeführt / nicht anderweitig benutzt sind :(
Noob A. schrieb: > Klingt gut... wenn es jetzt noch ein demo-board gäbe wo die 2 8xSPI > rausgeführt / nicht anderweitig benutzt sind :( Also wieder Salamitaktik vom Feinsten... Diese doch nicht ganz unwichtige Randbedingung wurde natürlich wieder wochenlang verschwiegen.
Andreas S. schrieb: > Noob A. schrieb: >> Klingt gut... wenn es jetzt noch ein demo-board gäbe wo die 2 8xSPI >> rausgeführt / nicht anderweitig benutzt sind :( > > Also wieder Salamitaktik vom Feinsten... Diese doch nicht ganz > unwichtige Randbedingung wurde natürlich wieder wochenlang verschwiegen. Dass der OP viele SPI nutzt steht in der Frage. Nachwievor ist aber unklar, warum er der Meinung ist einen FPGA oä und Gigabit nutzen zu wollen. Über die tatsächlich anfallende Menge der Daten schweigt er sich nach wie vor aus. Da er UDP nutzen möchte, scheint es nicht wirklich wichtig zu sein, denn von seinen Daten dürfen offenbar belibig viele verloren gehen.
Vielleicht gibt es keine konkreten Anforderungen, außer möglichst viel Bumms für die Werbebroschüre.
Andreas S. schrieb: > Noob A. schrieb: >> Klingt gut... wenn es jetzt noch ein demo-board gäbe wo die 2 8xSPI >> rausgeführt / nicht anderweitig benutzt sind :( > > Also wieder Salamitaktik vom Feinsten... Diese doch nicht ganz > unwichtige Randbedingung wurde natürlich wieder wochenlang verschwiegen. Das demo-board ist kein Muss, wäre aber schön weil man bei Fehlern nicht erstmal die HW im Verdacht hat...
Roland E. schrieb: > Über die tatsächlich anfallende Menge der > Daten schweigt er sich nach wie vor aus. am 28.3. Beitrag "Re: µC und Gbit Ethernet" > Da er UDP nutzen möchte, > scheint es nicht wirklich wichtig zu sein, denn von seinen Daten dürfen > offenbar belibig viele verloren gehen. Wie viel Daten habt ihr denn so bei einer point-to-point Verbindung mit UDP verloren? Das funktioniert erstaunlich gut. In den oben erwähnten Prozessdaten ist auch ein bischen checksum etc drin. Aber bei 90Mbyte/s ist wenig Spielraum für retransmission. ... Man muss immer Kompromisse machen ...
Und, nein es sind nicht "viele" SPI, sondern ein hexa-SPI. Also ein Bus mit 16 Datenleitungen ... gut, zur Not kann man das auch "zu Fuß" machen, ist also auch keine so harte Anforderung. HW-interrupts und DMA könnten dabei behilflich sein.
Sherlock 🕵🏽♂️ schrieb: > Vielleicht gibt es keine konkreten Anforderungen, außer möglichst viel > Bumms für die Werbebroschüre. Dann kann er auch einen GBit Phy an einen 8-Bitter hängen... X-) Aus dem SPI des OP kommen nicht annähernd genug Daten, um eine 100MBit auszulasten, bin ich mir ziemlich sicher. Das GBit ist höchstens der Kompatibilität wegen sinnvoll. Ich denke nicht, dass der OP seinen SPI mit zweistelligen MHz taktet... @strippenzieher: Ich selber habe es noch nie geschafft, einen Switch so vollzumachen, dass er UDP-Pakete dropt. Man muss aber eben davon ausgehen, dass es passiert und dann halt auch WorstCase.
Nicht, daß ich es nicht schon geschrieben hätte... Dann halt noch mal im Detail: Es fallen pro Messung 1152 x 32 x 2 byte an dazu noch pro Messung 96 byte Prozessdaten also knapp über 72kb d.h. wir brauchen 51 Pakete (max. 1500 byte mit je 28 byte obverhead) bei 1200 Messungen pro Sekunde sind das (aufgerundet) 51 x 1500 x 1200 = 91.800.000 byte also 87,5Mb die jede Sekunde anfallen ... und... der "SPI" wird mit 40-50MHz getaktet sein
:
Bearbeitet durch User
Roland E. schrieb: > @strippenzieher: Ich selber habe es noch nie geschafft, einen Switch so > vollzumachen, dass er UDP-Pakete dropt. Man muss aber eben davon > ausgehen, dass es passiert und dann halt auch WorstCase. Klar ist das berücksichtigt... Und, ich sag mal ganz salopp: die Anwendung verkraftet es, wenn alle paar Tage mal ein Paket fehlt und eine komplette Messung verworfen werden muss. Bisher läuft das aber so stabil dass wir quasi Null Ausfall über Jahre hatten
Noob A. schrieb: > sondern ein hexa-SPI. > > Also ein Bus mit 16 Datenleitungen ... "Hexa" steht übrigens für sechs, nicht für 16. Das "Dezimal" in "Hexadezimal" kommt nicht von ungefähr. Du solltes keine Fantasiebegriffe erfinden. Was für ein Gerät/Bauteil soll so einen "SPI"-Bus haben?
Roland E. schrieb: > Aus dem SPI des OP kommen nicht annähernd genug Daten, um eine 100MBit > auszulasten, bin ich mir ziemlich sicher. Schreibt er aber hier Beitrag "Re: µC und Gbit Ethernet" Er kommt darin auf 90MByte/s meint aber vermutlich 90MBit/s. Und das ist halt für 100Base-TX grenzwertig. Also brauchts einen Controller der ein GBit PHY treiben kann. Der schon vorgeschlagene STM32N6 sollte das schaffen. Daten rein mit PSSI -> DMA raus dann per DMA -> Ethernet. Matthias
Hab nicht ich erfunden: https://www.st.com/en/microcontrollers-microprocessors/stm32n6-series.html und ja, hexadeca-SPI oder wäre richtiger 16xSPI ist aber recht eindeutig, gell?
Μαtthias W. schrieb: > Er kommt darin auf 90MByte/s meint aber vermutlich 90MBit/s. Nein! meint er nicht! Man könnte lesen was da steht und nachrechnen... Ich habs aber nochmal detaillierter aufgedröselt: Beitrag "Re: µC und Gbit Ethernet"
Roland E. schrieb: > Dass der OP viele SPI nutzt steht in der Frage. Das schon, aber plötzlich wurde die harte Anforderung nachgereicht, dass es ein Demoboard geben muss, auf dem alle benötigten SPI-Kanäle herausgeführt sind. Und das dampft die Auswahl an Microcontrollerboards schon fast (oder ganz?) auf Null ein. Somit kommen hauptsächlich nur noch FPGA-(Aufsteck-)Boards infrage. Mittlerweile hat der TE diese Anforderung aber wieder aufgeweicht.
:
Bearbeitet durch User
Ja, das war unglücklich formuliert... Tut mir leid wenn ich für Verwirrung gesorgt habe! Dennoch, schön wärs wenn es sowas geben tät :) Bei selbstgemachten boards bleibt im Fehlerfall immer ein Zweifel ob man was in der HW falsch gemacht hat... Wobei, ST ja großzügigerweise viel Doku zur Verfügung stellt und man es nachbauen könnte..
Noob A. schrieb: > Das demo-board ist kein Muss, wäre aber schön weil man bei Fehlern nicht > erstmal die HW im Verdacht hat... Heutige Demoboards sind meist so mit Peripherie vollgestopft, dass die Schwarte kracht. Die bleibt kaum ein Pin frei, und das nachträgliche Herunterlöten/Pinhochbiegen/Leiterbahnaufkratzen ist ebenfalls extrem fehlerträchtig und unpraktisch. Warum also kein Aufsteckmodul, bei dem nahezu alle Peripheriepins herausgeführt sind und auf dem Board nur die wichtigsten Funktionen (Stromversorgung, Reset, Takt, ggf. zusätzlicher Speicher) realisiert sind? Ich nutze für Kleinserienprodukte bevorzugt die entsprechenden (FPGA-)Module von Trenz. https://shop.trenz-electronic.de/de/Produkte/Trenz-Electronic/
Noob A. schrieb: > Μαtthias W. schrieb: >> Er kommt darin auf 90MByte/s meint aber vermutlich 90MBit/s. > > Nein! meint er nicht! > Man könnte lesen was da steht und nachrechnen... > > Ich habs aber nochmal detaillierter aufgedröselt: > Beitrag "Re: µC und Gbit Ethernet" Stimmt. Da ist mir was durch. Jetzt sag ich nur noch das der STM32N6 das schaffen könnte. Könnte man mit https://www.st.com/en/evaluation-tools/nucleo-n657x0-q.html#overview relativ schnell testen ob das hinhaut. Die XSPI Einheit passt aber nicht. Die agiert als SPI Host. Der OP braucht aber ein Device. Also doch PSSI.
Das Nucleo-board ist leider nicht verfügbar :/ Und Danke für den Hinweis mit SPI-Device. Ist mir glatt entgangen 8-0 Die Nucleos find ich eh toll, sind eine erfrischende Ausnahme zu dem was Andreas S. schrieb: > Heutige Demoboards sind meist so mit Peripherie vollgestopft, dass die > Schwarte kracht. Die bleibt kaum ein Pin frei
:
Bearbeitet durch User
Noob A. schrieb: > Gibt es Empfehlungen welcher Hersteller auch brauchbare Frameworks > mitliefert? https://www.segger.com/products/connectivity/emnet/ Xilinx Zynq XC7Z007S SoC: https://www.segger.com/evaluate-our-software/segger/#segger-empower-zynq
Til S. schrieb: > Noob A. schrieb: >> Gibt es Empfehlungen welcher Hersteller auch brauchbare Frameworks >> mitliefert? > > https://www.segger.com/products/connectivity/emnet/ > > Xilinx Zynq XC7Z007S SoC: > https://www.segger.com/evaluate-our-software/segger/#segger-empower-zynq Danke :)
Noob A. schrieb: > Klingt gut... wenn es jetzt noch ein demo-board gäbe wo die 2 8xSPI > rausgeführt / nicht anderweitig benutzt sind :( Falls es keine devboards gibt SOM kaufen und ein breakout board selber erstellen. DH-electronics hat das Avenger96 für deren SOM. Olimex hat SOM. Das was ST unter der STM32MP verkuft gibt es auch von NXP. Dort läuft das unter NXP i.MX crossover. Bisher noch nie verwendet vondaher kann ich dir nichts dazu sagen außer das es die gibt.
:
Bearbeitet durch User
Noob A. schrieb: > Nicht, daß ich es nicht schon geschrieben hätte... > > Dann halt noch mal im Detail: > > Es fallen pro Messung 1152 x 32 x 2 byte an > dazu noch pro Messung 96 byte Prozessdaten > > also knapp über 72kb > > d.h. wir brauchen 51 Pakete (max. 1500 byte mit je 28 byte obverhead) > Nein. Zwei Pakete reichen. UDP kann 64kB pro Frame. Spart bandbreite. > bei 1200 Messungen pro Sekunde sind das (aufgerundet) > 51 x 1500 x 1200 = 91.800.000 byte > 2400 Frames pro Sekunde. Nurmalso.
Roland E. schrieb: > Nein. Zwei Pakete reichen. UDP kann 64kB pro Frame. Spart bandbreite. Das nützt aber nichts, wenn die darunter liegende physikalische Schicht (Ethernet) nur eine maximale Paketgröße von ~1500 Bytes unterstützt. Selbst Jumbo Frames bieten - je nach Ausprägung - nur ~9000 Bytes, setzen aber voraus, dass sämtliche Netzwerkkomponenten, d.h. Interfaces, Switches, Router, ebenfalls solche Paketgrößen unterstützen und entsprechend konfiguriert sind. Und das ganze führt nur zu einer Reduzierung des Protokolloverheads von wenigen Prozent. Das also nur in den seltestens Fällen.
Roland E. schrieb: > Nein. Zwei Pakete reichen. UDP kann 64kB pro Frame. Spart bandbreite. Oh, Dankeschön!
Andreas S. schrieb: > Das nützt aber nichts, wenn die darunter liegende physikalische Schicht > (Ethernet) nur eine maximale Paketgröße von ~1500 Bytes unterstützt. ... und wieder von der realität eingeholt Wie auch immer, ich hab in diesem Thread Einiges gelernt! Daher allen ein dickes Danke!
Noob A. schrieb: > Roland E. schrieb: >> Nein. Zwei Pakete reichen. UDP kann 64kB pro Frame. Spart bandbreite. > > Oh, Dankeschön! Fragmentierung spart nicht wirklich Bandbreite.
Andreas S. schrieb: > Roland E. schrieb: >> Nein. Zwei Pakete reichen. UDP kann 64kB pro Frame. Spart bandbreite. > > Das nützt aber nichts, wenn die darunter liegende physikalische Schicht > (Ethernet) nur eine maximale Paketgröße von ~1500 Bytes unterstützt. > Selbst Jumbo Frames bieten - je nach Ausprägung - nur ~9000 Bytes, > setzen aber voraus, dass sämtliche Netzwerkkomponenten, d.h. Interfaces, > Switches, Router, ebenfalls solche Paketgrößen unterstützen und > entsprechend konfiguriert sind. > > Und das ganze führt nur zu einer Reduzierung des Protokolloverheads von > wenigen Prozent. Das also nur in den seltestens Fällen. Naja, ich gehe mal bei den Anforderungen des OP davon aus, dass seine komplette Netzinfrastruktur dick genug dimensioniert ist, um den Hirnriss mitzumachen, den er da vor hat. Bei dem BroadCom-Switch, den ich letztes/diese Jahr gebastelt habe waren Jumboframes nur ein Konfigschalter. Und der hat sich bei 10GBit noch an den Füßen gespielt. Nettes kleines Teil, wenn das Geschäftsgebaren von BC nur nicht wäre... Klar, wenn er irgend eine 1G-Konsumergurke dazwischen hat ist Essig. Dann nützt ihm sein GBit-Interface am Messzwerg aber auch nix mehr.
:
Bearbeitet durch User
Roland E. schrieb: >> bei 1200 Messungen pro Sekunde sind das (aufgerundet) >> 51 x 1500 x 1200 = 91.800.000 byte >> > > 2400 Frames pro Sekunde. Statt alles mit HighEnd-Hardware zuzuschütten,wäre es da nicht sinnvoller, mal über Kompression nachzudenken? Wenn man genug "Dampf" für GBit einplant, sollte das doch eigentlich kein Thema sein, und dann reicht plötzlich wieder 100 Mbit...
:
Bearbeitet durch User
Beitrag #7859490 wurde vom Autor gelöscht.
Harry L. schrieb: > Statt alles mit HighEnd-Hardware zuzuschütten Echt jetzt? Dachte Gbit wäre mittlerweile Standard... wenn auch bei µCs wohl noch nicht soo verbreitet
Noob A. schrieb: > Dachte Gbit wäre mittlerweile Standard. Offensichtlich nicht, sonst wäre ja dieser Thread hier nicht entstanden.
Harry L. schrieb: > Statt alles mit HighEnd-Hardware zuzuschütten,wäre es da nicht > sinnvoller, mal über Kompression nachzudenken? Wieviel gewinnt man denn da, wenn verlustfrei komprimiert werden muss? Man müsste ja auf ganz grob 10% vom Datenvolumen runter... Oder hab ich grad 'nen Knoten im Rechner?
Harald K. schrieb: > Noob A. schrieb: >> Dachte Gbit wäre mittlerweile Standard. > > Offensichtlich nicht, sonst wäre ja dieser Thread hier nicht entstanden. der Thread entstand weil ich dachte das ist einigermassen verbreitet und es lohnt sich mal nach Erfahrungen anderer zu fragen...
Noob A. schrieb: > Wieviel gewinnt man denn da, wenn verlustfrei komprimiert werden muss? > Man müsste ja auf ganz grob 10% vom Datenvolumen runter... Oder hab ich > grad 'nen Knoten im Rechner? Komprimierung hängt alleinig von den Daten ab. Weißes Rauschen -> gar nicht. Im besten Fall (wenn sich nur selten Änderungen ergeben) kann man die Info: »So wie gestern morgen« senden.
Moin, Wieviel sich komprimieren laesst, haengt halt stark davon ab, wie "zufaellig" die Daten sind. Wuerde ich mir aber nur antun, wenn ich diese Daten dann ueber deutsche Internetzleitungen gebuehrenpflichtig weiterleiten muesste. Und sie sich heftigs komprimieren liessen, weil ich z.b. die Aussentemperatur mit 10nsec zeitlicher Aufloesung schicken will. Sonst ist derweilen GBitEthernet nicht wirklich viel mehr Raketentechnik als 10/100. Mittlerweilen denk' ich, wirds eher darauf ankommen, ob du lieber mit irgendeinem Fertig-CPU/SPI/GBitEthernet-Chip z.b. von ST arbeitest oder lieber mit irgend einem FPGA. Oder was halt teurer wird, wenns in Grossserie gehen soll. Gruss WK
Noob A. schrieb: > Echt jetzt? > > Dachte Gbit wäre mittlerweile Standard... wenn auch bei µCs wohl noch > nicht soo verbreitet Es gibt halt doch noch Unterschiede zwischen einem Rechner mit X GHz Multi-Core CPUs und XXX GB RAM und einem 32 Bitter Microcontroller. Bei Gigabit kommen einfach unglaublich schnell unglaublich viele Daten. Ein µC hat da Probleme auf vielen Ebenen und es stellt sich sofort die Frage was er überhaupt so schnell mit so vielen Daten anfangen will.
Und der GBit PHY schluckt auch deutlich mehr Energie als ein 100MBit PHY.
Dergute W. schrieb: > Sonst ist derweilen GBitEthernet nicht wirklich viel mehr Raketentechnik > als 10/100. > Mittlerweilen denk' ich, wirds eher darauf ankommen, ob du lieber mit > irgendeinem Fertig-CPU/SPI/GBitEthernet-Chip z.b. von ST arbeitest oder > lieber mit irgend einem FPGA . Oder was halt teurer wird, wenns in > Grossserie gehen soll. > > Gruss > WK Wir hatten ein ähnliches Projekt mit Vibrationsregistrierung - und es gab ähnliche Probleme mit der Lautstärke. Am Ende haben wir uns für einen lokalen Puffer und eine Nachbearbeitung vor dem Senden entschieden.
:
Bearbeitet durch User
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.