Hi @ all Ich möchte Daten mit Hilfe von Ethernet zwischen einem FPGA und einem PC übertragen. Ich habe schon mal 2 PC's über das Netzwerk verbunden. Mit Hilfe von Labview habe ich eine Programm erstellt, dass Daten zwischen den beiden PCs austauschen kann. Nun möchte ich aber nicht die Daten zwischen 2 PC's austauschen, sondern zwischen einem FPGA und einem PC. Hierzu will ich ein neues FPGA Board entwerfen. Jedoch weiß ich nicht welchen Ethernet-Chip ich benötige. Es gibt ja Ethernettransreceiver und Ethernetcontroller. 1 .Welchen Chip davon benötige ich? Ich habe schon bei Ti und Intel geschaut. Diese haben einige Chips im Angebot. Ich habe diese aber nicht ganz vestanden. Man kann dort Daten am Datenbus anlegen und dann einen Puls geben. Die Parallelen Daten werden dann in serielle umgewandelt und über das Kabel an den PC gesendet. Doch woher weiß dieser Transreceiver woher die Daten kommen (IP) und wohin die Daten gehen sollen (IP). Am anderen Ende der Leitung ist der PC. Der horcht die ganze Zeit auf einem Port ob die Daten ankommen. Jedoch weiß er halt nicht das die Daten für ihn sind. Hat vielleicht jemand Links zu diesem Thema oder Diplomarbeiten? Grüße Michael
Wenn du IP Pakete verschicken willst, brauchst du Komponenten, die dir Schicht 1, 2 und 3 des OSI Schichtenmodells realiseren. Du brauchst mindestens für Schichte 1 (physical layer) einen externen Chip, den sogenannten PHY. Der könnte mit dem FPGA, oder einem Mikrocontroller über ein MMI Interface kommunizieren, und sendet/empängt daten vom netzwerkkabel. Für Schicht 2, also das senden von Ethernet Paketn, mit fluss- und fehlerkontrolle, kann man einen externen Chip nehmen, nennt sich dann MAC. Gibts auch kombiniert mit einem PHY. Die Realtek und Microchip Netzwerkchips, die hier öfters in AVR Projekten verwendet werden sich solche. Alternativ kann man den MAC Teil aber auch als Hardware im FPGA implementieren. Naja, und dann musst du wohl noch IP und evtl TCP implementieren. Das geht nicht sonderlich gut in Hardware. Am besten wäre hier ein Microcontroller Core, der ins FPGA integriert wird, und als software ne tcp/ip bibliothek. Der Mikrocontroller muss dann die IP Pakete erstellen und den Datenstrom an den MAC Teil, der irgendwie dran angeschlossen ist, weiterschicken. Jedenfalls ist das auf diese Art und Weise ne ziemlich komplizierte Sache. Einfach wäre es, wenn du sowas wie den XPort Chip nimmst. Den kann man wohl so ähnlich wie eine serielle Schnittstelle anpsrechen, also vom FPGA aus die Daten seriell reinschreiben und der macht dann TCP/IP Pakete draus und schickt sie los. Wies genau geht weiß ich auch nicht, habe nicht damit gearbeitet. Die Datenrate ist hier aber im Gegensatz zu einer richtigen Netzwerklösung sehr begrenzt, aber vielleicht reichts ja für dich.
Ich habe bei TI folgenden CHIP gefunden : "TLK1521" http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=553&uiTemplateId=NODE_STRY_PGE_T¶mCriteria=no Dieser ist ein Transceiver. Er wandelt die Parallelen Daten in serielle um und sendet diese. Jedoch steht dort nicht wie viel Speicher er intern besitzt. 1. Ist dies ein PHY? Wenn ich einen PHY benutze, kann man damit ja Daten senden. Woher weiß denn der Empfänger das diese Daten für Ihn bestimmt wird. Ich sende da ja kein Protokoll mit. 2. Würde die ein PHY ausreichen um zwischen FPGA und PC Daten auszutauschen" 3. Muss ich dafür TCP oder UDM benutzen? 4. Hat der PHY keine Fehlerkontrolle (bekomme ich es mit wenn die Daten nicht richtig angekommen sind oder muss ich den CRC check selber machen?) Eigentlich brauche ich schon 1000MBit. Dies wäre toll, da ich eine Alternative zu USB 2.0 suche
Meinst du nicht, dass du dich erstmal ein bißchen mit der Theorie von Ethernet (z.B. OSI Schichten) beschäftigen solltest? Ich bezweifle, dass du mit deinem Wissensstand das Projekt bewältigst. Vor allem wenn ich lese, dass du Gbit Ethernet realisieren willst. Das erfordert schon einiges an Know How, auch im Harwdware Bereich.
Als Einstieg: Über das Kabel geht seriell ein sogenanntes Ethernetframe (1.Suchbegriff Wikipedia: Ethernet bzw Ethernetframe).Darin stehen im wesentlichen nur die MAC-Adresse (2.Fachbegriff zum einlesen!) von Sender und Empfänger sowie eine Kennung des Typs.Der Rest besteht aus den in das Ethernetpaket gekapselten Daten.Diese können vom Typ her z.B ARP (Adress Resolution Protocol,Punkt 3) oder IP sein.In letzterem steht dann schon die IP-Adresse von Sender und Empfänger sowie wieder einige Informationen zu den gekapselten Daten.Diese können dann wiederum TCP oder UDP Pakete darstellen. Du siehst,es sind eine ganze Reihe von Protokollen bzw Protokollheader zu interpretieren/zu parsen.Bei Ethereal kannst du ja mal in einige Pakete reinschnubern,ohne das Wissen was Abkürzungen wie TCP,IP,UDP,IMCP,ARP usw. bedeuten wird dir das aber nicht viel bringen. Wenn man das Prinzip erstmal verstanden hat (Paket in Paket in Paket...),ist die Implementation dann eine Fleissaufgabe.Verbindungsorientierte Verbindungen (TCP) sind allerdings richtig unschön zu debuggen (u.a. Timeouts,...).Zum Glück gibts da schon fertige Protokollstapel,die man einsetzen kann,sobald man die Grundlagen verstanden hat.Ich denke mal,du hast jetzt einige Begriffe zum googlen.Um tiefer in die Materie einzutauchen ist ein altmodisches Buch allerdings dennoch empfehlenswert.
Das habe ich schon mal gelesen. Ich dachte immer ich brauche nur einen PHY den es von TI gibt. Der sendet dann die Daten an dem PC. Jedoch habe ich gemerkt das der PHY kein Protokoll erzeugt sondern nur die Daten von Parallel in seriell wandelt. Also brauche ich noch einen MAC zwischen FPGA und PHY. Der MAC erzeugt dann ein Protokoll. 1.Reicht denn das MAC Protokoll aus, um mit dem PC sicher zu kommunizieren? 2.Gibt es denn keine weiteren ICs, die das TCP/IP-Protokoll mit integrieren? Das ganze kann doch nicht so schwer sein, denn jedes neue Mainboard hat doch einen Gigabit-Anschluss auf dem Board. Wie lösen die denn das Problem?
Wie ist das eigentlich auf dem Xilinx-Eval Board gelöst? Kann das nicht sowas?
10 MBit sind viel zu langsam. Wie machen die es denn auf den Mainboards. Dort kann doch nicht nur die CPU das TCP/IP Protokoll erzeugen. Dann würde die CPU-Last doch viel zu hoch sein. Was würde denn passieren wenn ich einfach mit einem PHY Daten an den PC übertragen würde, und nur die Leitung abhören würde. (Ohne Protokoll) Geht das überhaupt, oder würden zu viele Fehler entstehen?
@ Michael > 10 MBit sind viel zu langsam. Wie machen die es denn auf den Mainboards. Für wen zu langsam? Für dich? > Dort kann doch nicht nur die CPU das TCP/IP Protokoll erzeugen. Dann Warum nicht. So ein P4, Athlon und Co haben Power ohne Ende. Das einzige was der Ethernetcontroler macht ist die Prüfsumme ausrechenen. Alle anderen Daten (Adresse, Typ, etc.) schreibt die CPU. Und wenn er ein Paket empfangenhat das gleiche. Er prüft die CRC uns sagt der CPU per interrupt Bescheid, dass ein neues Paket angekommen ist. > würde die CPU-Last doch viel zu hoch sein. [ ] Du hast ein Vorstellung von der Rechenpower einer CPU. > Was würde denn passieren wenn ich einfach mit einem PHY Daten an den PC > übertragen würde, und nur die Leitung abhören würde. (Ohne Protokoll) > Geht das überhaupt, oder würden zu viele Fehler entstehen? Ohne Protokoll geht gar nix. Selbst reines RS232 hat ein "Protokoll", wenn gleich nur auf Byte-Ebene. Bei Ethernet brauchst du mindestens das Protokoll bis auf OSI-2, sprich Ethernet-Paket-Ebene. MfG Falk
Hallo, wirf mal einen Blick auf Wiznet (http://www.iinchip.com/) Die haben einen 10/100 Mb Ethernet-Controller mit integriertem TCP/IP-Stack. Dies ist ev. das was Du suchst. MfG. Andreas
Es kommt drauf an, WAS du über Ethernet übertragen willst. Ethernet legt lediglich den Frame fest: Präamble, SFD, Destination, Source, DATA, FCS. Das muss bei allen Netzwerkkomponenten gleich sein, sonst funzt es nicht. Dass in dem Datenfeld TCP/IP gesprochen wird, das ist eine Sache, die zwischen zwei Teilnehmern ausgehandlt werden muss. Darum ist der TCP/IP-Stack in deinem PC auch ein Stück Software. DU kannst es locker deinstallieren. Ergo: Du könntest dir auch ein ganz eigenes Protokoll ausdenken, was dann eben beide Teilnehmer sprechen müssen. Ergo: Du musst lediglich nen PHY kaufen. Den Rest kannst du in nem FPGA realisieren (auch die FCS Berechnung etc) Das ist aber alles n icht so ganz trivial, da du Aufgrund der unterschiedlichen Takte von PHY und FPGA dir ein wenig Gedanken machen musst, wie du die Daten ohne Setup-Verletzungen in das FPGA bekommst. Ich hab sowas mal für 100 Mbit gemacht (eigener MAC und eigenes Protokoll) Am PC musst du dann natürlich direkt auf die Netzwerkkarte zugreifen und NICHT über den TCP-IP-Stack
@Michael: Was willst Du denn mit 1000Mbit/s übertragen ? Das könnte mit einer CPU sehr schwierig werden zu verschicken. 1000Mbit/s sind ungefähr 100MByte/s. Schafft das überhaupt Deine Festplatte ? Ansonsten kann ich auch nur zum Lesen eines Buches raten. Es ist ratsam, sich erst einmal mit den Begriffsdefinitionen vertraut zu machen. Google auch mal nach OSI-Schichtenmodell. Das zu Verstehen ist ein wichtiger Schritt in die Welt der Netzwerke.
Du musst natürlich davon ausgehen, dass du nicht einen Frame nach dem andern rausschreibst. Ethernet ist für Netzwerke gedacht (wie der Name schon sagt). Da schwatzen ja noch andere Teilnehmer. Das heisst, nicht alle Teilnehmer senden ununterbrochen Frames. Trotzem muss die hohe Bandbreite her, dass bei vielen Teilnehmern das Netz nicht irgendwann "zu" ist. Der Prozessor schreibt seinen Frame komplett in den MAC (das kann er auch ganz gemütlich machen) Und wenn der Frame fertig geschrieben ist, dann versucht der MAC diesen zu versenden (Mit z.B 1 GB/s). So wird die Leitung schnell wieder frei für andere. Wie du siehst, dein Controller kann beliebig langsam sein und es funktioniert trotzdem noch. Das Empfangen geht genauso: MAC-Controller erkennt anhand der MAC Adresse, oder Frame für ihn ist. Empfängt mit 1 GB/s und schreibt das alles in einen Speicher. Dort kann der Prozessor das dann ganz gemütlich abholen Klaro, der Speicher ist beschränkt und wenn du einen Frame nach dem anderen immer an den gleichen Teilnehmer schickst, dein Prozessor langsam ist, dann wird irgendwann der Empfangsbuffer des MAC voll sein und Frames gehen verloren. Das passiert ständig auf dem Ethernet udn darum gibt es z.B. im TCP-IP-Stack mechanismen, die das erkennen und den Frame dann erneut senden. Das ist aber Protokollsache und hat mit Ethernet NIX zu tun. Du kannst theoretisch auch TCP/IP über deine serielle Schnittstelle sprechen
> "Du kannst theoretisch auch TCP/IP über deine serielle Schnittstelle > sprechen" @Schlumpf: Weisst du ob es eine Software gibt,mit der man sowas zum debuggen nutzen kann?Also irgendein Tool/Treiber das/der ein TCP/IP-Paket (oder vielleicht ein komplettes Ethernetframe) am PC auf einer seriellen Schnittstelle ausgibt.Vielleicht als virtuelle Netzwerkkarte oder so...
@ Ronny: Glaub nicht, dass es sowas gibt, bzw. was man damit anfangen sollte. Du müsstest ja ein ganzes Paket an Daten rausschiscken, da deine RS232 immer nur 8 Bit sendet. Also Startbit, 8 Datenbits, Parity usw... Das heisst, du bekommst keinen durchgängingen "Datenstrom" wie bei einem Ethernetframe hin. Was aber nicht heisst, dass du nicht TCP-IP sprechen kannst. Du müsstest dein Protokoll halt in viele kleine RS232-Paketchen zerhacken udn übertragen.
Hab noch was auf Wikipedia gefunden: http://de.wikipedia.org/wiki/MAC-Adresse Da sieht man es recht gut: Ethernet ist ein Transportmedium! Im Typenfeld steht, was für eine "Sprache" gesprochen wird (z.B. TCP). Im datenfeld steht dann die eigentliche Information, die z.B. bei TCP nochmals mit jeder Menge Overhead versehen ist, die die Verbindungen aufbauen, die Daten sichern und die IP-Adressen (source und Destination) beinhalten. http://de.wikipedia.org/wiki/Transmission_Control_Protocol (das ist das, was im Datenfeld eines Ethernetframes steht, wenn TCP gesprochen wird) Man sieht schon, dass die MAC Adresse nichts mit der TCP-Adresse zu tun hat und beide in einem Frame vorkommen. Ergo: du kannst dir nen eigenen Typ überlegen und dann in´s Datenfeld reinschreiben was du willst, du musst lediglich sicherstellen, dass der Empfänger anhand des Typenfeldes erkennt, wie er die Daten zu interpretieren hat.
@ Schlumpf & Ronny http://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol http://en.wikipedia.org/wiki/Point-to-Point_Protocol Ist bei Windows, Linux und auch anderen Betriebssytemen mit dabei. Cheers, Roger
Ich brauche halt 1000Mbit, da ich so schnell sein will wie USB2.0 High Speed (480MBit) oder Firewire. Zudem will ich nicht die 100MByt/s auf die Festplatte schreiben. Dafür gibt es ja Arbeitsspeicher. Mein Task ist die Datenaufnahme, Datenübertragung und Visualisierung der Daten. Bei der Visualisierung benutze ich einen großen Ringspeicher, da 1 Datensatz ein Bild ergibt. Kommt ein neues Bild, dann wird das alte Bild überschrieben. Daher brauche ich auch eine schnelle Übertragungsmethode. USB 2.0 Highspeed ist auch nicht so toll, da man dort die richtungen Treiber kaufen muss. (erst mal die richtigen finden, denn Treiber ist bei USB nicht Treiber, denn einige schaffen nur 10MByte/s) Da auch andere Programme auf Ethernet zugreifen, dachte ich 1000MBit sollte es schon sein, zudem muss ich meine Daten auch schnell genug übertragen können. Jetzt frag bitte nicht wie viele Daten es genau sind. Zudem habe ich das Schichtmodell schon durchgelesen. Wo findet man denn ein TCO/IC Protokoll im Datail beschriebn, damit ich es auf dem FPGA nachbilden kann? Bei Wiki ist nur eine allgemeine Beschreibung, aber für das Timing benötigt man schon mehr Angaben
Wenn du mit TCO/IC TCP/IP meinst, dann findest du alle Informationen in dem Dokument rfc793 (http://tools.ietf.org/html/rfc793). Der Link ist auch bei Wikipedia angegeben! Es gibt schon einige Links zu dem Thema im Forum, ich würde dir empfehlen diese durchzulesen. Ist das ganze ein Hobbyprojekt? Was für einen Fpga verwendest du? Der Ti Chip den du oben genannt hast, ist nicht für Ethernet gedacht!
Es ist kein Hobbyprojekt. Diese sind aber unter Gigabit Etherner aufgeführt. Es ist ein PHY. Jedoch besitzt dieser Chip keinen MAC. Kennt jemand Gigabit MACs + PHY?
Ich verwende einen Spartan 3 mit 400k Systemgates. Mal angenommen ich schaffe es mit 30 MHz 16 Bit and den MAC zu senden, dann schaffe ich 480MBit. Wenn die Schaltung mit 120 MHZ läuft dann habe ich 4 Takte um das Protokoll zu realosieren. Das ist nicht besonders viel. :-( Ich schätze mal, das man 8 Takte benötigt, um die Daten aus dem Block-Ram zu laden, und das Protokoll mit einzubinden. AH Ich werde einfach während ich die Daten digitalisiere in die ersten Speicherzellen schon den Header schreiben. Ist dann ein Bild im Block-Ram, kann ich mit der Ausgabe beginnen und volle Socke die Daten aus dem RAM übertragen :-) So sollte es dann noch schneller gehen. Nun brauche ich nur noch einen MAC und einen PHY für Gigabit
Wenn Du einen MAC und einen PHY habe möchtest solltest Du vielleicht gleich eine Netzwerkkarte benutzen. Aber: Warum nicht hiermit anfangen: http://www.fpga4fun.com/10BASE-T.html ? Dabei lernst Du auch alles was Du für 1000 Mbit brauchst, und dann von 10 zu (100 zu) 1000, ist einfacher als gleich mit 1000 zu beginnen. Dabei ändert sich schliesslich nur die Geschwindigkeit.
Ich habe da was bei Intel gefunden. Hört sich sehr interessant an http://download.intel.com/design/network/datashts/82541gi_ei.pdf Ich werde mir mal das Datenblatt genau durchlesen. Ist allerdings mit PCI.
Da ich mich selber gerade in meinem Job mit einer ähnlichen Problematik beschäftige und mir deshalb das Referenz-Design von Xilinx genauer angeschaut habe, glaube ich, daß Du mit einem Spartan keine Chance hast das mit TCP/IP zu realisieren. Das Protokoll ist zu kompliziert, ich habe jedenfalls keine Implementierung gefunden welche es komplett in HW realisiert. Du mußt nämlich beim Verbindungsaufbau Pakete empfangen und analysieren. Weiters brauchst Du eine Art ARP für die Bestimmung der Ethernet Addresse Deiner Empfangsseite. Das Referenz Design verwendet den PowerPC des Virtex und muß dort tricksen, weil man bei einer Framelänge von ca. 1500 Bytes theoretisch alle 12 us einen Interrupt zum Behandeln des Frames. Das einzige das vielleicht ginge ist UDP, bei dem die Pakete vom FPGA einfach nur gesendet werden, ohne Antwort und nichts. Bleibt immer noch die MAC Adresse deiner Empfangsseite, die Du fest ins FPGA verdrahten müßtest. Grüße Klaus
Ich würde, wenn es nur eine Peer-to-Peer verbindung ist, und du eh nur Bilder überträgst, auf ein eigenes Protokoll gehen. Wenn deine zusammengehörende Datenmenge (1 Bild) nicht größer als 1500 Byte ist, dann kannst du die Bilddaten einfach direkt in das Datenfeld eines Frames packen und verschicken. Du brauchst dann gar kein Protokoll und nutzt die Bandbreite ideal aus. Bei größeren Datenmengen könntest du dir einen eigenen kleinen Header erfinden. Also wenn du weisst, dass ein Datensatz immer in 4 Frames passt, dann könntest du ein Byte spendieren um anzuzeigen, um welchen Teil des Datensatzes es sich handelt. Dann brauchst das am PC nur noch zusammenbauen. Bei Übertragungsfehlern stimmt die FCS nicht und du musst dann eben diesen Datensatz verwerfen. Ich denke, dass sowas komplett ohne TCP/IP zu machen ist.
Aber wie kommt man dann von PC-Seite an die Daten? Mein Bild ist 4000 Byte groß. Bis jetzt habe ich immer ein Trennzeichen zum Schluss gesendet. z.B. "0xFF" Die digitalisierten Daten konnten diesen Zustand nie erreichen, somit war das Trennzeichen eindeutig. Jedoch gibt es 1 Problem. Der PC sendet auch noch DATEN (z.B. automatische Update-Sucher) Diese muss ich ja von den Daten auseinander, die meine PC Programm an den FPGA sendet. Daher denke ich ist es nicht Klug auf das TCP/IP Protokoll zu versichten. Außerdem kann ich momentan mit Labview sehr einfach auf das TCP/IP Protokoll zugreifen und Daten lesen und senden. Wenn ich jetzt noch ein eigenes Protokoll entwerfe, dann muss ich auch noch die PC-Software aufwendig schreiben. Und dies würde ich alleine im Zeitrahmen nicht schaffen.
Bei deinen Fragen erkennt man wenig Entwicklung von Frage zu Frage! Das Design eines Motherboards ist SEHR aufwendig! Die Taktraten die da auf den Leitungen gefahren werden, sind schon weit im HF Bereich und dann auch häufig noch parallel. Einfach zu sagen: Die können das doch auch irgendwie, dass muss ich auch können, ist SEHR SEHR mutig! Das Team, das so etwas realisiert, ist deutlich größer als eine Person und hat DEUTLICH mehr Erfahrung. Zum Thema eigenes Protokoll über die Ethernet Schnittstelle: Wie wäre es denn, wenn du einfach im PC eine zweite Netzwerkkarte nutzt? Dann musst du dir keine Gedanken über andere Anwendungen, die darauf zugreifen machen. Aber ich behaupte nach wie vor, du müsstest deutlich mehr Zeit in die Einarbeitung in das Thema investieren. Keine Antwort, die dir hier gegeben wird, wird dir dabei groß helfen können. Und da du das ja nicht als Hobby machst, sollte das ja auch möglich sein. Ansonsten hast du ein Problem!
Ich hätte da noch ne Idee: Nimm doch ein fertiges Board mit Embedded Controller, die gibts mittlerweile auch mit GBit-Ethernet und teilweise sogar mit FPGA drauf bzw. mit FPGA-Scnittstelle, schau mal z.B. bei MEN oder Microsys oder so. Die Daten schickst Du über einen 32 bit Bus an den Controller, das könnte relativ sportlich werden bei 480 MBits, sollte aber machbar sein. Dann musst Du Dich erstmal um das Interface zum Controller kümmern, auf dem Controller läuft dann ein Linux oder so und Du brauchst jemanden der Dir einen Treiber schreibt und eine kleine Applikation, die die Daten hin und herschaufelt (oder nur hin?). Vorteile: Simples Debugging, die ganze TCP/IP Geschichte kann ohne FPGA in Betrieb genommen werden, Im FPGA ist nur die Interface-Logik zum Controller nötig. Wäre das was?
Fragt sich, ob es einfacher ist, TCP/IP in Hardware zu giessen, oder einen kleinen Treiber für den PC zu schreiben der die Daten von der Netzwerkkarte abholt udn wieder zusammenflickt. Ich versteh allerdings nicht, wie du mit LABVIEW diese Datenraten bewältigen kannst... Na ja, ich hab mal 100MBit Ethernet in ein FPGA implementiert also MAC funktionalität und das war kein großes Ding. Aber wenn du nicht auf TCP/IP verzichten willst und das ganze in ein FPGA giessen musst, dann kannst über die ganzen Treiberschickten im PC drauf zugreigfen. Ich denke, dass du dir aber darüber im klaren bist, dass du auf der einen Seite Gas geben willst, die Daten mit Höchstgeschwindigkeit rausschieben musst um sie dann am anderen Ende über einen völlig lahmen Windows Treiber durchzunudeln... Du kannst natürlich auch für das Senden vom PC zum PFGA ein eigenes einfaches Protokoll verwenden. Na ja, vielleicht findest ja noch ne Lösung. Ich werd mich an dieser Stelle ausklinken. Hab alles gesagt, was ich dazu beitragen konnte. Du bist der Überzeugung, dass TCP/IP das Richtige für dich ist, dann mach an diesem Ansatz weiter.
@ Schlumpf Auf jedenfall vielen Dank für Deine Meinungen. @guelcki Ich weiß nicht wo das Problem beim eigenem Board sein soll. Heute gibt es Layout Programme die extra Bussysteme Routen. Die sind dann exakt gleich lang. Eine zweite Netzwerkarte kommt nicht in Frage, da es ein sehr kleines System werden soll. Hat denn schon mal einer mit dem weiter oben verlinkten Intel gearbeitet?
Okay, wenn du meinst, dass man einfach nur ein passendes Tool braucht, ohne irgendwelche großen Erfahrungen, um ein PC Motherboard zu designen, dann wünsche ich dir noch frohes gelingen bei deinem Projekt!
Ich habe mich da auch nur auf deine Ausssage bezogen: >Das ganze kann doch nicht so schwer sein, denn jedes neue Mainboard >hat doch einen Gigabit-Anschluss auf dem Board. Und ich sage dir nochmal, du musst dich weiter in die Theorie von Ethernet einlesen, wenn du wirklich TCP/IP über Gbit Ethernet nutzen willst. Du wirst keinen Chip finden, den du einfach anschließen und eine IP einstellen musst und es läuft wie du es dir vorstellst.
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.