Hi!
I am working on a fan controller for my PC. It will be controlling four 3-pin fans using a MOSFET for each, aswell as reading the hall sensor to calculate rpm.
In order to remember what RPM it was set to the last time it was powered on I want to save the data in the EEPROM. While I was reading about this I found that it takes ~3.3ms to write to the EEPROM. Could this be an issue when I use interupts to calculate the RPM? Since I have four fans sending interups twice per revolution there's a good chance an interrupt could come while I write. I wont be writing very often though, only when I have to change the speeds.
Could this be an issue? Do I need to disable the interrupt while writing?
ISRs should be as quick as possible. Set a flag in the ISR. In your loop() function, check for that flag, write the value into the EEPROM and clear the flag.
In order to remember what RPM it was set to the last time it was powered on I want to save the data in the EEPROM.
Perhaps you should explain why this is necessary. What controls the speed of the fan? Why would that not control it again when the Arduino starts up again?
Kalveo:
Hi!
I am working on a fan controller for my PC. It will be controlling four 3-pin fans using a MOSFET for each, aswell as reading the hall sensor to calculate rpm.
In order to remember what RPM it was set to the last time it was powered on I want to save the data in the EEPROM. While I was reading about this I found that it takes ~3.3ms to write to the EEPROM. Could this be an issue when I use interupts to calculate the RPM? Since I have four fans sending interups twice per revolution there's a good chance an interrupt could come while I write. I wont be writing very often though, only when I have to change the speeds.
Could this be an issue? Do I need to disable the interrupt while writing?
No you don't need to worry about this, the EEPROM library does the right thing. EEPROM
writing occurs in the background anyway and subsequent writes will busy-wait for
the EEPROM hardware to be ready before writing the next byte, none of this stops
interrupts from being serviced for 3.4ms (millis would be broken if this were
the case).
In particular if you only write one byte you don't see the 3.4ms delay at all
(but if the power fails during that time the EEPROM write is likely to be
garbled.)