Launch 3

[jackpot51]

Adds launch_3 board which is using the RP2040 controller

[13r0ck]

This is merging into the wrong branch. qmk-0.19.12 is the branch being used for the rebase (#34). rebuild-on-0.9.12 was just for testing. Sorry about that

[leviport]

Is this ready for reviews? I have a launch_3.1 PCB in a Heavy, and I've been using it for a few days without any issues.

[jackpot51]

I am ready if you are ready @leviport

[leviport]

Oh one more thing; should this be tested with supporting keyboard-configurator changes, or can that be handled after getting this firmware tested and merged?

[leviport]

Looks like "UNLOCKED" mode isn't working on this version. It seems to put it into bootloader mode instead, but I'm not sure it's flashing quite right when flashing with the make commands in this bootloader mode. Seems like I need to flash it twice for it to actually change the keymap to the one I specify in the make command.

Plugging in while holding Esc flashes the correct keymap and seems to reset the keyboard, but keypresses don't work until I unplug and re-plug after flashing.

[ids1024]

launch_heavy_3 seems to have issues like what #44 addressed. Although the specific layout is different. 86 and 87 appear twice.

[leviport]

The LED mapping correction is looking good, but I'm still seeing the weirdness I mentioned above with "UNLOCKED" mode.

While testing pop-os/keyboard-configurator#181, I discovered that it could change LEDs on launch_{heavy_}3, but my changes are lost when I unplug/replug the keyboard. I'm not sure if that's an issue with that PR or with this firmware, so I also wanted to mention it here: pop-os/keyboard-configurator#181 (comment)

[ids1024]

One thing I see is that launch_heavy_3 defines EEPROM_SIZE as 1024, like launch_1 and launch_2, but unlike launch_heavy_1, which is using 2048. Probably should be 2048? But not relevant to an issue that also applies to launch_3.

I don't think anything in the Configurator should cause that, if it works normally with other keyboards. I don't know how the EEPROM on this controller compares.

[leviport]

The launch_heavy_3 I've been using for several days seems to have just keeled over. I've tested it on multiple computers with multiple USB cables, and it doesn't show any signs of life or show up in lsusb. I'll dig into it tomorrow to see if I can learn anything more specific about what happened.

[jackpot51]

If you can give this a try again, that would help. The updated QMK from the thelio-io branch may improve things. Also, please try the other launch boards.

[g-berthiaume]

I think merging this PR would solve #45

[leviport]

UNLOCKED mode no longer puts the controller into bootloader mode, and it no longer takes more than one flash to see the keymap change.

The last remaining oddity I'm seeing is that after flashing with make and putting the controller into bootloader mode, the board resets and the LEDs come back on, but the keyboard is unresponsive until I unplug the keyboard and plug it back in. I'm not sure whether we want to consider this blocking or not.

I'll begin regression testing on other Launch models now.

[leviport]

Received a 3.2 prototype. So far the only problem I'm seeing is that LED settings that I set in the Configurator are dumped and reset to the default LED mode every time the keyboard is unplugged and plugged back in. Changes to the keymap itself seem to stick around just fine though.

It does still take an extra unplug/re-plug after flashing with the make command though, so I'm not sure how we feel about that.

[github-actions]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.

[github-actions]

Thank you for your contribution!
This pull request has been automatically marked as stale because it has not had activity in the last 45 days. It will be closed in 30 days if no further activity occurs. Please feel free to give a status update now, or re-open when it's ready.
For maintainers: Please label with bug, awaiting review, breaking_change, in progress, or on hold to prevent the issue from being re-flagged.