Atmel am Ethernet - Pollin Bausatz AVR-NET-IO (Ethernet-Plat

[Gerrit Heitsch]

Henry Kiefer wrote:

Michael Baeuerle schrieb:
Christian Dietrich wrote:
Hans-Willi Offergeld wrote:
Ausserdem wird der 7805 ziemlich heiss. Dem habe ich zuerst
einmal einen KK besorgt.
Naja liegt halt dran, dass der ENC28J60 relativ viel Strom (ca 100mA)
bei 3,3V braucht [...]

Laut Datasheet sind es typisch 120mA wenn er nichts tut und bis zu 180mA
beim Senden.


So wie in der guten alten NMOS-Zeit.

Naja, das Chipchen enthaelt auch noch den PHY fuer 10baseT, man braucht
nur noch den Uebertrager und schon kann man 100m ueberbruecken. Ich
denke mal, dass sowas nicht ganz ohne Treiberleistung abgeht.

Nebenbei hat er 2 LED-Treiber integriert, fehlt nur noch der Widerstand
und schon hat man 2 LEDs zur Anzeige des Betriebszustandes. Pro LED kann
er bis 12mA bringen. Die Polung der LEDs (gegen GND oder Vcc) wird beim
RESET erkannt, bei LEDB entscheidet die Polung ueber
Halbduplex/Vollduplex beim Ethernet (LEDB gegen GND = HDX)

Gerrit

 

[Peter Kern]

Gerrit Heitsch schrieb:

Peter Kern wrote:
Gerrit Heitsch schrieb:
Platine ist aufgebaut und getestet. Funktionierte auf Anhieb. Dem
7805 sollte man aber einen Kuehlkoerper verpassen, mir wird der ohne
Kuehlung entschieden zu heiss.

Wie hoch ist denn die Ruhestromaufnahme?

240mA, gemessen mit einem alten Multimeter auf der 10A-Stellung im
AC-Breich. Nachdem der ENC28J60 im Standby anscheinend knapp unter 200mA
braucht koennte das hinkommen (plus 2 LEDs, MAX232 und ATmega32). Er
wird ziemlich warm.

Na ein kleiner Aluwürfel liegt hier noch rum....

Frage mal noch dazu: Gibts ne Möglichkeit veränderte Firmware
einzuspielen?

Es ist ein Atmega32... Du kannst problemlos einen anderen Atmega32
einsetzen und deine eigene Firmware benutzen oder du steckst den
gelieferten Atmega32 in einen Programmieradapater und spielst neue
Firmware auf. Ein ISP-Connector ist onboard. Du brauchst also nur ein
pasendes Kabel und AVRdude oder Ponyprog.

Danke.
Dann weiss ich schon mal um was ich mich kümmern muss
Mal sehen, wann nachgeliefert wird....

Peter

 

[Michael Baeuerle]

Gerrit Heitsch wrote:

[...]
Die Polung der LEDs (gegen GND oder Vcc) wird beim
RESET erkannt, bei LEDB entscheidet die Polung ueber
Halbduplex/Vollduplex beim Ethernet (LEDB gegen GND = HDX)

Einer der Hauptnachteile dieses Chips. Neben den unzaehligen Erratas
kann er Full-Duplex nicht automatisch aushandeln.


Micha
--
http://micha.freeshell.org/

 

[Peter Kern]

Peter Kern schrieb:

Hat den jemand bekommen?
Wir hatten noch ein wenig dazu gepackt.. alles da nur die nicht ;(

Heute kam unser Satz.

Allerdings wirds wohl eher nächstes WE werden. Und Wetter sich noch so
hält dann erst in 14 Tagen. Die freien Tage sind jetzt vorbei. ;(

Peter...

....sein erstes digitales Projekt.

 

[Gerrit Heitsch]

Michael Baeuerle wrote:

Gerrit Heitsch wrote:
[...]
Die Polung der LEDs (gegen GND oder Vcc) wird beim
RESET erkannt, bei LEDB entscheidet die Polung ueber
Halbduplex/Vollduplex beim Ethernet (LEDB gegen GND = HDX)

Einer der Hauptnachteile dieses Chips. Neben den unzaehligen Erratas
kann er Full-Duplex nicht automatisch aushandeln.

Autonegotiation ist bei 10baseT meines Wissens nicht sauber
implementiert und deshalb sollte man, so Vollduplex nicht unbedingt sein
muss, bei Halbduplex bleiben. Nachdem das der Fallback ist kann die
andere Seite ruhig Autonegotiation benuten. Speziell beim ENC28J60 am
ueblichen Microcontroller ist es ja nicht so, dass die Bandbreite knapp
werden koennte und man ohne Vollduplex nicht auskaeme.

Hingegen sollte man bei allen anderen Anwendungen die ueber 10 Mbit
rausgehen _immer_ Autonegotiation benutzen. Also nicht, wie frueher
ueblich, 100FDX fest einstellen. Seit GBit ueber Kupfer Autonegotiation
zwingend vorschreibt bekommt das sogar Cisco hin.

Gerrit

 

[Henry Kiefer]

Michael Baeuerle schrieb:

Gerrit Heitsch wrote:
[...]
Die Polung der LEDs (gegen GND oder Vcc) wird beim
RESET erkannt, bei LEDB entscheidet die Polung ueber
Halbduplex/Vollduplex beim Ethernet (LEDB gegen GND = HDX)

Einer der Hauptnachteile dieses Chips. Neben den unzaehligen Erratas
kann er Full-Duplex nicht automatisch aushandeln.

*würg*

Aber es gibt ja noch die Taiwaner. Irgendwie ein nicht richtig
beackerter Markt. Hatte Maxim nicht nach Wünschen gefragt?


- Henry


--
www.ehydra.dyndns.info

 

[Michael Schwingen]

In article <gajge5$1tq$2@cb.generation-online.de>,
Henry Kiefer <ehydra_news_20080903@arcor.de> wrote:

*würg*

Aber es gibt ja noch die Taiwaner. Irgendwie ein nicht richtig
beackerter Markt. Hatte Maxim nicht nach Wünschen gefragt?

Ich denke, sinnvoll wäre das nur direkt im Controller integriert. Der ASIX
AX11001 hat einen 8051-Kern sowie integrierten Ethernet-PHY, ansonsten wäre
mein derzeitiger Favorit einer von Luminary - LM3S6100, LM3S6918 o.ä., die
haben einen funktionierenden 100MBit-MAC+PHY integriert.

cu
Michael
--
Some people have no respect of age unless it is bottled.

 

[Michael Baeuerle]

Gerrit Heitsch wrote:

Michael Baeuerle wrote:

Einer der Hauptnachteile dieses Chips. Neben den unzaehligen Erratas
kann er Full-Duplex nicht automatisch aushandeln.

Autonegotiation ist bei 10baseT meines Wissens nicht sauber
implementiert und deshalb sollte man, so Vollduplex nicht unbedingt sein
muss, bei Halbduplex bleiben.

Das Datasheet des CP220x von Silicon Labs behauptet zumindest, dass der
10BaseT und Vollduplex automatisch verhandeln kann.

Nachdem das der Fallback ist kann die
andere Seite ruhig Autonegotiation benuten. Speziell beim ENC28J60 am
ueblichen Microcontroller ist es ja nicht so, dass die Bandbreite knapp
werden koennte und man ohne Vollduplex nicht auskaeme.

Das Problem ist nicht die Bandbreite oder die Kollisionen sondern der
potentielle Paketverlust (und die damit verbundene Latenz und
Ressourcenverschwendung). Ohne Vollduplex gibts keine IEEE 802.3x
Flusskontrolle, d.h. es bleibt nur Backpressure. Dazu schreibt
Microchip:

| Given the detrimental network effects that are possible
| and lack of effectiveness, it is not recommend that half-
| duplex flow control be used unless the application will
| be in a closed network environment with proper testing.

Das will man nicht wirklich und muss dann mit TCP-Paketwiderholung
leben. Die kann man selbst bei nur einer Verbindung durch ein
TCP-Receive-Window das kleiner als der RX-Buffer des Chips ist nicht
vermeiden (da der Chip ja auch non-TCP Pakete empfaengt, z.B. ARP, ICMP,
UDP). Die anderen Pakete fuellen dann den Buffer des Chips schon mal
schneller als der langsame Mikrocontroller die Pakete verarbeiten kann.
Wenn dann der TCP-Treiber auf dem Mikrocontroller mangels Speicher kein
Reordering unterstuetzt, werden evtl. auch noch zusaetzlich Pakete
empfangen und letztlich weggeworfen (weil out-of-order) die bereits fast
den ganzen Protokollstack durchlaufen und entsprechend Ressourcen
verbraucht haben.

Damit nicht genug kommt beim ENC28J60 dann noch Errata 10 ins Spiel: Im
Halbduplex-Modus muss man nach jedem Paket den Transmitter resetten
(oder einen noch komplizierteren Workaround machen) weil sich sonst der
Chip aufhaengen kann ...


Micha

 

[Gerrit Heitsch]

Michael Baeuerle wrote:

Gerrit Heitsch wrote:
Michael Baeuerle wrote:
Einer der Hauptnachteile dieses Chips. Neben den unzaehligen Erratas
kann er Full-Duplex nicht automatisch aushandeln.
Autonegotiation ist bei 10baseT meines Wissens nicht sauber
implementiert und deshalb sollte man, so Vollduplex nicht unbedingt sein
muss, bei Halbduplex bleiben.

Das Datasheet des CP220x von Silicon Labs behauptet zumindest, dass der
10BaseT und Vollduplex automatisch verhandeln kann.

Ja, es kann funktionieren, muss aber nicht, haengt stark von der
Gegenstelle ab und ob sich der Chip-Designer noch die Muehe gemacht hat
10FDX incl. Erkennung sauber zu implementieren. Bei einem
Switch-Controller fuer GBit laesst man sowas inzwischen mal unter den
Tisch fallen. Ich hab hier einen GBit-Switch mit Marvell-Controller, der
ist bei 10baseT-Clients nicht stabil, der entsprechende Port haengt sich
nach ein paar Tagen gerne mal auf.

Nachdem das der Fallback ist kann die
andere Seite ruhig Autonegotiation benuten. Speziell beim ENC28J60 am
ueblichen Microcontroller ist es ja nicht so, dass die Bandbreite knapp
werden koennte und man ohne Vollduplex nicht auskaeme.

Das Problem ist nicht die Bandbreite oder die Kollisionen sondern der
potentielle Paketverlust (und die damit verbundene Latenz und
Ressourcenverschwendung).

Kollisionen sollte der Chip selber erkennen und den Restransmit
selbstaendig durchfuehren. Nachdem Hubs heute eher selten sind besteht
deine Kollisions-Domain nur aus dem ENC28J60 und dem Switchport.
Letzteren wirst du eher nicht ueberlasten koennen.

Damit nicht genug kommt beim ENC28J60 dann noch Errata 10 ins Spiel: Im
Halbduplex-Modus muss man nach jedem Paket den Transmitter resetten
(oder einen noch komplizierteren Workaround machen) weil sich sonst der
Chip aufhaengen kann ...

Solche Fehler sind nicht wirklich neu und auch bei anderen NICs zu
finden. Der INTeL 82557 hatte einen Fehler bei dem sich der Receiver
aufhaengen konnte (Siehe Bootmeldung des Linux-Treibers). Andere NICs
moegen Halbduplex nur wenn die minimale Paketgroesse auf um die 100
Bytes erhoeht wird. Von Problemen mit dem RTL8139 gar nicht zu reden.
Normalerweise siehst du diese Bugs aber nie, da du einfach den fertigen
Treiber installierst und dich nicht drum kuemmerst. Lies mal den
Quelltext zu den diversen Linux-Treibern, teilweise sehr unterhaltsam.

Der ENC28J60 ist nicht perfekt (waere schoen ), aber immerhin ist es
mit diesem Chip moeglich einen Microcontroller sehr einfach und
pinsparend mit Ethernet zu verbinden. Nebenbei gibts ihn als DIP was
fuer Bastler und Prototypen interessant ist. Wer mehr als nur
Grundperformance braucht muss sich nach einem anderen NIC umsehen. Die
gibts auch, sind dann aber SMD und aufwendiger in der Ansteuerung.

Gegen eine neue Revision mit weniger Bugs und weniger Stromverbrauch
haette ich allerdings nichts einzuwenden. Bitte per Software unterscheidbar.

Gerrit

 

[Gerrit Heitsch]

Georg Acher wrote:

Michael Baeuerle <michael.baeuerle@stz-e.de> writes:

Damit nicht genug kommt beim ENC28J60 dann noch Errata 10 ins Spiel: Im
Halbduplex-Modus muss man nach jedem Paket den Transmitter resetten
(oder einen noch komplizierteren Workaround machen) weil sich sonst der
Chip aufhaengen kann ...

Schon erstaunlich, dass es ca. 20 Jahre nach Einführung von 10Mbit-Ethernet
immer noch möglich ist, solche Bugs zu produzieren und das auch noch zu
verkaufen.

Das Problem duerfte im Unterschied zwischen simulierter Schaltung und
der Implementation auf dem Chip zu finden sein. Die Simulation laeuft
sicher problemlos. Eine neue Maske zu machen kostet Geld und wenn es
funktionierende Workarounds gibt wird die erste Revision erstmal
verkauft. Macht jeder Hersteller so.

Gerrit

 

[Georg Acher]

Michael Baeuerle <michael.baeuerle@stz-e.de> writes:

Damit nicht genug kommt beim ENC28J60 dann noch Errata 10 ins Spiel: Im
Halbduplex-Modus muss man nach jedem Paket den Transmitter resetten
(oder einen noch komplizierteren Workaround machen) weil sich sonst der
Chip aufhaengen kann ...

Schon erstaunlich, dass es ca. 20 Jahre nach Einführung von 10Mbit-Ethernet
immer noch möglich ist, solche Bugs zu produzieren und das auch noch zu
verkaufen. Mir fällt da spontan der Burggraben ein.

--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[Gerrit Heitsch]

Georg Acher wrote:

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes:

Das Problem duerfte im Unterschied zwischen simulierter Schaltung und
der Implementation auf dem Chip zu finden sein. Die Simulation laeuft
sicher problemlos. Eine neue Maske zu machen kostet Geld und wenn es
funktionierende Workarounds gibt wird die erste Revision erstmal
verkauft. Macht jeder Hersteller so.

Aber hallo, 10Mbit sind doch keine Raketentechnologie mehr, wo man mit nichts
ausser dem echten Chip testen kann. Der Kram passt von Grösse und Geschwindigkeit
locker in ein kleineres FPGA. Damit kann man den digitalen Kram problemlos
stressen, bevor man eine Maske in Auftrag gibt...

Das heisst dann aber nur, dass er in diesem FPGA problemlos laeuft. Der
ENC28J60 hat nebenbei noch 8K RAM als Paketpuffer integriert, so klein
wird das FPGA also nicht sein wo das reinpasst. Das Problem bei 'haengt
sich hin und wieder auf' sind eher kritische Pfade im Bezug auf Timing
oder Stromversorgung und die sind nunmal leider spezifisch auf die
verwendete Maske und den verwendeten Prozess.

Der Hersteller wird das alles getestet haben, wuerde mich jedenfalls
wundern wenn nicht. Trotzdem gibt es zumindest bei der ersten Revision
des echten Chips immer unangenehme Ueberraschungen.

Inzwischen scheint es mehrere Revisionen des Chips zu geben wobei B7 die
aktuelle ist, es werden also Fehler berichtigt. Die Frage ist wie
aufwendig manche dieser Fehler sind, ein komplettes Redesign moechte man
schliesslich vermeiden.

Gerrit

 

[Michael Baeuerle]

Gerrit Heitsch wrote:

Michael Baeuerle wrote:
Gerrit Heitsch wrote:
Michael Baeuerle wrote:

Einer der Hauptnachteile dieses Chips. Neben den unzaehligen Erratas
kann er Full-Duplex nicht automatisch aushandeln.

Autonegotiation ist bei 10baseT meines Wissens nicht sauber
implementiert und deshalb sollte man, so Vollduplex nicht unbedingt sein
muss, bei Halbduplex bleiben.

Das Datasheet des CP220x von Silicon Labs behauptet zumindest, dass der
10BaseT und Vollduplex automatisch verhandeln kann.

Ja, es kann funktionieren, muss aber nicht, haengt stark von der
Gegenstelle ab und ob sich der Chip-Designer noch die Muehe gemacht hat
10FDX incl. Erkennung sauber zu implementieren.

Wenn nicht ist der Port kaputt, jedenfalls fuer 10MBit/s. Dann haetten
sie es im Zweifel lieber gar nicht implementiert, ein konformes Geraet
haette dann korrekt auf Halbduplex geschaltet.

Nachdem das der Fallback ist kann die
andere Seite ruhig Autonegotiation benuten. Speziell beim ENC28J60 am
ueblichen Microcontroller ist es ja nicht so, dass die Bandbreite knapp
werden koennte und man ohne Vollduplex nicht auskaeme.

Das Problem ist nicht die Bandbreite oder die Kollisionen sondern der
potentielle Paketverlust (und die damit verbundene Latenz und
Ressourcenverschwendung).

Kollisionen sollte der Chip selber erkennen und den Restransmit
selbstaendig durchfuehren.

Er _sollte_, tut der ENC28J60 aber nicht dank Errata 13:

| When transmitting in Half-Duplex mode with some
| link partners, the PHY will sometimes incorrectly
| interpret a received link pulse as a collision event.
| [...]

Empfohlener Workaround laut Microchip:

| Implement a software retransmit mechanism
| whenever a late collision occurs. [...]

Nachdem Hubs heute eher selten sind besteht
deine Kollisions-Domain nur aus dem ENC28J60 und dem Switchport.
Letzteren wirst du eher nicht ueberlasten koennen.

Ack. Mir ging es ja eigentlich auch um Paketverlust durch RX-Overflow im
ENC28J60 (wegen fehlender L2-Flusskontrolle).

Damit nicht genug kommt beim ENC28J60 dann noch Errata 10 ins Spiel: Im
Halbduplex-Modus muss man nach jedem Paket den Transmitter resetten
(oder einen noch komplizierteren Workaround machen) weil sich sonst der
Chip aufhaengen kann ...

Solche Fehler sind nicht wirklich neu und auch bei anderen NICs zu
finden. Der INTeL 82557 hatte einen Fehler bei dem sich der Receiver
aufhaengen konnte (Siehe Bootmeldung des Linux-Treibers).

So einen habe ich zu Hause im Rechner, da heult der Treiber auch immer
rum.

Andere NICs
moegen Halbduplex nur wenn die minimale Paketgroesse auf um die 100
Bytes erhoeht wird. Von Problemen mit dem RTL8139 gar nicht zu reden.
Normalerweise siehst du diese Bugs aber nie, da du einfach den fertigen
Treiber installierst und dich nicht drum kuemmerst. Lies mal den
Quelltext zu den diversen Linux-Treibern, teilweise sehr unterhaltsam.

Die Sprueche kenne ich schon. Nett find ich den hier im Treiber fuer die
3Com 3C501:

| Do not purchase this card, even as a joke.
| It's performance is horrible, and it breaks in many ways.

Der ENC28J60 ist nicht perfekt (waere schoen ),

"Nicht perfekt" ist schon stark untertrieben. Was Microchip da als Rev.
B7 verkauft heisst anderswo "engineering sample". Positiv anrechnen muss
man ihnen, dass sie die Probleme offen dokumentieren und man die
Erratasheets nicht nur auf Anfrage bekommt.

aber immerhin ist es
mit diesem Chip moeglich einen Microcontroller sehr einfach und
pinsparend mit Ethernet zu verbinden. Nebenbei gibts ihn als DIP was
fuer Bastler und Prototypen interessant ist. Wer mehr als nur
Grundperformance braucht muss sich nach einem anderen NIC umsehen. Die
gibts auch, sind dann aber SMD und aufwendiger in der Ansteuerung.

Ack. Das serielle Interface ist der Punkt der den ENC28J60 ausmacht.

Gegen eine neue Revision mit weniger Bugs und weniger Stromverbrauch
haette ich allerdings nichts einzuwenden.
Bitte per Software unterscheidbar.

Die Revision war doch schon immer auslesbar (Register EREVID).


Micha

 

[Michael Baeuerle]

Gerrit Heitsch wrote:

Inzwischen scheint es mehrere Revisionen des Chips zu geben wobei B7 die
aktuelle ist,

Kaeuflich waren AFAIK die Revisions B1, B4, B5 und B7.

es werden also Fehler berichtigt. Die Frage ist wie
aufwendig manche dieser Fehler sind, ein komplettes Redesign moechte man
schliesslich vermeiden.

Es wurden eigentlich nur zwei Fehler behoben: Seit B5 braucht man nicht
mehr mindestens 8MHz SPI-Takt und der Temperaturbereich ist wie er sein
soll. Bleiben noch 15 Fehler von denen 7 weh tun.


Micha

 

[Gerrit Heitsch]

Michael Baeuerle wrote:

Gerrit Heitsch wrote:
Michael Baeuerle wrote:
Gerrit Heitsch wrote:
Michael Baeuerle wrote:
Einer der Hauptnachteile dieses Chips. Neben den unzaehligen Erratas
kann er Full-Duplex nicht automatisch aushandeln.
Autonegotiation ist bei 10baseT meines Wissens nicht sauber
implementiert und deshalb sollte man, so Vollduplex nicht unbedingt sein
muss, bei Halbduplex bleiben.
Das Datasheet des CP220x von Silicon Labs behauptet zumindest, dass der
10BaseT und Vollduplex automatisch verhandeln kann.
Ja, es kann funktionieren, muss aber nicht, haengt stark von der
Gegenstelle ab und ob sich der Chip-Designer noch die Muehe gemacht hat
10FDX incl. Erkennung sauber zu implementieren.

Wenn nicht ist der Port kaputt, jedenfalls fuer 10MBit/s. Dann haetten
sie es im Zweifel lieber gar nicht implementiert, ein konformes Geraet
haette dann korrekt auf Halbduplex geschaltet.

Bei dem erwaehnten Switch ist 10Mbit komplett im Eimer. Egal welcher
Client und/oder Port, wenn er 10Mbit spricht schaltet sich der Port nach
ein paar Tagen ab. Da hat sich der Hersteller die Tests gespart, denn
wer benutzt heute noch 10Mbit und steckt den Client an einen
GBit-Switch? Der Workaround war ein alter 10/100-Switch zwischen GBit
und 10Mbit. Jetzt laeufts. Hier waere eher ein Bad im Burggraben angesagt.

Damit nicht genug kommt beim ENC28J60 dann noch Errata 10 ins Spiel: Im
Halbduplex-Modus muss man nach jedem Paket den Transmitter resetten
(oder einen noch komplizierteren Workaround machen) weil sich sonst der
Chip aufhaengen kann ...
Solche Fehler sind nicht wirklich neu und auch bei anderen NICs zu
finden. Der INTeL 82557 hatte einen Fehler bei dem sich der Receiver
aufhaengen konnte (Siehe Bootmeldung des Linux-Treibers).

So einen habe ich zu Hause im Rechner, da heult der Treiber auch immer
rum.

Wie man sieht sind Workarounds nicht notwendigerweise schlecht. Ist
immer die Frage welchen Einfluss ein Workaround auf die Performance hat.

Andere NICs
moegen Halbduplex nur wenn die minimale Paketgroesse auf um die 100
Bytes erhoeht wird. Von Problemen mit dem RTL8139 gar nicht zu reden.
Normalerweise siehst du diese Bugs aber nie, da du einfach den fertigen
Treiber installierst und dich nicht drum kuemmerst. Lies mal den
Quelltext zu den diversen Linux-Treibern, teilweise sehr unterhaltsam.

Die Sprueche kenne ich schon. Nett find ich den hier im Treiber fuer die
3Com 3C501:

| Do not purchase this card, even as a joke.
| It's performance is horrible, and it breaks in many ways.

Das gleiche gilt fuer den RTL8139, zumindest vor ein paar Jahren. Wenn
du mit dieser Karte NFS machen wolltest musstest du die Blocksize auf
3072 Bytes begrenzen, schon bei 4096 brach die Performance komplett
zusammen. Grund ist die etwas 'geizige' Implementation des
DMA-Controllers im 8139. Eine gebrauchte 3C905 loeste alle
diesbezueglichen Probleme.

aber immerhin ist es
mit diesem Chip moeglich einen Microcontroller sehr einfach und
pinsparend mit Ethernet zu verbinden. Nebenbei gibts ihn als DIP was
fuer Bastler und Prototypen interessant ist. Wer mehr als nur
Grundperformance braucht muss sich nach einem anderen NIC umsehen. Die
gibts auch, sind dann aber SMD und aufwendiger in der Ansteuerung.

Ack. Das serielle Interface ist der Punkt der den ENC28J60 ausmacht.

Ein weiteres Feature ist das kleine Gehaeuse (bei der SMD-Version) und
das integrierte RAM. Man braucht also nur den ENC28J60, einen MagJack
plus etwas Kleinkram und schon hat man Ethernet.

BTW: Laut Errata-Sheet fuer B7 Punkt 6 soll man als Rbias einen
Widerstand mit 2,32KOhm 1% verwenden. Pollin packt beim Bausatz einen
2,2KOhm 5% dazu. Zu funktionieren scheint es damit auch...

BTW2: Bei meinem Bausatz war ein ENC28J60-I/SP dabei. Laut microchip ist
das die Version fuer -40 bis +85 Grad C. Normal waeren 0-70.

Gerrit

 

[Georg Acher]

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes:

Das Problem duerfte im Unterschied zwischen simulierter Schaltung und
der Implementation auf dem Chip zu finden sein. Die Simulation laeuft
sicher problemlos. Eine neue Maske zu machen kostet Geld und wenn es
funktionierende Workarounds gibt wird die erste Revision erstmal
verkauft. Macht jeder Hersteller so.

Aber hallo, 10Mbit sind doch keine Raketentechnologie mehr, wo man mit nichts
ausser dem echten Chip testen kann. Der Kram passt von Grösse und Geschwindigkeit
locker in ein kleineres FPGA. Damit kann man den digitalen Kram problemlos
stressen, bevor man eine Maske in Auftrag gibt...

--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[Gerrit Heitsch]

Georg Acher wrote:

Ich habe mir den Chip auch schon mal für unser Praktikum angeschaut, bin dann
aber lieber bei der Athernut-Kombination AVR+RTL8019 geblieben. Die Taiwanesen
konnten sowas schon vor 15 Jahren produzieren und der 8019 hat wahrscheinlich
weniger echte Fehler...

Das Problem mit dem 8019 ist, dass er SMD ist und einen Haufen Pins hat.
Du musst einen ISA-Bus in Software nachbauen und verballerst da eine
Menge I/O-Pins. Intern verhaelt er sich meines Wissens wie eine NE2000,
ist also kein wirklich neues Design.

Statt dem RTL8019 muesste auch ein UMC UM9007 oder UM9008 funktionieren,
ist auch so ein Ein-Chip NE2000-Clone.

Gerrit

 

[Gerrit Heitsch]

Georg Acher wrote:

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes:

Das Problem mit dem 8019 ist, dass er SMD ist und einen Haufen Pins hat.
Du musst einen ISA-Bus in Software nachbauen und verballerst da eine

Naja, ein Nachmittag Kabel abisiolieren halt, passt aber alles in ein
Steckbrett:

http://www.lrr.in.tum.de/~acher/imgs/20071119_003.jpg

Ausserdem bekommt der gemeine Student bei der Grösse des Steckbretts auch etwas
Respekt vor der Technik ;-)

Dem Aussehen nach muesste man das zweite Steckbrett komplett
wegrationalisieren koennen, oder?

Gerrit

 

[Gerrit Heitsch]

Georg Acher wrote:

Das ist für die Verbastelung der FPGA-Ausgänge gedacht. Das Projekt (so ca. 8-10
Erst/Zweitsemester-Informatiker) macht eine übers Netz ansteuerbare Grafikkarte
(so ala VTX). Da muss man dann plattformübergreifend programmieren können, am PC
für das Client-Tool, den AVR für das Netzwerkprotokoll über TCP und das FPGA in
VHDL als VGA-Karte. Sieht am Anfang immer monströs komplex aus, klappt aber immer
recht gut.

Wenn ich mir ueberlege, dass ich damals noch mit einem 8080 rumspielen
musste... Hex-Tastatur usw. Wird man direkt neidisch.

Fuer fortgeschrittene Studenten waere der ENC28J60 aber wieder eine gute
Idee. Warum? Weil sie dabei lernen wuerden, dass ein Chip sich nicht
unbedingt wie im Datenblatt beschrieben verhaelt sondern zusaetzliches
Gehirnschmalz erfordern kann bevor er funktioniert.

Gerrit

 

[Joerg]

Georg Acher wrote:

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> writes:

http://www.lrr.in.tum.de/~acher/imgs/20071119_003.jpg

Ausserdem bekommt der gemeine Student bei der Grösse des Steckbretts auch etwas
Respekt vor der Technik ;-)
Dem Aussehen nach muesste man das zweite Steckbrett komplett
wegrationalisieren koennen, oder?

Das ist für die Verbastelung der FPGA-Ausgänge gedacht. Das Projekt (so ca. 8-10
Erst/Zweitsemester-Informatiker) macht eine übers Netz ansteuerbare Grafikkarte
(so ala VTX). Da muss man dann plattformübergreifend programmieren können, am PC
für das Client-Tool, den AVR für das Netzwerkprotokoll über TCP und das FPGA in
VHDL als VGA-Karte. Sieht am Anfang immer monströs komplex aus, klappt aber immer
recht gut.

Informatiker bauen bei Euch mit Steckbrettern rum? So richtig mit
Bauteilen? Alle Achtung. Dann besteht ja doch noch Hoffnung fuer die
naechste Generation.

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.