OldSalt1945:
For instance, I was unaware of the F() macro and it's implications. I was thinking "I've got 32K of memory, why worry about conserving it". Oops, 1K. At the same time, by putting stuff in Flash memory, if there is a power failure, when it comes back up, it should all still be there.
Question: Is there any restriction on saving all the various situational states (timeHeaterCOn, prevLowerFwTub, stateSolenoidRoDi, etc.) in Flash memory? If so, a power flicker would not result in a complete reset. The process could just pick up where it left off.
1K? UNO with ATMega328P chip has 2K RAM and Duemilanove with ATMega168P chip, IIRC, has 16K flash.
The flash memory only gets compiled code in Arduino, it's a kind of ROM at run-time.
However the UNO has 1K EEPROM you can read/write for power-off storage.
But... if you really want cheap mass storage and you can solder then you can make an SD module out of a micro-SD to full SD adapter (those sleeves that come with micro-SD cards), some resistors (there's a diode alternative) and wire and maybe even some kind of board for less than $5 in parts not counting the micro-SD card itself.
Just remember that SD has limited writes. Don't treat it the same as a hard drive. If you have a data file that you want to sort, write a sorted index file instead and access the data through the indexes. The card might last "forever" that way.
I just received a DS1307 via the "slow boat from China". I haven't yet gone through the learning process for using it. Not necessary for this process, but fun. Actually, the whole thing is not necessary. I could just check the aquarium every day to make sure everything is working. But I'm 'way too lazy for that.
If you include a set of indicator leds, or even one, then a quick glance at those can tell you how it's going.
RGB leds are pretty cheap now. I paid $1 for 5. The same light can be 8 easy to see as different colors (if off is a color) and blink rate can also provide whole new levels to those. That takes 3 pins though, for 1 pin you can blink and idiot light too.
Heater list should use C,D,E (initialized as "xCDEx").
Rats! I have looked at that 100 times and noticed nothing wrong! That's why I can't get those routines to work! I originally had Sensors A,B,C,D,E and Heaters A,B,C with Heaters A,B,C connected to Sensors C,D,E. This got so confusing that I took the time to change it so that C,D,E were connected to C,D,E. I missed the rotater. Thanks eversomuch. I would probably be gazing past it next winter.[/quote]
All of those beg using arrays so that the same code that uses one sensor/heater can work for all just by feeding it different indexes.
You can also give indexes names to reduce confusion and need fewer comments through enumerators.
Enums are like defines only better, the compiler can check their use.
define a struct to hold the set of data being displayed
Excellent suggestion. Now I have to investigate what a Struct is and how it works. Thanks for causing trouble.[/quote]
The compiler had some minor problem with structs in the past if they were not in their own .h file.
A struct is a named container for variables. You can group elements that go together as a meta-variable and even make arrays of those to index through. Then there's Classes which are bundled data and functions to handle the data. When you use Serial or most libraries you are using Classes through Class Objects. They make it harder for you to step on your own or included code/data (especially the included stuff you don't know so much about).
Be real happy about structs and classes, they already make your Arduino life easier.
You can compare blocks of memory using memcmp() from string.h.
The memXXX() functions are nice and clean.You guys are determined to make me hurt my head by having to learn a whole bunch of new stuff, aren't you? Thanks. Looks like a much cleaner way to do it. Used with the F() macro, it will solve a bunch of my mess.
All the mem functions are address & bytes based. It's really very primitive and general which is also the power.
If I want to compared structs then I can write a whole bunch of lines of ifs or just 1 line with memcmp().
memmove() will let you shift a block of data (say bytes in an array) without fear of overwriting in the process.
memset() lets you set a block of memory to all the same value.
Millis and micros values should be held as unsigned long values.
Fixed. But it messed up the nice, neat columns of comments by making the code line longer. :~
"const uint8_t"
What's "uint8_t"?
unsigned 8 bit integer and the _t means type as in variable type.
The short name is byte.
Bytes instead of int
I never thought about it. Good idea. Thanks. Fixed.
change all your calls to now() with millis()
The time.h stuff looked more interesting than millis(). I saw a discussion about millis() rolling over to start over after some length of time and I didn't want to deal with it. I'm going to use a DS1307 clock sometime soon. Not needed. Just because it looks interesting.
millis() does roll over after 49.7-some days which is the longest interval you can get using unsigned long.
The rollover is NOT A PROBLEM as long as you use unsigned integers and the unsigned subtraction.
For a simple example of why, consider a clock face has 12 hours and we don't have problems with that.
It's possible to use 64 bit unsigned long long to time with. One VERY GOOD coder here, Morris Dovey, left a time library that uses those, the longest interval even using micros() instead of millis() is effectively forever.