I'm trying to bypass any attempted access to the ADC on my Bela Mini, so that I can use the second hardware SPI bus and omit the ADC from my board. I came across this commit in an old thread. Is this improvement still needed in the latest release?
I imagine that bypassing some code in PRU.cpp won't be enough, and I'll have to dig into the assembly. Or maybe I'm overcomplicating things - if I could comment something out to accomplish this, let me know.
I think if you disable the analogs with the appropriate flag then no SPI transaction will be performed. Anyhow, if you are using the other SPI peripheral, then activity on this one should not matter.
giuliomoro Sorry, I should've clarified - I would like to use both SPI busses.
I've built a PCB that's very identical to the Bela Mini cape, but the ADC circuit is removed so that both SPI busses can be broken out. Running board_detect with my cape connected returns BelaMini. The codec seems to be fine, when running i2cdetect -y -r 2 the codec shows up at address 18, as I believe it should. I still get a PRU interrupt timeout error when I run a project, with both -N0 and -N1, which led me to assume there was still an attempt made to read the "fake channels" mentioned in the commit I linked.
Maybe there's a way to get a more descriptive error message instead of just PRU interrupt timeout? I just want to rule out anything I could try in software before building another PCB.
I am on a board with the latest dev branch, and both -N0 and -N1 work fine. I recently added a slightly more meaningful error ... https://github.com/BelaPlatform/Bela/blob/dev/core/PRU.cpp#L931
However, "PRU interrupt timeout" just means that the PRU did not send an interrupt to ARM in a reasonable amount of time, which most likely means that the McASP encountered an error.
-N0 and -N1 are the only two options available, do you mean your board never runs any audio? There are several ways the codec can be wired or soldered wrong, and/or the McASP could be configured wrong in the dtb/dtbo. It's also possible that the PRU hangs when setting up the SPI peripheral if the peripheral (and/or its clock) has not been initialised elsewhere (not sure though).
ebai101 Maybe there's a way to get a more descriptive error message instead of just PRU interrupt timeout
Actually there is such a thing. The McAsp error codes could be read from the PRU and relayed over to ARM. This is already implemented when using pru_rtaudio_irq.p (for the CTAG boards), but not for the Bela capes.
giuliomoro Actually there is such a thing. The McAsp error codes could be read from the PRU and relayed over to ARM. This is already implemented when using pru_rtaudio_irq.p (for the CTAG boards), but not for the Bela capes.
Awesome, this is just what I need. So if I can get the error codes to write to COMM_ERROR_OCCURED, the errors should be printed via PRU::testPruError() right?
giuliomoro -N0 and -N1 are the only two options available, do you mean your board never runs any audio? There are several ways the codec can be wired or soldered wrong, and/or the McASP could be configured wrong in the dtb/dtbo.
The board currently doesn't run any audio, although it is intended to. I plan on using the PocketBeagle's built in ADC for analog input, as it is sufficient for my purposes. I have not modified the device tree from what comes with the Bela image, I do run a script with some config-pin calls on boot to set up spi1 however.
ebai101 So if I can get the error codes to write to COMM_ERROR_OCCURED, the errors should be printed via PRU::testPruError() right?
yes
ebai101 I do run a script with some config-pin calls on boot to set up spi1 however.
make sure you are not messing with any of the pins highlighted with a green frame here. Even better, try without any config-pin and see if that fixes the audio.
