[Keyboard] add aki27/cocot46plus

[markstos]

Adds the cocot46plus keyboard by aki27

This is the RP2040 variant.

I've tried to convert a maximal amount from the old config.h and rules.mk to keyboard.json.

I don't regularly work with QMK source code so there is likely room for improvement here.

Types of Changes

• Keyboard (addition or update)

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[markstos]

Thanks for the prompt and helpful feedback. I've applied a number of suggestions. I currently need to pivot to $job but have started getting some build failures for the firmware.

I can investigate more later, but suggestions welcome!

 | /usr/bin/avr-ld: /tmp/ccAEZNvn.ltrans0.ltrans.o: in function `.Loc.4948':
 | /home/mark/git/qmk_firmware/quantum/keyboard.c:420:(.text.startup.main+0xe4): undefined reference to `matrix_init'
 | /usr/bin/avr-ld: /tmp/ccAEZNvn.ltrans0.ltrans.o: in function `.Loc.5015':
 | /home/mark/git/qmk_firmware/quantum/bootmagic/bootmagic.c:65:(.text.startup.main+0x1fa): undefined reference to `matrix_scan'
 | /usr/bin/avr-ld: /home/mark/git/qmk_firmware/quantum/bootmagic/bootmagic.c:67:(.text.startup.main+0x210): undefined reference to `matrix_scan'
 | /usr/bin/avr-ld: /tmp/ccAEZNvn.ltrans0.ltrans.o: in function `.Loc.5033':
 | /home/mark/git/qmk_firmware/quantum/bootmagic/bootmagic.c:56:(.text.startup.main+0x216): undefined reference to `matrix_get_row'
 | /usr/bin/avr-ld: /tmp/ccAEZNvn.ltrans0.ltrans.o: in function `.Loc.5195':
 | /home/mark/git/qmk_firmware/quantum/keyboard.c:538:(.text.startup.main+0x49e): undefined reference to `matrix_scan'
 | /usr/bin/avr-ld: /tmp/ccAEZNvn.ltrans0.ltrans.o:/home/mark/git/qmk_firmware/quantum/keyboard.c:541:(.text.startup.main+0x4b6): undefined reference to `matrix_get_row'
 | /usr/bin/avr-ld: /tmp/ccAEZNvn.ltrans0.ltrans.o:/home/mark/git/qmk_firmware/quantum/keyboard.c:553:(.text.startup.main+0x4ce): undefined reference to `matrix_print'
 | /usr/bin/avr-ld: /tmp/ccAEZNvn.ltrans0.ltrans.o:/home/mark/git/qmk_firmware/quantum/keyboard.c:559:(.text.startup.main+0x4d6): undefined reference to `matrix_get_row'
 | /usr/bin/avr-ld: /tmp/ccAEZNvn.ltrans0.ltrans.o: in function `.Loc.5288':
 | /home/mark/git/qmk_firmware/platforms/suspend.c:45:(.text.startup.main+0x59e): undefined reference to `matrix_scan'
 | /usr/bin/avr-ld: /home/mark/git/qmk_firmware/platforms/suspend.c:48:(.text.startup.main+0x5a6): undefined reference to `matrix_get_row'
 | collect2: error: ld returned 1 exit status

[markstos]

I believe I've addressed the outstanding feedback and did a test flash of the firmware to the keyboard, but afterwards only the left halve and the pointing device register any key events. I'll work on reverting different parts of the changes until I get back to a working state. I expect it was changes related to the matrix.

[markstos]

Thanks for the help again. I've addressed the most recent suggestions and now the right half of the keyboard is working again-- 🚀-- but I noticed the OLED was no longer working. So I added back oled:true, but now the screen displays a random pattern of dots with "506" in the upper left corner. I'll go back through and revert the OLED-related refinements until it works again.

[markstos]

I understand now what went wrong in the OLED refactoring. There were two issues with the attempt to get rid of snprint. The first was the number of characters printed didn't precisely match, the second was that the old code used an signed int to display an angle of "-30", but the new function, get_u8_str() expects an unsigned int.

This keyboard is challenged to have all of its features enabled on a Pro Micro on modern QMK. I've ordered the parts to switch mine over to an RP2040 with more storage. Then we could use snprint without complications.

I'll convert this a draft PR and re-open once I have something confirmed to work with the RP2040.

[markstos]

I now have this keyboard working with RP2040 and am targeting that instead of Pro Micro. I was able to get an get an alternative to sprintf working, so I reverted to using that, which there is plenty of room for on the RP2040.

[markstos]

I found the documentation of the GPX notation: https://docs.qmk.fm/platformdev_rp2040#pin-nomenclature

And I found the source code of the converter, but it doesn't show what the mappings to GPx notation are, but some other notation that ends in "U". (Below).

I found the pin-out for the Pro Micro: https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide/hardware-overview-pro-micro

But this doesn't match either the left or right-hand side of what's in the converter file.

I'm stuck for now.

// Left side (front)
#define D3 0U
#define D2 1U
//      GND
//      GND
#define D1 2U
#define D0 3U
#define D4 4U
#define C6 5U
#define D7 6U
#define E6 7U
#define B4 8U
#define B5 9U

// Right side (front)
//      RAW
//      GND
//      RESET
//      VCC
#define F4 29U
#define F5 28U
#define F6 27U
#define F7 26U
#define B1 22U
#define B3 20U
#define B2 23U
#define B6 21U

// LEDs (Mapped to QT connector to avoid collisions with button/neopixel)
#define D5 17U
#define B0 16U

[yudai-nkt]

I tried this PR yesterday, and the following commit seems to do the job mentioned in the review:

yudai-nkt/qmk_firmware@8ec47db

However, this introduces another error:

$ qmk compile -kb aki27/cocot46plus -km default
Ψ Compiling keymap with gmake -r -R -f builddefs/build_keyboard.mk -s KEYBOARD=aki27/cocot46plus KEYMAP=default KEYBOARD_FILESAFE=aki27_cocot46plus TARGET=aki27_cocot46plus_default INTERMEDIATE_OUTPUT=.build/obj_aki27_cocot46plus_default VERBOSE=false COLOR=true SILENT=false QMK_BIN="qmk"

[snip]

platforms/chibios/drivers/i2c_master.c: In function 'i2c_init':
././platforms/chibios/boards/QMK_PM2040/configs/config.h:17:26: error: 'D0' undeclared (first use in this function)
   17 | #    define I2C1_SCL_PIN D0
      |                          ^~

[snip]

 [ERRORS]
 |
 |
 |
gmake: *** [builddefs/common_rules.mk:373: .build/obj_aki27_cocot46plus_default/i2c_master.o] Error 1

The following patch fixes the above error and builds a functioning firmware, but I doubt this is an appropriate fix as it involves modification outside the keyboard directory.

diff --git a/platforms/chibios/boards/QMK_PM2040/configs/config.h b/platforms/chibios/boards/QMK_PM2040/configs/config.h
index f8b46b7fe4..87554f6b83 100644
--- a/platforms/chibios/boards/QMK_PM2040/configs/config.h
+++ b/platforms/chibios/boards/QMK_PM2040/configs/config.h
@@ -11,10 +11,10 @@
 #    define I2C_DRIVER I2CD1
 #endif
 #ifndef I2C1_SDA_PIN
-#    define I2C1_SDA_PIN D1
+#    define I2C1_SDA_PIN GP2
 #endif
 #ifndef I2C1_SCL_PIN
-#    define I2C1_SCL_PIN D0
+#    define I2C1_SCL_PIN GP3
 #endif

I asked a similar question at Discord but got no response so far.

[fauxpark]

The U suffixed values are an intermediate step. Just look at the pinout on the hardware you have...

[markstos]

The encoder is working now, but the lights are now not.

I suspect the pin number for the ws2812 driver is not right.

[markstos]

@yudai-nkt Are the lights working you with the latest changes on this branch? Could you check the pins for those?

[yudai-nkt]

@markstos I've just sent a PR against your fork that fixes my silly mistake. Please take a look at markstos#1 when you have time!

[markstos]

All feedback is now been addressed and all features of the firmware have been tested to work as intended.

Thanks to everyone for the collaboration.

[markstos]

awaiting review

[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.

[markstos]

Latest feedback has been addressed.

[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.

[markstos]

Feedback has been addressed.

[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.

[markstos]

This work has been completed and approved by one reviewer.

That said, in recent testing, I noticed that the keyboard immediately wakes up the host when suspending the host. I've tried suspending every feature but the keyboard during suspend, but it still happens.

Maybe it's related to the custom Japanese duplex matrix scanning? The irony is with the new RP2040 chip being used with the board, a custom scanning matrix is not required because there's no longer a shortage of GPIO pins, but it seems that perhaps because of the way the PCB is wired, custom scanning is required in the firmware. (I'm not expert here). I can try to do some more debugging by seeing if I can log the raw events that the keyboard is emitting after the host initiates suspend to see what the issue is.

[markstos]

@fauxpark @zvecr @waffle87 Your feedback has been addressed.