Multiple nexus nodes, and using I2C on a nexus node

Hello:

I am developing a board and shields based on nRF5340 (but this question is not really specific to nRF5340, it also applies to most other nRF5x chips). The main-board has 4 identical connectors, and I have defined a nexus node for each of the connectors. For simplicity assume each connector has 6 pins, pwr, gnd, and 4 gpios.

I have several different shields, lets say an accelerometer (i2c and irq), and a LED display with 4 LEDs (4 gpios).

I would like to plug a shield into any one of these connectors and be able to plug several of the same shields onto the main-board (lets say 3 LED shields, and one accelerometer shield).

1) My first issue is how do I write a CMakeLists.txt which tells the build system I have a LED shield plugged into CON2? I can write an overlay for the LED board plugged into  CON2, but I would need 4 (slightly different) overlay files to describe the 4 places that the LED shield could be plugged in (only the nexus node name changes). I have this working.  What I really want to do is have one overlay for LED shields and pass a variable into the overlay describing which connector (nexus node) it is plugged into.  I think the variable could be defined in prj.conf, CMakeLists.txt or app.overlay. How can I pass a variable into the shield overlay so that the shield overlay can put the correct nexus node name into the overlay?

2) my second issue is the NRF_PSEL macro doesn't accept nexus nodes  the parameters are type (TWIM_SDA, TWIM_SCL, etc.), bank (0 or 1), and port (0-31). Ideally the NRF_PSEL macro should accept a nexus node, which would be translated by the nexus node to the bank and port. Nexus node translations work fine for gpios and int-gpios. Is there a way to get NRF_PSEL to do nexus node translations?

&pinctrl {
    // TODO: these should reference CON2 pins 4 and 5. not
    // the pins directly on the processor. eventually
    // it should be configurable for CONx
    i2c1_default: i2c1_default {
        group1 {
            // psels = <NRF_PSEL(TWIM_SDA, &my_cpu_con2, 5)>,
            //         <NRF_PSEL(TWIM_SCL, &my_cpu_con2, 4)>;
            psels = <NRF_PSEL(TWIM_SDA, 1, 2)>,
                    <NRF_PSEL(TWIM_SCL, 1, 3)>;
            bias-pull-up;
        };
    };
};

Parents
  • Hello,

    There is no documentation about passing a variable into a shield overlay to which nexus node it references.

    Shield variants ([Shield variants]) documentation shows that some shields may support several variants or revisions. In that case, it is possible to provide multiple versions of the shields description each with its own overlay/defconfig, selected by --shield <shield_v2> etc.

    Board compability (Board compatibility) shows how to configure shield per board (boards/shields/<shield>/boards/<board>*.overlay).

    So, there both are static. There will be separate overlay for each case.

    Regarding NRF_PSEL for nexus node, nexus nodes is only used for GPIO specifiers. There is no information indicating that NRF_PSEL can use nexus nodes or that pinctrl psels can be resolved via a nexus mapping. You can read this documentation Sound & edge blogGPIO nexus nodes

    However, I will ask relevant team to get more insight. I will come back to you lately.

    Thanks.

    BR
    Kazi

Reply
  • Hello,

    There is no documentation about passing a variable into a shield overlay to which nexus node it references.

    Shield variants ([Shield variants]) documentation shows that some shields may support several variants or revisions. In that case, it is possible to provide multiple versions of the shields description each with its own overlay/defconfig, selected by --shield <shield_v2> etc.

    Board compability (Board compatibility) shows how to configure shield per board (boards/shields/<shield>/boards/<board>*.overlay).

    So, there both are static. There will be separate overlay for each case.

    Regarding NRF_PSEL for nexus node, nexus nodes is only used for GPIO specifiers. There is no information indicating that NRF_PSEL can use nexus nodes or that pinctrl psels can be resolved via a nexus mapping. You can read this documentation Sound & edge blogGPIO nexus nodes

    However, I will ask relevant team to get more insight. I will come back to you lately.

    Thanks.

    BR
    Kazi

Children
No Data
Related