diyAudio

diyAudio (http://www.diyaudio.com/forums/)
-   Analog Line Level (http://www.diyaudio.com/forums/analog-line-level/)
-   -   cs3318 and arduino (http://www.diyaudio.com/forums/analog-line-level/206157-cs3318-arduino.html)

linuxworks 7th February 2012 03:04 AM

cs3318 and arduino
 
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:

http://farm8.staticflickr.com/7017/6...467be183_b.jpg

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

http://farm8.staticflickr.com/7152/6...6d074156_b.jpg

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 7th February 2012 07:25 AM

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 7th February 2012 08:15 AM

Quote:

Originally Posted by janneman (Post 2895352)
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 7th February 2012 10:28 AM

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 7th February 2012 11:12 AM

Quote:

Originally Posted by Turbon (Post 2895385)
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 7th February 2012 02:29 PM

Quote:

Originally Posted by janneman (Post 2895352)
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 7th February 2012 02:50 PM

Quote:

Originally Posted by janneman (Post 2895352)
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 7th February 2012 02:53 PM

Quote:

Originally Posted by Turbon (Post 2895385)
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 7th February 2012 02:57 PM

Quote:

Originally Posted by ds23man (Post 2895715)

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 7th February 2012 02:58 PM

Quote:

Originally Posted by linuxworks (Post 2895736)
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???????


All times are GMT. The time now is 11:00 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio


Content Relevant URLs by vBSEO 3.3.2