Saturday, August 5, 2017

Detour, redux.

One library (XEEPROM) turned into two - the second being vmem, a way to wrap read and write of flash, eeprom, xeeprom, or other media. I didn't do it as a stream class (but probably should, later). I also split up addressing so that subsequent reads increment the ADDR position, much like I2C memory access does.

A minor tweak along the way was to change the default page size from 1k to 512bytes; this means that the second pointer has access to individual opcodes without a third offset byte. It does cut the max memory size by half, but the max was already larger than needed for this project, and it means instantiating a few (maybe 8 or more) of these objects saves one byte per object.

Even with two bytes for memory addressing (instead of three) it makes sense to have a 'zero page' style access. I can fake that with a jump table, so instead of JMP (16bit), it would be a JMT (byte), which is an indirect lookup in the table for a real 16 bit address. There is space in the MAP lookup table, so it's an item in the toolkit for later.

Next up is scheduling. Rather than combine schedule info with code info, it's probably easier/safer/cleaner to split the schedule for sequence elements; which becomes 8 bytes. We don't have to load all of this into memory at once, either:

  • Year/Month
  • Date
  • Hour
  • Minute
  • Interval (Lo)
  • Interval (Hi) + Interval (units)
  • Page (of code)
  • Entry (of code)
Interval is a new idea. It won't matter much for a solar array, but it will be handy later. For the sake of exercising the code & idea, I'll use it to for the hourly-ish moves of the panel instead of hard-coding the schedule lookups.

But this brings up something important that wasn't possible with a linear schedule - concurrence. This would normally be the point where the KISS principle should kick in, but it seems worth pursuing. So for now I'll leave it to human operators (and possibly data flags) to catch conflicts.

For now, I have - wait for it - ANOTHER library, SCHED, now half-built, which sits on top of vmem and can read a structure to calculate it's interval and fetch next opcodes and parameters.

// TODO:
  • write up the keywords.txt and example for the XEEPROM library, and test it all out
  • Write up something that manages the 4 byte structs for describing execution state. Library?Plain array? Library, I think. This is linked to schedule, code and the way it's loaded in memory as objects. Gotta finish that this weekend.
  • organize the reg[ ] array into config and run entries. Those entries that are only used during setup() don't have to be copied in memory. I should be able to save about 32 bytes of SRAM this way.
  • copy the sun position schedule currently in a FLASH_ARRAY into some of the unused low bytes of internal EEPROM. I think it fits between the reg[] and MAP.
  • sift thru the current spreadsheet of opcodes and stuff all the blocking calls into one group so we can flag those in the sequence generator - in case we need to run those as 'exclusive'.
  • I had an idea to wrap the stock LCD library so we can include references to a string_table for option-list type fields. Currently it's all numeric. Smells like scope creep.
  • UPDATE: I forgot the August 31 deadline for autonomous operations. I've started a reverse calendar to count down the work items left.

No comments:

Post a Comment