ENC28J60 verzählt sich (EPKTCNT)

OP #3169948
Lesenswert?

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:
1
forever:
2
 warten bis EPKTCNT != 0
3
 paket verarbeiten und ERXRDPT weiter setzen (Errata berücksichtigt)
4
 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?
Gast #3170653
Lesenswert?

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...
OP #3171282
Lesenswert?

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:
1
forever:
2
  warten:
3
    EPKTCNT auslesen, falls != 0 => verarbeiten
4
    ERXWRPT auslesen ; nur gültig wenn EPKTCNT vorher und nachher identisch
5
    EPKTCNT erneut auslesen, falls != 0 => verarbeiten
6
    falls ERXWRPT==NextPacketPointer => warten
7
  verarbeiten:
8
    paket verarbeiten und ERXRDPT weiter setzen (Errata berücksichtigt)
9
    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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren