cs3318 and arduino

[linuxworks]

I'm starting my journey on the new (to me) cs3318 8-channel analog volume control chip.

for the last 2 years or so, I have been using singles and pairs of pga23xx chips and now I'm going to give the cirrus 8ch chip a try.

today, I soldered that expensive chip onto a schmartboard:



and since this chip is 3.3v based and my arduino is native-5v based, I'll need i2c level conversion:



I'm using my Volu-Master code base (newer version of what is on AMB.org's website for the LCDuino and alpha10 preamp). since the cirrus chip works very similarly to the pga, it should be a few lines of code change to at least be able to control the master1 fader group (in theory..)

will continue as progress is made...

[jan.didden]

I'm using a CS3318 in my DCX2496 output mod. So if needed I can probably answer questions on driving it when they come up.
At the time I was stilll programming in assembly so the code is probably not very usefull.
Are you aware of the dummy register writes you have to do to overcome a firmware error? Don't know if it has been solved in the chip at the moment but I still do it.

jan didden

[Turbon]

Originally Posted by janneman

I'm using a CS3318 in my DCX2496 output mod. So if needed I can probably answer questions on driving it when they come up.
At the time I was stilll programming in assembly so the code is probably not very usefull.
Are you aware of the dummy register writes you have to do to overcome a firmware error? Don't know if it has been solved in the chip at the moment but I still do it.

jan didden

Jan, why would assembly be a bad choice and unusable today?

Brgds

[nalinb80]

I am also interested in it, however to avoid complexity i will be driving it with PIC24 series PIC , which is 3.3v driven.
Probably will need many help related to this . i am new in the digital control .

[jan.didden]

Originally Posted by Turbon

Jan, why would assembly be a bad choice and unusable today?

Brgds

No it's not a bad choice at all, it's just that for occasional use (not using it on a daily basis) it's not easy to maintain your proficiency.
I now do all my programming on PICs using Flowcode, which is a graphical programming interface on top of C. Works great and has a very shallow learning curve, which is great for occasional use.

jan

[ds23man]

Originally Posted by janneman

Are you aware of the dummy register writes you have to do to overcome a firmware error? Don't know if it has been solved in the chip at the moment but I still do it.

jan didden

http://www.digikey.com/Web%20Export/...f?redirected=1

Regards Gerhard

[linuxworks]

Originally Posted by janneman

Are you aware of the dummy register writes you have to do to overcome a firmware error? Don't know if it has been solved in the chip at the moment but I still do it.

jan didden

have not gotton that far yet. can you give more detail on that issue? does the chip lock up somehow or is this the method they describe known as 'aborted writes' in order to execute a read command?

I'm not even sure I need to do reads. why do you need to read anything? the whole chip is write-oriented and seems like you can fully control it via write-only CSRs.

[linuxworks]

Originally Posted by Turbon

Jan, why would assembly be a bad choice and unusable today?

Brgds

my take is that its too much work and the compilers are so good at optimizing, its rarely needed to do assembler anymore.

for high speed things, sometimes it makes sense; but for example, the arduino code that actually follows the 38k IR signal, bit by bit, is a pure C code software routine. no hardware help was needed other than setting a hardware timer inside.

my whole last project was about 12,000 lines of C code. no way would I ever consider doing that much end coding in assembler! I shudder to think of how many assembler lines that would have been!

[linuxworks]

Originally Posted by ds23man

http://www.digikey.com/Web%20Export/...f?redirected=1

Regards Gerhard

aha! so that's what the issue was.

I did not notice this until you pointed it out

I went all up and down the main data sheet but I guess cirrus did not think it was 'worth the effort' to updat their MAIN data sheet. wow.

thanks!

[ds23man]

Originally Posted by linuxworks

have not gotton that far yet. can you give more detail on that issue? does the chip lock up somehow or is this the method they describe known as 'aborted writes' in order to execute a read command?

I'm not even sure I need to do reads. why do you need to read anything? the whole chip is write-oriented and seems like you can fully control it via write-only CSRs.

If I read the errata correct it is neccessary to write these once after startup for achieving max. audio performance. Nothing to do with reading.

Regards Gerhard

PS Why is this not in the Datasheet???????