Update the Speedo firmware for v3.0

[pcewing]

Description

I have recently released a new major version of the CozyKeys Speedo which was an overhaul of the entire design. This PR implements the firmware to support the new version.

The original firmware was implemented years ago and a lot has changed in QMK since then so there is a fair amount of cleanup in this PR, some of which was recommended by the PR Checklist document.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

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

ChangeLog

• Existing firmware for the Speedo was moved into the cozykeys/v2 directory

[pcewing]

Hey @fauxpark, thanks for the review! I agree with all of the suggestions except for one and committed those changes.

Replied directly to the one suggestion I'd prefer not to make.

[noroadsleft]

@pcewing Do you know how many of the previous version boards are in the wild? The changes you've made here break support for that version.

[pcewing]

@noroadsleft Unfortunately I don't know the answer to that. I never created a PCB for the previous version or directly sold the case parts, so if anyone had a copy they would have had to get their own case from a laser cutter. I never saw anyone post pictures of their own but that obviously doesn't mean no one ever built one.

I'd be happy to leave the existing firmware in tact and maybe restructure the directory tree to look something like:

./keyboards
 |_ cozykeys
     |_ speedo_v2
     |_ speedo_v3

Similar to how keebio is set up. I have another keyboard I eventually need to merge the firmware for as well so this would help keep my things organized nicely. Thoughts?

[noroadsleft]

@pcewing If the layout of the board isn't going to change in a future revision, I'd suggest something slightly different:

[-] keyboards
    [-] cozykeys
        [-] speedo
            [+] keymaps
            [+] v2
            [+] v3
        [+] bloomer

If the layout of the board doesn't change, then setting the directories up this way makes the keymaps revision-agnostic – the Planck does this, for example – so anyone who may have the V2 and wants to upgrade can use their existing V2 keymap and compile it with make cozykeys/speedo/v3:keymap

[pcewing]

That depends what you mean by layout. From v2 -> v3 the pin mappings changed due to using a more modern MCU on the PCB and coming up with a schematic that makes more sense. The key locations also changed somewhat; however, the number of keys is identical and ideally a v2 keymap would be fine on v3 and vice versa.

I don't expect anymore changes in the number of keys or where they are placed; however, I could see the pin mappings changing if I ever use a different MCU on a future version.

(For the bloomer, v2 and v3 are actually very different but I'll address that when I eventually get a PR set up for those.)

[pcewing]

@noroadsleft I looked at how the Planck and iris are set up and it seems like anything in config.h and <keyboard>.h can differ per version. If that's the case, then I completely agree with your suggestion because the keymaps should work in either case.

I'll get the PR updated with that change, thanks for the suggestion!

[pcewing]

Hey @noroadsleft, after I started implementing this, I noticed the info.json has to be shared by all versions in ./keyboards/cozykeys/speedo; however, the layout is slightly different between v2 and v3:

• v2
• v3

I've seen cases where other keyboards have multiple layouts in their info.json, for example: https://github.com/qmk/qmk_firmware/blob/master/keyboards/choc_taro/info.json

Would it make sense in the speedo's info.json to do something like:

{
    ...
    "layouts": {
        "LAYOUT_v3": {
            "layout": [
                ...
            ]
        },
        "LAYOUT_v2": {
            "layout": [
                ...
            ]
        }
    }
}

I think the downside is that in keymap.c users would have to use LAYOUT_v2 / LAYOUT_v3 macros which sort of defeats the whole purpose of sharing keymaps between the two versions. What would you suggest?

Sorry for all the questions, just trying to figure out the right way to go about this.

[noroadsleft]

You can actually do an info.json file for each revision independently. The Clueboard codebase actually does a vendor-level info.json in keyboards/clueboard/ and then each board gets an info.json that's specific to that board. The keyboard-level files inherit properties that are set at levels above. So you could do:

[-] keyboards
    [-] cozykeys
        [-] speedo
            [+] v2     <--- the existing codebase
                [+] keymaps
                    info.json
            [+] v3     <--- the codebase for v3.0
                [+] keymaps
                    info.json
        [+] bloomer

This does however make it so that keymaps are specific to either v2 or v3, but in this case I think that would be unavoidable.

[pcewing]

Yea, I think that makes the most sense. Technically speaking, a keymap could work between v2 and v3 but I think it just needlessly complicates things. After looking at the ErgoDash, it also does what you just described having a separate directory for mini and rev1, each with it's own info.json and keymaps.

That's the direction I'm going to go. Have had a busy week but should get that done and the PR updated over the weekend. :)

[pcewing]

I've restored the files for the v2 and gave them the same cleanup treatment as
the new ones for the v3. I also updated the folder structure so now everything
is under:

keyboards
|_  cozykeys
    |_  speedo
        |_  v2
        |_  v3

I retested building and flashing and also tested that the info.json files
load properly in the QMK configurator.

[drashna]

This moves around the folder location for the keyboard, and should go through the breaking changes process, and be retargeted to develop.

[pcewing]

@drashna I've re-targeted the PR to the develop branch and added a ChangeLog section to the PR description. Let me know if there is anything else I need to do to address the breaking change process.

I see that the develop branch is closing to new PRs on October 31 and I'd love to get this merged before then if possible so the firmware for the new version is available when the next set of breaking changes are merged to master. Thanks!

[drashna]

Thanks, and not a problem!