ENC28J60 verzählt sich (EPKTCNT)

[Cube S. (cube_s)]

Ein Atmega328 und ENC28J60 arbeiten ansich gut zusammen. Ich kann jede 
Menge Ethernet-Frames über Stunden empfangen bis ich irgendwann merke, 
dass die gesendeten Pakete mit einer deutlichen Verzögerung verarbeitet 
werden.

Ich gehe wie folgt vor:

forever:
 warten bis EPKTCNT != 0
 paket verarbeiten und ERXRDPT weiter setzen (Errata berücksichtigt)
 PKTDEC bit schreiben um EPKTCNT herunterzuzählen

Dabei beobachte ich folgendes:
ERXRDPT und ERXWRPT klaffen im Laufe der Zeit immer weiter auseinander.
EPKTCNT ist am Anfang der Schleife manchmal plötzlich um 2 kleiner als 
beim letzten Durchlauf. Das kann zwar nicht sein, erklärt aber das 
zunehmende Hinterherhinken der Pakteverarbeitung.

Das Verhalten lässt sich relativ gut dadurch reproduzieren, dass man den 
ENC28J60 mit ein paar Ethernet Frames "bombardiert". EPKTCNT springt 
dadurch um deutlich mehr als nur 1 pro Schleifendurchlauf.

Was geht hier vor?

[c-hater (Gast)]

Cube S. schrieb:

> Was geht hier vor?

Wenn du das bei vorliegendem Quelltext schon nicht siehst, wie sollen 
wir das dann ohne diesen sehen können?

Der ENC28J60 hat einen Haufen Bugs, aber der von dir beschriebene kann 
nur deinem eigenen Code entsprungen sein.

Vergleiche, verdammt nochmal, deinen eigenen Müll einfach mit 
vergleichsweise gut ausgetestetem Code wie etwa dem des 
Ethersex-Projektes.

Der Kram ist zwar auch nicht 100% fehlerfrei, aber offensichtlich immer 
noch weitaus besser, als das, was du da produzierst...

[Cube_S (Gast)]

@c-hater:
woher der Frust?

[Cube_S (Gast)]

In diesem Artikel:

http://www.microchip.com/forums/m240135-print.aspx

wird meiner Meinung nach das gleiche Problem geschildert. Zitat:

"Upon the second iteration of the loop, reading EPKTCNT would result in 
0, when I knew more packets were left."

[Knut B. (Firma: TravelRec.) (travelrec)]

Wenn Du die Wahl hast, probier mal den KSZ8851SNLI.

http://code.google.com/p/avr-uip/source/browse/trunk/drivers/ksz8851/ksz8851.c?r=11

[Cube S. (cube_s)]

Knut Ballhause schrieb:
> Wenn Du die Wahl hast, probier mal den KSZ8851SNLI.

Vielleicht tue ich das einmal. Bis auf diese Geschichte bin ich aber 
ziemlich zufrieden so wie es läuft und möchte nicht jetzt schon die 
Flinte ins Korn werfen.

Folgende Variante läuft bislang fehlerfrei:

forever:
  warten:
    EPKTCNT auslesen, falls != 0 => verarbeiten
    ERXWRPT auslesen ; nur gültig wenn EPKTCNT vorher und nachher identisch
    EPKTCNT erneut auslesen, falls != 0 => verarbeiten
    falls ERXWRPT==NextPacketPointer => warten
  verarbeiten:
    paket verarbeiten und ERXRDPT weiter setzen (Errata berücksichtigt)
    PKTDEC bit schreiben um EPKTCNT herunterzuzählen

NextPacketPointer muss also letztendlich immer bei ERXWRPT landen, 
insbesondere wenn EPKTCNT==0.

Gemäß einem freundlichen Hinweis habe ich mir auch die Ethersex-Routinen 
ein bisschen angesehen. Ich denke hier wird das Problem durch 
gelegentliche Resets des ENC28J60 nach dem Auftreten vom Empfangsfehlern 
(RXERIF gesetzt) mit behoben.

[Cube S. (cube_s)]

Auch hier nocheinmal die gleiche Beobachtung:

http://members.home.nl/bzijlstra/software/examples/enc28j60.htm

Bei Step 22:
"I noticed that on some occasions when the packet count got to 2 or more 
waiting it would loose one packet, so the register would be one message 
behind the actual packet count."

Leider konnte ich den dort angekündigten Workaround nicht finden.