Pisound v1.0 MIDI issues (Zynthian)

Pisound Support
1

Back when Blokas was starting up I purchased a Pisound v1.0 back in 2017. Never did get around to using it until recently, when I got myself an RPi5, running Zynthian on it. Zynthian seems to have full support for Pisound; it’s one of the potential soundcards listed in the audio configuration for Zynthian, although I had to select a different devicetree overlay specifically for the RPi5.

The audio part seems to work fine, but when trying DIN MIDI (in) I get dropped and hanging notes. I seem to recall that the MIDI interface uses an MCU which communicates with the RPi using SPI. So I’m wondering if the firmware in the MCU might need an upgrade, considering how old my Pisound is. Or is it something that cannot be upgraded? Can’t really see any information in the forums about it, so I’m guessing it’s not possible, but thought I’d ask just the same.

2

Good guess, you must be running an old firmware version on your Pisound.

See here for info on upgrading the firmware: Pisound + Raspberry Pi 5: Hanging MIDI Notes - #6 by Giedrius

The scripts are not compatible with Pi 5 or bookworm OS, to make the upgrade, please use Pi 2, Pi 3 or Pi 4 and use the older Raspberry Pi OS, based on bullseye or buster Debian versions.

1 Like
3

It very likely is old, I think this was one of the first Pisounds, funded by Kickstarter if I remember correctly.

Thanks for the info on upgrading, I’ve got a Pi3 lying around that I might try with, otherwise, it looks like the core of the upgrade is a device tree overlay which brings in the SPI device so that avrdude can use it with the appropriate .hex file with the firmware.

1 Like
4

The differences between Pi 5 and older models also include different GPIO numbering at the OS level, at least it was like that initially on Pi 5 release. I think at some point they decided to make it match, to make things more compatible, but I haven’t rechecked this since then.

5

I had a buster image which I booted an RPi3 with. Instead of running the flash script as written, I went through the commands manually, since I was apprehensive of the difference in Raspbian version and also the actual drivers in this image. The core of the script is to remove the snd_soc_pisound driver and adding the dtoverlay that adds spidev support, before running avrdude with the appropriate arguments. However, avrdude wanted to use gpio24 which seemed to be in use by one of the drivers in this particular (Zynthian) image. After some fruitless rmmoding I gave up. Booting a bullseye image (also Zynthian, but configured differently) was more hopeful because gpio24 was free, although the numbering was different, so GPIO24 corresponds to gpio536 . At this point I hacked avrdude to use gpio536 instead of gpio24 (see patch below), which seemed to work; running avrdude seemed to terminate as expected:

root@zynthian:~/src/pisound-firmware# sudo avrdude -c linuxspi -p t841 -b 150000 -P /dev/spidev0.0 -U flash:w:pisound.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9315
avrdude: NOTE: “flash” memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file “pisound.hex”
avrdude: input file pisound.hex auto detected as Intel Hex
avrdude: writing flash (1466 bytes):

Writing | ################################################## | 100% 0.85s

avrdude: 1466 bytes of flash written
avrdude: verifying flash memory against pisound.hex:
avrdude: load data flash data from input file pisound.hex:
avrdude: input file pisound.hex auto detected as Intel Hex
avrdude: input file pisound.hex contains 1466 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.40s

avrdude: verifying …
avrdude: 1466 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:D7, L:EF)

avrdude done. Thank you.

Now to test if this made a difference, but it looks hopeful so far.

avrdude patch:

diff --git a/avrdude/avrdude.conf.in b/avrdude/avrdude.conf.in
index 7e83c26..ecc57e4 100644
--- a/avrdude/avrdude.conf.in
+++ b/avrdude/avrdude.conf.in
@@ -1271,7 +1271,7 @@ programmer
   id = "linuxspi";
   desc = "Use Linux SPI device in /dev/spidev*";
   type = "linuxspi";
-  reset = 24;
+  reset = 536;
   baudrate=400000;
 ;
 
diff --git a/avrdude/pindefs.h b/avrdude/pindefs.h
index c060708..df33231 100644
--- a/avrdude/pindefs.h
+++ b/avrdude/pindefs.h
@@ -57,7 +57,7 @@ enum {
 #define PIN_MASK    (UINT_MAX>>1)
 #define PIN_INVERSE (~(PIN_MASK))      /* flag for inverted pin in serbb */
 #define PIN_MIN     0   /* smallest allowed pin number */
-#define PIN_MAX     31  /* largest allowed pin number */
+#define PIN_MAX     1023  /* largest allowed pin number */
 
 #ifdef HAVE_LINUX_GPIO
 /* Embedded systems might have a lot more gpio than only 0-31 */
1 Like
6

Yes, this different pin numbering is one of the reasons why the older OS builds are needed. :slight_smile: This procedure is very rarely necessary though.

It could have been Pisound driver itself blocking the use of the GPIO24. You could unload it:

sudo modprobe -r snd_soc_pisound

The flash.sh script is doing its best to unload as much stuff that could prevent access as possible.

7

No, it wasn’t snd_soc_pisound, it wasn’t loaded at this time. The pin was described as ‘dc’ in /sys/kernel/debug/gpio. I’m guessing it was used by some other hardware that Zynthian was configured to use. I tried unloading the codec drivers with no difference, so it must have been something else.

Yeah, my Pisound is very old, I seem to remember it being a kickstarter project at the time, so it must have been one of the first ones. I thought it was pretty cool, but by the time the card actually arrived I had lost my immediate interest in RPi sound so the card has been packed away since then.

1 Like
8

Ok, most likely it was something Zynthian specific, the scripts were meant to be run on Patchbox OS or Raspberry Pi OS.

Another place to look for GPIO pin reservations is whether there’s any dtoverlays specified in config.txt or some special settings cmdline.txt, but anyway, as you got the firmware upgraded, it should be good to go, just sharing some ideas in case anyone stumbles across this thread. :slight_smile:

1 Like