I'm currently building an aquarium computer and I have the following question:
Some actions should be processed at a certain time, so I've two options to deal with it.
Find a good Alarm Schedule Library and try to implement it.
As I'm using RTClib only (no time.h) I can't use timeAlarm.h. Has anyone a good schedule library which i can use out of the box with rtclib without time.h? Or should I implement time.h as well, which would be some unnecessary overhead.
Pro: Maybe easier?
Tested many times?
Con: If I want to turn on my lights at 8 o'clock but there's an power failure at this time - this alarm would never be triggered - my lights would be off until next day 8 o'clock. (Happened today! )
Programm a sheduler by my own and calling it every 10 seconds or something like this.
Pro: Calling the schedule funtion every 5 to 10 seconds would also work if the arduino is not powered at the time the alarm should trigger. (something like now>poweron && now <poweroff )
Con: Maybe a big lag every time the function is called, because I've to wait until all calculations are over and I get out of the funtion - back in my loop?
More Resource needed?
What would you say? I think I'd love to code it myself - cause I've more possibilities, but I'm afraid this could make my arduino laggy when the projects grows.
Look at the 'blink without delay' example. Study it, absorb the principle and use it.
Use it to regularly (say every minute) check the time. If the time is after 7:59 PM, turn on the lights.
Even if there's been a power cut, the lights will come on as soon as there's power available. DO NOT USE DELAY()
but do you think it wont be a problem that the arduino will get slow while he does this calculations?
I have a similar problem with my touch. For sure it takes about 3 seconds to build the whole screen - while the arduino is in this funciton it doesn't react to any inputs (touch). But I also think to build 480 * 800 pixels - many colors and get the time, temperature, ph value need much more power then just to some DateTime calculations.
at the moment I'm using a simple if (currentmillis>millis5secondsago+5000) {do my stuff} in my loop function
NatroN:
but do you think it wont be a problem that the arduino will get slow while he does this calculations?
Why would it do that?
at the moment I'm using a simple if (currentmillis>millis5secondsago+5000) {do my stuff} in my loop function
no delay()
How long do you think it will take to check that if statement? If the 'if' is untrue, it won't {do your stuff}.
To avoid problems when millis() rolls over, your if statement should be like this:
if (currentmillis - millis5secondsago > 5000) {
do my stuff;
}
I would switch libraries.
I'd use these libraries:
Time - for the time tracking
A real time clock library pick one of:
DS1307RTC
DS3231 (I'd use a DS3231 for better accuracy and an internal temp sensor)
TimeAlarms - for the Alarms
Timezone - so you can run the proper timezone and get automatic daylight savings time changes
For a full blown Aquarium controller, I'd use existing libraries and focus on the higher level
functions since there are so many other things to worry about than the lower level code.
Maybe even add a GLCD for displaying information.
The time taken to calculate whether a scheduled event is due should be negligible; use a library or roll your own since that's your preference. The non-responsiveness in your system is apparently caused by the length of time it takes to "do my stuff", particularly, by the sound of it refreshing the screen.
You might consider splitting "do my stuff" up into subtasks and only do one of them on each iteration of loop. i.e. the millis checks tell you what tasks it's time to do and on each subsequent iteration of loop, pick just one of them and do it so you can respond more quickly to button presses.
It also sounds like you should consider optimizing your screen refresh routine - can you just redraw what's changed?
It makes absolutly no sendso to draw all the up/down button on every button press. The refresh ot the changed value just takes some miliseconds.
So I switched from using "drawScreen()" to a subroutine - something like "refreshScreen()" where all the bitmaps stay the same and just the values are printed on the screens. Made the refresing of the screens superfast again.