With the latest work commit, things look pretty dang good. The delays are working like they should.
The only thing I noticed was that the delays are a little short and get worse as the delay increases.
I'm using an ice pack and warm water to manipulate the timer. I started a stopwatch when the solid cooling led went off, then raised the temperature back above the set point. Stopped the clock when the cooling led came back on solid instead of blinking.
A 60 second delay was pretty close.
A 5 minute delay was more like 4m50s.
A 10 minute delay was about 9m40s.
A 15 minute delay was a little less than 14m30s
I've run those tests a couple of times each and they're as consistent as my reaction time can be with a stopwatch.
This isn't a big deal for the heat/cool delays. If the programs are using the same timing system it might add up on long steps and cause a problem. Though, when we're talking about step times for a fermenting process, even an hour or so either way is probably not going to make any difference.
Well, wow. Unless you've been reading the code... I didn't think anyone would notice.
The delays are short, but the reason is a good one.
In fact one of the things I have been very careful in doing, is selecting counter sizes so they wont overflow.
The frequency of the main timer is also very carefully selected.
I need one hour to fit in a 16 bit counter, that means frequency needs to be below around 18Hz. I also want 1 sec marks to be easy to detect (i.e. freq. should be power of 2). And I also need frequency to be high enough to sample buttons.
This pretty much leaves 16Hz as only option (62,5ms). It is a bit slow for buttons, but will work.
Now unfortunately, 16Hz is not possible to achieve with the timers. Closest possible value is 16,66Hz (60ms). That means that the one second marks (16*60ms) really only is 960ms. So yeah, it is close, but not really accurate.
The one hour mark occurs on the counter being 60000 which should be an hour exactly (of course no timer is totally accurate, but I have no control over that).
Just wow. This latest work branch version, alpha, is amazing.
So many improvements, and I'm really liking the up & down button quick-views (they work well). It's really handy to see how many hours have elapsed.
I'm going to keep testing, but this is a night-&-day difference versus last night's experience with the previous build. You should def push this to the main public branch for "official" releases, though that's purely a symbolic move anyways.
Thanks! There really is not that big a change from yesterday, except that I found the compiler problem (which is really not my fault).
I'll push the changes.
I'm looking at some of the programming.... Wow... I salute you...
I'm still trying to figure how you figure the temperature out with this... I need more scratch paper...
Code:
for (i = 0; i < 32; i++) {
if((temperature & 0x1f) <= i){
temp += ad_lookup[((temperature >> 5) & 0x1f)];
} else {
temp += ad_lookup[((temperature >> 5) & 0x1f) + 1];
}
}
I get the for loop..
If the lower five bit of the variable temperature <= i - I get this...
temp = temp + look up the value in the variable ad_lookup at the location held within bits 5-10??
Do this 32 times?
You sir must be a genius... I'm still scratching my head.
(I've never been a professional C programmer - but I can kinda read it..)
The loop is for interpolation between the lookup points.
As you said, upper five bits are used to lookup the value in in lookup table. Lower 5 bits are used to interpolate.
((32-x)*lookup[y] + x*lookup[y+1]) / 32 (where x is lower 5 bits and y upper)
Only the MCU doesn't have hardware multiplier, so the multiplication is rolled out to additions.
but it is free (as in freedom).
WHaaaaaaat? Uhhh.......yeah. Sounds right, totally. 
