How is flashing accomplished?

[uberrice]

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 ;)~~

[uberrice]

Nevermind, again. I did find an issue in your most recent commit - you switched rows and cols in the json, but the rest was my fault. On another note, the assembled half is fully working! (although some magic smoke did erupt from the pico once... No idea what that was.

By the way, no level shifting for the LEDs is required and everything seems to stay nice and cool ;) so for the next revision, I'd propose to remove the level shifting footprint.

[JellyTitan]

Looks great! It sounds like i need to rework the readme. I cribbed it from Junco/Sofle_choc and have been reworking it every iteration. There have been at least 2 QMK releases that required an extensive rewrite since I started the project.
The next big qmk task is to get as much code converted to .json as possible, and add in Via support.

The loss of magic smoke worries me . . .

[uberrice]

The magic smoke was most probably caused by sloppy soldering.

I had issues with the LEDs only working up to a certain point - and I realized that the far-in thumb button (the one for the 1.5u cap) seemingly had no ground connection from the leds GND pin as per multimeter. Thought I'd wire in a little patch to see what was going on - to the pimoroni GND, which I confirmed was connected to the other GND pads - turned on the board, magic smoke. Quickly unplugged it, removed the patch, replugged, and suddenly, the 'broken' led also worked.

I hardwired the pico, so I can't talk about the underside, but I can't see any blown chips on the top.

[JellyTitan]

The v3.4.4 PCB came in yesterday.
As i was building, I wrote the section in the README for easy drag and drop flashing. (I still haven't added via support though - so it's not terribly useful yet)

Everything works - but I'm seeing some weirdness.
When i plug in the left half to USB, the right half doesn't get power. When I plug the right half in, the left half works fine but the OLEDs are on the wrong sides. Totally not what I would expect. I'm going to check for shorts, try swapping the round corner OLEDS for Oval corners, and then pick through the QMK build again. (I tried the same firmware on an earlier v3.3 variant, and it seemed to work fine, but that had Oval corners OLEDs).
Are you using oval corner OLED's in your variant?

[JellyTitan]

Hurray! It was just sloppy soldering - everything is working as expected now. Eagerly awaiting confirmation on your variant.

[uberrice]

I have round hole ones, in white. I'm still waiting on my picos, so I can't comment on full functionality. My screen doesn't work yet though - I temporarily hard-soldered it in because I didn't have sockets on hand (which I do now), and that doesn't seem to work. It updates with what seems like random noise in chunks when plugging in, then turns off. Should the screen also work if only one half is connected?

[JellyTitan]

While i was debugging, i installed both the round hole screens and the oval hole screens - they both worked. (You can see the sockets for the oval screens poking out below)
I double checked the screens activation - they work even if both sides aren't connected. There's 'chunks' missing from the images, but that's from the screen refresh rate. When only the righthand is plugged in, it'll be perceived as the lefthand, and the OLED output will be upside down.

From the image above, it looks like you've got the screen installed correctly in the top set of holes for the round OLEDs. Did the build log instructions for the OLEDs make sense? (I'll be updating the images for clarity).

[JellyTitan]

It just occurred to me - the wiring of the OLED's may not be consistent between oval/circle models.
Here's the sequence i expect to see:

Round Hole:
GND | VCC | SCL | SDA
Oval holes are:
VCC | GND | SCL | SDA

Which sequence is printed on your OLED?

[uberrice]

Received second Pico.

Are you SURE a TRS cable works? There's 4 connections between the picos, GND, VCC, RX and TX.

I only have a TRS cable on hand, and while the 'slave' powers on, there doesn't seem to be communication (half does not work, no RGB).

Independently, the two halves work.

[uberrice]

OLEDs work now, by the way. The slave board even correctly turns on with the ' Sofle Pico' logo. Just the RGB and keystrokes are not sending. The connections are in place, but again, it's only a TRS cable, so RX is shorted to ground.

[uberrice]

Figured it out - for TRS compatibility, I needed to comment out the 'full duplex' line in config.h, the 'screens not working' seems to be config based. With your prebuilt binaries they display, with my compiled ones, they go black - because no OLED config was present. Thus, HW all seems to be working!

[JellyTitan]

Interesting! That was completely my mistake, the TRS reference was from before I got full duplex working. Since the RP2040 does the duplex pin switching in firmware - maybe it's a 'task failed successfully' situation? Do all the features work with TRS? (That would greatly simplify the configuration.)

…

On Thu, Nov 30, 2023 at 2:34 AM uberrice ***@***.***> wrote: Figured it out - for TRS compatibility, I needed to comment out the 'full duplex' line in config.h, the 'screens not working' seems to be config based. With your prebuilt binaries they display, with my compiled ones, they go black. Thus, HW all seems to be working! — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARGTI3HWLNSAFZIJ2ZE5ZXLYHBOK3AVCNFSM6AAAAAA7Y4TT5CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZTGQ4TMMRXHA> . You are receiving this because you commented.Message ID: ***@***.***>

[uberrice]

Yes, everything seems to work with my TRS cable. TRRS/full duplex, in my opinion, is just 'better' though - if the capability is there, why not use it (and keep a simple config swap for people with only a TRS cable).

[JellyTitan]

I think that would be a swell feature. As I'm going through the docs, I'm not finding much on split communication protocols in .json config.