Phase Three
Phase Three is all about the user interface and data logging. I have a nice menu system working now, and a fairly intuitive button layout. Also the routines for saving and loading temperature samples from the eeprom is working real well. With a solid date-code routine, each temperature sample is taking 13 bytes. Three bytes for the y+m+d code, one byte for the hour and ten bytes for temperatures. I know my code can support 40+ temp probes, but that’s not realistic and beyond the scope of a simple indoor/outdoor thermometer. So ten probes is sort of set in stone, since the memory map for the eeprom is hard-coded in.
To avoid absolute refrences to any specific memory address for the samples, I have a few formula and different routines to find out where the last sample was stored, and append from there. Originally I was just storing the last used address at a single eeprom location, however, I realized that cell would get worn out pretty quick from being re-written so often. Now there is a static starting point and a routine that searches for the last used address, which is stored at the end of each page of eeprom memory. This eeprom has 512 pages of 128 bytes each, and when doing “page writes” in my compiler, one must take into account the pagnation of the memory, since a page-write cannot cross a page boundry (due to the buffer onboard the eeprom). Experts have suggested it’s easier to just write the data out one byte at a time (works but takes more code and time) and that ASM does not have that problem. I’m not sure how ASM would know any more about the specifics of my eeprom than my current compiler does. Anyhoo… I have some math formula that checks to see if the next sample to be saved would cross the page boundry, and if it does, to advance to the next page before comitting the write. Problem solved. Of course, there are a few bytes wasted at the end of each page, but that doesn’t bother me none, this eeprom has a TON of room on it. Right now there is close to 3k set aside for a weeks worth of hourly temperature samples.
Speaking of a TON of room, in order to save code space, I’m using the eeprom to store my menu prompts and other assorted texts. I have over 500 bytes of text stored on the eeprom so far, and I usually find a few more prompts to add each day.
The task at hand now is how to access the logged data, and how to manipulate it for statistical purposes. Since I’m using a character based VFD, graphs are really out of the question. But I would like to have historical recorded highs, lows and averages.
I have written some code that keeps track of what I’ve been calling run-time highs and lows. Each time the temperatures are measured, a pair of routines checks them against some in-ram byte arrays. Numbers higher or lower than previously recorded replace that value in the array. I hope to bang out an interface for that data yet tonight.
There’s not really anything to photograph yet, and I’m too lazy to hook up the video gear… but I am taking the occassional picture, and I’ll put up a gallery when I get further along.
Popularity: 1% [?]
