Thanks for this answer, which I think is incorrect for my version of the RPi (B+) but it helped me to find the correct answer.
Free GPIO pins are connected to the Expansion Header on the Audio Card. The Expansion Header is the header next to the SPKOUT connections. Pin 1 is the pin right next to SPKOUT R+.
The available GPIO pins are as follows:
Exp pin RPi pin GPIO
1 2 5V
2 - 3.3V
7 6 GND
8 6 GND
13 6 GND
14 29 5
16 22 25
17 31 6
18 32 12
19 36 16
20 37 26
There is (now after 2 years) another question to that point.
In addition to Wolfson CLAC on my RPi 2 B Model, i want to have a 2*16 LCD beeing fed via 4bit mode.
In total, this requires all of the six free pins left on Extension Pin Header. (mentioned above, GPIO 5,25,6,12,16,26).
That means: no GPIO left! But in the same time there i need another three GPIO PINs to be used for user interaction.
I already regret having decided for CLAC because of this design aspect that i was not aware of in advance.
But I looked in the manual
and found another free PINs "unused" (GPIO 4,27,24) (on page 15 of 21). Those are not available on the expansion header.
What is your guess, may it be possible to use them e.g. by contacting via a (not yet designed) break-out PCB?
Thanks for your contribution!
Assuming you are correct about the free pins, have you seen https://www.piborg.org/triborg?
It may do what you want. BTW, I am not compensated or have this, so lets us know what you think if you try it.
that Piborg PCB is exactly the kind of board that i was thinking of! Thanks for that hint.
Going through the CLAC documentation, I found that the mentioned RPi-GPIOs (BCM 4,24,27) are actually routed from the 40Pin header to input PINs of the sound processors on board of CLAC. But, "unused".
Anyway, the following warning is provided on p. 16 of the CLAC "user documentation"
Unused functions need to be treated carefully. Although they are not enabled in the current driver they provide scope for increased functionality going forward.
So, using them might cause trouble with future driver roll outs.
(on the other hand, will there reallly be so many driver updates in regard of the fact that they have stopped selling the card?)
As I already faced a lot of struggling with this card, I will check and let you know about my experience.
(it will maybe take some time until i have checked.)
Hi Gero, Hi Clem,
An other way to intercept unused GPIO signals between Pi and CLAC can be done with these kind of boards:
and then replace the 40 pin header with one with long pins like:
Then you can stack all on top of each other without modifying your Pi or CLAC
I use it myself to add functionality to a pizero / phatdac combination, but soon I intend to add rotary controllers and relay boards to my clac sets too.
The mere 6 GPIO pins transposed to the expansion header will be used up quickly.
As Hias rewrote the driver after 2 yeas of nothing from Cirrus Logic, He might be able to confirm the unused pins are really unused the the current driver.
thanks for your contribution. Meanwhile, I ordered that 40pin- piborg 1:3 replicator board mentioned above.(There is no question that Marcel's idea would work as well)
In this case, my idea was:
- the first replicated 40pin row would be used to connect a LCD which already takes all six GPIOs being normally routed to the 20-pin external header of CLAC.(here futher difficulties, it seems that the external Pins jitter, (at least the LCD shows corrupted signs whereas those do not appear if it is directly connected on RPi without CLAC)
- On the second row of the replicator board, i would simply pinch off the corresponding pins (PIN4,PIN18,PIN13) before connecting CLAC.
- this will cause floating pins at CLAC input.
- to intercept GPIOs (GPIO4,GPIO24,GPIO27) by using the third 40pin row on the replicator board. I need them for additional I/O functions of my Raspbian/KODI project.
To investigate on the concept, i tried writing on (GPIO4,GPIO24,GPIO27) with directly connected CLAC (using PIGPIO).
- with GPIO24 and GPIO27, i did not encounter any problems.
- GPIO4? not that sure, it seems that this pin is pulled to "LOW".
At this point, it seems to be useful to ask Hias for his inside knowledge of the drive functionality....Hopefully, my writing is understandable for everyone reading this.
What are your ideas, futher suggestions?
Have a nice week,
BTW: does anyone have a clue how to adress Hias?
Matthias does follow this forum , he will answer if he has some time.
There is also some more info in the other threads , and I need to revisit them too, as there are useful pins on the expansion header of the CLAC itself I need to use for a rotary controller and IR in and output.
My ultimate goal would be to add the rasptouch power switch/board too, and drive a relay to power an external amp and thus use about each and every unused GPIO pin from my Pi.
So a full list of unused , otherwise available and even forwarded GPIO pins should be compiled.
I just checked pinouts.ru , and no hits, but we could use that to document what we have and expand that with help of the community.
GPIO27 (WM5102 IRQ) is used by the new, reworked driver - it wasn't used by the older driver (but probably also driven by wm5102). GPIO4 should be safe (it's an input to WM5102), but not sure why you measured low on it. GPIO24 should also be safe as the WM5102 GPIO pins aren't enabled by the driver.
A better solution would be to use an I2C expander like the PCF8574. I've used one of these to hook up a HD44780-compatible VFD display to the RPi and it worked fine in parallel to the Wolfson/Cirrus card.
thanks for that PCF8574 hint. I would go for that idea.
What I have in mind is the following statement from the "CLAC user documentation", Annexe 7f, p.16.:
"Please note that I2C and SPI are functions utilised on the card so these cannot be changed for other functions."
For me, it is not clear if and how accessing the I2C bus ressource is feasable without disturbing CLAC functionality.
My first attempt would be to send the needed signals on the I2C bus by calling Python methods. (BTW, i have pigpio in use.)
OK, but no idea if this would work in parallel with the CLAC driver or maybe only stand-alone?
So Hias, i would like to ask you for brief overview how the CLAC driver accesses the I2C ressource of the PI
and how those two applications could use the I2C system resource of the RPI simultaneously?
I2C is designed as a shared bus with one master and up to 128 slaves and unless 2 devices use the same address (check with i2cdetect for unused I2C addresses) that should work just fine. The Linux kernel takes care about bus access management, so multiple programs/drivers can use the same I2C bus, but whenever one program/driver transfers data the others have to wait.
The Cirrus Driver accesses the I2C bus to configure the WM8804 chip on start and end of playback/recording. While playing/recording the I2C bus is "free".
It's been a while since I used the I2C expander / VFD display but I'm pretty sure everything's still working as before. So just give it a try.