qmk_firmware/tmk_core/protocol/chibios
a-chol d4be07dad3 Hid joystick interface (#4226)
* add support for hid gamepad interface
add documentation for HID joystick
Add joystick_task to read analog axes values even when no key is pressed or release. update doc
Update docs/feature_joystick.md
Manage pin setup and read to maintain matrix scan after analog read

* Incorporates patches and changes to HID reporting

There are some patches provided by @a-chol incorporated on this commit,
and also some changes I made to the HID Report structure.

The most interesting is the one dealing with number of buttons: Linux
doesn't seem to care, but Windows requires the HID structure to be byte
aligned (that's in the spec). So if one declares 8/16/32... buttons they
should not have any issues, but this is what happens when you have 9
buttons:

```
 bits |0|1|2|3|4|5|6|7|
      |*|*|*|*|*|*|*|*| axis 0 (report size 8)
      |*|*|*|*|*|*|*|*| ...
      |*|*|*|*|*|*|*|*|
      |*|*|*|*|*|*|*|*|
      |*|*|*|*|*|*|*|*|
      |*|*|*|*|*|*|*|*|
      |*|*|*|*|*|*|*|*| axis 6
      |*|*|*|*|*|*|*|*| first 8 buttons (report size 1)
      |*| | | | | | | | last of 9 buttons, not aligned
```

So for that I added a conditonal that will add a number of reports with
size 1 to make sure it aligns to the next multiple of 8. Those reports
send dummy inputs that don't do anything aside from aligning the data.

Tested on Linux, Windows 10 and Street Fighter (where the joystick is
recognized as direct-input)

* Add save and restore of each pin used in reading joystick (AVR).
Allow output pin to be JS_VIRTUAL_AXIS if the axis is connected to Vcc
instead of an output pin from the MCU.

Fix joystick report id

Fix broken v-usb hid joystick interface. Make it more resilient to unusual settings (none multiple of eight button count, 0 buttons or 0 axes)

Correct adc reading for multiple axes. Piecewise range conversion for uncentered raw value range. Input, output and ground pin configuration per axis.

Documentation fixes

* Fix port addressing for joystick analog read

* The other required set of changes
As per the PR, the changes still holding it up.
Add onekey for testing.
Fix ARM builds.
Fix device descriptor when either axes or buttons is zero.
Add compile-time check for at least one axis or button.
Move definition to try to fix conflict.
PR review comments.
qmk cformat

* avoid float functions to compute range mapping for axis adc reading

* Remove V-USB support for now. Updated docs accordingly.

* Update tmk_core/protocol/lufa/lufa.c

Co-Authored-By: Ryan <fauxpark@gmail.com>

* Update tmk_core/protocol/usb_descriptor.c

Co-Authored-By: Ryan <fauxpark@gmail.com>

* Update tmk_core/protocol/usb_descriptor.c

Co-Authored-By: Ryan <fauxpark@gmail.com>

* Update tmk_core/protocol/usb_descriptor.c

Co-Authored-By: Ryan <fauxpark@gmail.com>

* Add support for joystick adc reading for stm32 MCUs. Fix joystick hid report sending for chibios

* Fix HID joystick report sending for ChibiOS.
Add one analog axis to the onekey:joystick keymap.
Fix pin state save and restore during joystick analog read for STM32
MCUs.

* Update tmk_core/protocol/chibios/usb_main.c

Co-Authored-By: Ryan <fauxpark@gmail.com>

* Update tmk_core/protocol/lufa/lufa.c

Co-Authored-By: Ryan <fauxpark@gmail.com>

* Add missing mcuconf.h and halconf.h to onekey:joystick keymap.
Add suggested fixes from PR.

* Switch saveState and restoreState signature to use pin_t type.
onekey:joystick : add a second axis, virtual and programmatically animated.

* Update docs/feature_joystick.md

Co-Authored-By: Ryan <fauxpark@gmail.com>

* Update docs/feature_joystick.md

Co-Authored-By: Ryan <fauxpark@gmail.com>

* Add PR corrections

* Remove halconf.h and mcuconf.h from onekey keymaps

* Change ADC_PIN to A0

Co-authored-by: achol <allecooll@hotmail.com>
Co-authored-by: José Júnior <jose.junior@gmail.com>
Co-authored-by: a-chol <achol@notamail.com>
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Ryan <fauxpark@gmail.com>
2020-08-29 14:30:02 -07:00
..
lufa_utils/LUFA/Drivers/USB clang-format changes 2019-08-30 15:01:52 -07:00
init_hooks.h Add support for hardware and board initialisation overrides. (#8330) 2020-04-13 09:39:38 +10:00
main.c Add dual-bank STM32 bootloader support, given GPIO toggle on BOOT0 to charge RC circuit. (#8778) 2020-08-29 14:30:02 -07:00
README.md Add ChibiOS support for QMK (#465) 2016-07-01 10:04:53 -04:00
usb_driver.c 2020 February 29 Breaking Changes Update (#8064) 2020-02-29 11:59:30 -08:00
usb_driver.h clang-format changes 2019-08-30 15:01:52 -07:00
usb_main.c Hid joystick interface (#4226) 2020-08-29 14:30:02 -07:00
usb_main.h 2020 May 30 Breaking Changes Update (#9215) 2020-05-30 13:14:59 -07:00

TMK running on top of ChibiOS

This code can be used to run TMK keyboard logic on top of ChibiOS, meaning that you can run TMK on whatever ChibiOS supports. The notable examples are ARM-based Teensies (3.x and LC) and on the boards with STM32 MCUs.

Usage

  • To use, get a zip of chibios and unpack/rename it to tmk_core/tool/chibios/chibios; or you can just clone the repo there. For Freescale/NXP Kinetis support (meaning ARM Teensies and the Infinity keyboard), you'll also need a zip of chibios-contrib, unpacked/renamed to tmk_core/tool/chibios/chibios-contrib. Likewise, for git-savvy people, just clone the repo there.
  • Note: the abovementioned directories are the defaults. You can have the two chibios repositories wherever you want, just define their location in CHIBIOS and CHIBIOS_CONTRIB variables in your Makefile.
  • You will also need to install an ARM toolchain, for instance from here. On linux, this is usually also present as a package for your distribution (as gcc-arm or something similar). On OS X, you can use homebrew with an appropriate tap.

Notes

  • Some comments about ChibiOS syntax and the most commonly used GPIO functions are, as well as an example for ARM Teensies, is here.
  • For gcc options, inspect tmk_core/tool/chibios/chibios.mk. For instance, I enabled -Wno-missing-field-initializers, because TMK common bits generated a lot of warnings on that.
  • For debugging, it is sometimes useful disable gcc optimisations, you can do that by adding -O0 to OPT_DEFS in your Makefile.
  • USB string descriptors are messy. I did not find a way to cleanly generate the right structures from actual strings, so the definitions in individual keyboards' config.h are ugly as heck.
  • It is easy to add some code for testing (e.g. blink LED, do stuff on button press, etc...) - just create another thread in main.c, it will run independently of the keyboard business.
  • Jumping to (the built-in) bootloaders on STM32 works, but it is not entirely pleasant, since it is very much MCU dependent. So, one needs to dig out the right address to jump to, and either pass it to the compiler in the Makefile, or better, define it in <your_kb>/bootloader_defs.h. An additional startup code is also needed; the best way to deal with this is to define custom board files. (Example forthcoming.) In any case, there are no problems for Teensies.

Immediate todo

  • power saving for suspend

Not tested, but possibly working

  • backlight

Missing / not working (TMK vs ChibiOS bits)

  • eeprom / bootmagic for STM32 (will be chip dependent; eeprom needs to be emulated in flash, which means less writes; wear-levelling?) There is a semi-official ST "driver" for eeprom, with wear-levelling, but I think it consumes a lot of RAM (like 2 pages, i.e. 1kB or so).

Tried with

  • Infinity, WhiteFox keyboards
  • all ARM-based Teensies
  • some STM32-based boards (e.g. ST-F072RB-DISCOVERY board, STM32F042 breakout board, Maple Mini (STM32F103-based))

ChibiOS-supported MCUs

  • Pretty much all STM32 chips.
  • K20x and KL2x Freescale/NXP chips (i.e. Teensy 3.x/LC, mchck, FRDM-KL2{5,6}Z, FRDM-K20D50M), via the ChibiOS-Contrib repository.
  • There is also support for AVR8, but the USB stack is not implemented for them yet (some news on that front recently though), and also the kernel itself takes about 1k of RAM. I think people managed to get ChibiOS running on atmega32[8p/u4] though.
  • There is also support for Nordic NRF51822 (the chip in Adafruit's Bluefruit bluetooth-low-energy boards), but be aware that that chip does not have USB, and the BLE softdevice (i.e. Bluetooth) is not supported directly at the moment.

STM32-based keyboard design considerations

  • STM32F0x2 chips can do crystal-less USB, but they still need a 3.3V voltage regulator.
  • The BOOT0 pin should be tied to GND.
  • For a hardware way of accessing the in-built DFU bootloader, in addition to the reset button, put another button between the BOOT0 pin and 3V3.
  • There is a working example of a STM32F042-based keyboard: firmware here and hardware (kicad) here. You can check this example firmware for custom board files, and a more complicated matrix than just one key.