- remove all the INFOx, ERRORn, etc style faux-variadic logging macros
and replace with real variadic macro equivalents
- switch all direct usages of trace(), log2(), log3() and log_num() to
use the equivalent logging macros instead. i guess that these logging
macros were added later on at some point but not all code was switched
over to use them at that time?
- remove trace(), log2(), log3() and lognum() functions
- some formatting cleanups
- rename log() to log_msg() so as to not ever risk conflicting with
log() from math.h
- use snprintf() instead of sprintf() in log.c
the Makefile now builds all artifacts, including final output s37 and
bin files under "build" so as to not clutter up the root directory
and making it easier to gitignore all build artifacts now and into the
future.
as well, the Makefile now has a new target to invoke srec2bin.py for us
to build ready-to-flash artifacts
srec2bin.py has been updated to be more flexible and do some minimal
argument error checking. it now also will output a CSV file for use
with FoenixMgr's flash-bulk option. this is useful as the number of
8k bin files can and will vary now and into the future, especially if
you are building with -O2 optimizations for size, etc.
KBD_OPTICAL (0xf01dc0) is only "valid" on F256K2 hardware. i would
assume that this value is unknown on non-F256K2 hardware, thus sometimes
you might read some garbage value from here perhaps?
what i observed on my f256k was that always on cold bootup (that is,
booting from flash) the keyboard would never work. hitting reset or
booting from a ram build would not exhibit the same problem.
sometimes (somewhat more rarely) kbd_init() would lock up at some
point, presumably when it was trying to initialize/scan the non-existent
optical keyboard.
so far this also *seems* to resolve intermittent issues with reads to
the SD card on my f256k locking up. best not to read from those new
F256K2 registers on non-K2 devices!
i'm not really sure why this was commented out to begin with. possibly
due to the broken parsing of the channel path string in uart_open, but
i am unsure exactly.
i am really not a big fan of the current "Makefile in each directory"
build system in this project. sorry.
i don't have any C256 devices, so i've not kept anything for them in
this new Makefile. to the best of my knowledge, you can't get any of
these devices anymore anyway, so i don't particular care. sorry again.
Gered
