Hallo Gemeinde, ich will meinen µC mit einem Netzerk-Interface ausstatten. Anbieten würde sich für mich der rtl8139. Der Chip ist relativ günstig zu haben (PCI-Karten kosten um die 5-7 Euro) und tut bisher auf den Karten auch ganz gut seine Dienste. Nur leider finde ich keine Projekte, die mit dem Controller arbeiten. Meine Frage ist nun: Hat schon einmal jemand Erfahrungen mit dem Chip gesammelt? Gibt es gründe ihn nicht zu verweden (kein TCP-Stack wäre ja schon ein Grund) bzw. hat evtl. schon jemand Software zu dem Teil? Besten Dank, Scheintod
Hi, es gibt da nen schönes Kommentar zu diesem Chip in den BSD sourcen: * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is * probably the worst PCI ethernet controller ever made, with the possible * exception of the FEAST chip made by SMC. [...] Vielleicht ist das ja der Grund, wieso sich da noch niemand mit einem µC drann getraut hat ;) Gruß, Daniel
Abgesehen vom Realtek-Bashing: Du wirst mit einem µC kaum PCI-Devices ansprechen können; im Gegensatz zum ISA-Bus ist der PCI-Bus alles andere als trivial. Obendrein können die wenigsten µCs 32-Bit-Zugriffe ausführen. Daher dürfte das ein triftiger Grund dafür sein, warum noch niemand einen RTL8139 an irgendwas anderes angeschlossen hat. Du wirst Dich also auf einen ISA-Netzwerkchip wie den RTL8019 "beschränken" müssen. Daß Du mit einem µC dessen Datenrate ausreizen kannst, wage ich vorsichtig in Frage zu stellen ... daher ist der Einsatz eines 100 MBit-NICs wohl auch kein dringendes Problem. Der RTL8019 ist, soweit ich informiert bin, NE2000-kompatibel.
@Daniel: Naja, in unseren Linux-Servern tut er brav seine Pflicht & ist noch nicht mal langsam. (Was man von früheren Versuchen mit 20x so teuren 3com Karten nicht sagen kann.) Klar, liegt dann vermutlich am Treiber-Programmierer der besser war als der Chip :) @Rufus: Hm. Hört sich vernünftig an. Hätte aber doch gerne einen 100MBit chip. Nicht wegen der Datenrate (die ist tatsächlich nicht besonders hoch) sondern wg. der Latenz einzelner Datenpakete, die möglichst gering sein sollte. Es soll auch nur eine Punkt->Punkt Verbindung werden. Serielle ist mir zu lanksam, USB zu aufwändig (Windows/Linux-Treiber). Die Anwendung die die Daten auswertet ist in Java geschrieben. Das hat eigentlich nur Sinnvolle Kommunikationsmechanismen via TCP/IP. Schoene Gruesse, Scheintod.
Tja, Du solltest dann vielleicht nach Ethernet-Chips mit anderen Interfaces als PCI suchen. Was ist Deine Anwendung? Was generiert die Daten, die Du mit geringer Latenzzeit transportieren möchtest, welche Datenmengen werden bewegt, was für ein Controller soll dahinterstecken?
Hi Rufus, Conroller: at90can128. Interfacet CAN (im Moment Lowspeed 83kBit, soll aber auch schnelleres verarbeiten.) Kleinere Logikfunktionen im Controller (wenn Empfang Frame A, dann sende Frame B). Komplexere Logikfunktionen in der Java-Anwendung 'skriptbar'. Daher auch der Wunsch nach niedrigen Reaktionszeiten. Java steht fest für die Anwenung (exitiert zu Teilen schon). Daher auch kein USB. Anschluss via Ethernet dann vermutlich über x-link kabel. Schoene Gruesse, Scheintod
Hallo Scheintod, an einen µC macht es meiner Meinung nach nur Sinn einen non-PCI-NIC anzuschließen. Das wäre z.B. der RTL8019 (den kennst Du sicher schon) oder z.B. einen von diesen hier: http://www.smsc.com/main/catalog/networking.html Der LAN91C96 wäre z.B. so ein Kanditat. Ich habe von dem sogar mal Samples bekommen. Die haben eine sehr freundliche und kompetente deutsche Vertretung: http://www.smsc.com/corp/smscworldwide.html Gut ich habe mit denen dienstlich zu tun gehabt aber vielleicht sind sie ja auch bei Privatleuten nicht so... Gruß Andreas
Nicht sooo geschickt, zuerst die Software zu schreiben und dann die Hardware daran anpassen zu wollen. Und dann auch noch Java ... Da gibts ne schöne Geschichte dazu: http://www.ee.ryerson.ca:8080/~elf/hack/ktoast.html
@hebel23: Danke für den Tipp. Ich werfe mal einen genaueren Blick auf das Teil. Die Frage nach dem tcp/ip Stack bleibt. Aber es sieht wohl nach einem modifiziertenn ethernuts-design aus. (Auch wenn ich mit fremden RTOSen noch garkeine Erfahrung habe). @Marko: Nette Geschichte. Leider nicht besonders hilfreich. Ich rate Dir mal u.a. zu "Entwurfsmuster" (Gamma et. al.), "Refactoring" (Martin Fowler) um Dich zu überzeugen, dass objektorientierter Software-Entwurf u. Entwicklung durchaus auch Sinnvoll ist jenseits des "Elektroingeneure im Studium quälens". Gerade bei diesem Projekt kommt es sehr auf eine umfangereiche, vielseitige u. erweiterbare Oberfläche an, mit der man letztendlich ja auch Arbeiten soll. Schaut man sich das eher elende Bild an, das käufliche Can-Analyzer bieten, wäre es da wohl sinnvoll gewesen sich mehr mit den möglichen Anforderungen an die Software zu beschäftigen. (Und würde es mir jetzt ersparen.) Schoene Gruesse, Scheintod
Hi Ich verstehe die Abneigung gegen USB nicht ganz. Die FT245BM sind super simpel, benötigen auf keiner der beiden Seiten auch nur die geringste Beschäftigung mit USB und ermöglichen ähnlichen Datendurchsatz wie 10MBit Ethernet. Die Latenz könnte aber ein Problem sein aufgrund des 1ms Zeitrasters des USB. Matthias
Ich setze auch den LAN91C96 ein, der ist ideal für 8-Bitter angepaßt. Der kann nämlich im 8-Bit Modus arbeiten und hat obendrein noch das notwendige Adreßlatch mit drin. Ist also ohne weitere Komponenten direkt an einen 8051 oder AVR anschließbar (als memory mapped IO). Peter
hier gabs doch schon mal eine low cost Lösung: http://www.mikrocontroller.net/forum/read-4-87092.html Und vielleicht klappt es auch hiermit: http://www.lantronix.com/device-networking/embedded-device-servers/xport.html
Hi, ich habe nach LANGER SUCHE einen gefunden, der 16Bit/8Bit tauglich ist. Der AX88796L von der Firma ASIX. Leider bekommt man den derzeit nicht in Deutschland. Bei Futurlec bin ich dann fündig geworden. Der Preis von 10,90 USD ist auch ok. Gruss Steffen p.s. läuft bei mir mit dem ATmega128.
@alle: Erst mal danke für die Tips. Ich denke ich brauche eine Weile bis ich mich durch das Material durchgelesen habe. @Mathias: Über die alternative USB<->Seriall converter hab ich auch eine Weile nachgedacht. (In der Tat hab ich sie auch noch nicht ganz ad acta gelegt.) Es gäbe sogar noch die einfachere Alternative über einen simplen 'Serial-USB-Dongle" das ganze "einfach nur anzuschließen". Allerdings erhoffe ich mir von einem Umstieg (egal ob auf USB oder auf Ethernet) noch ein wenig mehr, dass ich bisher noch nicht erwähnt hatte: Das zukünftige Übertragungsprotokoll zur PC<->µC Kommunikation besteht aus einer 2-Wege kommunikation mit unterschiedlichen Nachrichten (Controll/Data) in Nachrichtengrößen zw. 2 und 20 Bytes. Um hier eine sichere Übertragung zu gewährleisten muss ich Mechnismen implementieren, die mir die Übertragung absichern: v.a. Sendebestätigungen, Nachrichtenanfangs u. -ende Kennungen etc. Dafür sind mehrere Verfahren denkbar. (Escape-Sequenzen, 7-bit kodierung o.ä.). Alleine schon aus Durchsatzgründen stellt hier das 1ms delay eine schwere Einschränkung dar. Was aber für mich interessanter ist: Die ganze Transport-Absicherung auf Byte-Ebene und die Bestätigungen auf Nachrichtenebene könnte ich komplett an eine tiefere Netzwerkschicht übergeben. Hiermit würde sich der Entwicklungsaufwand für das Übertragungsverfahren deutlich reduzieren. Zumindest ist das meine Hoffnung und die stirbt bekanntlich zuletzt ;) Schoene Gruesse, Scheintod
Mal was anderes: Nachdem das warscheinlich noch eine Weile dauert, bis ich hier die Hardware zusammen habe, um Ethernet für die Übertragung zu nutzen: Gibt es schon fertige freie Kommunikationslibraries für die Serielle (rs232) Datenübertragung zw. µC & PC? Mein Hauptaugenmerk läge auf der Übertragungssicherheit. Ich stelle mir so etwas wie ein modifiziertes Z-Modem-Protokoll vor in dem einzelne Datenblöcke von µC->PC bzw. vice versa übertragen und auch bestätigt werden. Bei fehlerhafter Übertragung bzw. beim Fehlen ganzer Blöcke sollten die fehlerhaften Blöcke wiederholt gesendet werden. Leider ist so ein Protokoll wohl nicht ganz einfach sowohl robust als auch performant zu entwickeln. Deswegen wären fertige Lösungen eine feine Sache. Alternativ könnte ich mir vorstellen, sollte der Hard-/Softwareaufwand für Ethernet für meine Verhältnisse erst einmal zu groß sein, könnte ich mich selber (trotz mangelnder Vorkenntnisse in dem Bereich) an die Arbeit machen. Wenn hier noch mehr Leute interesse an solch einer Lösung hätten, würde das natürlich meine Motivation erheblich Steigern ;) Schoene Gruesse, Scheintod
Eine Variante wäre die Verwendung eines TCP/IP-Stacks. Der ist zwar recht groß, bietet aber Fehlerkorrektur und wird vor allem von der PC-seite aus standardmäßig unterstützt - PPP ist hier das Schlüsselwort. Dein µC muss also entweder PPP-Server oder PPP-Client werden (k.A. was aufwendiger ist), und schon kann er wahlweise direkt oder über serielle Modems mit einem PC verbunden werden. Und die Software auf dem PC kommuniziert mit dem µC genauso, wie sie auch mit anderen Netzwerkdevices kommunizieren kann - was der Java-Anwendung von Scheintod ja wohl auch entgegenkäme. Prinzipiell gibt es PPP-Implementierungen auf sehr kleinen Systemen; wenn ich mich nicht total irre, kommunizieren viele der ethernet-losen Webserver auf µC-Basis mit genau diesem Protokoll. Wär' das was?
Hi Rufus, hört sich wie keine schlechte Idee an. Muss mal ein bisschen rumsuchen. Nut/OS hat ja PPP schon mit drinnen (zumindest siehts im Konfigurator so aus). Vielleicht finde ich ja was ohne gleich in ganzes OS aussenrum. Besten Dank für den Tipp.
Hi nochmal. Nach ein bissl nachlesen und rumrechnen fällt die Alternative doch leider aus. Alleine an Overhead für die 3 Protokollschichten (PPP/IP/TCP) fallen ca. 80 Bytes an. Für meine Nutzinformationen von 2-20Byte wäre das schon im günstigesten Fall ein 1:4. Ohne die Geschwindigkeit von Ethernet bekomme ich da nicht mehr genug Daten rüber. Geschwindigkeitsboost über SER->USB scheidet leider auch aus. Naja, noch ein bissl PPP alleine anschauen, vielleicht kann ich da ja noch was rausholen. Schoene Gruesse, Scheintod
Hi ich wage aber mal zu bezweifeln das du mit einem AVR viel mehr als die von mir genannten 800kByte/s mittels Ethernet übertragen bekommst. Ich versteh also immer noch nicht die Abneigung gegen USB. Matthias
Hi Mathias, prinzipiell habe ich überhaupt nichts gg. USB. Die Lösung via FT245BM wollte ich in der Tat schon lange einmal ausprobieren. Leider bringt es mir für meine Anwendung gerade keinen Vorteil. Mein Problem sind die kleinen Nutzdatenpakete und die hohe Latenzzeit von der USB-Übertragungen: Wenn ich also meine Datenintegrität überprüfen will und ggf. einen Frame neu anfordern will sieht mein Protokoll vereinfacht so aus: Adapter PC ----[Frame1]----> <----[ack1]------ ----[Frame2]----> <----[ack2]------ ... Bzw. Im Fehlerfall: ----[Frame1]----> <----[err1]------ ----[Frame1]----> <----[ack1]------ ... Optimierterweise lässt sich auch schon Frame2 senden wenn Ack1 noch nicht da ist und so die Kommunikation etwas "assynchroner" gestallten. Im endeffekt läuft es aber darauf hinaus, dass ich 2 Frames / Datenframe verschicke. Bei 1ms Latenz werde ich bestenfalls auf 1000 Frames / Sekunde kommen, wenn nicht sogar nur 500. (Das ist, glaube ich, auch das Problem für die langsame Datenübertragung zum stk500 via USB.) Bleibe ich einfach bei meiner normalen Seriellen Schnittstelle mit 115k Baud komme ich ca. auf 10k Byte / s was bei durchschnittlicher Framesize von 10 Bytes (2-20Bytes) auch wieder auf die 1000 Frames kommt. Dabei aber mit (etwas) besseren Reaktionszeiten und ohne zusätzliche Hardware. Den Aufwand mich um meine Übertragungssicherheit zu kümmern, habe ich aber bei der einen wie bei der anderen Lösung. TCP/IP würde mit nicht nur besseren Speed bescheren (800k / 90 Bytes ~= 9000 Frames), sondern sich auch gleich mit um die fehlerfreie Übertragung kümmern. Schoene Gruesse, Scheintod
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.