Interrupt während Netzwerk I/O == Crash?

Question

Es scheint, dass wenn ein E/A-Pin-Interrupt auftritt, während Netzwerk-E/A durchgeführt wird, das System zurückgesetzt wird - auch wenn die Interrupt-Funktion nur eine lokale Variable deklariert und zuweist (im Wesentlichen eine Do-nothing-Routine) Ich bin ziemlich sicher, dass es nicht damit zu tun hat, zu viel Zeit in der Interrupt-Funktion zu verbringen. (Meine tatsächlichen Arbeitsunterbrechungsfunktionen sind ziemlich spartanisch, streng inkrementieren und zuweisen, nicht einmal irgendeine bedingte Logik.)

Ist das eine bekannte Einschränkung? Meine Problemumgehung besteht darin, den Interrupt während der Verwendung des Netzwerks zu trennen, aber dies führt natürlich zu einem möglichen Datenverlust.

function fnCbUp(level) 
    lastTrig = rtctime.get() 
    gpio.trig(pin, "down", fnCbDown) 
end 

function fnCbDown(level) 
    local spin = rtcmem.read32(20) 
    spin = spin + 1 
    rtcmem.write32(20, spin) 
    lastTrig = rtctime.get() 
    gpio.trig(pin, "up", fnCbUp) 
end 

gpio.trig(pin, "down", fnCbDown) 
gpio.mode(pin, gpio.INT, gpio.FLOAT) 

Zweig: master

bauen auf gebaut: 2016-03-15 10:39

angetrieben durch Lua 5.1.4 auf SDK 1.4.0

Module: adc , Bit, Datei, GPIO, i2C, Netz, Knoten, pwm, rtcfifo, rtcmem, rtctime, sntp, tmr, uart, Wi-Fi

Answer 1

Nicht sicher, ob dies sollte eine Antwort oder ein Kommentar sein. Kann jedoch ein bisschen lang für einen Kommentar sein.

Also ist die Frage "Ist das eine bekannte Einschränkung?" und die kurze, aber nicht zufriedenstellende Antwort lautet "Nein". Kann es nicht so lassen ...

Ist der Code-Auszug genug für Sie zu schließen, muss der Reset wegen etwas innerhalb dieser paar Zeilen auftreten? Ich bezweifle das. Was Sie zu tun scheinen, ist eine einfache "globale" Erhöhung jedes GPIO 'down' mit einer gewissen Entprelllogik. Ich sehe jedoch keine Entprellung, was fehlt mir? Sie bekommen die Zeit in die globale lastTrig, aber Sie tun nichts damit. Nur für die Entprellung brauchen Sie nicht rtctime IMO, aber ich bezweifle, dass es etwas mit dem Problem zu tun hat.

Ich habe eine gist of a tmr.delay-based debounce sowie one with tmr.now, die eher wie ein Gashebel ist. Sie könnten der Erste verwenden wie so:

GPIO14 = 5 
spin 

function down() 
    spin = spin + 1 
    tmr.delay(50)     -- time delay for switch debounce 
    gpio.trig(GPIO14, "up", up)  -- change trigger on falling edge 
end 

function up() 
    tmr.delay(50) 
    gpio.trig(GPIO14, "down", down) -- trigger on rising edge 
end 

gpio.mode(GPIO14, gpio.INT)   -- gpio.FLOAT by default 
gpio.trig(GPIO14, "down", down) 

ich auch dies gegen den dev Zweig schlage vor, weil Sie sagte, es I/O während Interrupts zu vernetzen in Beziehung gesetzt werden.

Answer 2

Ich habe fast das gleiche Problem. Wird ESP8266Webserver mit GPIO14 Interrupt ausgeführt, mit zu schnellen Impulsen als Eingang, stoppt das System die Interrupts. Bitte sehen Sie hier für weitere Details.

http://www.esp8266.com/viewtopic.php?f=28&t=9702

Ich verwende ARDUINO IDE 1,69 aber das Problem scheint das gleiche zu sein. Ich benutzte einen ESP8266-07 als Generator & Zähler (ohne Webserver) , um die Impulse zu generieren, verdrahtet zu meinem ESP8266-Watersystem.

Der Generator funktioniert sehr gut, mit viel mehr als 240 puls/sec, generieren und zählen auf dem gleichen ESP.

Aber die ESP-Watersystem, stoppt Interrupts hier bei impuls > 50/ second:

/*************************************************/ 

/* ISR Water pulse counter      */ 

/*************************************************/ 

/** 

* Invoked by interrupt14 once per rotation of the hall-effect sensor. Interrupt 

* handlers should be kept as small as possible so they return quickly. 

*/ 


void ICACHE_RAM_ATTR pulseCounter() 

    { 

     // Increment the pulse Counter 

     cli(); 

     G_pulseCount++; 

    Serial.println ("!"); 

    sei(); 

    } 

Der serielle Ausgang ist hier nur für die Ansicht, was geschieht Aufnahme. Es zeigt den korrekten gezählten Impuls, bis der Webserver mit dem Netzwerk interagiert. Dann ist der Interrupt blockiert (keine serielle Ausgabe von hier) Durch die Belastung des Systems, wenn ich die Website in kurzer Zeit mehrmals aktualisiere, beginnt die Interrupt-Zählung für kurze Zeit, aber es hört kurz wieder auf .

Das Problem ist überall entlang Interrupt-Behandlung und Webservices. Ich hoffe, ich konnte helfen, dieses Problem zu finden.

Interessiert, einige Lösungen zu erhalten. Wer kann helfen?

Dank von Mickbaer Berlin Deutschland Email: michael.lorenz@web.de