How do I use SPI1?

[karsteny]

When using SPI, I can't figure out how I can make it use SPI1. I have two SPI devices, an OLED display that actually uses SPI, and a LED strip using the code that's listed in the examples. I tried putting in channel 1 in the constructor for the LED strip, as well as the OLED screen (separately) but it ended up outputting both over SPI1, causing major issues. I'm using a Pi Zero 2 W, and pi4j 2.6.0 (so it's not the pre-2.6 issues with multiple SPIs, it seems to open both just fine and the program runs without errors, but it's going over the same SPI)

[karsteny]

Update: I tried using .bus(1) to see if that would work, and while it does appear to no longer be routing both data streams over the SPI0 port (the OLED works correctly on SPI0), the LEDs just go white (they are connected to SPI1). I also tried to add the dtoverlay=spi1-3cs to /boot/firmware/config.text to try and enable SPI1, but that didn't change anything.
If I try to switch the OLED to SPI1 and LEDs to SPI0, the LEDs work fine (no timing errors), but the OLED doesn't do anything

[taartspi]

Not certain which java example code you are using as far as changing the spi bus number. I did find a post to validate the config.txt changes https://forums.raspberrypi.com/viewtopic.php?t=309400

And depending on which version of the OS you have loaded validate those SPI pins
raspi-gpio get 7,8,9,10,11,12,16,17,18,19,20,21
or
pinctrl get 7-20

[karsteny]

The SPI bus number was me just searching the available methods for SpiConfigBuilder, and setting that to 1 for the LED strip seemed to at least move the conflicting LED strip commands off of SPI0, since the OLED was getting corrupted inputs when that wasn't set (implying more than one datastream on SPI0). I'll admit that besides that, I don't know what it's doing. Otherwise, the LED strip code more or less the same as this code.

It does appear that the pins are set up correctly:

[taartspi]

I used a program also more or less that example.
/boot/firmware/config.txt
dtparam=spi=on
dtoverlay=spi1-1cs

pi@rasp48alt:~ $ pinctrl get 7-20
 7: a0    pu | hi // GPIO7 = SPI0_CE1_N
 8: a0    pu | hi // GPIO8 = SPI0_CE0_N
 9: a0    pd | lo // GPIO9 = SPI0_MISO
10: a0    pd | lo // GPIO10 = SPI0_MOSI
11: a0    pd | lo // GPIO11 = SPI0_SCLK
12: a0    pd | lo // GPIO12 = PWM0_0
13: a0    pd | lo // GPIO13 = PWM0_1
14: ip    pn | hi // GPIO14 = input
15: ip    pu | hi // GPIO15 = input
16: ip    pd | lo // GPIO16 = input
17: ip    pd | lo // GPIO17 = input
18: op -- pd | hi // GPIO18 = output
19: a4    pd | lo // GPIO19 = SPI1_MISO
20: a4    pd | lo // GPIO20 = SPI1_MOSI

  private SpiConfig buildSpiConfig(Context pi4j, int channel, int frequency) {
        return Spi.newConfigBuilder(pi4j)
                .id("SPI" + 1)
                .name("LED Matrix")
                .bus(SpiBus.BUS_1)
                .address(channel)
                .mode(SpiMode.MODE_0)
                .baud(8 * DEFAULT_FREQUENCY_PI4) //     bit-banging from Bit to SPI-Byte
                .provider("pigpio-spi")
                .build();

    }

Changing this to bus 0 or 1, the spi traffic moves as expected and the neopixel illuminates. I am using a Pi4 and have no access to any Pi Zeros. As with you, sometimes the neopixel has the correct colors, other times just all white. I am not going to attach a scope and chase what frequency the is usually using. I have old notes on setting the Pi HW to maintain a more steady FREQ and reliable operation.

So as I said I have no Pi Zero to use with the scope and verify how it operates. Sorry

[karsteny]

I unfortunately no longer have access to mess with this for the next few months (long story), so I can't exactly test anything. I will say that I did try putting the bus() command on the OLED screen and the LEDs separately, and neither the OLED (which is a proper SPI device) nor the LEDs worked properly on SPI1, so I don't think it's just a timing issue.

[taartspi]

When you are able to get back to this I will be interested to hear the resolve. take care Tom