#Attempting to put a Shift Register on a Xiao Plus

1 messages · Page 1 of 1 (latest)

ruby verge
late oak
#

This is where having a local (docker) dev environment really helps.. you have all the build artifacts so you can trace where along the way the chain broke.

There are a bunch of temp files (especially the .config under build/zephyr/.config iirc)

In this case.. a linker error.. so the c file compiled, so the header did offer up the symbol, but the matching implementation (C) file is missing. I had similar, had to look at the appropriate CMakeLists.txt, the C file would be protected by a CONFIG_* variable I missed.. rinse and repeat.. (which is also way easier on a local setup)

But __dts* is some generated device from the device tree.. Zephyr is an absolute magic at C preprocessor, so hard to guess, but maybe thats enough of a clue?

Thats me going off 'first principles'; somebody knowing more about ZMK code..

fast ether
#

Indeed, it looks like CONFIG_SPI isn't enabled

ruby verge
#

It's now currently based on this:
https://github.com/WainingForests/ZMK-XIAOv4-Std/

Which builds fine. The only changes are the addition of the shift register. Which is based off the working code here: https://github.com/WainingForests/ZMK-XIAOv4-SR/tree/Working-No-studio-support

 &pinctrl {
    spi0_default: spi0_default {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 1, 3)>,
                <NRF_PSEL(SPIM_MOSI, 1, 5)>;
        };
    };

    spi0_sleep: spi0_sleep {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 1, 3)>,
                <NRF_PSEL(SPIM_MOSI, 1, 5)>;
            low-power-enable;
        };
    };
};

&spi0 {
    status = "okay";
    compatible = "nordic,nrf-spim";
    pinctrl-0 = <&spi0_default>;
    pinctrl-1 = <&spi0_sleep>;
    pinctrl-names = "default", "sleep";
    cs-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>;

    shifter: 595@0 {
        compatible = "zmk,gpio-595";
        status = "okay";
        gpio-controller;
        spi-max-frequency = <200000>;
        reg = <0>;
        #gpio-cells = <2>;
        ngpios = <8>;
    };
};

and then the swap of the pinouts for columns:

&kscan0 {
    col-gpios           // SR 0-7
        = <&shifter 0 GPIO_ACTIVE_HIGH>
        , <&shifter 1 GPIO_ACTIVE_HIGH>
        , <&shifter 2 GPIO_ACTIVE_HIGH>
        , <&shifter 3 GPIO_ACTIVE_HIGH>
        , <&shifter 4 GPIO_ACTIVE_HIGH>
        , <&shifter 5 GPIO_ACTIVE_HIGH>
//      , <&shifter 6 GPIO_ACTIVE_HIGH>
//      , <&shifter 7 GPIO_ACTIVE_HIGH>
        ;
};
worldly violet
#

boards/shields/skreecustom/skreecustom.conf is not read by the build process. I would put it in boards/shields/skreecustom/Kconfig.defconfig next to config ZMK_SPLIT like

config SPI
    default y

boards/shields/skreecustom/skreecustom_left.conf and ..._right.conf would also work

ruby verge
#

I originally had the boardname.conf in the config file

worldly violet
#

That is only supported in config/<shield>.conf

#

Not in boards

ruby verge
#

Gotcha! I'll give it a go thanks so much!

worldly violet
#

IIRC boards/shields/<name>/<name>.conf has higher priority and can't be overridden by users in config/<name>.conf

ruby verge
#

Yep! That got it to build!

late oak
#

I've spent quite a bit of time arguing with the build recently.. two useful tricks (on a local build) to see if a config variable is on/off and why..

  • build/zephyr/.config contains all the config variables merged from all the sources
  • if you add -t menuconfig to your build command, you can then search for the symbol. It lists where the symbol gets turned on (i.e. filename of the source config file)

Common mistakes I had made myself..

  • if you duplicate an Kconfig option, it overrides the imply/select from the original file, missing things like imply SPI or imply USB..
  • imply is better then select (keeps dependencies), but.. it can also not actually turn on the option (then you need the menuconfig to track down the conflicts that ignore the imply)
  • select turns on options without dependencies..

And sooo many more 🙂

ruby verge
# late oak I've been doing a 'novel' thing and creating bunch of `SHIELD_*` config options....

I don't know if this still works but it should.

https://github.com/WainingForests/zmk-config-nano/blob/wylderbuilds_00249/config/boards/shields/wyld_dm/wyld_dm_right.conf

Wylder had a couple dual trackball ZMK builds.

GitHub
zmk-config-nano/config/boards/shields/wyld_dm/wyld_dm_right.conf at...

Configs for Nice!Nano and associates. Contribute to WainingForests/zmk-config-nano development by creating an account on GitHub.

late oak
#

oh.. the repos you had showed me helped me a bunch!

I can't use inorichi's driver because he refers to symbols only available to the central half.. but badjeff did seem to have taken care of all of that! (i.e. you cant use inorichi's driver on the periferal). It also doesn't seem to support all the 'input processor' stuff that recently dropped.

I actually threw up my hands.. after a month (or more now??) of the screen and trackball just not working.. I splurged for an osciloscope! finally a valid excuse to get me one of those 🙂 SDS804X..

few hours with it.. turns out.. my sck and my mosi were swapped at the jst connector, GRR! now the device initialized in the debug log!

The screen!? also oscilloscope.. noticed reading the SHARP datasheet that the CS line is actually ACTIVE_HIGH (i.e. the referse of the trackball!!?? even more reason you cant have it on the same SPI bus)

Your repo you showed me did have the screen set up correctly, I was just too blind to notice.

Screen works.. trackball.. dunno.. did a lot of refactoring.. might have missed something

fast ether
late oak
ruby verge
fast ether
ruby verge
#

Right, just wasn't sure where the configuration for them went. But this is the new input processor that I'm not used to

#

Looks like enabling it is in the defconfig and then dtsi handles xy rotation and stuff.

fast ether
#

Oh, I mean you can do some of these either on the driver or with input processors

#

Just simple inversions etc.

ruby verge
#

I'm just now trying to get up to speed on the new input processor and studio at the same time. Didn't think I'd have this much trouble relearning things but boy am I!