3 ms·

This is really fantastic. I am currently building my own keyboard with my own controller and it will be much easier for me to first implement mock controller in

This is really fantastic. I am currently building my own keyboard with my own controller and it will be much easier for me to first implement mock controller in userspace before I try to get it right on external device. Especially because I will want to put some complicated functionality in it like steno.

jrockway 7y ago
I don't think you need that for this. The keyboard firmware likely consists of three big chunks, the USB code, the matrix scan, and the processing of the matrix scan data into keystrokes. The USB stack is likely a peripheral on your microcontroller, which they have in theory already tested. The matrix scan will need to be tested on real hardware. The processing code should be abstracted enough from USB and matrix scanning that you can just compile it for your host machine and write tests the usual way (given matrix state x then y, output state should be foo). For final integration tests, you can use an additional microcontroller to be the key matrix. Instead of wiring up keyswitches, wire the microcontroller to the matrix pins, and have it accept commands over the serial port to set the matrix to a certain state. This way, you can do a full end-to-end test on your real hardware. The only place USB gadget emulation might be helpful is in writing the code that switches the keyboard from compatibility mode (6KRO) to the NKRO mode. It's been done a million times, though, so there is plenty of library code to just copy.
- lmilcin 7y ago
  First, this is going to be my first USB device. Second, I plan to put some more complex functionality. I intend it to be my last keyboard so I want to be able to map every key however I want (the whole point of having my own controller). I also want it to have built-in steno which is much more than just matrix scanning. While I could achieve all of that with OS driver and plover the sad reality is that I am unable to install my own software on my corporate PC and I would like to have consistent environment at my home and office.
  - jrockway 7y ago
    All I'm saying is that the interesting part of the code will run just fine on your host machine, so you don't need any complicated tricks to develop and test it. Obviously in production it will run on the microcontroller, so you get the functionality you desire without OS drivers. Do keep in mind that /usr/share/dict/words is about 10x larger than the flash on microcontrollers. This is why most people do the steno conversion in software, not on the keyboard itself.
    - lmilcin 7y ago
      I plan to store configuration data on an SD card for convenience. If it wasn't clear yet it is my personal project, I don't plan to make product from it.
      - ihuman 7y ago
        If you're not designing your own microcontroller, you might want to check out the Proton-C. It has 248kB of usable flash memory, which could be enough to store a stenography-optimized word list in addition to the firmware. It was made to be flashed with the qmk keyboard firmware, but I don't think there's any requirement that you have to use qmk. https://qmk.fm/proton-c/ https://qmk.fm/proton-c/
        jrockway 7y ago
        I used an STM32F103 for my last keyboard, and you can buy four for the price of a Proton C. I am still not sure why they chose the F3 series for the Proton C, as it doesn't seem to be a chip that's commonly used in the maker community. I am somewhat surprised they didn't bite the bullet and just port QMK to the nRF52 (since everyone wants bluetooth out of the box), actually. The F103 is also interesting in that it is well-supported by Rust and Tinygo, if C isn't your thing. I picked it because QMK supports it (and works great), but I'm actually planning to write the firmware in Go and ditch all the things that bug me about QMK. However the USB stack is not there and I dread writing it. I might pull a QMK and just have ChibiOS run my Go code ;)
rijoja 7y ago
I am very interested in USB / stenography / chorded typing http://tbf-rnd.life/ http://tbf-rnd.life/
- lmilcin 7y ago
  So the idea is to have a kind of blank slate, 40 to 60% ortholinear keyboard, that I will be able to experiment with. The base layout will be a small grid that will fit traditional (ie. dvorak;) layout but that I will also be able to change to my liking. I plan to be able to experiment with 3d printed keys to support traditional steno or maybe some other chorded method. I don't have much experience with steno so I want to keep my options open. Configuration and dictionaries will be provided on an SD card. The keyboard will be reversible (ie. the enclosure such that it will be possible to rotate entire mounting plate with the switches and PCB) to provide negative slope. And yes, it will be RGB because even if the keys are not marked it is still nice to be able to see individual keys in the dark for more complicated Emacs bindings...
  - brokenmachine 7y ago
    I currently use an ergodox running TMK with support for Plover. The layout is shown at https://gist.github.com/nelstrom/11232558 https://gist.github.com/nelstrom/11232558 If I were trying to do the project you are talking about, I would experiment with coming up with a way for a Raspberry Pi running Plover to act as a usb gadget to connect to your work PC. I'd think it'd also be quite simple to get Plover to output words over serial to an atmega32u4 that can act as a HID keyboard. So you have keyboard -> RPi with Plover -> Atmega32u4 -> Work PC. Then you don't have to come up with the chording/dictionary support yourself. In fact I've had a very similar project on the backburner myself. I'm planning to eventually end up with an nrf52840 combined with a RPi Zero W, so the entire device can act as a bluetooth keyboard with chording support for any PC or phone that can use a bluetooth keyboard. I haven't made a lot of progress so far however.
    - lmilcin 7y ago
      RPi Zero would be possible to put inside the keyboard (aside from its physical footprint) although it will limit where I can connect the keyboard (due to power drain). But then I will also have to forget about bluetooth and making it battery powered later because 200mA is I think the lowest I could get with this design with bluetooth enabled.

jrockway 7y ago

I don't think you need that for this. The keyboard firmware likely consists of three big chunks, the USB code, the matrix scan, and the processing of the matrix scan data into keystrokes. The USB stack is likely a peripheral on your microcontroller, which they have in theory already tested. The matrix scan will need to be tested on real hardware. The processing code should be abstracted enough from USB and matrix scanning that you can just compile it for your host machine and write tests the usual way (given matrix state x then y, output state should be foo). For final integration tests, you can use an additional microcontroller to be the key matrix. Instead of wiring up keyswitches, wire the microcontroller to the matrix pins, and have it accept commands over the serial port to set the matrix to a certain state. This way, you can do a full end-to-end test on your real hardware. The only place USB gadget emulation might be helpful is in writing the code that switches the keyboard from compatibility mode (6KRO) to the NKRO mode. It's been done a million times, though, so there is plenty of library code to just copy.

lmilcin 7y ago
First, this is going to be my first USB device. Second, I plan to put some more complex functionality. I intend it to be my last keyboard so I want to be able to map every key however I want (the whole point of having my own controller). I also want it to have built-in steno which is much more than just matrix scanning. While I could achieve all of that with OS driver and plover the sad reality is that I am unable to install my own software on my corporate PC and I would like to have consistent environment at my home and office.
- jrockway 7y ago
  All I'm saying is that the interesting part of the code will run just fine on your host machine, so you don't need any complicated tricks to develop and test it. Obviously in production it will run on the microcontroller, so you get the functionality you desire without OS drivers. Do keep in mind that /usr/share/dict/words is about 10x larger than the flash on microcontrollers. This is why most people do the steno conversion in software, not on the keyboard itself.
  - lmilcin 7y ago
    I plan to store configuration data on an SD card for convenience. If it wasn't clear yet it is my personal project, I don't plan to make product from it.
    - ihuman 7y ago
      If you're not designing your own microcontroller, you might want to check out the Proton-C. It has 248kB of usable flash memory, which could be enough to store a stenography-optimized word list in addition to the firmware. It was made to be flashed with the qmk keyboard firmware, but I don't think there's any requirement that you have to use qmk. https://qmk.fm/proton-c/ https://qmk.fm/proton-c/
      - jrockway 7y ago
        I used an STM32F103 for my last keyboard, and you can buy four for the price of a Proton C. I am still not sure why they chose the F3 series for the Proton C, as it doesn't seem to be a chip that's commonly used in the maker community. I am somewhat surprised they didn't bite the bullet and just port QMK to the nRF52 (since everyone wants bluetooth out of the box), actually. The F103 is also interesting in that it is well-supported by Rust and Tinygo, if C isn't your thing. I picked it because QMK supports it (and works great), but I'm actually planning to write the firmware in Go and ditch all the things that bug me about QMK. However the USB stack is not there and I dread writing it. I might pull a QMK and just have ChibiOS run my Go code ;)

rijoja 7y ago

I am very interested in USB / stenography / chorded typing http://tbf-rnd.life/ http://tbf-rnd.life/

lmilcin 7y ago
So the idea is to have a kind of blank slate, 40 to 60% ortholinear keyboard, that I will be able to experiment with. The base layout will be a small grid that will fit traditional (ie. dvorak;) layout but that I will also be able to change to my liking. I plan to be able to experiment with 3d printed keys to support traditional steno or maybe some other chorded method. I don't have much experience with steno so I want to keep my options open. Configuration and dictionaries will be provided on an SD card. The keyboard will be reversible (ie. the enclosure such that it will be possible to rotate entire mounting plate with the switches and PCB) to provide negative slope. And yes, it will be RGB because even if the keys are not marked it is still nice to be able to see individual keys in the dark for more complicated Emacs bindings...
- brokenmachine 7y ago
  I currently use an ergodox running TMK with support for Plover. The layout is shown at https://gist.github.com/nelstrom/11232558 https://gist.github.com/nelstrom/11232558 If I were trying to do the project you are talking about, I would experiment with coming up with a way for a Raspberry Pi running Plover to act as a usb gadget to connect to your work PC. I'd think it'd also be quite simple to get Plover to output words over serial to an atmega32u4 that can act as a HID keyboard. So you have keyboard -> RPi with Plover -> Atmega32u4 -> Work PC. Then you don't have to come up with the chording/dictionary support yourself. In fact I've had a very similar project on the backburner myself. I'm planning to eventually end up with an nrf52840 combined with a RPi Zero W, so the entire device can act as a bluetooth keyboard with chording support for any PC or phone that can use a bluetooth keyboard. I haven't made a lot of progress so far however.
  - lmilcin 7y ago
    RPi Zero would be possible to put inside the keyboard (aside from its physical footprint) although it will limit where I can connect the keyboard (due to power drain). But then I will also have to forget about bluetooth and making it battery powered later because 200mA is I think the lowest I could get with this design with bluetooth enabled.