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.
Du darfst nicht den Flankeninterrupt verwenden, sondern den Pegelinterrupt. Peter
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
Angehängte Dateien:
-
Zwischenablage01.png
270 KB
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.
1 | while( PIN == low ){ |
2 | // handler
|
3 | }
|
Also Pegelinterrupt in Software nachbilden. Peter
@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
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.