- Hex debug for debugging VT100 control characters from the keyboard
- Renamed reset to restart (software reset)
- Added reset command (same as bash reset, which resets the VT100 variables)
- Cleaned up the version module field

- reset   -> Simulates power cycle (Not yet compatible with AVR)
- reload  -> Sets the device into firmware reload mode
- led     -> Toggles the error LED
- version -> Displays detailed version information (additions to CMake files was necessary, might have broken Windows builds...)

- Issue with the first space delimiter before the args

- Supports multiple custom command dictionaries
- Basic handling of control characters
- Initial dictionary for integrated commands

* Initial cli code

- Any keys that exceed the high average are temporarily disabled
- If the sense value goes below the initial average sense, it is re-enabled
- Even works if *many* keys are pressed initially

- Still needs a bit of detection of consistent high keys that sometimes sneak below the threshold
  (May be able to have an elastic threshold that could deal with this)

- Removed dead code (and redundant calculations)

- Enabling the test point strobe on the kishsaver really kills the sensing (many keys don't work, even at 400)

- Should fix the last of the phantom keys

- Not confirmed that this fixes all known phantom keypresses

- Added debounce mechanism, currently looks for 5 consecutive scans
- Temporarily disabled the test point strobe on the kishsaver (spams debug messages, and not useful anymore; needs to be addressed before strobe detection is implemented though)
- Reorganized code to cleanup the main scan loop function

- Haven't fully verified all the strobes yet, but should be correct

- Basic strobe mapper added (only kishsaver for now)
- Removed more (less obvious) dead code
- Moved keypress detection closer to detection
- Added more informative keypress debug messages

- Added a print macro for colourful convenience
- Removed the usb_keymap variable as it is no longer needed
- Changed usb_dirty to keymap_change (more accurate description)
- Removed the dumpkeys function and now detect key changes much sooner as well as displaying error messages more often
- Added a warming up information message and removed its error status (as it's not an error)

- Added LGPL headers to appropriate files
- Removed *LOTS* of dead code
- Started standardizing formatting (important stuff done)

- Hardcoded strobe lines (required to make the hardware less noisy)
- Updated debug code

- Adding "template" keymap
- Removed "stray" functions, variables
- Cleaned up warnings
- Now builds
- Added buffered macro integration (rather than dealing with USB directly)
- Updated the print messages to use the Kiibohd print header

TODO
- Add generic matrix integration (this will require some changes to the matrix code)
- Add more comments...lots more
- Clean up dead code

- Directly printing numbers rather than having to convert them into strings first

- Also a bit of general house-keeping

- Had to add the iSerialNumber parameter to the AVR USB descriptor
- Removed a faulty pack command for avr-gcc that is not required

- Defined Manufacturer name
- Product name now references each of the selected modules
- Serial number refers to the last commit date, branch, and whether modified since the last commit

- I won't do any more, as I can't make the converter fully functional on a modern computer
- Basic typing support is working
- Some of the function modes move around the ASCII values, and this takes a while to decipher and figure out the pattern; it's not hard to do, and I don't really feel like doing it
- The hard part is already done :P

- Transmit seems to be working
- Receive isn't working yet
- Inversion of the transmit signal doesn't seem to be working

- No scan modules are functional yet, but all of the API code is now "hardware support" complete

- All modules have a default avr compatibilty right now (since that is what they were developed on)
- As modules get tested and added, arm support has to be turned on in the respective setup.cmake file

- CDC Output seems to be working
- USB Keyboard output has not been tested, but is "ready"
- UART and Timers have not been tested, or fully utilized
- Issues using Timer 0
- Initial template for MBC-55X Scan module (only module currently compatible with the arm build)
- Updated the interface to the AVR usb module for symmetry with the ARM usb module
- Much gutting was done to the Teensy 3 usb keyboard module, though not in an ideal state yet

- Very small updates to files, mostly modifying to remove name duplications

- Also added some extra CMake build messages for indicating the Compiler family and chip being built for

- Abstracted USB Module
- Abstracted compiler specific includes for Scan, Macro, Debug, and USB modules
- Updated CMake build files to support changes
- Added abstractions necessary to main.c as well as a compiler specific include file

- Tested with the AVR builds
- Partially tested with basic ARM test builds

- Removed another key from the latch list to use as a normal key

- Shouldn't affect anything, and will allow for greater buffer clearing control

- Required some small API changes, shouldn't affect any other Scan modules (addition of a parameter)
- Still have the latching annoyances for some of the modifiers
- Swapped Esc and Tilde for convenience
- Removed the old Esc key from the latch list (no one needs 13 latches anyways...)
- Added the control cluster mappings (Insert, Delete, Home, End, PgUp, PgDn)
- All other misc keys are currently un-assigned if a keycap legend doesn't map to anything known
  (e.g. blank keys, 000 and 00 are mapped, but your OS probably doesn't know what they mean :P)

Unfortunately, the protocol annoying, with only 3 keys having Press/Release signals.
Some of the keys were only meant to be pressed once, and do not have repeat functionality.

The current implementation is a bit slow, so some keys may get lost during USB sending.
This is probably fixable, not sure if I want to spend the time on it though.

There is a keyboard input protocol, but I'm not sure of what information can be transmitted to the keyboard.
The terminal does send some information back and forth between the keyboard, but I'm unclear of the purpose, as I can never get any response out of the keyboard.