Each pin on the PocketBeagle (or the BeagleBone) can be assigned to have one of several functions, using the pinmuxer (pin-multiplexer), I wrote a bit about pinmuxer here.
PaulELong Related to that, when I try to reference the PocketBeagle Expansion Headers diagram, I'm not sure I understand how to read it. There are some boxes that have dotted lines, other than have bright green, and then other's that look like they are highlighted vs being colored in. Is there a legend or description that helps clarify the diagram?
If you are looking at this, then the solid colors are as they were found on Beagleboard's original diagram (a more modern version of which, including a legend, is in figure 42 here). They represent some of the function that the pin can assume. On top of that, I overlaid in semi-transparent blue the Bela digital pins, and in a green square with a brief description, the pins used by the Bela core.
The pinmuxer can only be programmed from kernel space in order to change the function of a pin. There are two ways of doing so: device tree overlays, and
config-pin, which is the easiest on the PocketBeagle. More details on that are here. The overlays were introduced by Beagleboard on the BeagleBone Black, and in principle each overlay is the digital equivalent of a given cape: you can physically attach a cape, but in order to enable its functionalities you have to load the overlay that tells the computer what is connected where. On the BBB you can load capes while the computer is running, using the
capemgr (cape manager), however this is now being phased out, and on the PB you can only load device tree overlays at boot. On the PB, the only way to change pins while the computer is running is to use
config-pin can only control those pins that in the device tree have been assigned to a specific "virtual cape". The Bela device tree overlay disables the virtual cape for those pins that are critical to Bela's functioning, which is why for some pins you get
pinmux file not found! Pin has no cape (SPI0 is used by Bela, and you should not use it for anything else).
The overlays also take care of doing something more than setting the pinmuxer: they ask the kernel to load a suitable device driver. In the case of
config-pin, the driver is already loaded in the device tree.
Now, what are these commands actually doing?
config-pin P2.25 spi
config-pin P2.27 spi
config-pin P2.29 spi_sclk
config-pin P2.31 spi_cs
They are telling the PB to enable the specified pinmuxer configuration for the specified pin. After running
config-pin P2.25 spi, for instance, P2.25 will cease been a GPIO (which is the setting it needs to have in order to work as a Bela digital), and is instead connected to the SPI1.MOSI (master-out-slave-input) signal. At this point, toggling GPIO41, the signal that is normally assigned with it, will have no effect, but the pin can be used for SPI communication. This will not be a "soft" SPI, but a "hardware" SPI *.
PaulELong , so that's ok as long as supercolider doesn't cause interference when it starts.
If I have been any clear until now, Supercollider CANNOT cause any interference, because Sc (through Bela) controls the GPIO pins, but these pins are no longer connected to the GPIO signals now, so anything that happens to the GPIOs will not be reflected there).
PaulELong Is there a hardware SPI overlay I can use?
You shouldn't need it. The
config-pin settings above should do instead of the overlay. Note that I think that
/dev/spidev1 corresponds to the pins labelled
/dev/spidev2.1 is the device actually available on P9.25-27-29-31.
Hope this helps.
* a SPI peripheral has several pins which provide functions such as SCK(serial clock)/MISO(master in slave out)/MOSI(master out slave in)/CS(chip select).
Soft SPI: the operating system toggles each pin individually and controls the timing. This requires a lot of CPU time and the speed is therefore very limited (< 100kHz).
Hardware SPI: the operating system configures the peripheral, and then for each transmission it writes one or more "words" in one go. The SPI peripheral (i.e.: some dedicated circuit on the chip) generates the necessary serial signal. This requires very little CPU time (because the data transmission itself is performed by the dedicated circuitry) and the speed can be much higher (up to 24 or 48MHz on the PB/BBB)