www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik rtl8139


Autor: Scheintod (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel Nöthen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Scheintod (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Scheintod (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: hebel23 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marko B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Scheintod (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/embedde...

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Scheintod (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Scheintod (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Scheintod (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Scheintod (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

schau mal hier:  http://www.laskater.com/projects/uipAVR.htm


Gruss

Steffen

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Scheintod (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.