since we weren't executing scheduled functions inside the interrupt
vector, and therefore had to wait to execute a cycle's worth of
scheduled "millisecond tasks" at the end of each cycle anyway, it was
kind of a misleading function to have around. i'd keep it around and
change the functionality back to running scheduled tasks inside the
interrupt vector, except i feel that that should be strongly discouraged
never mind what i was talking about in the last few commits. i'm not
sure if i'll be able to get fault tolerance logic designed well or not,
but after all this, it appears that i really really want to try, lol.
i'm thinking about how i might implement logging right now.
going to retain a degree of fault tolerance... but probably the more
old school kind, where if there's a power loss at a bad time, we know
about it, and can usually correct the problem, but it takes a while
(fsck style)
would it be better to just assume power won't fail (and writes will
always be successful), and tell people that if there's a macro they
really care about, they really should write it in the source, and
recompile?
at least initially... and then if i decide that there needs to be fault
tolerance in the library, i can implement some logging of some sort. it
probably wouldn't take *that* much more space, actually, even to do it
pretty generally, than what i'm trying to do right now... dunno.
but under normal use, it should be safe enough to live dangerously...
and i'm not going to implement a way for people who don't want to get a
nice avr toolchain going to put macros in after compilation anyway (since
it'd be easier to just write a UI... and hopefully other people haven't
lost interest, and will still do that for me... :) lol ). so the eeprom
is not really a place that permanent macros *shoud* be, anyways...
ya... i think i should do that
</random thoughts> ... i'm tired
Ben Blazak