mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ENC28J60 oder RTL8019AS?


Autor: nicht der Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will einen AVR-Webserver aufbauen und muss mich nun fuer einen 
Ethernetchip entscheiden.
Meine Auswahl fiehl auf den RTL8019AS oder den ENC28J60.
Nun wuerde mich interessieren, welcher von beiden besser ist (gibt ja 
fuer beide bereits funktionierende Projekte)

Mich wuerde dabei folgendes interessieren:
 - externe Hardwarebeschaltung (wenige und leicht beschaffbare Bauteile)
 - Anschluss an den AVR (SPI oder Adressleitungen)
 - Leistungsaufnahme (soll moeglichst geringe Stromaufnahme haben, habe 
ich leider nicht im Datenbaltt gefunden)
 - Softwareaufwand fuer Betrieb (suche keine fertigen TCP/IP-Stacks oder 
fertige Projekte, sondern einfach welcher sich besser anfuehlt)

Bauform und Beschaffung der beiden Chips sind egal (gibt beide bei CSD), 
da alles (MC + NIC) auf eine Platine soll (dh. keine ISA-Karte oder so)

Und ja, ich habe mir bereits die Datenblaetter runtergeladen und 
angeschaut :-)
Aber so Sachen wie Stromaufnahme habe ich leider nicht gefunden. 
Schaltplaene fuer Hardwarebeschaltung habe ich auch, ich will einfach 
eine subjektive Meinung von euch, welchen ihr nehmen wuerdet :-)

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Subjektiv, würde ich den ENC nehmen.
Hat weniger Füße und größer sind die auch noch.
Und es gibt eine DIP-Version, so braucht man nicht gleich die ganze 
Platine zerbraten.

Autor: Seb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Können beide "nur" 10Mbit/s?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn der Strom eine Rolle spielt, dann ist der ENC draussen. ~160mA. 
Steht übrigens im Datasheet. Chips von ISA-Karten liegen typischerweise 
bei 40-60mA.

Autor: nicht der Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Seb:
jep, koennen beide nur 10Mbit

@A.K.:
mist .. dann muss ich mir wohl doch ein paar ISA-Karten ersteigern oder 
so :-(
Hatte gehofft, dass es mit den ICs auch so geht (40mA sind deutlich 
besser als 160mA)

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sachte. Wozu war so ein RTL8019 wohl ursprünglich mal vorgesehen? Wozu 
hat er soviel Adress- und Datenpins? Noch dazu genau jene des guten 
alten ISA-Busses.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Najaa - 160mA bei 3.3V sind ja nun auch nicht sooo viel.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für dem Finger auf dem Chip ist der Unterschied überaus markant. Ich 
wundere mich nicht wirklich darüber, dass Microchip von den 
85°C-Anspruch des Datasheets im Erratasheet gleich wieder abrückt.

Autor: nicht der Rahul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K.:

wie meinst du das mit "Wozu war so ein RTL8019 wohl ursprünglich mal 
vorgesehen? Wozu
hat er soviel Adress- und Datenpins?"? Als Chipsatz fuer eine 
Netzwerkkarte natuerlich :-)

Ne im ernst, wie meinst du das? Stehe wohl ein wenig auf dem Schlauch.

Und 85°C sind mir definitiv zuviel, da der in einem Kleinen 
Platikgehaeuse rund um die Uhr laufen soll (deswegen auch der geringe 
Stromverbrauch).

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab mir hier einen kleinen POP3-Client mit dem ENC gebaut, dass 
Ding kann man ohne Probleme selbst nach mehreren tagen anfassen. 0,5 W 
Leistungsaufnahme bringen das Teil nicht gleich zum Glühen...

Nur der kleine 3,3 V Regler wurde anfangs merklich warm. In meinem 
endgültigen Layout hab ich dann einfach das Laschenpad deutlich größer 
gemacht und nun ist der auch saucool.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wollte damit sagen, dass man keine Netzwerkkarten via ebay 
schlachten muss, um an stromsparende ISA-Bus-Chips ranzukommen, denn der 
RTL8019 ist so einer. Die 40-60mA bezogen sich allerdings auf DM9008 und 
3COM, wieviel der RTL braucht weiss ich nicht.

Der ENC wird nicht 85° warm, sondern kann laut Datasheet bis 85° 
Umgebungstemperatur arbeiten.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ding kann man ohne Probleme selbst nach mehreren tagen anfassen

Die SMD-Version auf dem Olimex-Modul wird jedenfalls heiss. In der 
DIL-Version dürfte das weniger auffallen.

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Echt? Also ich hab die SO-Variante, ist völlig cool. Auf dem Olimex-Teil 
ist doch glaube ich die TSSOP-Variante, oder? Bin jetzt zu faul zum 
gucken :)

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich würde den ENC vorziehen. Der ist leichter zu beschaffen und man 
braucht keine ISA-karte ausschlachten oder benutzen, was ja auch platz 
spart. Die Temperatur-Probleme kann ich nicht bestätigen, nur wenn die 
Spannungsversorgung schlecht ist, sonst werden alle Handwarm. Auch der 
Aufwand beim Verdrahten ist besser beim ENC. Und 160mA bei 3,3V ist ja 
auch nicht die Welt.

CA Dirk

Autor: Frank aus Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich kann Dir eigentlich auch nur den ENC empfehlen, da er auch in 28 Pin 
SDIP erhältlich ist. Für so ein SMD Flat Pack müsste man zum 
experimetieren erst ein Layout entwerfen, das hätte mir zu Anfang doch 
ziemlich die lust verdorben.
Ausserdem ist er günstig, so um die 7 - 8 Euro, und gut für 
Privatbastler erhältlich. Ich habe mittlerweile auch meinen Webserver 
mit einem AT89c51ed2 laufen und auch nach längerer Betriebsdauer kann 
ich keine übermässige erwärmung feststellen. Bei mir läuft der 
AT89c51ed2 mit 5V im X2 Modus und der ENC mit 3,3V. Mit der 
Spannungsstabilisierung habe ich das so gelöst das der 3,3V Stabi nach 
dem 5V stabi kommt, so teilt sich die verbratene Energie schön auf beide 
Stabis auf.
Was noch Klasse wäre, wenn es den ENC noch in 100 MBit ausführung gäbe.

Gruß

Frank

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und dann? Du mußt den ja auch mit Daten versorgen, wie willst du dass 
geschickt und vor allem schnell lösen?

Autor: Frank aus Köln (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jupp

Das stimmt allerdings, da wird das Nadelöhr wohl der uC werden.

Gruß

Frank

Autor: guru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hmm, naja ich glaub es geht mehr um "Connectivity", dass man seinen 
Webserver auch in ein 100M-Ethernet einbinden kann. Oder würde der 
Bustakt zwischen uC und ENC in 100M so hoch werden, dass der uC es nicht 
mehr schafft?

Autor: Breti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Muss man bei dem RTL nicht die Checksummen im AVR in Software berechnen? 
Wenn ich mich recht erinnere, so senkt dies die mögliche Transferrate 
auf wenige kb/s in zusammenarbeit mit einem AVR.
Ich glaube der ENC kann das selber in Hardware.

Gruß,
Thomas

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Ethernet-CRC kann der RTL wie jeder andere Controller ganz gut 
selber rechnen. Für die TCP/IP-Checksums ist Software angesagt, das wird 
einem aber erst von Controllern für Gbit-Ethernet abgenommen.

Autor: Breti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich meinte die TCP/IP Checksummen (Ethernet ist selbstverständlich). 
Jetzt hab ich mir mal die Mühe gemacht und im Datenblatt nachgelesen:

"The ENC28J60 incorporates a dual purpose DMA
controller which can be used to copy data between
locations within the 8-Kbyte memory buffer. It can also
be used to calculate a 16-bit checksum which is
compatible with various industry standard protocols,
including TCP and IP." (Seite 73)

Ansonsten ist auch der Pattern Matching Filter für eingehende Pakete 
erwähnenswert.

Insgesamt würde ich Dir damit auch zum ENC raten, eben weil dieser für 
die zusammenarbeit mit 8bit Microcontrollern konstruiert wurde. Er 
besitzt einfach einige nette features, die der RTL nicht hat. Ich habe 
zwar selbst noch nicht damit gearbeitet - würde ihn bei einem solchen 
Projekt aber wählen.

Gruß,
Thomas

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, soweit die Theorie. "Do not use the DMA module to perform checksum 
calculations; perform checksums in software." (Errata Sheet).

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Apropos Performance: Eine deutliche Bremse bei den kleineren 
TCP/IP-Stacks für Microcontroller ist die oft fehlende Unterstützung für 
TCP Windows. Grund dafür: Entweder muss das ganze Window 
zwischengespeichert werden, was bei DSL ohne Fastpath auf einige zig KB 
pro Socket rausläuft, oder der API muss die Daten entsprechend weit 
zurück reproduzieren können.

Die TCP-Checksum hingegen lässt sich mit AVRs per Assembler-Code 
ausgesprochen flott berechnen. Je nach Grad der Optimierung 4-6 Takte 
pro Byte.

Autor: Breti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

das mit dem Errata Sheet hatte ich nicht gelesen. Ich ging davon aus, 
dass wenn es im Datenblatt steht, es auch funktioniert :)

Auf jeden Fall ist es mal wieder ein super Beispiel für den Unterschied 
zwischen Theorie und Praxis :)

Gruß,
Thomas

Autor: Thomas B. (thomasb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine weitere Alternative wäre wohl der CP2200 von Silicon Labs. 
Zumindest schaut der dem Datenblatt nach für mich sehr gut aus. (z.B. 
schnelle parallele Anbindung)

Hat damit schon jemand was gemacht ?

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> das mit dem Errata Sheet hatte ich nicht gelesen. Ich ging davon aus,
> dass wenn es im Datenblatt steht, es auch funktioniert :)

Kleiner Tip zu Microchip, zuerst Seite 1 des Datenblatts lesen, 
anschließend  sämtliche Erratas dazu und meißtens wirst du dann 
feststellen, dass sich die auf Seite 1 des DB beworbenen ach so tollen 
Features mehr oder weniger in Luft auflösen.

Autor: Breti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Kleiner Tip zu Microchip, zuerst Seite 1 des Datenblatts lesen,
> anschließend  sämtliche Erratas dazu und meißtens wirst du dann
> feststellen, dass sich die auf Seite 1 des DB beworbenen ach so tollen
> Features mehr oder weniger in Luft auflösen.

Naja - bisher habe ich halt immer die AVRs benutzt. Mit PICs habe ich 
noch keine Erfahrungen gemacht. Wenn ich dann mal irgendwann PICs 
einsetzen wollen würde, werd ich mich sicher an deinen Ratschlag 
erinnern und vorher auch die Errata durchlesen ;)

Gruß,
Thomas

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das bezog sich in diesem Fall auf den ENC28J60, nicht auf die 
PIC-Controller...

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal was zu praktisch erzielbaren Datenraten:

Schlanke TCP/IP Implementierungen wie uIP oder Ulrich Radigs Webserver 
spielen TCP als Pingpong. Bei jedem gesendeten Paket wird auf die 
Bestätigung gewartet. Da allerdings erwachsene TCP-Stacks zumindest bei 
grösseren Datenmengen solche Bestätigungen nur ca. 200msec verzögert 
senden, ist die Datenrate zwangsläufig sehr begrenzt. Da ist m.W. auch 
kein Kraut gegen gewachsen. Und je kleiner der Paketpuffer, desto 
langsamer wird es.

Praktisch kam dabei im lokalen Netz bei uIP und Frames <1200 Bytes eine 
Rate von etwas über 5KB/sec heraus. Nicht berauschend, aber im Rahmen 
eines solchen simplen TCP/IP-Stacks ist bei TCP wohl nicht mehr drin. 
Für die üblicherweise einfaches Seiten eines Controllers aber ok.

Will man grössere Datenmengen übertragen (z.B. Dataflash,SD-Card,...), 
dann kann man ggf. auf UDP ausweichen. Und eine Protokoll oben drauf 
setzen, dass verlorene Pakete wiederholt. Was im einfachsten Fall auch 
heissen kann, dass man die ganze Übertragung wiederholt - allerdings 
darf man davon ausgehen, dass diese Methode nur im lokalen Netz zu 
befriedigenden Ergebnissen führt.

Jedenfalls kam so eine Datenrate von ca. 150KB/sec heraus (AVR 16MHz, 
Daten aus Dataflash). Damit kann ich ganz gut leben.

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@A.K.

Also was du da beschreiben tust kann ich nachvollziehen, aber nur in 
bezug auf µIP. Aber wer sich mit Netzwerken beschäftigt wird schnell 
merken das µIP das letzte ist womit man TCP/IP machen will. Denn Ihre 
"vollständige" Implementierung entpuppt sich bei genauer betrachtung als 
mehr hingefuscht als programmiert. So setzen sie sich über viele 
vereinbarungen hinweg die IP/TCP vorsehen. Einzig das Fragment haben sie 
ein bisschen gelöst, was aber auch mehr eine Krücke ist. Ich selber 
komme mit meinen eigenen Stack schon auf wesentlich mehr, ohne das ich 
das irgend was optimiere, gerade im lokalen LAN geht da die Post schon 
recht ordentlich ab.

CA Dirk

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Radig'sche Implementierung ist strukturell auch nicht besser, zudem 
grauenvoller Programmierstil. Aber uIP finde durchaus brauchbar, 
vorausgesetzt man unterstützt nur sehr wenige Dienste. In meiner 
Anwendung wäre ich zudem auch ohne Tempo ausgekommen, den UDP-Transfer 
hatte ich dann einfach mal in kurzer Zeit hingesemmelt und er lief gut.

Dass solche Implementierungen mit den RFCs etwas grosszügig umgehen 
liegt nahe. Wenn man sowas in einen Mega168 reinquetschen will muss man 
sparen.

Hast du es etwas konkreter bzgl. Missachtung von Konventionen?

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jup ... mit Sicherheit, aber die haben auch utopische beispiele bei µIP. 
Sie werben z.b. mit einen Webserver der in nur 600Byte rein passt, ohne 
die Randbedingungen zu nennen, abgesehen das der grauenvoll ist. Und zu 
dem ist der Stack für den Ottonormalbenutzer nicht zu handhaben und für 
stabile Anwendungen fast unbrauchbar, das einzig praktische ist die 
Implementierung der ProtoThreads.
Was mir zum Stack einfallen tut ist z.b. das Handling der MSS (maximum 
segment size). Das ist einer der wichtigsten Optionen im Optionfeld 
neben der Windowsize im TCP-Header. Wer was brauchbares haben will 
benutzt den, und die RFC erwähnt dies auch explizip. Oder das sparen der 
Stats der TCP-Vrbindung, wieso muss das im TCP/IP-Header mit rein 
codiert werden, nur um eine Handvoll Bytes zu sparen, ganz zu schweigen 
das man damit schon nicht die Stats komplett sichern kann. Der Stack 
greif dadurch oft daneben beim Handling und könnte viel fließender 
arbeiten, gerade was das ACK und so angeht. Aber mehr will ich mich auch 
nicht drüber auslassen.

CA Dirk

Autor: Muräär (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hätte hier noch einen RTL8139D (Realtek) rumfliegen, ist aber ein 
128Pin-Monster.
Der schafft glaub 100Mbit/s

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RTL8139D wird PCI sein, nehme ich mal an. Es gibt zwar so allerhand 
Micros mit PCI-Anschluss (z.B. jene Sorte, die Drucker rotieren lässt), 
aber die hier üblichen müssen ohne auskommen. Und dann wirds spassig.

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.