IS31FL3733 driver hardcoded to use STM32 mcu

[sonnius]

Hello,

I'm trying to add LED support to the k_type and when I add the IS31FL3733 driver it pulls in 'drivers/arm/i2c_master.c', this library is only valid for STM32 #processors.

Is there any way to use the IS31FL3733 with different processors?

The k_type is using k20x mcu

#2964

@yiancar
@drashna

[drashna]

Dead giveaway:

qmk_firmware/drivers/arm/i2c_master.c

Line 18 in 07d317a

/* This library is only valid for STM32 processors.

Basically, you'd need to find out what is the correct values, and .... maybe ifdef this stuff:

qmk_firmware/drivers/arm/i2c_master.c

Lines 37 to 39 in 07d317a

	STM32_TIMINGR_PRESC(15U) |
	STM32_TIMINGR_SCLDEL(4U) | STM32_TIMINGR_SDADEL(2U) |
	STM32_TIMINGR_SCLH(15U) | STM32_TIMINGR_SCLL(21U),

qmk_firmware/drivers/arm/i2c_master.c

Lines 49 to 50 in 07d317a

	palSetPadMode(GPIOB, 6, PAL_MODE_ALTERNATE(4) | PAL_STM32_OTYPE_OPENDRAIN | PAL_STM32_PUPDR_PULLUP);
	palSetPadMode(GPIOB, 7, PAL_MODE_ALTERNATE(4) | PAL_STM32_OTYPE_OPENDRAIN | PAL_STM32_PUPDR_PULLUP);

edited for permalinks – noroadsleft

[yiancar]

Yep you can ifdef an i2c driver for k20x mcus I dont exactly remember which makefile is the correct one to do so but you can follow the flow and see where files get pulled in.

[dmgm]

This seems to be the only open issue for the k_type.
I would prefer to use qmk, because I can program CapsLock to be Ctrl and Escape on tap.
Unfortunately I dont seem to have any option for backlight, which I miss. I don't care if I cant have rainbows and fingerprints, I'd settle for backlight for might shine through keycaps.

Anyone working on this?

[drashna]

The controller driver was fixed. Now somebody just needs to convert the K_Type to the LED Matrix feature.

https://docs.qmk.fm/#/feature_led_matrix

[gogades]

@drashna since the stock k-type firmware is also open source, I'm guessing the needed information could be found in https://github.com/kiibohd/controller ... I don't really know (yet) what to look for but I'll poke around.

[drashna]

I think so, yeah

[peterctl]

I tried to do some work on this but I have no experience with embedded development and so it failed. I did a fork with my progress under https://github.com/pottar/qmk_firmware if anyone wants to take a look at it and help me get it working.

What I could find is that the i2c driver in drivers/arm/i2c_master.c expects that only a single i2c driver will be used, with different i2c slave addresses for each is31 chip. However, the K-Type keyboard has 2 i2c buses and each is31 chip uses a different bus, all with the same i2c slave address. My fork has a modified version of the i2c_master.c file inside the keyboards/k_type folder but, again, that didn't work as I don't know much about embedded development.

[yiancar]

drivers/arm/i2c_master.c has nothing to do with how many slaves you have. It can address all of them.

both is31fl3733.c and is31fl3731.c are capable of being multidriver.

As said above the only thing one should need to do here is map the led matrix correctly to the way the driver files expect it.

[peterctl]

It can address all of them as long as they are in the same bus. The K-Type uses a different bus for each ic31 chip. If you look at the signature for i2c_* funcions in i2c_master.c, they take uint8_t addr as a parameter and only use I2CD1 as the hardcoded driver.

At least this is my understanding from reading the code, but again I have little experience with embedded development.

[yiancar]

AHHH I see, I didnt have a look on the schematic :)

[dmgm]

Is there still interest in this? I have three keyboards, 2 use qmk and one, the k-type relies on the input club configurator.
While I'll take the qmk functionality, it would be nice to at least be able to use the LED backlights.

[gogades]

I'm definitely still interested. I took a crack at it but couldn't figure it out: the k-type uses ChibiOS so I couldn't figure out how to do it by looking at the Massdrop CTRL qmk code and the input club kiiboohd firmware.

[peterctl]

Still interested too, I also took a shot at it but I have zero experience with embedded development so I was never able to figure out why it wasnt working. My code is still in my cloned repo so feel free to take a look at it and see if you can come up with why it doesnt work. I would love to keep attempting but I'm a DevOps/SRE kinda guy and I have no idea how to do embedded.

[sonnius]

I'm in the same boat, not enough knowledge and not enough time..

[fauxpark]

It turns out the K-Type has two 3733s, which is not usually a problem, except that they are on different I2C buses, which i2c_master currently does not support.
I have a PR open to clean up this board a bit. There is an experimental keymap with RGB matrix enabled: #9864
EDIT: whoops, that was already mentioned...

[Andrew-Fahmy]

I was able to take the existing drivers and make changes so that they support multiple i2c busses. I have opened up a PR #11551 that has those changes if anyone would like to try it on their k-type.

[gogades]

@Andrew-Fahmy I tried it on my K-Type. I was able to load it and the keyboard seems to work ok, but I was unable to trigger any LED effect - they're all off. Idea? Thanks.

[Andrew-Fahmy]

@gogades What keymap are you using? Currently only my keymap (andrew-fahmy) and the rgb keymap have RGB support. It is also possible the lights are toggled off, you can toggle them with fn+print, and make sure the brightness is up (fn+pgup).

[dmgm]

I was able to take the existing drivers and make changes so that they support multiple i2c busses. I have opened up a PR #11551 that has those changes if anyone would like to try it on their k-type.

I've tried on my k_type which was previously running qmk. Well done. It works fine and it's lovely to have some LED prettiness back to compliment the qmk functionality. I just turn it on with Fn Print, and selected a mode where random keys light up.

Two things I have questions about;

1. Does RGB also control the lighting strip around the base? I've not found a mode that uses those leds. It would be nice to have a white or blue light ring.
2. Could the changes have affected my computer's ability to recognise the usb keyboard? I use a usb switch to share the computer and mouse between 4 computers. Was working fine, now mouse always works but sometimes I need to unplug and replug the k_type. This is new behavior since I flashed a new firmware image with the rgb changes. Happy to file a bug report but I can't reproduce it reliably, maybe it's just coincidence.

[Andrew-Fahmy]

@dmgm Glad you got them to work! You can look here for more of the shortcuts that change the lighting.

1. The lighting around the base does work, make sure you have the latest changes pulled. They should work with whatever lighting animation, but you could probably manually set the colors if you dig into the code. (The LEDs around the base are numbers 88-119)
2. Nothing was change other then the lighting, so the only thing I could think of would be that the increase in power needed to drive the LEDs might cause some weird behavior with the usb switch? I haven't run into this issue myself.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.
For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

[tzarc]

Closing due to inactivity.