They definitely should not call SPIFFS, should not call the real time clock, should not allocate or instantiate objects and should not do i/o operations. Interrupt handlers should do as little as possible. If an interrupt handler needs to use a shared data structure, disable interrupts before beginning to modify it outside of the interrupt handler, and re-enable them when you're done. The only time you should disable interrupts is when a data structure that an interrupt handler needs to use is in an inconsistent state. Locking them out will cause these functions to be unreliable and may disrupt network connections. Interrupts are used for critical timing functions and for network and other communications. You should lock out interrupts as little as possible. If it doesn't, the software will crash hard. It doesn't matter if it's at the exact moment that a function is saving something - a properly written interrupt handler will save any necessary state so that whatever was interrupted can continue without problems. Interrupts happen all the time and code works just fine without locking them out. Assume that an interrupt is triggered at the exact moment when the above function is saving something, what exactly happens if I didn't have noInterrupts. I surround code with noInterrupts and interrupts however I am not sure if it is required. **Ĭommit: datetime,minHumidity,maxHumidity,minTemperature,maxTemperature,rainfall,irrigationRanĭBG_OUTPUT.println(F(" Attempting to save weather data.")) īool writeHeader = SPIFFS.exists("/weather_data.csv") ? false : true įile file = SPIFFS.open("/weather_data.csv", "a") ĪddPrintError(" There was an error opening weather_data.csv for writing.") ĭata += "datetime,minHumidity,maxHumidity,minTemperature,maxTemperature,rainfall,irrigationRan\r\n" ĭata += t + "," + minHumidity + "," + maxHumidity + "," + minTemperature + "," + maxTemperature + "," + rainfall + "," + irrigationRan + "\r\n" ĭBG_OUTPUT.println(F(" File was written.")) ĪddPrintError(" File write failed.") ĭBG_OUTPUT.println(F(" Task completed.")) You can’t jump to some code to handle the reset.I've got a few functions like this that log, or do more critical things like get/save configuration variables. The downside is when the timer pops, the system just resets. Unlike Teensy and Arduino, WDT is very easy to use. But if you are doing something compute bound that will take more than a second or so, you should manually reset the timer with ESP.wdtFeed() While you must pass a timeout value to wdtEnable, it is currently ignored.Īs mentioned before, most of the libraries will automatically reset the WDT for you so you should not have to do so. The SW WDT is enabled with: ESP.wdtEnable(msecs) If you wish to disable it, the SW WDT is disabled with ESP.wdtDisable() There seems to be little point in disabling the SW WDT as you must reset it to also reset the HW WDT.Īs previously mentioned, the SW WDT is running by default. You can enable/disable the SW WDT, but not the HW WDT. The SW WDT seems to reset the MCU at 1.5 about seconds. The HW WDT is always running and will reset the MCU after about 6 seconds if the HW WDT timer is not reset. There is a hardware WDT and a software WDT. My primary resource for researching ESP8266 WDT was: Most of the library routines reset it so you may never even know it is running unless your program hangs in a loop. Turns out the WDT is enabled automatically for the ESP8266. While messing with an ESP8266 for the past couple of days, I decided I should look into how the watch dog timer operates.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |