New reworked driver for Wolfson/Cirrus Logic audio card

Hias,

A huge thank-you for all the work you've put into supporting the Cirrus Audio card.  Until now I've been using your kernel packages, and have just got round to trying the latest official 4.9 kernel which is also working very nicely.  It's a real shame that the Cirrus card has (or appears to have) gone out of production just when the software support became so good.  The older Wolfson cards are still available, so perhaps I'll get a couple and try modifying them to fit a 40-pin header.  Anyway, thanks again for everything you've done.  I really do appreciate it.

Tim

The Cirrus Card does seem to be out of stock everywhere - what a shame.  I just started working on an alternative ultrasound sensistive microphone, since the electret type I was using has been out of production for years and is now virtually impossible to get hold of.

What other options are there for recording audio at 192kHz with the Raspberry Pi?

Nice case design  .... how will you fabricate? 3 d printer?

Have started work on a proper pcb design.  Trouble is my Kicad skills are limited.  Anybody more gifted out there ?? Please!.  There seems no point in making the daughter board anything other than a Pi hat shape, that way it gets support from the pi itself.  Two problems

1) The wolfson card will overhang one side of the hat card.  The pink /green jack sockets will overhang the edge of both the hat and the pi by (probably) 5.08mm. Nothing I can do to avoid that because the 40 pin headers have to be offset from one another.

2) That will impact your case design I guess.

At the moment, I am thinking of putting an eeprom on the board (which if memory serves me well is on the cirrus version of this audio card).  And some i2c / power holes for flying leads.

I would suggest that the board, whilst having the overall shape of a hat, does not have the slot for the camera flex, and that display flex cutout is left to the end user to cut out, otherwise production costs will rise.

Hi John 

CNC router  : )   Thanks for all your hard work it is much appreciated

Hi Athanasios (and others)

Had some family problems here, so apologies for the delay.  The design is finally moving ahead ..... here is the alpha artwork (eg I have still to wire in the eeprom and change some pads around)  ... It gives some idea of what board space is still open

Hi John

I hope that everything is well now, with you and yours 

Well done for the Great work!

Will be in touch 

My best

Here is version 2 of the PCB  .... anybody see anything wrong?

The wolfson card overhangs this lower edge by 0.45 inches, this is the edge with the jack sockets.  The left hand edge of the wolfson (with the spidfs) sits directly over the left hand edge indent shown above, so the two cards are, in general, offset in this sense too. It would be nicer if the left and right edges aligned between hat card and wolfson card, but that is not possible since it would involve offsetting the 26 way connector and there is not enough space to route the tracks

Here is the last version, the Gerber files are generated, ready to go.  It is the first time I have sent artwork away for PCB production (rather than making the boards myself).

hi John

can you confirm the hardware mods needed to connect the wolfson to an RPi 2/3?

I have:

pin 40 rx to 5

pin 38 tx to 6

pin 35 frame to 4

pin 12 (on wolfson) to 3

remove resistor  r39 .... can I do this by scraping it out with a scalpel/stanley knife? has anyone posted a picture elsewhere showing its location? (my eyes aren't good)

thanks,

chris

Chris,

I hope those are the connections,  they are the ones on the artwork above !  (note that the 8 pogo pins are mirror numbered because of their spatial inversion)

Pages 6 & 7 (and indeed later) of this thread give some further details on the original modification made by Hias (and me).  We differed in our approaches but the two solutions are electrically equivalent.  Like you, I didnt fancy removing the pogo pins and r39.  Instead I opted for a daughter board, which has become the pi hat shown above  ...... this requires zero modification of either the pi or the wolfson card.  However it does demand additional space  ..... and additional money!

If you want to plug the wolfson directly onto the pi then you will need to remove the 8 pogo pins, or shield their tips from making contact with the "mother" board (both these approaches have been documented in this thread).  You will also need either to remove r39 OR cut off pin 12 on the pi 40 way header.  Of the two I would prefer to cut off pin 12 because it avoids me putting a soldering iron near the Wolfson  .... but of course if you ever re-use the pi AND you need pin 12 then you will have a problem.

If you follow the unsolder solution, I must urge you to find a good magnifying glass and check out your board. As Hias has (I think) said, it is less difficult than it looks  ...  the heat from a normal soldering iron direct onto the component will melt both pads (and the component) and it should lift off by capillary action   .... but lift off the wrong component, or surface tension breaks down, or get a solder smear between this and adjacent pads ........ and unsoldering the pogo pins will demand lots of heat .........  Hias has nerves of steel, at least by my standards.

But then that pi hat daughter board I am designing/building is going to cost 25 euros or there about   ...... more than Farnell currently charge for the  Wolfson card!

Where is R39 on the Wolfson card?  Offhand I cannot say, I will need to look at the card when I get back

A quick (and not too dirty) solution that nobody has yet tried is a 40 way idc plug and ribbon (as used on old ATA HDD) and connecting the appropriate wires to a 26 pin header plus the pogo pins.  Not all of the connections need to be made, but Hias will need to say which GPIO the driver uses .... or simply wire them all (switching pin 12 as previously noted)  ..... and remembering the mirror inversion !!!!

Athanasios

Hi.  The artwork is with the pcb manufacturers and the quote for manufacture should be with you  ...... how do you want to proceed???

Best regards

John

thanks John.

but things are confused: there is another thread where you originally gave the mods but including cutting a trace to pin 12 with rewiring to pin 33 ....

and then in this thread R39 was brought up as an alternative to the pin 12 re-route but then R30 was mentioned without .... for why?

so, to short-circuit those ambiguities, is 3 wires from P5 to the Pi 40pin header, and removing R39 enough and can it be done by scratching out the component with a scalpel/stanley knife rather than by solder iron? (I have a friend with good eyes who has found R39 but doesn´t solder!)

thanks a lot

chris

thanks John.

but things are confused: there is another thread where you originally gave the mods but including cutting a trace to pin 12 with rewiring to pin 33 ....

and then in this thread R39 was brought up as an alternative to the pin 12 re-route but then R30 was mentioned without .... for why?

so, to short-circuit those ambiguities, is 3 wires from P5 to the Pi 40pin header, and removing R39 enough and can it be done by scratching out the component with a scalpel/stanley knife rather than by solder iron? (I have a friend with good eyes who has found R39 but doesn´t solder!)

thanks a lot

chris

Chris,

A full reply is probably best, for others that may be reading (oh I flatter myself).  The original thread is correct,  you could cut the trace,  but equally you could remove pin 12 from the 40 pin header. Or equally remove R39. All three are electrically identical. Removal of R39 is the most elegant in my opinion, but carries risks in implementing.

I cannot find mention of R30 anywhere but, if I have missed the reference, it is a typing error, 9 and 0 being next to one another  on the keyboard.

Also on this question I note what I think is a typo on your part.  So just to clarify, when you say "pin 12 (on wolfson) to 3" that should of course read "pin 12 (on pi) to 3"  .... ie as per the pcb layout above.

So to answer your question directly, your approach is one of several possible equally valid solutions.  I would not underestimate the hardness of the component, nor the risk to the PCB, but it is your call.

For the approach that you are proposing,  the description of Hias on page 7 of this thread seems to answer your needs the best.

John

hi John

the R30 is in there a few times! but belonging to Matthias.

here's the full thread:

New reworked driver for Wolfson/Cirrus Logic audio card

I should have said soldering point on the 40pin wolfson  connecter that mates with pin 12 on the Pi, to pin 3 of. P5!

that's right, isn't it?

on your circuit diagram above, it appears to me that the wolfson pin 12 goes to pi pin 33.

how is it that p33 doesn't figure in the other two solutions, R39 and trace cut?

thanks again.

chris

Chris

Hi .  I am pretty sure it is R39 is the one to go,  perhaps Hais could confirm (The reason I am not 100% certain is that my solutions do not involve a board modification, so I have never done this myself). It is R39 that connects the 8804 (spdif controller) to GPIO A (ie pin 12 of the 26 way header). R30 is the pull up resistor on the same line (which, if memory serves me correctly, Hais says to leave:- which would make perfect sense)

Yes, that is right, pin 12 of 40 way connector to pin 3 of the 8 pin header.

Your reading of my pcb is correct. That connection is there for completeness  ...... the board is designed to make the Wolfson card resemble the Cirrus card as closely as possible  ..... but the current (and all previous versions) of the linux driver do not use this line (hence why removing R39 and leaving a weak pull up , R30, is a completely acceptable solution)

psyj  schrieb:

 

I am pretty sure it is R39 is the one to go

Yes, it's R39. It's on the backside of the PCB, located next to R30, near the mounting hole. Here's a picture:

so long,

Hias

John, so you're saying the pin 33 connection is redundant?  thanks

z z

that is correct

John

Hias,

Where can I find the parameter set generated by the driver (and modified by cset commands) please? I need to populate a database of current values and parsing the plain text output given by "amixer -Dhw:0 scontents" takes a great deal of effort

My intention is to continue "-Dhw:0 cset commands to control the device,  but tracking revisions through scontents does not seem wise

Many thanks

John

You can use alsactl store to get a complete dump of the current mixer settings. eg:

/usr/sbin/alsactl store -f my-settings

This'll create a simple to read and parse text file. Linux distributions also use that to get persistent mixer settings across reboots. On shutdown they call alsactl store, on boot alsactl restore.

If you are interested in specific changes from the mixer scripts just call them with sh -x,. eg "sh -x ./Playback_to_Lineout.sh" and watch for amixer calls.

so long,

Hias

Hias,

Many thanks for that alternative approach, it does seem to provide a more readable text file than "amixer -Dhw:0 scontents". My only problem is that it is still a huge file to parse (27000+ lines, 500k file)  ...... but I will see if it parses more easily/ more rapidly.  Either way many thanks,  I will let everyone know how I get on  ..... my final objective is to generate a GUI based on php/html in order to control the device in a rather more informative way than alsamixer.

Regards

John