Is the Raspberry B+ GPIO passed through with the Cirrus Audio card?

There is a table in the user manual with the remaining I/O on the expansion header.

In this table (e), pins 16-20 are ALL described as "General Purpose Pin GPIO 3", which looks to me like a copy/paste error from the pin 15 description.

It would be nicer if table (e) were to read:

However, there are discrepancies between this table (e) and the description within the schematic that need to be figured out.

Pins 10 and 11 are flipped between the schematic and table (e). (In the schematic, pin 10 is listed as PDMOUT_DAT [3] while table (e) says pin 10 is SDA. And vice versa for pin 11.) Which is correct?

In the schematic, pin 14 is listed as connected to "GPIO5_EX [7]", which SHOULD correspond to PI GPIO 5 (PI pin 29). However table (e) lists pin 14 as being GND. Which is correct?

In the Cirrus Logic Audio Card Comparison Table, it says that there are 8 PI connections (including the UART). The UART is connected to the Cirrus J8 Header. (RPI pins 8&10)

Can anyone confirm definitively which are the other two GPIO pins that are tied directly from the PI into the Cirrus expansion header?

• Expansion header pin 15 and 16 are marked GPIO4 and GPIO3, but those appear to be connected to GPIO4&3 on the WM5102_CSP137 chip instead of the RPi GPIO pins.
• Pin 14 might be one of them if the schematic is correct but table e is not.

Any definitive clues?

Thank you again. I am sorry, I've misread your previous comment (and not looked at the schematic and table attentively.) Now I've done this.

The user manual definitively needs major corrections. What is not clear now is what are pins 15 and 16 on the expansion header, if they are not GPIO4 and GPIO3.

9 GPIO pins passed through from the RPi doesn't sound very bad, but what worries me very much is that the SPI bus pins (GPIO9, 10 and 11, not counting CE0 and CE1) are not between them. So how can I use any SPI device then?

Another note. According to the Cirrus Logic Audio Card Comparison Table, the previous Wolfson Audio Card had only 3 available Pi GPIO pins, including UART. Is that true? It follows that using the new one would be a better choice. But on the old card and RPi I could access the general protocol pins, in particular the SPI bus because the whole RPi P1 header was available. Am I right?

The pdf user manual I downloaded is not text searchable, at least I cannot search it with Linux evince. Is this my fault?

Correct, pins 15&16 are marked GPIO4&3. But if you look at the schematic, you will see that those are GPIO connections from the AUDIO chip, and NOT the RPi. And I haven't seen any reports of anyone finding an interface for controlling those audio chip pins.

You cannot directly use an SPI device when the audio board is mounted. But you can use UART and I2C.  If you >really< need SPI, you'll need to use a bridging device between I2C or UART and SPI.

The older Wolfson Audio card has the same architecture as the newer board: it plugs into the RPi J8 header AND has contact pins to the P5 interface, then uses most of the available RPi GPIO pins for its own purposes, including the P5 GPIO pins. Your choices are limited.

Hope this helps.

Thanks for looking up the 15 & 16 pins.

"You cannot directly use an SPI device when the audio board is mounted."

Why? To my knowledge, the SPI control pins are general: the clock, MOSI and MISO are shared between all SPI devices (like on the I2C). There is one pin dedicated to each slave, a CHIP SELECT (and maybe some other pins too, depending on the device). I have an nRF24 device connected to my Raspberry now, what seems that I should abandon if I enter the Wolfson/Cirrus world. Do you see any reason for not using the SPI bus for several devices?

"But you can use UART and I2C.  If you >really< need SPI, you'll need to use a bridging device between I2C or UART and SPI."

I am not sure what kind of bridging device you mean, but if it would be a protocol translator chip, for ex. from SPI to I2C I would definitely avoid this. The I2C interface implementation on the Raspberry PI is quite (I would say "very") limited. It does not allow repeated starts (by the software driver), which already hinders the use of some devices. It also supports only single-master setups (by hardware), so you should carefully design your network. But you may understand if I would stay clear from translating other (and quicker) protocols to I2C.

Regarding the UART, it's fine but allows a connection with only one device and you should decide to disable or not the kernel console on it. If you leave it enabled, you have a "single master" only operation (commands only from the connected device). If you disable it, you can implement a duplex communication (where each device can initiate write), but you loose the kernel messages.

I am thinking of connecting the RPi to a controller (an Arduino), but even this has issues, knowing the mentioned limitations.

For SPI, you're making a few assumptions:

• that you can get at the pins for CLK, MOSI and MISO. They are not passed through to the audio card expansion header.
• that they haven't been reassigned to other uses by the audio card. We don't know the answer to this.

Some people have played around with resoldering some of the audio card connectors to gain access to hidden pins like CLK, MOSI, and MISO. Feel free to try that and let us know how it goes.

With the Wolfson card, because of the P5 spring-loaded connector, there was little leeway to access the pins >from below< the audio card. But with the Cirrus Logic card, I don't see any reason that something like Element 14's RTC shim board wouldn't work.

So you MIGHT be able to do something similar to the shim board to access the CLK/MISO/MOSI pins. They MAY or may NOT work for you as SPI access. Go go for it and let us know what happens.

The thing to remember with the Wolfson and Cirrus Logic audio cards is that they were designed to take advantage of the RPi's capabilities to provide high-quality audio features. To do that, those cards use a LOT of the RPi's resources. Anything else we get to do with the RPi after that is a bonus. :-)

Hi Tony,

No, I am not making the assumption that the SPI bus pins are exposed. I know they are not, and that is what makes me wonder: why have the designers decided to hide them? In general, there should be no reason for that, except in some (unusual) cases.

In the schematics I see these 4 pins (MIS, MOSI, SCLK, SS) routed to the corresponding CIF2XX on the WM5102 chip (the RPI pins enter into IC U8, what seems to be a level shifter). From this I conclude that they are used for their purpose, in an SPI protocol and not been "reassigned to other uses", if you meant that. This also means that they can be used for other devices too (except SS). All SPI devices in a module share the same bus pins, ignoring them if their SS slave select pin is not active. So the question remains.

(I could go and try this with some experiments, but I don't have a Cirrus card yet. I am trying to figure out if it is worth buying one.)

May I ask if you could search through the "Cirrus Logic Audio Card User Manual.pdf"?

I agree very much with you in that a Cirrus card takes a lot of RPi's resources. But what worries me more, is the quality of documentation (very poor) and the lack of support. Is somebody at Cirrus reading and taking notice of these discussions? Or is there a place we can show some of these to a competent personnel (thinking of your table, etc.) ?

In Windows the pdf CLAC user manual also not text searchable (it searches only in small parts of text like tables and command examples).

Yes, and looks like there is nothing relevant to your question in the manual, any way.

Zsolt Gere Kiss wrote:

 

Hi Tony,

 

No, I am not making the assumption that the SPI bus pins are exposed. I know they are not, and that is what makes me wonder: why have the designers decided to hide them? In general, there should be no reason for that, except in some (unusual) cases.

In the schematics I see these 4 pins (MIS, MOSI, SCLK, SS) routed to the corresponding CIF2XX on the WM5102 chip (the RPI pins enter into IC U8, what seems to be a level shifter). From this I conclude that they are used for their purpose, in an SPI protocol and not been "reassigned to other uses", if you meant that. This also means that they can be used for other devices too (except SS). All SPI devices in a module share the same bus pins, ignoring them if their SS slave select pin is not active. So the question remains.

(I could go and try this with some experiments, but I don't have a Cirrus card yet. I am trying to figure out if it is worth buying one.)

May I ask if you could search through the "Cirrus Logic Audio Card User Manual.pdf"?

I agree very much with you in that a Cirrus card takes a lot of RPi's resources. But what worries me more, is the quality of documentation (very poor) and the lack of support. Is somebody at Cirrus reading and taking notice of these discussions? Or is there a place we can show some of these to a competent personnel (thinking of your table, etc.) ?

I cannot speak for the Wolfson designers - I don't know why they made some of their trade offs. I think they've heard loud and clear, though, that GPIO access is important to RPi designers.

However, their bottom line design rule appears to have been to provide access to a high-quality audio board. Everything else seemed to be secondary for them.

If that's your highest priority, as it was mine, then the answer is clear. If something else is more important, then your mileage will vary.

Searchability of PDF files is entirely dependent on the tools used when they are built. These do not appear to be searchable. But they are perfectly valid PDF files.

A number of people have asked similar questions to what you're asking. There's no consensus on any answers yet.

I have put together a complete table to capture the 26/40 way pins for the B and A+/B+ and the use of these pins on both the Wolfson and Cirrus cards. Hopefully this helps bring the information together and highlights the functions and availability of pins on the card. If there are any comments or feedback on the information please provide here, I think this will be useful based on the questions in the forum so I will pass the information on to E14 with the aim of adding to the user manual.

26/40 Way Pin allocation and function

Based on Tony's table of the 8 available GPIOs, I have updated this to include additional information. To clarify the 8 referenced available GPIO are numbers 6 to 13 in the table. I2C and SPI are functions utilised on the card so these can not be changed for other functions.

Thank you, Scott, it looks great and very helpful!

"Although they are not enabled in the current driver they provide scope for increased functionality going forward."

Does it mean I can use those "unused" GPIOs as is, or I need to hack kernel driver somehow to make them free for using?

>  Does it mean I can use those "unused" GPIOs as is, or I need to hack kernel driver somehow to make them free for using?

I guess it means that you could use them now as is, if you'd want this very much, but you are not advised to do so, because they can be used some time in the future (drivers), for "increased functionality going forward"

>  Does it mean I can use those "unused" GPIOs as is, or I need to hack kernel driver somehow to make them free for using?

I guess it means that you could use them now as is, if you'd want this very much, but you are not advised to do so, because they can be used some time in the future (drivers), for "increased functionality going forward"

If so, I'm happy to hear that! It solved half of my alleged problems.

I have some comments about using "semi free" or "unused" GPIOs of Cirrus Logic AC. I mean GPIOs 04, 24, 25, and 27.

In my project I use RPi with CLAC and SleepyPi to make battery powered field recorder for animal sounds. To make possible these three boards be connected I had have to make an adaptor from Exp. header of CLAC to Sleepy. To managing power of Rpi Sleepy needs GPIOs 24 and 25. 25 is present in CLAC Exp. header, so at the beginning I wanted to use it as is. But it didn't work, and when I checked voltage on this pin, my multimeter showed 0.7V, but not 3.3V. I measured this pin voltage in all combinations of boards (I have Rpi B+, couple of RPi A+, two CLACs and two Sleepy Pi) - results were the same. On Rpi without audio card and normal Raspbian loaded, those GPIOs of course had 3.3V when I switched them to High. Finally I have used "true free" pins from Exp. header, and everything is working properly.

Thus, these pins (at least 25th), it seems, can not be used as normal GPIOs, despite the fact that they are unused in this version of the CLAC driver.

Thanks for the feedback. We believe we have discovered and resolved the cause of the problem in the 3.18 driver which has been just been released. The GPIO pin of the WM5102 was incorrectly configured as an output, in the 3.18 driver this is now configured as an input. This issue was stopping the use of GPIO25 from the Pi as reported by Ivan W.

Correct me if I'm wrong, but from reading this thread it seems like one needs to use (some of) the 20 Expansion Header pins for GPIO access.

If this is the case is there a recommended 2 x 10 pin ribbon cable ?

Thanks