joefutrelle / tinycube Goto Github PK

Not sure how to do this, research.

Now that I'm logging to eeprom I can ditch the a4 debugging display, but I want to be able to re-enable it. May require some Makefile conditional finagling.

Currently there's no way to display a dash for negative numbers, or a decimal point for real numbers. Add those.

Right now the eeprom is just being tested. intstead, log time/temp.

packed time is 5 bytes, so if I add 3 bytes for variables I'm logging (initially just temp), that's 8 bytes for 8 log entries per 64-byte page.

since the first byte of such a record will never be zero (that was only possible in part of 2000), it's easy enough to zero a series of log pages, write entries, and then the code reading it can easily tell when there are no more entries to read.

To retrieve data from the EEPROM it needs to be accessible through USB. The easiest way is probably via an Arduino's serial monitor.

The new config of powering the peripherals from an output pin has been factored in, now take the rest of sleepy and factor it in so that the instrument only wakes up occasionally to read / display the time / temp.

CR2302 doesn't fit, need to just go and look at batteries until I find one that fits.

Right now I just have read/write byte.

Next step is to log data, need a storage-agnostic API for timestamped sensor readings and a proof-of-concept implementation that r/ws to internal EEPROM (all 512 bytes of it); to extend later to external EEPROM or FRAM.

The DS3231 normally reads the temperature every ~60s but has an I2C command to force read the temperature.

Add an API and call that before reading time/temperature, to get a current reading.

The device sometimes resets on sleep causing it to restart logging from the beginning of the eeprom (need to confirm).

This may be related to a low power condition as I'm seeing surprisingly low battery life on 3x AAA batteries. The battery hog is almost certainly the LED display.

Running out of power also seems to cause incorrect RTC readings and gibberish on the display.

Should be one API for internal and external that enables

• variable buffer size (is this even possible?) or at least device-dependent buffer size
• arbitrary address read/write of arbitrary size data with transparent page wrangling underneath including auto-flush
• flush function to force page write

uint8_t is descriptive, but annoyingly precise for buffer data

The device will spend most of its time asleep, so need to take some uncommitted code that does this and port it to this codebase.

see #10

The alpha4 font takes up lots of RAM (for an ATtinyX5), is constant, and is only used internally in the alpha4 module, so it's a good candidate for PROGMEM optimization.

http://www.avrfreaks.net/forum/tut-c-gcc-and-progmem-attribute