Ward I was also wondering in what order are the digital pins read or written? 0 -> 15?
From https://github.com/BelaPlatform/Bela/blob/master/pru/pru_rtaudio_irq.p#L754-L761:
//takes 30ns in total to go through the following two instructions
SBBO r7, r2, 0, 8 //store r7 and r8 in GPIO1_CLEARDATAOUT and GPIO1_SETDATAOUT
//takes 145ns to be effective when going low, 185ns when going high
SBBO r4, r3, 0, 8 //store r4 and r5 in GPIO2_CLEARDATAOUT and GPIO2_SETDATAOUT
//takes 95ns to be effective when going low, 130ns when going high
that's not a typo: the instructions are executed in 30ns, but the time it takes for the values to be propagated to the GPIO pin are as stated. So, pins on the GPIO1 bank are written all at once (thought they propagate 40ns earlier if going LOW than if going HIGH), and pins on the GPIO2 banks are written all at once (similarly small offset between LOW/HIGH) a few ns later. Effectively, all pins should change state within about max 50ns between the first and the last one to transition.
The digital inputs are read about 400ns before writing to them : https://github.com/BelaPlatform/Bela/blob/master/pru/pru_rtaudio_irq.p#L696-L701
Ward To what should I connect the ABC lines? MUX1A, MUX1B and MUX1C or MUX2A, MUX2B and MUX2C?
Either will do. Get 1
for simplicity. In the PRU code, the 1
counter and the 2
counter are incremented at half sampling rate (I think). If you are happy with that (i.e.: reading twice the same muxed channel), leave the code as is. Otherwise here (https://github.com/BelaPlatform/Bela/blob/master/pru/pru_rtaudio_irq.p#L2178-L2186 )
// If enabled, update the multiplexer settings
// Change mux settings for ch0-3 after reading ch. 3
QBBC MUX_0_3_DONE, reg_flags, FLAG_BIT_MCSPI_FIRST_FOUR_CH
MUX_INCREMENT_0_TO_3
MUX_0_3_DONE:
// Change mux settings for ch4-7 after reading ch. 7
QBBS MUX_4_7_DONE, reg_flags, FLAG_BIT_MCSPI_FIRST_FOUR_CH
MUX_INCREMENT_4_TO_7
MUX_4_7_DONE:
you could change MUX_INCREMENT_4_TO_7
in the last but one line to MUX_INCREMENT_0_TO_3
to increment the counter every sample instead (again, I think), which kind of(*) doubles your effective sampling rate.
* in both cases you are reading each muxed channel every Fs/nMux
times per second, but in the stock case you are reading each muxed channel two times in a row, while in the patched case you are reading each muxed channel once and then move on to the next one. This is more desirable because you are sampling your signal uniformly and can detect faster changes regardless of where they happen with respect to the clock's phase.
Ward so we don't accidentally choose a pin to use with the GPIO library that's used by the CTAG cape for soft spi
fair point