- added high-level (logical) led macros, so that the top level firmware
doens't need to know what numbers leds are (or how many there are)
- left low-level (processor specific) led macros in
keyboard/.../teensy-2-0.h , where they were
- put non processor|layout specific led macros in keyboard/.../led.h
- put layout specific led macros into keyboard/.../layout/*.h (with
default empty macro definitions in keyboard/.../layout.h)
also
- cleaned up some typos and such
- moved the debounce time macro to 'keyboard/ergodox.h', since it's
technically keyboard (keyswitch) specific
aggregate changes for PCB update
- documentation updated to reflect that the columns are now the driving
pins, and the columns are the read pins. both are still treated as
open drain.
- macros for led pins 1 and 2 were swapped
- update functions now cycle through columns->low, read rows
- added a matrix macro to map from how we want the key layouts
represented, to how things are scanned into the matrix
(plus a few small aesthetic things in /src/keyboard. i changed some
function like macros to lower-case, because someday they might be
implemented as real functions... and there's no real reason to
distinguish between functions and function like macros in the main() and
other higher level code. at least that's what it seems like to me right
now.)
- simple bug fix in kbfun_press() and kbfun_release()
- no longer check for previous init() in the mcp23018 functions;
something would happen when i tried to read from it, sometimes, when
it'd been unplugged or stoped some other way, and it would hang - and
the only thing that would make it better was running the test_twi_2
function (a series of writes, with stops after each). so now
mcp23018_init() is a series of writes, with stops after each. it
doesn't take appreciably longer to run... maybe it should be looked
into later though.
- changed the main() loop a little
also, mcp23018_init() needs fixing: `twi_stop()` needs to be at the end
of transmission blocks. i wouldn't think that would be necessary, but
it seems to be the only thing that'll make it work, and it also seems
consistent with the protocol diagram in the datasheet (lol, imagine
that), so i think that's what i'll have to do. not as though it matters
much i guess, since it's a single master / single slave system anyway, i
was just hoping not to release the bus till i was finished..
