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?

Good call. I've seen only now the whole schematics, sorry.

Yes, some of these errors I pointed out too in my comments to the CL manual.

Pin 14 is GPIO 5 for sure. It is wired physically to the Pin 29 in 40-pin header.

Pin 11 (Not Pin 10!) is wired to the Pin 03 of 40-pin header - GPIO 2 (SDA1, I2C). So, Pin 10 could be PDMDAT.

As far as Pin 09 is SCL, and (I checked) it is connected to the Pin 05 of 40-pin header - it's GPIO 3. So the Pin 16 of Expansion header should be something else.

Both of pins 15 and 16 are not connected to any of pins of 40-pin header.

So we have 6 GPIOs that are tied directly from the RPI into the Cirrus L Expansion header (Pins 09, 11, 14, 17, 18, 19, 20).

This is what can be easily verified by a simple multimeter.

Sorry, I mean 7 GPIOs, of course...

If what you say is correct, that means I count 9 GPIO pins that are passed through from the RPi, the 7 GPIOs (not 6) you list (Pins 09, 11, 14, 17, 18, 19, 20) that are passed through the Expansion header, and 2 more that are passed through the J8 header.

I put together this table for my own notes and figured I'd share it:

Of course, this doesn't match the number 8 that is mentioned in the Cirrus Logic Audio Card Comparison Table. No reconciling that yet.

Sorry to ask, what do you mean by GPIO pins that are passed through from the RPi? How can I access those? (I don't have a Cirrus card yet).

The Cirrus Logic Audio Card (and the Wolfson Audio Card before) have a few headers sticking up. In particular, the Cirrus Logic Audio Card has a header known as the J2 Expand (or Expansion) Header and another header known as J8 (marked UART on the CL), some of whose pins are direct connections to (i.e., pass-throughs of) the GPIO pins on the Raspberry Pi itself. The other pins are instead connected to various features of the Audio Board itself.

For more information, see

• the table in previous posts for which CL header pins are hooked to which RPi pins,
• the user manual (which currently has some typos in it), or
• the schematic.

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.

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"

Scott, many thanks for this and for passing the information on to E14. Could you pls. correct "SCL I2C" in the table to "SCL1 I2C"? (there are 2 I2C interfaces on the RPi, and that is from intf. 1)

Also, if you could ask E14 to generate the doc pdf-s as for them to be searchable, it would be great. I don't think this to be too complicated, but the current manual is very, very hard to use. You cannot search any text, but neither can you copy and paste most of them, should it be a link, for example (text in tables *is* searchable, but normal text is not). I had to manually enter the (long) link from Annexe 7 d. of the "Schematic diagram" (have to enter this as well;), and on top of that, as I remember it was wrong, linking to the schematic of the Wolfson audio card! So please, can somebody at Cirrus check the links validity as well? Thanks,

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

Scott,

Your table suggests that the SPI control pins are still exposed through a header called J9. While this is good news, I am sorry to not find this header on the Cirrus schematics. Maybe I've missed it, but if not, would you be so kind to ask them for an update?

Thanks,

  Zsolt