![]() Unless you seriously know what you're doing, on microcontrollers like Arduinos, the ESP8266 and the ESP32, the best thing an interrupt handler can do is just set a flag to indicate that the interrupt occurred, and let code in the loop() check for the flag. You can't make assumptions about exactly how modules that you call are implemented, or how they'll be implemented in the future. And maybe SPIFFS doesn't allocate memory - but do you know that SPIFFS in the future will never allocate memory? Do you know exactly how SPIFFS works? Do you know whether SPIFFS uses any other functions that you might need to disable interrupts for in other parts of your code so that the interrupt handler won't disrupt them? Do you know for certain that SPIFFS doesn't allocate memory temporarily? Imagine that it does - now you also need to find every place in your code that might allocate memory and lock out interrupts around it, too. So you think you'll be clever and disable interrupts before you call SPIFFS outside the interrupt handler. Take this as an example: suppose you want to use SPIFFS in both an interrupt handler and outside the interrupt handler. And you should not be disabling interrupts around calls to SPIFFS in hopes of making it safe for your interrupt handler to also call SPIFFS. 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.")) I've got a few functions like this that log, or do more critical things like get/save configuration variables.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |