Qmk_firmware: Split Keyboard, Troubleshooting No Input from Slave

Created on 8 Oct 2019  路  5Comments  路  Source: qmk/qmk_firmware

I hand wired a small split keyboard to familiarize myself with setting up the QMK firmware for custom split keyboards. I used the util/new_keyboard.sh script to start, then modified it using the Split Keyboard page in the QMK docs and the Let's Split files for reference. My current code can be found here. It compiles without issue.

Currently, when the halves are wired as a master and slave, the master functions as expected, but there is no input from the slave.

Each half is four columns by three rows and uses a Teensy 2.0 as a controller. Each half works as expected when the USB is plugged in directly, correctly differentiating between the left and right halves, so the SPLIT_HAND_PIN at least appears to be working. When connected as a master and slave, the LEDs on both controllers are on, and I measure 5V across the VCC and GND pins of both controllers with a multimeter. I also confirmed continuity between the D0 pins of both controllers with a multimeter.

I also tried setting #define SELECT_SOFT_SERIAL_SPEED to the different values and added #define MASTER_RIGHT in my config.h, neither of which resolved the issue.

I'm not sure what my next step should be to troubleshoot this. Any insight would be appreciated!

help wanted question solved

Most helpful comment

Teensy 2.0 have a known hardware issue that means vbus detection (used for master/slave selection) does not work.

See https://github.com/qmk/qmk_firmware/blob/master/keyboards/handwired/splittest/teensy_2/teensy_2.c#L3-L14 for a short term workaround using SPLIT_HAND_PIN and #6424 for a longer term solution.

All 5 comments

I consider @drashna our resident expert on split keyboard issues.

Teensy 2.0 have a known hardware issue that means vbus detection (used for master/slave selection) does not work.

See https://github.com/qmk/qmk_firmware/blob/master/keyboards/handwired/splittest/teensy_2/teensy_2.c#L3-L14 for a short term workaround using SPLIT_HAND_PIN and #6424 for a longer term solution.

Thank you for the guidance. I put function from the short term workaround in split_layout_test/split_layout_test.c and then moved it to split_layout_test/keymaps/default/keymap.c (which already has the #include QMK_KEYBOARD_H so I'm now thinking this is where it's supposed to go) I then also added #define NO_USB_STARTUP_CHECK to split_layout_test/keymaps/default/keymap.c because I noticed it in the splittest code and it appeared relevant. In all cases, the firmware compiled without issue, but upon loading it onto the controllers, no input is received from either the master or slave.

I then decided to test if I could get the splittest code working, thinking it might be simpler to work forwards from there. I successfully compiled the splittest code unmodified (after making sure I had the latest master), loaded it onto the controllers, and manually shorted F5 and F7. It didn't appear to be resetting as expected, so I changed the layout to {KC_A, KC_B}, recompiled, and confirmed that no input is sent when the pins are shorted. I'm compiling using the command make handwired/splittest/teensy_2:default in the root directory of the repo. Am I missing something?

Have you wired up the SPLIT_HAND_PIN on both halves? Its a requirement within that block of code in keyboards/handwired/splittest/teensy_2/teensy_2.c.

Figured it out! I had to add #define MASTER_RIGHT, since I have the USB plugged into the right controller. After that, the unmodified code worked, so I re-added the line to my test code, and it worked as expected!

Thank you very much for your help; I really appreciate it!

Was this page helpful?
0 / 5 - 0 ratings