will probably have to take a break for a while
javascript looks promising :) . this application just lends itself so
well to state! or maybe it's because i'm not used to programming in a
pure functional language like Elm... Elm is fun though :)
decided not to write a second test for Elm. partly because i didn't
have time. what i wanted to try was doing things based on the Elm
calculator example. I haven't tried using buttons yet, and they might
work out. then again, it might turn out to be a whole lot easier in
javascript. and then it would be a bit more portable as well...
so i suppose i'm leaning towards javascript. we'll see :)
Thanatermesis (via email) told me that this worked for him, fixing his
issue of having some keys unexpectedly double tap (though, I think he
might have gone down to 50Hz, or something). since he mentioned it,
i've been noticing my keys double tapping sometimes (on one of my brown
boards, with an acrylic case... it didn't seem to happen at all with my
blue caseless board...), so i decided to give this a try :)
- changed how things are organized
- LEDs now indicate layers! layers 1 and 2 have a corresponding LED,
along with capslock (which also kinda needs one)
- this organization of things is not final. but i hope (and think) it's
a little better :)
originally, it seemed that the little endian version of write...(), and
the big endian version of read...() would be the easiest. this was
true, when i first wrote the functions. after optimization, the big
endian write...() got much better, but for some reason, i couldn't quite
crack the little endian read...(). perhaps i'm missing something. in
any case, the big endian versions of both look quite good to me now, so
they're what i'll be going with. too bad the little endian versions
didn't quite work out... but i was expecting to go with the big endian
versions anyway, since we'll be reading much more often than writing.
// - sizes for each function (in bytes) (with optimizations on):
//
// function frame stack
// read big endian 154 3 10
// read little endian 200 2 10
// write big endian 160 0 6
// write little endian 172 0 5
also, note that while optimizing, i was looking only at compiled
function size, and frame and stack usage: actual profiling would have
been a bit difficult, and i don't feel like writing versions of the
algorithms for testing on my laptop right now (though, i might later,
for fun, if i can give it as an assignment to the class i hopefully TA
for next semester - hehe). i tried to pay attention to the amount of
code inside the loops though, when i was changing things, and i'm under
the impression that the AVR has fairly predictably timed assembly
instructions (1 or 2 cycles each?), so compiled function size seemed
like a good proxy.
done experimenting with this for now. yay! :) . i'll remove the extra
code in the next commit.
Ben Blazak