From 9540016b12f2182dc6ced530d2a9ab399a2b2ca1 Mon Sep 17 00:00:00 2001 From: flabbergast Date: Thu, 10 Sep 2015 10:49:47 +0100 Subject: [PATCH] Update chibios README. --- tmk_core/protocol/chibios/README.md | 31 +++++++++++++++++++++++------ 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/tmk_core/protocol/chibios/README.md b/tmk_core/protocol/chibios/README.md index 5df4c6e7..06569c51 100644 --- a/tmk_core/protocol/chibios/README.md +++ b/tmk_core/protocol/chibios/README.md @@ -1,12 +1,12 @@ -## USB stack implementation using ChibiOS +## TMK running on top of ChibiOS ### Notes -- To use, unpack or symlink ChibiOS here, to `chibios`. -- For gcc options, inspect `chibios.mk`. For instance, I enabled `-Wno-missing-field-initializers`, because TMK common bits generated a lot of hits on that. +- To use, unpack or symlink [ChibiOS] {currently 3.0.1} to `tmk_core/tool/chibios/chibios`. +- 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. Also pay attention to `-O0` (enabled for debugging); for deployment use `-O2`. -- USB string descriptors are a mess. 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. -- There are some random constants left so far, e.g. 5ms sleep between calling `keyboard_task` in `main.c`. There should be no such in `usb_main.c`. Everything is based on timers/interrupts/kernel scheduling (well except `keyboard_task`), so no periodically called things (again, except `keyboard_task`, which is just how TMK is designed). +- 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. +- There are some random constants left so far, e.g. 5ms sleep between calling `keyboard_task`, or 1.5sec wait for USB init, in `main.c`. There should be no such in `usb_main.c` (the main USB stack). Everything is based on timers/interrupts/kernel scheduling (well except `keyboard_task`), so no periodically called things (again, except `keyboard_task`, which is just how TMK is designed). - 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 bootloader works, but it is not entirely pleasant, since it is very much MCU dependent. The code is now geared towards STM32 chips and their built-in bootloaders. So, one needs to dig out the right address to jump to, and pass it to the compiler in the `Makefile`. Also, a patch to upstream ChibiOS is needed (supplied), because it `ResetHandler` needs adjusting. - Sleep LED works, but at the moment only on/off, i.e. no breathing. @@ -14,6 +14,7 @@ Also pay attention to `-O0` (enabled for debugging); for deployment use `-O2`. ### Immediate todo +- host-wakeup packet sending during suspend - power saving for suspend? - PWM for sleep led @@ -23,9 +24,27 @@ Also pay attention to `-O0` (enabled for debugging); for deployment use `-O2`. ### Missing / not working (TMK vs ChibiOS bits) -- eeprom / bootmagic (will be chip dependent; eeprom needs to be emulated in flash, which means less writes; wear-levelling?) +- eeprom / bootmagic (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 - ChibiOS 3.0.1 and ST F072RB DISCOVERY board. - Need to test on other STM32 chips (F3, F4) to make it as much chip-independent as possible. + +## 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. +- For breathing the caps lock LED during the suspended state ("sleep LED"), it is desirable to have that LED on a hardware PWM pin (there's usually plenty of those, look for TIMERs in the datasheet). + +## ChibiOS-supported MCUs (as of 3.0.1) + +- Pretty much all STM32 chips. +- There is also support for AVR8, but the USB stack is not implemented for them yet, 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 some support for K20 and KL25 Freescale chips (i.e. Teensy 3.0, mchck, FRDM-KL25Z, FRDM-K20D50M), but again, no USB stack yet. +- I've seen community support for Nordic NRF51822 (the chip in Adafruit's Bluefruit bluetooth-low-energy boards), but not sure about the extent. + + + +[ChibiOS]: http://chibios.org