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.
Najaa - 160mA bei 3.3V sind ja nun auch nicht sooo viel.
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.
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 :)
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
Und dann? Du mußt den ja auch mit Daten versorgen, wie willst du dass geschickt und vor allem schnell lösen?
@Jupp Das stimmt allerdings, da wird das Nadelöhr wohl der uC werden. 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
Ok, soweit die Theorie. "Do not use the DMA module to perform checksum calculations; perform checksums in software." (Errata Sheet).
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
Hätte hier noch einen RTL8139D (Realtek) rumfliegen, ist aber ein 128Pin-Monster. Der schafft glaub 100Mbit/s
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.
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.