Assigning non aligned pins

[tobozo]

Hi and thanks for this great project!

It works out of the box on a Waveshare RP2040-LCD-0.96.
That device has an onboard display connected to pins [8..12] though, and I'm worried that the readings on those pins may be incorrect.

I have tried to modify the source to assign a different set of pins but I'm only discovering rust and obviously didn't get the expected results.

        pins.gpio0.into_mode::<FunctionPio0>();
        pins.gpio1.into_mode::<FunctionPio0>();
        pins.gpio2.into_mode::<FunctionPio0>();
        pins.gpio3.into_mode::<FunctionPio0>();
        pins.gpio4.into_mode::<FunctionPio0>();
        pins.gpio5.into_mode::<FunctionPio0>();
        pins.gpio6.into_mode::<FunctionPio0>();
        pins.gpio7.into_mode::<FunctionPio0>();
        // pins.gpio8.into_mode::<FunctionPio0>();  // TFT DC
        // pins.gpio9.into_mode::<FunctionPio0>();  // TFT CS
        // pins.gpio10.into_mode::<FunctionPio0>(); // TFT SCLK
        // pins.gpio11.into_mode::<FunctionPio0>(); // TFT MOSI
        // pins.gpio12.into_mode::<FunctionPio0>(); // TFT RST
        pins.gpio13.into_mode::<FunctionPio0>();
        pins.gpio14.into_mode::<FunctionPio0>();
        pins.gpio15.into_mode::<FunctionPio0>();
        // added this
        pins.gpio16.into_mode::<FunctionPio0>();
        pins.gpio17.into_mode::<FunctionPio0>();
        pins.gpio18.into_mode::<FunctionPio0>();
        pins.gpio19.into_mode::<FunctionPio0>();
        pins.gpio20.into_mode::<FunctionPio0>();

I understand this breaks the pins alignment and may affect any logic using the pins array index as an offset information, but I haven't spotted where this could happen (triggers.rs?), and I'm not even sure core logic would allow it.

Is that idea even realistic?

Sorry about the dumb questions, feel free to close if this is out of scope for this project.

[dotcypress]

There are a few ways to do this:

• Easy one: you can change PIN_BASE to 13, in this case logic analyzer channels will be mapped to gpio 13-29 (do not forget to change pins mode pins.gpioXX.into_mode::<FunctionPio0>();)

• Hard one: use sparse pin config, but this will require reimplementing data packing algorithm here: https://github.com/dotcypress/ula/blob/main/src/sampler.rs#L110

[tobozo]

thanks for the quick reply!

Easy one

Pin25 is in the way and disabling the status led in the code would probably not free that channel as pin25 is also TFT backlight for the Waveshare device.

Hard one

I'll try this one and will update this thread with the progress 🤞

[tobozo]

followup:

• Asked a friend familiar with rust for help
• Stopped using the text-editor+shell and started using vscode+rust-analyzer
• Found the sikgrok OLS API source to use as a cross-reference

I can't figure out the strategy to reimplement the data packing algorithm though and I haven't fully understood the current mechanics, so I apologize about the dumb questions:

• Is that the only code block that needs editing in this scenario (the Hard one)?

Sparse pin configuration: my C/C++ reflexes are telling me to create an array with the pin numbers to match index with values later, but it somehow feels wrong:

pub const ANALYZER_PIN_MAP: [u8; 16] = [
    0, 1, 2, 3, 4, 5, 6, 7,
    13, 14, 15, 16, 17, 18, 19, 20
];

• What would be the best type to store the sparse pin configuration?

Data packing algorithm: I'm tempted to skip samples based on their order, but this is assuming that a sample contains the pin states for every 32 pins on the rp2040, and I'm not sure this assumption is true.

• does the contents of s02/s13 need to be modified, or do I need to filter at sample level?

for full_gpio_chunk in sample_mem.chunks(64)

• is this situation friendly with gdb/mocked-device unit test debugging?