whitehatmiddleman / crkbd-pimoroni-trackball

crkbd with pimoroni trackball
MIT License
131 stars 11 forks source link

Left side keypresses not working #2

Closed douglance closed 3 years ago

douglance commented 3 years ago

I have assembled my crkbd-pimoroni-trackball to your precise specifications. It looks great. I'm excited to get it up and working, but I've hit a snag.

The left side's keys don't work when connected via TRRS. When plugged in directly (as the slave side), it types as if it were the Master side. But when connected via TRRS, the light comes on, but no keys work. I double checked the serial port to PCB connections and they all look good. I also double checked that I flashed the correct keymap.

The code is the same as the latest here. I didn't modify anything.

Any ideas?

whitehatmiddleman commented 3 years ago

Could please you tell me which controllers you have? If you have the same sparkfun usb-c pro micro, you may need to break the VCC 5v bridge on the back of the board, ONLY for the slave/left hand controller. I recommend loading your firmware, then breaking the bridge. You'll need to jump the 5V and RAW pins every time you want to load a new firmware.

VCC Note: This is the image of the master/right hand controller with 5v soldered for VCC. For the slave/left hand controller this needs to be open.

The sparkfun controller has a power safe feature, to ensure it runs on the necessary voltage level. I was going to reference the article that I read this, but I cannot locate it at the moment. Due to how the QMK firmware detects the slave controller, the slave/left hand controller needs to run on 3v. Breaking the VCC 5v bridge ensure that the controller can function as the slave.

I haven't tested soldering VCC to 3v on the slave/left hand controller.

douglance commented 3 years ago

I have the same exact controller (even same version). I haven't soldered either VCC on either board.

Are you saying I should be soldering the VCC-5V on the master board and leave the slave board unsoldered?

Or should I be soldering the VCC-3V on the slave board and VCC-5V on the master board?

whitehatmiddleman commented 3 years ago

No soldering needed. I mistakenly cut the bridge connection on both controllers.

You just need to break the small bridge on slave hand controller.

douglance commented 3 years ago

I see. I have broken that small bridge, and the left side still does not work. Also, now the master side doesn't work if they're connected via TRRS (but it does work if not connected).

Now that the bridge is broken, the controller on the slave side doesn't light up when powered only by TRRS.

The slave side still works as a master board if I plug it in via USB and bridge the 5V-VCC.

Do we need to use #define SPLIT_USB_DETECT somewhere?

It's the crkbd v2.1 if that makes a difference.

whitehatmiddleman commented 3 years ago

No code change needed. Mind if you can send pictures? Also have you used a multimeter to tone if the connections from the controller to the TRRS sockets are not broken, on both hands? Then also tone to make sure the TRRS connection between the hands are complete and correct?

I've made updates to the readme about the sparkfun controllers. There is a picture on how each controller should look. If you are still having problems with the sparkfun usb-c controllers, I recommend starting with the standard pro micro controllers.

I had to work my way from the standard pro micros to the sparkfun controllers and there was a learning curve between the controllers.

douglance commented 3 years ago

image

image

image

image

image

image

I tested using a multimeter and the slave side is receiving power. But no light is coming on.

Do you see any issues with the connections?

whitehatmiddleman commented 3 years ago

I just tested the code, no light will go on the slave, but both the left and right hands should be working. I was able to type on both hands accordingly.

Have you tested with a generic crkbd firmware to make sure the entire keyboard is working, without the trackball attached?

Can you send me a copy of the commands you use to compile and flash each firmware?

Also you must use my entire fork of the qmk firmware, I haven't had time to test any of the updated releases. There might be issues with the transport, if using any of the updated qmk firmware releases.

douglance commented 3 years ago

Have you tested with a generic crkbd firmware to make sure the entire keyboard is working, without the trackball attached?

I just tested and everything seems to be working as we expect (though with the sides flipped because the voltage bridge was broken on the left).

Can you send me a copy of the commands you use to compile and flash each firmware?

I used the commands from the README.md, copy and pasted in.

I used your fork running in a MSYS application from the QMK releases, which I was using because I'm on Windows 10. I also tried installing with the QMK Toolbox, with the same result. Is there a better way to do it on Windows? Which OS are you using?

whitehatmiddleman commented 3 years ago

I use linux, but will be willing to test in a windows environment. I don't have time at the moment, but will need to spin up a windows vm.

One thing you can test, prior to me spinning up and testing in a windows environment. 1) Delete the transport.c and transport.h files in both the left and right hand folders. These were custom transport files for someone that wanted oled enabled.

2) In both rules.mk files make sure that oled is disabled

OLED_DRIVER_ENABLE  = no

3) Then in both the rules.mk files delete the following lines:

ifeq ($(strip $(SPLIT_KEYBOARD)), yes)
    ifneq ($(strip $(SPLIT_TRANSPORT)), custom)
        SPLIT_TRANSPORT = custom
        QUANTUM_LIB_SRC += transport.c serial.c i2c_master.c i2c_slave.c
        OPT_DEFS += -DCUSTOM_TRANSPORT
        # Unused functions are pruned away, which is why we can add multiple drivers here without bloat.
        ifeq ($(PLATFORM),AVR)
            ifneq ($(NO_I2C),yes)
                QUANTUM_LIB_SRC += i2c_master.c \
                                   i2c_slave.c
            endif
        endif

        SERIAL_DRIVER ?= bitbang
        OPT_DEFS += -DSERIAL_DRIVER_$(strip $(shell echo $(SERIAL_DRIVER) | tr '[:lower:]' '[:upper:]'))
        ifeq ($(strip $(SERIAL_DRIVER)), bitbang)
            QUANTUM_LIB_SRC += serial.c
        else
            QUANTUM_LIB_SRC += serial_$(strip $(SERIAL_DRIVER)).c
        endif
    endif
endif

ifeq ($(PROMICRO), yes)
  BOOTLOADER = caterina
else ifeq ($(ELITEC), yes)
  BOOTLOADER = atmel-dfu
endif

4) Run the clean and compile commands:

qmk clean
qmk compile -kb crkbd/rev1/common -km greyhatmiddleman_trackball_left
qmk compile -kb crkbd/rev1/common -km greyhatmiddleman_trackball_right

5) If no issues with the compile then flash:

qmk flash -kb crkbd/rev1/common -km greyhatmiddleman_trackball_left
qmk flash -kb crkbd/rev1/common -km greyhatmiddleman_trackball_right

I hope this works for you.

douglance commented 3 years ago

Success! With that change, the keyboard now works as expected.

Thanks for your help!

whitehatmiddleman commented 3 years ago

Awesome, I'm glad it works.