[Feature Request] Split i2c transfer to RGB controllers in smaller blocks

[ebastler]

Feature Request Type

• [ ] Core functionality
• [ ] Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
• [X] Alteration (enhancement/optimization) of existing feature(s)
• [ ] New behavior

Description

At the moment the data for all LEDs on a board is sent in one go to an LED controller - in the case of a is31fl3733 that's 192 Byte. In my case (2 controllers), ~3000 Bit total. With 400 kHz fast I2C that takes ~8ms, during which the matrix scan is effectively stopped, as can be seen by the attached image. While I can personally not notice this, it could be noticeable for fast games, mostly rythm games. Quick note regarding the scope screens - this is measured on a shorted switch, so "high" equals this column not being polled, "low" equals the column being polled.

With i2cv1 defaults (e.g. on F411) this is even worse, as the driver defaults to 100 kHz -> ~40ms of idle - this is enough to lose keypresses during regular typing in my experience.

Now, my idea - the chips need their data sent in chunks of 16 Byte, which would take ~0.3ms. If we send the data in 16 Byte blocks, then do at least one matrix scan, and get back to the next 16 Byte, we should be able to maintain a continuous matrix scan rate of >1 kHz (on stm32/other ARM chips) while still sending out all the necessary data to the controllers - maybe at the cost of some minor glitches in animations, if the framebuffer changes mid-transmission, but I think that's a small price to pay. Maybe make it an optional feature that can be toggled in config.h.

This would be a good workaround for now, that does not require any core changes for a threaded parallel core, while still successfully removing the issue.

[drashna]

well, I know that the F4xx can be boosted to 400kHz for i2c. But that still has the issue.

This sounds like a good idea. It's just a matter of skill to implement it

[ebastler]

Yes, 400 kHz i2c on my board is tested and working, couldn't get 1 MHz to work, sadly. Maybe with 1k Pull-Up, but untested.

If I had the skill I'd implement and PR, sadly I don't - that's why I raised it here, hoping someone with sufficient coding skill and free time (the big issue for all hobby projects...) comes along.

Glad to hear my idea wasn't totally unreasonable!

[drashna]

I doubt it would help, but IIRC, the i2c split code is multi-transactional.

Also, long term, threads for stuff like this, would be the way to go. But that requires things like thread safety to be supported. That's probably a better goal, but definitely more invasive. (I've messed with it a bit, and it does work, but...)

[ebastler]

I guess threading the whole driver would also break on AVR, and only work for a "chibi only" possible future approach?

[drashna]

yup. Threading is a chibiOS specific feature

[github-actions[bot]]

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.

[github-actions[bot]]

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know. // [stale-action-closed]