Let's Split with Teensy 2.0

[nachie]

I am fairly new here and new to mechanical keyboards as well. After lurking for a few months, I decided to finally build a custom board. I am trying to build a hand wired Let's Split keyboard. I have some spare Teensy 2.0 boards that I would like to use instead of the pro micros. I thought that the support from QMK should just work since its the same MCU. However, I am having issues getting I2C to work on this. I am using this (https://github.com/qmk/qmk_firmware/tree/master/keyboards/lets_split) without any modifications other than changing the bootloader size to 512 to match the teensy. The connected half works, but the other half never works. I tried adding some prints and it seems that the i2c_transaction keeps error'ing out.

So, my question is this. Has anyone used teensy 2.0 to build a let's split? Anything obvious that I might be missing?

[mrjoechin]

Nachie, any luck with a teensy?

[climbalima]

The i2c pins are on a different spot on the teensy.

Sent from my Pixel using Tapatalk

[spindle]

The only code that would be affected that I can think of is the USB detection code. The let's split code detects the presence of the USB port by checking the UVCC pin of the ATmega32u4. Compare the schematics of the two boards:


On the Teensy, UVCC is directly connected to 5V from USB and the 5V supply. So when it is powerd by the TRRS cable connected to VCC pin of the Teensy, the Teensy will see 5V on UVCC. So the let's split code will think that the USB cable is connected as UVCC == 5V.


(Ignore annotation) On the pro micro, the UVCC supply is separated by a diode. This means that the ATmega32u4 will only see voltage on UVCC pin when the micro USB cable is plugged in. If it is powered by TRRS jack which is connected to VCC, UVCC is disconnected because of the diode, so the controller will know that it is not being powered by USB. (Note: that the jumper SJ1 on the pro micro has to be left open for this to work)


An easy way to work around this would be to force one side to always be the slave and one side to be the master. To do this you would 
change this function to always return true for the master, and always return false for the slave.  You would have to compile two different versions of the code. Of course if you use this method, the side you designate as the master must be the side connected with the USB cable.

If you want to be able to connect the USB cable to either device, you will have to implement a more advanced method. When the device is powerd on, you would initialize the USB controller and wait to see if the USB controller is able to communicate with the host. If we observe any communication, then run the master code. If no communications are observed after a short period of time, then run the slave code. If you want to try this method, you could probably [hook into this function](https://github.com/qmk/qmk_firmware/blob/master/tmk_core/protocol/lufa/lufa.c#L331).

[nachie]

On the Teensy, UVCC is directly connected to 5V from USB and the 5V supply. So when it is powerd by the TRRS cable connected to VCC pin of the Teensy, the Teensy will see 5V on UVCC. So the let's split code will think that the USB cable is connected as UVCC == 5V.

I never understood why it wouldn't work, but this explains it. I did ask on reddit as well. My eventual solution was as the earlier post mentioned, have the slave side always return has_usb() as false. It works, but the master side is the one that should be plugged in to the computer always.