-
-
Notifications
You must be signed in to change notification settings - Fork 39.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate keyboards using uGFX to LED_MATRIX #9657
Conversation
I suspect that it will need more changes to get this working properly (read: 100%), but it looks like a good start, at least! |
Given that it's changing a bunch of things at once, it'll need to go to |
Definitely. For now, I'm waiting for the i2c support to be merged before doing more work on this. I partly put it up here in case I forget, or someone else wants to continue. :) |
Looks like there is an issue with the whitefox board:
|
Yeah, I haven't touched the Whitefox yet, but I have changed some common code in quantum/visualizer, so it's entirely expected that it doesn't compile yet. ;) Making this posting as a PR might have been jumping the gun a bit, it might have been better to make a normal issue and just refer to my branch... |
The I2C PR has been merged now, so this should be good to progress. |
1d4c0cd
to
65c27a3
Compare
a1b96ba
to
3430907
Compare
Thank you for your contribution! |
Yeah, that's an issue with the rest of the ISSI drivers too. It'd probably be best to update them all in one go, this will involve modifying some keyboard-level code as some of them also have SDB hooked up to a GPIO and needed a similar patch:
|
@fauxpark Do you intend to work on that, or what is the plan? EDIT: In the meantime, I'll check if setting SDB in |
Yup, but it might be a short while as technically develop is now locked to new PRs (apart from urgent bugfixes, of course). |
067a3bf
to
e8b3fac
Compare
Updated to be based on #12864 (not including it, but can't be built without it), and moved the IS31FL3731 SDB stuff to |
Completely untested, but it at least compiles, and is based on similar (tested) work on Ergodox Infinity.
e8b3fac
to
37c22b1
Compare
#ifdef LED_MATRIX_ENABLE | ||
/* | ||
* Since K20x is stuck with a 32 byte EEPROM (see tmk_core/common/chibios/eeprom_teensy.c), | ||
* and neither led_matrix_eeconfig.speed or .flags fit in this boundary, just force their values to default on boot. | ||
*/ | ||
# if !defined(LED_MATRIX_STARTUP_SPD) | ||
# define LED_MATRIX_STARTUP_SPD UINT8_MAX / 2 | ||
# endif | ||
led_matrix_set_speed(LED_MATRIX_STARTUP_SPD), | ||
led_matrix_set_flags(LED_FLAG_ALL); | ||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally, I would like to see if something like #12947 for the K20x fixes this, before merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as my research has lead me to understand, you basically need to wipe the entire MCU and reflash the bootloader to change the "EEPROM" size. 🙁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then I'm not sure how else this can be solved if we want VIA support (and room for future core settings)... perhaps we should just fall back to the transient EEPROM implementation, that will eliminate the need for this code at least.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've done some more investigation and realized that the partitioning code in eeprom_teensy.c isn't actually run on an already partitioned MCU. When I tried increasing EEPROM_SIZE
locally, I guess my board therefore just crashed due to the firmware configuration not matching the hardware configuration.
The documentation is a bit fuzzy on the subject, but NXP Support claimed in their forum that the relevant flash and registers need to be in "an erased state" before running the PGMPART command. I'm a bit hesitant to try since I don't want to risk bricking my main keyboard, but it might be possible to try skipping the FTFL->FCNFG & FTFL_FCNFG_RAMRDY
if statement and that way force the PGMPART command to be run. Due to what NXP Support said in the forums, my guess is that it won't work.
Edit: Forgot to mention that I have verified that the current config on my board MCU matches the setup that would be created by eeprom_initialize
for a 32 byte EEPROM. Skimming the bootloader code made me worried that it expected a different partitioning, but that doesn't seem to be the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've done some more investigation and realized that the partitioning code in eeprom_teensy.c isn't actually run on an already partitioned MCU.
As far as I can tell, the original Kiibohd firmware doesn't do any partitioning (so there is no persistent storage, apparently). So what probably happens when switching from Kiibohd to QMK is the eeprom_initialize()
function gets called and sets up the FlexNVM for a 32-byte EEPROM.
This code seems to be mainly intended for actual Teensys, which have an external chip doing the bootloading, and according to the PJRC forum thread mentioned in the other PR, it sends the SETRAM
command to turn the EEPROM functionality off. It also likely does a mass erase first.
And yeah, the manual says:
After clearing CCIF to launch the Program Partition command, the flash memory module first verifies that the EEPROM Data Size Code and FlexNVM Partition Code in the data flash IFR are erased.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. It might even be possible to switch the FlexRAM function over from EEPROM to RAM when an incompatible EESIZE is detected in SIM->FCFG1
, in effect making the EEPROM driver work using the same code, but behaving transient. I'm gonna do some experimenting. 👨🔬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also realized that the "crash" during boot after increasing EEPROM_SIZE
was just an infinite loop in flexram_wait()
due to the EEERDY
flag never being set after an out-of-bounds write. Just making sure the FlexRAM isn't written to outside the partitioned EEPROM size is enough to make the board boot properly. In other words, the entire if (eeprom_size < EEPROM_SIZE) { ... }
block in my prototype can be removed (but it might be desired).
If you feel that this would be a valid solution to the problem, I can make a PR of this after #12947 has been merged (would conflict heavily otherwise).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An issue detailing all of these findings may be a good idea, rather than having it all in this tangentially-related PR discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point... I'll get one started.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last thing, then I think I can merge this :)
Fixed. Was considering adding a check of |
Thanks for all your work! |
Migrate Input Club keyboards (Ergodox Infinity and Whitefox) away from uGFX for keyboard backlight.
Description
Ergodox Infinity and Whitefox use uGFX to control their keyboard backlight. Because of licensing issues, it's desirable to move away from uGFX (see #5268). The chip in question (IS31FL3731C) already had a working driver for use with LED Matrix (drivers/issi/is31fl3731-simple.c).
Since uGFX is still compiled for the LCD display in Ergodox Infinity, and it caused some naming conflicts, I had to rename the
point_t
type of LED/RGB Matrix.led_point_t
seemed fitting. (This is in conflict with two lines in #12651, but is an easy fix.)Types of Changes
Checklist