As someone who recently started dabbling into MCU programming, I can tell you that a tutorial that shows you all the steps, and has an end result that works and can still be tweaked, is valuable. The DX you may be used to in modern programming is something you can only dream of in the embedded world. Every manufacturer has their own bespoke frameworks, tools, and conventions. The development loop is long: you have to build the thing, flash it to the firmware, reboot the device... You're dealing with raw bytes 99% of the time, so compiler type safety is little help in checking that your program will behave as expected and mistakes are frequent. The global state is huge, and with so little computing/memory resources, you're discouraged from introducing complex abstraction that would help clarify the code or avoid mistakes.
Blue Pills and Black Pills are popular with the DIY mechanical keyboard crowd as the brains of a keyboard circuit. The Arduino Pro Micro is also popular. I imagine that nowadays people also use the Raspberry Pi RP2040.
The common feature among these boards is that they have relatively full-featured USB client support in hardware. This is different from other hobbyist embedded boards, such as most Arduinos, for example, which have only a USB virtual serial interface via a discrete chip for the purpose of uploading and debugging firmware. So if you can make the board look like a USB keyboard, and it has enough I/O to handle a matrix of keyboard switches, then with the right firmware like QMK, you've got yourself the building blocks of a custom keyboard.
My info is stale as of the start of the pandemic, when I gave up my mechanical-keyboard hobby and pivoted to DSLR-based videoconferencing.
Windows HID interface is very flexible IIRC, and even added I2C support to the HID module or something... in Windows 8 or so?
I don't know all the details, but as I understand it, you don't necessarily need a USB License ($5000/year membership fee) to have a microcontroller running USB-HID across Windows.
Though I haven't figured out all the details of how all the mechanics work, its still interesting to work through even the most "toy" example of the USB-HID stack.
Windows will try to use the VendorID/ProductID pair on the device to look up which driver to load, but if there isn't any then a regular USB-HID device will default to using the generic HID driver.
You'd get assigned a VendorID if you have a USB license: That is a USB-IF thing, not a Microsoft thing. Then each licensee gets to assign its own ProductIDs.
There is no authentication in the core USB protocol: A device can declare any VendorID.
Major microcontroller board manufacturers such as Sparkfun and PJRC provide specific VendorID/ProductIDs to be used by DIY projects using their boards ... but I've seen some of those being reused by other boards. I have also seen the VendorID 0xf055 used by free open source firmware.
If your project is open source, you can get a PID for free. [1]
I received one for a virtual usb keyboard [2] that I made to work alongside a desktop app. Having a dedicated VID/PID makes detecting the presence of the device easy.
I was very intrigued by that possibility, but it seems like the stack there is inverted from what it sounds like at first glance. It's for supporting HID devices that are connected to an I²C interface on the motherboard chipset without having to write any kernel-mode drivers. Think stuff like custom lighting or other devices built in to your system that don't need the speed to take up a whole USB endpoint.
I think if someone wanted to have a very simple interface to control I²C devices over USB, it looks like there's plenty of cheap chips around that expose an I²C bus as a simple USB serial port to your computer.
Yeah it’s just a tutorial. I don’t really have any kind of platform for saving links I find useful so figured I’d post it here to save it for myself and maybe someone else would like it. I expected it to be completely ignored.
It's an example using STM32CubeMx dev environment. ST supplies many examples, including this one. However, this walkthru helps beginners navigate some of the complexity in getting it running.
Could it also be used to bridge a BT keyboard to USB for the semi-rare cases where having a wired keyboard is necessary (BIOS access, boot loader, login screen etc.)? I expected this type of product to exist, but couldn't really find a good one after a cursory look.
I don’t know of an off-the-shelf way to implement what you want. There’s a usb-usb converter in QMK which allows you to add QMK features to any keyboard, but QMK does not have Bluetooth support. ZMK is designed for Bluetooth but doesn’t seem to have anything like QMK’s protocol converters (tho I might have looked in the wrong place).
You might be able to DIY it with a Raspberry Pi Pico W, by gluing together the picow_bt_example_hid_host_demo and tinyusb_dev_hid_multiple_interface examples from https://github.com/raspberrypi/pico-examples
In principle, yes, but you'd need something additional to act as a Bluetooth host. You'd probably be better off using a part that can do both, like an ESP32.
Are howto articles considered spam? I found it useful and wanted to share it as well as save the link so I could find it later. If this post violates some code of etiquette I’ll not do it again.
