Are there any free GPIO ports that I can use? If so, which ones?
What would be the best way to use them? Soldering?
Thanks!
Are there any free GPIO ports that I can use? If so, which ones?
What would be the best way to use them? Soldering?
Thanks!
From the user manual: Cirrus Logic Audio Card User Manual, here is a chart:(15-20 look available)
Thanks fvan For showing where.
Clem
PS. the best way is to use headers soldier on so you can connect other cards and/or use them with correct wires.
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
Hello all,
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!
Gero
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.
Clem
Hi Clem,
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.)
Greets,
Gero
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.
Regards M
Hi all,
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:
To investigate on the concept, i tried writing on (GPIO4,GPIO24,GPIO27) with directly connected CLAC (using PIGPIO).
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,
Greetz,
Gero
BTW: does anyone have a clue how to adress Hias?
Hi Gero,
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.
Greetz M,
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.
so long,
Hias
Hi all,
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?
Thanks,
Gero