jellytitan / sofle-pico Goto Github PK

It seems like there is something not quite right with the config.

I am writing from the Sofle Pico right now, so, working it is!

However, at least for my board, it looks like two keys are swapped. Specifically the two keys on the right thumbcluster, left side - the big one and the one next to it. SW26 and 27. Whatever button press is configured for SW26 happens on SW27 and vice versa. Only happens on the right side. Any idea why? Do you have the same behaviour?

During QMK PR, Drashna recommended setting handedness via pin. We certainly have enough spare pins to do this. I tried setting this up on an earlier iteration, found it would likely need a pull up resistor, then abandoned the idea.
Revisit if time permits.

I pulled the repo and tried to build, however I am getting this error:

qmk flash -kb sofle_pico/rev1 -km default
Ψ Compiling keymap with gmake --jobs=1 sofle_pico/rev1:default:flash


QMK Firmware breakpoint_2022_05_28
Making sofle_pico/rev1 with keymap default and target flash

arm-none-eabi-gcc (SUSE Linux) 12.3.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Generating: .build/obj_sofle_pico_rev1_default/src/default_keyboard.c                               [ERRORS]
 | 
 | <class 'IndexError'>
 | ☒ list assignment index out of range
 | Traceback (most recent call last):
 |   File "/home/uber/qmk/venv/lib/python3.11/site-packages/milc/milc.py", line 539, in __call__
 |     return self.__call__()
 |            ^^^^^^^^^^^^^^^
 |   File "/home/uber/qmk/venv/lib/python3.11/site-packages/milc/milc.py", line 544, in __call__
 |     return self._subcommand(self)
 |            ^^^^^^^^^^^^^^^^^^^^^^
 |   File "/home/uber/qmk/qmk_firmware/lib/python/qmk/cli/generate/keyboard_c.py", line 72, in generate_keyboard_c
 |     keyboard_h_lines.extend(_gen_led_config(kb_info_json))
 |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 |   File "/home/uber/qmk/qmk_firmware/lib/python/qmk/cli/generate/keyboard_c.py", line 36, in _gen_led_config
 |     matrix[row][col] = str(index)
 |     ~~~~~~~~~~~^^^^^
 | IndexError: list assignment index out of range
 | 
gmake[1]: *** [builddefs/build_keyboard.mk:336: .build/obj_sofle_pico_rev1_default/src/default_keyboard.c] Error 1
Make finished with errors
gmake: *** [Makefile:392: sofle_pico/rev1:default:flash] Error 1

Is this caused by my environment or by a bug in the fw? Since it's seemingly generating code, I'm not immediately sure where to start looking.

~~EDIT: Nevermind for now - I took a look at the qmk folder within this project and read only that readme, not the flashing part in the main readme :)

Was able to build one half of the keyboard at least ;) - still waiting on the second RP2040.

I wanted to try flashing it - but I'm kind of confused on how to go about it, since the Sofle Pico is not in the official repositories yet.

What am I supposed to make? the only things in the repo are config sources, not a complete source project. What do I need to pull/run in order to build the FW?

Note: I do have QMK installed and set up - I'm just a bit lost between 'do qmk list keyboards to get all keyboards' and getting to the point where i can add a keyboard that is not in the repos yet ;)~~

First, thank you very much for your hard work on this keyboard! I'm a total newbie and this is my first time ordering a PCB, so any help would be much appreciated.

After submitting the 3.5.4 version of the keyboard to the PCB vendor, they asked me this:

As shown below, there's no solder mask opening for below indicated holes. Here we have 2 suggestions. Please make a choice.

A: Open them to be covered by tin on both sides. So that they can be soldered components.

B:Follow the file to cover them with solder mask ink.

Which one is it?

Adding a DMG2305UX PFET to the left-hand side by the TRRS jack seems like a low-cost / low effort option for folks who want added backpower protection. Its a bog-standard SOT23 package, pretty easy for anyone comfortable with surface mount soldering, and the bypass option is just another simple solder-bridge.

Originally posted by @TheWerle in #11 (comment)

Adding TRRS short protection would be really helpful! I don't have the bandwidth for this improvement right now, but I'd love to see this implemented. A through-hole alternative component would also be really nice, since this board may be the first/only soldering experience that many users have.

Some USB cables don't work. I'm not sure why. Anybody got any ideas?

1N5817 is solid for add-in USB-backpower protection diode purposes, but could be swapped /optioned with a lower forward voltage alternative if a SOD123 surface mount pad option was added. The surface mount package reduces power consumption/heat from a reduced forward voltage current response. The MBR120VLSF diode already used for D1 on the Pico is pretty ideal and in the same SOD123 package as the 1n4148, so anyone who's open to surface mount shouldn't be intimidated, so making it the option for D31 would be nice.

Originally posted by @TheWerle in #11 (comment)

Having a surface mount alternative for the USB-backpower protection diode would be nice!

Hiya. Decided to check out the new VIA FW. Looking good so far. Removes the need to reflash everything all the time!

However, at least on the version of the board I ordered, the left screen seems to be upside-down. I have the screen mounted exactly as you do in the main picture: https://github.com/JellyTitan/Sofle-Pico/blob/main/docs/images/build_guide_pico/sofle_pico_v3.4_hero.jpeg . Top side, round holes, screen wraps around on the left. Yet, plugging in the left side of the board, the screen is upside down / rotated in the wrong direction. Was this some change in newer revisions, or is the VIA code borked? Or do I simply have a weird screen?

I quickly looked over the PCB - noting what I found in case it's relevant

Here your annular rings are tiny. See minimum size as per JLCPCB below

Same with the LEDs - you should be able to get away with the actual minimum required annular ring (0.13mm).

Happens all over the board. I didn´t take a look at the original Sofle - the issue might also be present there - but violating minimum annular width might lead to more production failures. When you order like 5 boards, you will get 5 functioning boards, because they often overproduce and test every board at small scales - at least for JLCPCB - but it's not good practice to go for such small tolerances.

EDIT: Just noticed - the LED mount is part of the Cherry_MX_DS_Hotswap_miniE_1U_v3.03 footprint - so, not directly related to your routing. But I would recommend making your default Via size 0.3mm unless specifically needed smaller:

The vias around the Pico footprint are 0.2/0.4mm - I´d go for a standard size of 0.3/0.6mm - it looks like there's more than enough space for it.

Digging through the Build Log and I think I know why you can't get the Cirque to work. Sadly its because I suspect you've blown it up.

Cirque input voltage is 3.6V max tolerance per datasheet, nominally 3.3V or 1.8V to match the I/O logic levels of whatever device controls it. Your J2/J3 headers are attached to VCC, and as I detailed in VCC will be in the 4.5-5.0V range for all your operating conditions.

J2/J3 power connections need to be reassigned to 3V3.