Proposal: Native RP2040 variant

[JellyTitan]

I've built a 2040 based variant, with the working title of "Sofle Pico". I took all the stuff i loved from the previous iterations, and tried to make it easier to build for people new to the hobby. I'm preparing to send out for the 4th, and hopefully final, prototype. The README is mostly complete, but will need to be reformatted before a PR. The build log is mostly notes on what changed between iterations. There is a small punch-list remaining, mostly QMK related, that can wait until the hardware is finalized.

@brianlow @DaneEvans @josefadamcik Would you be so kind as to take a gander & let me know if there's features or design choices that could be improved?

One decision i'm struggling with - should the LEDs be omitted in favor of combo MX/choc footprints like the Sofle V1? The drag soldering required for the level shifter & and the non-standard SK6803 makes the build more difficult.

[josefadamcik]

Hi @JellyTitan, that looks like an amazing piece of work, good job! I love rp2040. My new design, Stana, uses it as well. I am so happy to see that there's now a RP2040 variant of Sofle.

Unfortunately, I don't really have the capacity to do a detailed review of your design. And to be honest, I am not a big authority on DIY keyboard designs since I don't spend that much time playing with them anymore.

I would be happy to welcome this version to the repository whenever you feel ready (and make you a contributor with some rights so you can maintain it). However, there would be nothing wrong with keeping the design in your own repository. I could link your variant from this one and from the main web page. That would give you full control (and full credit) for your design which I think is a good way to do it.

[josefadamcik]

Oh, and the last question: I have personally never built nor used a keyboard with RGB lighting. I am just not interested in it. So if it was just about me, I would drop the RGB support.

That said, it was the most common change request for Sofle V1/V2 and the main reason for Sofle RGB made by Dane Evans. But it is indeed a conundrum because the Choc version was the second most common request for Sofle V2 and that's why we have the version from Brain Low.

Nowadays, I would really love to have a design where I could "generate" several variants of the main PCB with different configurations. Something like having custom footprints for different configurations of switches / sockets / RGB that I could replace by script and routing on the main PCB that would be shared among them. However, I am not sure if that's achievable and I have never really invested in trying that out.

[JellyTitan]

Thank you for the thoughtful reply! I love the Stana btw - I would have developed this board using the 2040 zero if I had known how inexpensive it was. (Plus it's got that 5v for Solenoid support)!

Your input on the direction of the project is helpful! High level guidance is really appreciated.

I'll go with your advice and keep the variant in a separate repo. In the next month or so I should have the final version tested, and then I'll submit a PR to link this variant from the main page.

I appreciate the input on the RGB. As a touch typist - i don't really use the RGB & OLED - but those features were what drew me to the Sofle initially. I think the Sofle is a really great first board for people new to the hobby. I've tried to make this variant extra easy to solder and used accessible parts, in hopes that it would entice others to try it out. I'd like to keep the RGB in this version, and eventually, build a 2040 zero based version that drops the RGB in favor of supporting both choc & MX, along with a horizontal OLED. (I love the idea of a horizontal screen for a keymap 'cheat sheet' - i think that would be great for people transitioning into the split world).

I cribbed the RGB circuit for this board from the Junco. For that board, I added a guide for PCB ordering that covers using the pick 'n place automated manufacturing for easier assembly. I was hoping that would drive adoption among the etsy sellers.

Are ordering guides something you'd like to allow, or discourage? I know that some of the contributors to this project sell directly, and I don't want to detract from the value of their work.

[brianlow]

Are ordering guides something you'd like to allow, or discourage? I know that some of the contributors to this project sell directly, and I don't want to detract from the value of their work.

If you are referring to me, I'd encourage it. This is all open source.

[JellyTitan]

Ha! Yep! @brianlow I know you had a shop setup at one point. I see the value in making the variant immediately available to help drive adoption. It looks like the shop is shut down? Would you recommend starting a shop, if you knew then what you know now? i.e. - was it worth it to you? I know the initial QMK PR was also a nightmare - I know it's been at least a year if not more. Did that factor into your decision to shut down the store?

[uberrice]

Looking great! Been meaning to build a split keyboard for myself for quite a long time - never got around to it, and the whole Pro Micro dependancy irked me somewhat.

I'd be glad to build one as a test and share my experiences once you're confident no HW bugs remain!

[JellyTitan]

@uberrice That would be fantastic! I'm hung up on a quiet bug, but I intend to have it resolved by Monday. I tried to place an order yesterday for v3.4 - but something causes the JLCPCB ordering process to hang. (I'm using PCBA to have them do the diodes and level shifter).

I've got a ticket open with them to resolve it - but I'm not terribly optimistic. I suspect the problem stems from either my outline rendering incorrectly, one of the custom component footprints, or a problem with my BOM/PNP files. (Design wise, the biggest change from 3.3->3.4 was OLED footprint variant additions, so i have high confidence in the design).

I'll let you know when it's all fixed and ready to try out. I really appreciate any insight you can offer. I've tried to document the heck out of this.

[uberrice]

@JellyTitan One issue you might face with partial assembly is your paste (stencil) layer. Of course, maybe JLCPCB does this automatically, but if they don't, then you'll have solder on all of your SMD pads - notably the sockets. Otherwise - did you get PCBA before? I'm not sure how they handle irregular-sized PCBs in assembly - they would need to panel them, and the 'flipping' part might also be somewhat of a problem, unless you make 2 seperate PCBA orders.

The documentation is looking great and I'm already filling my shopping basket with the required parts, so give me the go-ahead when you tested your prototype!

[JellyTitan]

@uberrice I did try PCBA with this board v3.2 & v3.4 through JLC - and it came out pretty good. (No problems with extra solder on pads).

You'r point about flipping brings up another interesting point regarding board design. I made a bunch of design choices along the way, and they might be worth discussing.

I just contributed to a new version of the Junco, as well as a PCBA ordering guide where I've been learning all this stuff through trial and error.

I'm by no means an expert, and would welcome any input.

From what i've seen, I think at a high level, there's two approaches when designing split keyboards, and PCBA considerations factor in.

1) double-sided/single-hand (Sofle)

• lower the cost per unit with a lower minimum quantity. (5 boards for 2 1/2 sets)
• Harder to setup 100% automated PCBA, because you'll have to develop revisions/separate orders for each hand.
• Lower manufacturing and shipping costs.

• Better for casual builders that want one or two boards, and will solder components themselves.

  2) single-sided/double-hand (Corne Cherry)

  • lower cost per unit with a higher minimum quantity. (5 boards for 5 sets)
  • PCBA is easier, because you can put most things on one side of one board.
  • Higher manufacturing and shipping costs.
  • Better for resellers that will use PCBA and order in bulk.

I stuck with the double-sided/single-hand board because all the Sofle's are that way, plus i tend to go through multiple iterations and want to keep my costs down.

With the Sofle Pico, I tried to hit a happy medium between the two - some PCBA can be done, easily and inexpensively - but not all. (Plus i think it's a good introduction to PCBA for those new to it).

With PCBA at JLC there's the two tiers basic assembly. The "Economic" version which is usually an $8-10 setup fee that you can find a coupon for. The "economic" assembly covers basic components, components on one side of the board, SMD components, and 'non-special' components. I designed the Sofle Pico so that you can use PCBA for the backside only, and that gets you all 305 diodes & 5 level shifters for $10-$15. If you think about the effort involved in hand soldering, that $ is worth it for many. (The diode placement is such that it can be on either side of the board - hurray!)

The other PCBA tier is "Standard" assembly, which is a $25 up-charge. It covers assembly on both sides of the boards, and 'special' components like switch sockets. PCBA switch sockets & LEDs for all 5 boards on a single-sided/double-handed board would have run about $70 more.

The LED's on this design were the problem child. They are hard to solder by hand, and I would have preferred to make those easy with PCBA - but those would have been better suited to the single-sided/double-handed layout. (It feels like I often see Reddit posts asking for help with LED trouble shooting)!

I could absolutely turn this into a single-board/double-hand variant. I could add footprints for PCBA surface mount Picos and simplify OLED footprints. I think that would make the board more appealing to vendors, which would help drive adoption and make the board accessible - but also more expensive, which would make it less accessible.

Thoughts?

[TheWerle]

@JellyTitan I'm a custom keyboard newbie but a professional PCB designer (IPC CID+ certified). I'm looking at Sofle build for my first keyboard, you've got a wonderful repo here to get people going.

I'm using the project as a chance to learn QMK/KiCAD/Git-hub (I use Altium/SVN professionally) and would be interested in offering design reviews and/or design-for-manufacturability suggestions that could hopefully advance a native RP2040 variant and contribute here. If nothing else, adding a common KiCAD rules/constraints file compliant with common PCB ordering services seems like it could be beneficial to people leveraging the project.

[uberrice]

Hi @TheWerle . I did a little review on the board and fixed some stuff. While I am an electrical engineer and do design (prototype) boards from time to time, I'm nowhere near that level, I am more of an embedded software guy - but I thought about the possibility of interesting the rp2040 as well. Sounds like a cool project, and I'd be up to assist if needed!

Would you keep the 'reversible design' that allows for moq 5 ordering, or would you go for 2 different halves? Keeping it to one board could introduce quite a lot of net antennae, which might (or might not?) lead to issues.

[JellyTitan]

@TheWerle Any input would be greatly appreciated.

I've been working on the Sofle Pico here.

The review and contributions be @uberrice were really helpful.

I've got a good stable version, so currently I'm focusing on the documentation, cases, and cleanup for a PR to the main SofleKeyboard repo, as well as PR for QMK. (The VIA PR is ready, but blocked by the QMK PR).

By 'native RP2040 variant - do you mean skipping the Pico completely?

[TheWerle]

@JellyTitan I just meant a design re-spin for new capabilities that the RP2040 brings to the table. I'm still doing my "market survey" phase of things, but it seems like the added memory and power make RGB and wireless stuff more functional than ATMega32U4 QMK.

@uberrice Based on my impressions of the target audience for Sofle, I'd initially lean towards continuing the reversible design for ease-of-use to DIYers, but that has to be balanced between both design and assembly. I'd assume the bulk of Sofle builders are still buying kits rather than spinning their own boards (I could be wrong). Any design choices that emphasize ease-of-assembly would seem most beneficial with that context.

(Caveat: know how to do this in Altium but am new to KiCAD, so I don't yet grasp the level-of-effort for this) I'm likewise still familiarizing myself with the common PCB turnkey options and process, but in theory choosing between optimizing single-sided pick'n'place and reversible board layout should be a false choice for a balanced two-layer PCB. The kinda-hacky way would be to drop a second copy of your SCH down, copy-paste-flip the first layout, and remap it to the second SCH instance. The "proper" way would be to design it, output your gerbers and mirror it in CAM panelization. Either way you should be able to flip the artwork and have both left/right halves on the "primary" assembly layer. Pick'n'place would need an equivalent "flip" operation performed.

The current PCB designs are a very mixed bag in regard to intuitive hand assembly. The Choc and RGB definitely show the benefits of iterative design improvements, both with the dual-footprints used and particularly with the silkscreen markings. I'm still giving the current PCBs a once-over to understand the design choices / tradeoffs made and haven't done an assembly yet myself.

Keeping it to one board could introduce quite a lot of net antennae, which might (or might not?) lead to issues.

Regarding this, I wouldn't worry too much for a PCB design, particularly if you do GND flooding and stitching vias. The number of nets with signal integrity concerns is presumably fairly limited if you're using a pro-micro type module, basically limited to the serial-link between the board-halves. With clever use of termination resistor footprints and/or jumper pads you can set things up for isolating stubs as needed.

[JellyTitan]

A PR has been submitted https://github.com/josefadamcik/SofleKeyboard/pull/195

[t-8ch]

FWIW I'm using a normal sofle choc with RP2040. The only thing needed was CONVERT_TO = kb2040 in QMK rules.mk

[JellyTitan]

@t-8ch

FWIW I'm using a normal sofle choc with RP2040. The only thing needed was CONVERT_TO = kb2040 in QMK rules.mk

Which Sofle version are you using? I've seen some issues with LED's not working as expected on kb2040 conversions.

[t-8ch]

Which Sofle version are you using?

Sofle Choc (as mentioned)

I've seen some issues with LED's not working as expected on kb2040 conversions.

That should be fixable, no? (But I'm a software guy, so this is my preferred approach)