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 :-)
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.
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.
@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)
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.
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.
@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).
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.
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.
> 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.
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
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
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?
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
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.
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
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.
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
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 ?
> 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.
> 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
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.
@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
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?
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
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.
