STM32 Creating a USB Programmable Keypad - Don't Know Where to Start - Page 1
Forum section: electronics / general

author: evglabs
author_rank: Contributor
timestamp: December 02, 2019, 01:49:19 am
content: So, I'm creating a USB input device with an STM32F042C6 and I've got it working as a mouse scroll wheel. The ultimate goal I'd like to do is to be able to set the action the device does without reflashing (whether it acts like a programmable keyboard or just a program running on the desktop that receives signals from the device then executes the action).The problem is I don't really know what to look for or where to start to achieve that.Any pointers?Thanks.

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: December 02, 2019, 09:11:01 am
content: The USB HID spec would be a good place to start, if you don't mind lots of reading. You may end up there anyway.The way I'd go about it is to build a single HID descriptor that covers the entire space of everything you foresee wanting to send (buttons, keys, modifiers, dials, mouse motion axes, etc.), and mode-switch within the device to format your HID report differently according to the selected mode. The mode would be selected by on-device switches or commands from the host.Another way to go about it would be to use some of the F042's 6kB of RAM to store code and descriptors, and build the base program and the overlay with a custom linker script. You would then use a host-side loader to stop reports, load a new code overlay into RAM, and command the F042 to re-enumerate and send its new descriptor. You gain complete open-endedness without ever having to flash, but it's a little bit cheesy and not entirely seamless.Yet another way is to build a completely custom device using a non-HID protocol and write your own driver for it. It allows the device to be very dumb and the host to control all aspects of the UI events, but it's pretty janky and not very portable.One more way is to surrender on the no-reflashing requirement and use the DFU bootloader on the chip to load new images according to your desired mode. It's fully seamless but you only get to do this 10k times or so.How you would send mode select commands or new code from the OS to effect that mode switch would vary by OS, and I don't do Windows, so aside from vague references to unified driver layers such as libusb,

author: evglabs
author_rank: Contributor
timestamp: December 02, 2019, 02:50:12 pm
content: Thanks, I'm afraid I've got a lot of reading to do.

author: lawrence11
author_rank: Frequent Contributor
timestamp: December 02, 2019, 03:32:08 pm
content: You are also going to have to electronically disconnect it to re-enumerate.

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: December 02, 2019, 04:02:25 pm
content: Quote from: lawrence11 on December 02, 2019, 03:32:08 pmNo, you only need to turn off the D+ pullup for a little while. On the 32F0, that is controlled through the DPPU bit in the USB_BCDR register.

author: senso
author_rank: Frequent Contributor
timestamp: December 02, 2019, 05:16:22 pm
content: Does it need to be an STM32?Lots of code for keyboard and mouse are already done in the TMK Keyboard project.There is even some support for Arms, read about it:https://github.com/tmk/tmk_keyboardOn the PC side, if its Windows, see if AutoHotKey doesn't help you, its kinda of a programming language for macros.

author: lawrence11
author_rank: Frequent Contributor
timestamp: December 02, 2019, 05:32:43 pm
content: I thought you needed somekind of transistor setup on that pullup.And a dedicated pin.O well, I dont recall what I did on the microchip anymore.It was programmed as registers and poor commenting a long time ago and I never finished the project.Serves me well.

author: GromBeestje
author_rank: Frequent Contributor
timestamp: December 02, 2019, 06:18:10 pm
content: The STM32F1 doesn't have the internal pullup, and required external pullup, but the F0 series have it internal

author: thm_w
author_rank: Super Contributor
timestamp: December 02, 2019, 10:09:28 pm
content: Quote from: senso on December 02, 2019, 05:16:22 pmQMK supports bluepill:https://github.com/qmk/qmk_firmware/tree/master/keyboards/handwired/bluepillbut that is one hell of a codebase, still struggling with it.You can set up layers, have a key to switch between layer functions, but it is hardcoded and does not happen on the fly and not sure what macro support is like.For something like that I would strongly consider PC based software like Autohotkey or luamacros:https://linustechtips.com/main/topic/577981-87-key-macro-keyboard/Since OP already has some keys working, the only remaining work they should need to do on the STM32 is map each button to a unique keycode. Then you can re-map and set up whatever macros via PC.

author: martinayotte
author_rank: Regular Contributor
timestamp: December 03, 2019, 03:21:40 pm
content: Quote from: GromBeestje on December 02, 2019, 06:18:10 pmNot true ! If you read datasheet, STM32F1xx can provide either PullUp or PullDown on any of its GPIOs.

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: December 03, 2019, 04:21:46 pm
content: Quote from: martinayotte on December 03, 2019, 03:21:40 pmBut we're specifically referring to the 1.5k pullup for USB, which in any case must be external on the F1. Maybe he could switch the pin on the other side of the 1.5k resistor between high and hi-Z state, at some (hopefully minor) cost to signal integrity.