Hallöle.
Ich habe das Problem, das mein ENC28J60 im zusammenspiel mit einem
ATMEGA32 scheinbar nur 1x einen Interrupt feuert, und dann ruhe gibt.
Die Schaltung ist absolut simpel. Nur das nötigste ist drauf.
Kann den ENC Inizialisieren, daten endlos versenden, usw.
Auch Empfangen kann ich laut LED's daten. Auch empfängt der ENC offenbar
Packete. Allerdings bekomme ich nur einen einzigsten Interrupt gefeuert,
beim ersten Packet. Alle weiteren Packete werden nicht mehr mit einem
Interrupt signalisiert. Auch ein Pooling zeigt, das er offenbar nur ein
einzigstes Packet empfangen hat, obwohl regelmässig Packete zum ENC
laufen.
Die LED's zeigen ebenfalls Kommunikation an.
Muss man den Interrupt neu setzen, oder irgend etwas anderes
"zurücksetzen", nach dem Empfang eines Packetes, oder dem Auslesen
dieses Packetes aus dem Puffer des ENC's ?
MfG
TPM
Ganz vergessen zu erwähnen. Wenn ich den ENC reinizialisere, dann geht
das spiel von vorne los. Nach dem inizialiseren kann ich wieder nur ein
einzigstes Packet empfangen, udn dieses wird ebenfalls wieder nur mit
einem Interrupt signalisiert. Alle anderen Packete scheint er nicht mehr
zu "schnallen".
Es kann ja nicht sein, das ich nach jedem Empfang eines Packetes den ENC
neu inizialisieren muss. ... :/
MfG
TPM
Ist zwar lange her, dass ich was mit dem ENC28J60 gemacht habe, aber
wenn ich mich recht erinnere musst du den Interrupt bestätigen und das
Interrupt Flag im ENC28J60 zurücksetzen, wenn du alle Daten abgearbeitet
hast.
Simon K. schrieb:> Ist zwar lange her, dass ich was mit dem ENC28J60 gemacht habe, aber> wenn ich mich recht erinnere musst du den Interrupt bestätigen und das> Interrupt Flag im ENC28J60 zurücksetzen, wenn du alle Daten abgearbeitet> hast.
Wie meinst du das mit "Bestätigen" ?
@Peter
Was genau meinst du mit Flankeninterrupt bzw. Pegelinterrupt?
Ich Detektiere die Interrupts mit Fallenden Flanken, Falls du das
meinst.
MfG
TPM
Martin W. schrieb:> Simon K. schrieb:>> Ist zwar lange her, dass ich was mit dem ENC28J60 gemacht habe, aber>> wenn ich mich recht erinnere musst du den Interrupt bestätigen und das>> Interrupt Flag im ENC28J60 zurücksetzen, wenn du alle Daten abgearbeitet>> hast.>> Wie meinst du das mit "Bestätigen" ?
Hab ich doch geschrieben?! Das Flag zurücksetzen.
Ja ist schwer im Datenblatt zu finden. Ich habe geschätzte 5,3 Sekunden
gebraucht inkl. Download des Datenblatts.
achso .. ich war verwirrt, weil du in deinem Satz ein "und" verwendet
hattest. Daher ging ich davon aus, zum "bestätigen" noch ein
"zurücksetzen" angedeutet hattest. Also .. 1x Bestätigen und 1x
zurücksetzen, bitte.
OK. Werde ich mal ausprobieren.
Viele Dank!
MfG
TPM
Martin W. schrieb:> @Peter> Was genau meinst du mit Flankeninterrupt bzw. Pegelinterrupt?
Der Interruptpin ist ja die ODER-Verknüpfung mehrere Quellen.
Nun kann es passieren, daß wärend der Abarbeitung eines Ereignisses ein
weiteres auftritt. Dann bleibt der Pin low und Du kriegst keine neue
Flanke.
Flankeninterrupt ist also falsch.
Wenn aus irgendeinem Grund kein Pegelinterrupt mehr verfügbar ist, dann
kann man sich dadurch behelfen, daß im Interrupthandler der Pin händisch
geprüft wird, ob er immer noch low ist.
@Peter: Nein, das sollte hier nicht der Fall sein. Man muss nach dem
Interrupt den Chip ansprechen und schauen welcher Interrupt aufgetreten
ist. Dann die Flags zurücksetzen (mit einem atomaren SPI Befehl) und
dann alle Daten verarbeiten bis nichts mehr da ist.
So oder so ähnlich sollte das funktionieren. Das steht auch in dem Bild
das ich hochgeladen habe.
Simon K. schrieb:> @Peter: Nein, das sollte hier nicht der Fall sein.
"Sollte" heißt aber nicht, es ist ausgeschlossen.
Ich würde daher den sicheren Weg nehmen, man hat ja keine Nachteile
dadurch.
Was ist z.B., wenn Du einen CPU-Reset machst und der Chip hält den Pin
noch auf low, dann siehst Du nie ne Flanke.
Peter
Beim CPU Reset resettest du aber auch den ENC28J60. Dann sollte das
wieder hinhauen.
Aber du hast Recht, das ist wohl mehr oder weniger Geschmackssache.
Simon K. schrieb:> das ist wohl mehr oder weniger Geschmackssache.
Finde ich nicht.
Wenn man etwas sicherer programmieren kann, dann sollte man dies
unbedingt tun.
Und wenn ich mir die Bugliste des ENC28J60 so anschaue, dann glaube ich
nicht, daß es keine race-conditions geben könnte.
Das Problem hatte ich nämlich auch mit dem Ethernet-Controller LAN91C96.
Der lief je nach Traffic stundenlang, eher er abstürzte. Der Grund war
genau der, daß neue Interrupts verloren gingen. Das Problem konnte dann
mit dem obigen Work-Around gelöst werden (der AVR hat leider keinen
High-Pegel Interrupt).
Peter
anscheinend lag es nicht am Interrupt selbst.
Offenbar gab es probleme beim einlesen des Speichers in den AVR, das
dann dazu geführt hat, das der ENC abgekracht is.
Mittlerweile funktioniert das ganze.
THX nochma für die Hilfestellung.
MfG
TPM
Gibt es eigentlich bekannte Probleme mit dem ENC und deren
Packetgrössen, im speziellem beim Empfang?
Ich habe das Kuriose Problem, das mein ENC mal funktioniert, und sich
mal aufhängt. Zumindest teilweise .. irgend wie ... schwer zu
beschreiben.
Je nachdem, was ich zu dem Teil sende, kommt es zum einem dazu, das die
Packete bzw. deren Packetgrösen im Speicher nicht richtig sind.
So erhalte ich z.B. nach dem Start der Schaltung (PCB) und dem empfang
eines ARP-Requests mit Broadcast MAC grundsätzlich eine Packetgrösse von
64Byte.
Dabei werden allerdings laut etherreal nur 42 verschickt.
Beim auslesen der 64Byte kann ich nach den 42 koreckten Byte's einen 0
Auffüllung sehen, und zum schluß erhalte ich 4Byte mit Kuriosen werden.
Sende ich jedoch nach dem Start der Schaltung zuerst ein UDP Packet mit
einer Nachrichtenlänge von 5Byte (Hallo) dann erhalte ich ebenfalls 64
Byte's.
Merkwürdig ist auserdem, das bei UDP Nachrichten mit einer Datenlänge
von 15Byte das Packet offensichtlich vom ENC empfangen wird (LED
Blinken), allerdings diese im Puffer nicht hinterlegt wird.
Wenn ich die üblichen Broadcastnachrichtem von einem NETBIOS System auf
das Netzwerk gebe, dessen nachrichtenlängen weit über 200Byte's sind,
scheinen diese alle vollständig an zu kommen. Auch die grössen stimmen.
Ich habe bereits einen anderen ENC ausprobiert, welcher genau die selben
fehler erzeugt.
Auserdem habe ich auch einen komplett andere Schaltung (PCB) verwendet.
Ebenfalls mit anderen Taktraten für den ATMega32 (11,0592 / 16).
Zu guterletzt habe ich sogar "fremden" Sourcecode (bascom) organisiert,
(Internet) und diesen Kompiliert. (Dieser sollte angeblich
funktionieren)
Allerdings geht das mal garnicht richtig. Und wen man die ganzen Bug's
durch schlechte preprozessorstatements korrigiert, läuft zwar der Code,
allerdings sind die eigentlichen Fehler immernoch vorhanden.
Merkwürdig ist auserdem, das der ENC scheinbar abkracht, nachdem ich ein
ARP Request gesand habe, dieses mit einem Antwort bestätige, und
anschliessend ein UDP Packet empfange. Danach kommen keine Nachrichten
mehr durch.
Auserdem scheint das mit dem Filter auch nicht ganz hin zu hauen. Je
nachdem wie ich filtere, kommen packete durch, die eigentlich nicht
durch kommen sollen, und manchmal garnicht.
Zwar habe ich zu diesem Problem schon einiges gefunden (scheinbar ein
BUG im enc), aber ich hoffe, das nicht dies mein problem beinflusst.
Auch kam es schon einmal vor, das der ENC die Packete nicht richtig
empfängt. (aber absolut äuserst selten). Nach einem software-Reset.
Funktioniert das ganze wieder. (Fehler beim Init des ENC!?!)
Kennt jemand dieses Problem oder weis jemand was da los sein könnte?
MfG
TPM
