controlling a shift register with phasor~ via spi

Fedde

Hi,

I'm working on SPI controlled analog switches with Bela, Arduino and max349 ic's. I want to be able to route audio on sample rate to 80 different speakers.
The current workflow is the following. I use pd's phasor~, that is rounded to 16 voltage steps and is send to one of Bela's analog outs The voltages correspond to the 16bit's of a shiftregister that is inside a nice chip named MAX349. It controls 8 analog switches with a shift register.
For converting the ADC value I currently use an Arduino and the bits are pushed with SPI from the Arduino. All this works fine but it's a bit of a waste to use an analog port on the Bela when there is SPI on the beagle bone.
I am wondering if this procedure can be translated making use of only Bela.

giuliomoro

We are using one of the SPI ports for the ADC/DAC, and I am not sure if we are using some of the pins of the other port for something else. Good thing is you probably do not need a very high bandiwth, so you can use soft-SPI on the Beaglebone for this. This consists in toggling a GPIO pin "as fast as possible", often reaching transmission speed in the range of a few hundred kHz (while using the dedicated SPI port you could go up to a few tens MHz) and can be done through a standard Linux driver.
This would involve some C++, but whether you are using Heavy or libpd, the C++ code can be integrated fairly easily: https://github.com/BelaPlatform/Bela/wiki/Puredata-and-C--

There probably are a number of examples online of how to do SPI on Linux, also using the soft SPI driver. One good example is in our codebase: https://github.com/BelaPlatform/Bela/blob/dev-ctag/core/Spi_Codec.cpp
Check in particular the constructor and destructor (which open() and close() the device), and then the _spiTransfer method, which does the actual transfer. If you do this while the audio is running, you will need to run this in a separate thread. There is need to load a device tree overlay for this to work, e.g.: this one.

If you need higher bandwidth you could also use the other PRU to "bitbang" one of the PRU's GPIOs. I got this to work at 8MHz here.
If you are fine with the bandiwidth of Linux's soft-GPIO, I would discourage the PRU option, though, as it is more complicated and involved.

zajili

Hello everybody,

As stated in the title, I'm trying to use a the hard-SPI interface SPI0. I'm using the SPI bus to sample some devices and I need an SPI frequency greater than ₅₀₀ kHz, which is why I need to use a hardware SPI. Here is the version I'm using :

Image:
v0.3.8h, 5 January 2023
Core code:
Last updated on '29 Aug 2025 16:37:39 '
from file '/root/Bela/updates/Bela-master.zip'
via 'make update'
Update was successful
Git desc: 'e43b8abe-dirty'

After navigating through some posts related to SPI on this forum, I understand now that the SPI0 interface/pins are already in use to communicate with the ADC for analog inputs. I don't need these in my project so I assume I can safely disable them as stated here or here.

I'm not very familiar with Linux kernel and I'm having trouble finding how to disable the analog inputs properly, or what flags are being referred to in the second link.
Using the IDE switch button for "Use Analog" and disabling it, it appears I managed to disable the analog inputs (I checked by printing BelaContext values). I then modified the SPI communication example (that is used for Bela Mini) and changed the struct use for setup by this :

	spiDevice.setup({
			.device = "/dev/spidev3.0", // Device to open
			.speed = 500000, // Clock speed in Hz
			.delay = 0, // Delay after last transfer before deselecting the device
			.numBits = 8, // No. of bits per transaction word
			.mode = Spi::MODE1 // Spi mode
			});

I modified the device field according to bela_hw_settings.h and the mode field to suit my device.

However I have the following issue when trying to run the example code :

PRU interrupt timeout, -1 110 Connection timed out
McASP error, abort

So here are my questions :

1) How do you properly disable analog inputs only ? Which flags is @giuliomoro talking about ?
2) What is causing PRU interrupts to timeout (I guess this is related to McASP failing) ?
3) I know that PRU can be programmed to run a soft-SPI at 8Mhz according to the reply below. I might also give this method a try. Regarding the GPIO, I guess I should use the available I/Os described here ?

giuliomoro If you need higher bandwidth you could also use the other PRU to "bitbang" one of the PRU's GPIOs. I got this to work at 8MHz here.

giuliomoro

Actually, if you do not need Bela's DAC, you could connect your SPI device in parallel on the same SPI bus and using the same chip select line, so you run all on one PRU and you can send data to it simply by sending to a [dac~ ] object without changing the C++ code. You will have to change the device initialization code and the data width in pru_rtaudio.p, but this is another option.

giuliomoro

Although if this is the sort of things you are doing, then the Linux soft-SPI may be too slow ? For sure, it is not sample-accurate! You would be able to get at most one speaker change per audio block, is that acceptable?
You may be better off using this solution I reckon:

giuliomoro Actually, if you do not need Bela's DAC, you could connect your SPI device in parallel on the same SPI bus and using the same chip select line, so you run all on one PRU and you can send data to it simply by sending to a [dac~ ] object without changing the C++ code. You will have to change the device initialization code and the data width in pru_rtaudio.p, but this is another option.