STM32 keyboard controller

[vvb]

Hi, I'm working on a keyboard controller based on STM32 MCU.

STM32 is a microcontroller family based on 32bit Contex-M3 CPU, it supports various peripherals, has lots of GPIO pins and more RAM than most megaAVR MCUs.

Here are some advantages and disadvantages of STM32F103C8 compared to generic megaAVR

Disdvantages:

• incompatible with AVR
• 3.3V operation (many pins are 5V tolerant)
• no "free" EEPROM

Advantages:

• 32bit ARM CPU clocked at 72MHz
• 20KB RAM
• cool features like better timers and nested interrupts
• slightly more usable I/O pins

Controllers are very different but both are not very expensive, have good documentation, various libraries and are supported by GCC.

If I forgot something significant, it's unintentional, sorry.

Hardware

I have a SteelSeries 7G keyboard, MX Blacks are replaced with MX Clears.

This keyboard has 3 LEDs and 16x8 matrix with diodes, so 4+16+8=28 GPIOs needed if LEDs are hardware PWM controlled by one timer. STM32F103C8 can handle this with its 48pin package and yet have some pins to spare.

I'm using cheap development board, not the highest possible quality, but OK. You can find it on ebay or aliexpress by searching "STM32F103C8T6 board".

Spoiler:

development board connected to 7G

wip.jpg (383.69 KiB) Viewed 12692 times

Firmware

There are 3 major sections.

Embedded boot loader - read-only, factory programmed. Selected by BOOT pins, supports flash programming via USART.

Boot loader - custom loader. Features:

• DFU to load/update Main secion
• checks if magic keys are not pressed, Main is programmed and then runs Main
• HID keyboard with basic functionality (boot protocol, 6KRO, two layers - one FN key as a layer shift)

Missing features: ghosting

Main - all advanced stuff to go here. But nothing really interesting here yet.

Source code is available here: https://sourceforge.net/p/keyboard-stm3 ... ree/trunk/ I believe almost any ARM EABI toolchain should work fine, there are almost no external dependencies.

To build, check the config.mk file and either edit it or define overrides in config-local.mk. Then change directory to boot and run GNU Make.

Firmware is built from single file from which all other source files are included - this allows GCC to perform some advanced optimizations and significantly reduce binary size (up to 2 times).

Conclusion

I'm typing all this on a modded 7G keyboard in a "bootloader" mode. I'm planning to start working on Main firmware soon, sort out some things, implement "missing boot features" and port them to bootloader later.

Advanced keyboard features seemed pretty straightforward at first but the more I digged the less I could comprehend how to actually implement everything, it'll take some time...

Anyway, questions? ideas? If somebody wants to try the "STM32-way", I'll try to help

[Findecanor]

Have you considered supporting the Teensy 3.0? (MK20DX128, Cortex-M4 @ 48 MHz, 16 K RAM, 34 I/O pins)

[vvb]

The first problem with this is that the project relies heavily on ST libraries now (for simplicity and readability - almost no direct register programming), license limits their usage only with ST microcontrollers. The second - K20, while being ARM, has different peripheral programing interfaces. It's certainly possible to do but I doubt it makes sense in foreseeable future - instead of implementing keyboard-related software it'll end up being peripheral driver and abstraction layers collection which happens to do some keyboard stuff too. It would be more sensible to fork and rewrite related bits later, IMHO.

Adding support for other STM32 families should be easy, though, but I have only F1s here, so I can not test that it'll actually work, and again this would mean project focus loss too.

And Teensy is more than 2 times more expensive than the board I have.

[Daniel]

Very interesting. I have a STM32F4 Discovery laying around...

[kile]

Nice

I also made a programmable controller for the 7G, but I used an AVR - ATMega169PV, and I made the controller wireless. Check out the details here: http://deskthority.net/workshop-f7/stee ... t5929.html

I didn't make a bootloader, though. But I brought out the 6 pin AVR-ISP to the hole in front of the keyboard where the USB hub plugs used to be on the original controller.

7G is a great keyboard for experimenting. I also changed the switches to greens (I plan to try out clears as well), and changed the LEDs from white to blue. I've also put Max keyboard front printed translucent keycaps, and I thought about making a new wired controller with backlighting to go with the new keycaps. That would require a new PCB for the switches, and would probably be too much work to justify the benefits (I don't really need a backlit keyboard), so I gave up on that.

Do you plan to make a dedicated PCB or do you want to keep the devboard?

What are those jumper wires on the PCB with the switches on the right side of the image you posted?

[vvb]

Very interesting. I have a STM32F4 Discovery laying around...

Unfortunately it won't work at the moment. As fas as I understood, there are two major USB peripherals for STM32: USB FS and USB OTG FS, they're quite different. I guess, I'll need an USB abstraction layer after all...

STM32F102, STM32F103, STM32L1xx and STM32F3xx have USB 2.0 FS, should be easy to port to these MCUs.

I also made a programmable controller for the 7G, but I used an AVR - ATMega169PV, and I made the controller wireless. Check out the details here: workshop-f7/steelseries-7g-wireless-mod-t5929.html

Yes, I saw it, good work!

7G is a great keyboard for experimenting. I also changed the switches to greens (I plan to try out clears as well), and changed the LEDs from white to blue. I've also put Max keyboard front printed translucent keycaps, and I thought about making a new wired controller with backlighting to go with the new keycaps. That would require a new PCB for the switches, and would probably be too much work to justify the benefits (I don't really need a backlit keyboard), so I gave up on that.

Max keycaps look interesting indeed, I'm looking for a keycap replacement for a some time now, are they good? As for LEDs on my keyboard I've added resistors to reduce brightness only. They were just too bright...

Do you plan to make a dedicated PCB or do you want to keep the devboard?

I know devboard is ugly but it works for me now. My primary objective is to develop a firmware and as long as hardware does its job I'll keep it that way. Maybe sometime later.

What are those jumper wires on the PCB with the switches on the right side of the image you posted?

There are 3 jumpers on that board - two, that are on a photo, are BOOT0 and BOOT1. They select the code that is run after reset - RAM, flash or embedded boot. The third jumper (P2) was hardwired, it's a 1.5K USB pull-up.

On the left side of the board there's serial port for bootloader programming. Serial and BOOT1 pins are "dual-role" - when firmware is running these pins control LEDs or scan matrix.

[kile]

Max keycaps look interesting indeed, I'm looking for a keycap replacement for a some time now, are they good?

Not bad, I guess. After a few days of use I got used to them, and don't really notice them and more. The good thing about them is that the letters on the caps will probably never wear out. It looks nice, and as far as keycaps go - they were cheap.

Have a look here: http://geekhack.org/index.php?topic=50443.0

Another good thing is that I now have enough left over translucent keycaps to make a backlit gamepad I've been planning to build.

As for LEDs on my keyboard I've added resistors to reduce brightness only. They were just too bright...

Yes, they were very bright. I'm powering my 7G from 3V (Still the Lithium coin cell after 50 days and still at 2.95V ), so they are not nearly as bright as the white ones at 5V, and I'm also PWM-ing them, so they are even less bright. But I didn't put a current limiting resistor for the LEDs at all. I figured the blue LEDs don't really need current limiting at 3V.

[philpirj]

There's a more compact option, while twice as expensive with expensive delivery, check it out:
http://www.mikroe.com/mini/stm32/


$29

[vvb]

Have a look here: http://geekhack.org/index.php?topic=50443.0

Looks good, thanks for sharing!


Another board: http://www.kickstarter.com/projects/214 ... ontrollers
Not small but slim and under free license, probably price will be lower from other suppliers in future.

[vvb]

Found one more board, probably the best one out there - compatible (same MCU), small size and open hardware.

Not tested, but should work.

LeafLabs Maple Mini

772-11280-01c.jpg (100.91 KiB) Viewed 12507 times

772-11280-03c.jpg (107.23 KiB) Viewed 12507 times

There are blue-colored ("non-original", I suppose) boards on ebay and aliexpress.

[vvb]

Small update:

Initial implementation of SET_IDLE is ready, most likely there are some issues, can't test it now but looks like it works in Mac OS in VMware.

Suspend and resume, as far as I can test it in Linux, Windows and BIOS, works fine. MCU enters low-power state, can wakeup a PC on a keypress event or transit itself from suspended to active state when only keyboard is suspended.

I've measured power consumption too. My devboard draws 17 mA in active state and 5 mA while suspended. This may seem like a lot but the board has a AMS1117 power regulator with a 5 mA quiescent and minimum load current. Using better regulator should significantly reduce power consumption. I was going to write that no LEDs were lit on keyboard but then I remembered that the board has bright always-on power LED indicator... measurements are very rough.