ES9018 I2C controller - Page 4 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Line Level

Digital Line Level DACs, Digital Crossovers, Equalizers, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 16th October 2012, 09:20 PM   #31
glt is offline glt  United States
diyAudio Member
 
Join Date: Oct 2004
gwikse, thanks!

Other comments:

There is a limit on the size of the code, so not everything can be implemented. I think network takes up a lot of code.

i2c address extender is useful for people that may have more than 2 Sabre, more than 2 OPUS, etc.
__________________
www.hifiduino.wordpress.com
  Reply With Quote
Old 16th October 2012, 09:27 PM   #32
gwikse is offline gwikse  Norway
diyAudio Member
 
Join Date: Feb 2010
Location: Oslo, Norway
Quote:
Originally Posted by glt View Post
gwikse, thanks!

Other comments:

There is a limit on the size of the code, so not everything can be implemented. I think network takes up a lot of code.

i2c address extender is useful for people that may have more than 2 Sabre, more than 2 OPUS, etc.
That is why I was hoping that it would be possible to link several 328 chips so that some of the code is located on the extention module (network module, external i2c module etc). I have no idea if this is possible but it would be nice if it was possible. Otherwise a different chip (with more memory) would be the way to go imo.
  Reply With Quote
Old 16th October 2012, 09:29 PM   #33
gwikse is offline gwikse  Norway
diyAudio Member
 
Join Date: Feb 2010
Location: Oslo, Norway
Quote:
Originally Posted by Corpius View Post
How funny is that. I also forgot to add the PCF8574 to the list as well. It is already incorporated, but thanks!

I planned to use the I2C LCD extra IO in combination with the library you mentioned. I am currently using it with my Arduino as well. It doesn't feel slow to me. According to the webpage you where referring to, the library should be almost 5 times faster than the original LCD library.

I have been busy with the design today. It is not final, but this is what I have for so far. The PCF8574 needs to be positioned to a better location and all connections to it are also still not drawn.
Looks very nice. Perhaps an idea to have an adress jumper possibility for the i2c extender?
  Reply With Quote
Old 16th October 2012, 10:33 PM   #34
diyAudio Member
 
Join Date: Jan 2011
Location: sitting down
Quote:
Originally Posted by Corpius View Post
I can understand that it is not needed for the display and the other ICs that are going to be used within the controller, but using it for the outbreaks seems a good idea to me. Maybe you have a good reason to disagree. If so than please share it with me.

Galvanic isolation is OK for the digital signal path so you don't want to polute the dac through the I2C connection from a MC. Who cares about noise for the other I2C devices on the bus. Unless I misunderstood what the other devices would be used for. Also, these components tend to be expensive .

regards.
  Reply With Quote
Old 16th October 2012, 10:54 PM   #35
gwikse is offline gwikse  Norway
diyAudio Member
 
Join Date: Feb 2010
Location: Oslo, Norway
Quote:
Originally Posted by necplusultra View Post
Galvanic isolation is OK for the digital signal path so you don't want to polute the dac through the I2C connection from a MC. Who cares about noise for the other I2C devices on the bus. Unless I misunderstood what the other devices would be used for. Also, these components tend to be expensive .

regards.
Also is it not possible to connect more than one slave to the same isolated i2c connection?
  Reply With Quote
Old 16th October 2012, 10:55 PM   #36
diyAudio Member
 
Join Date: Jan 2011
Location: sitting down
Quote:
Originally Posted by gwikse View Post
Also is it not possible to connect more than one slave to the same isolated i2c connection?

good point. I don't see any problems as long as the isolated devices share the same grounds.
  Reply With Quote
Old 17th October 2012, 05:58 AM   #37
Corpius is offline Corpius  Netherlands
diyAudio Member
 
Corpius's Avatar
 
Join Date: Jan 2011
Quote:
Originally Posted by glt View Post
gwikse, thanks!

Other comments:

There is a limit on the size of the code, so not everything can be implemented. I think network takes up a lot of code.

i2c address extender is useful for people that may have more than 2 Sabre, more than 2 OPUS, etc.
There are ways of dealing with the limited size of the code, but like I wrote I will only use it when I'm able to use it.
I will have a better look at the i2c extender, but there is also limited space on the design . I do not want to end up with a very large controller.

Quote:
Originally Posted by gwikse View Post
That is why I was hoping that it would be possible to link several 328 chips so that some of the code is located on the extention module (network module, external i2c module etc). I have no idea if this is possible but it would be nice if it was possible. Otherwise a different chip (with more memory) would be the way to go imo.
These are indeed some possibilities.

Quote:
Originally Posted by gwikse View Post
Looks very nice. Perhaps an idea to have an adress jumper possibility for the i2c extender?
Good idea, I'll add it to the list

Quote:
Originally Posted by necplusultra View Post
good point. I don't see any problems as long as the isolated devices share the same grounds.
That is a good and cheap solution. I'll add some extra connectors on the "slave" side of the isolator.
__________________
CE-Designs.net
  Reply With Quote
Old 17th October 2012, 06:04 AM   #38
Corpius is offline Corpius  Netherlands
diyAudio Member
 
Corpius's Avatar
 
Join Date: Jan 2011
Updated the list at post 1 again.
__________________
CE-Designs.net
  Reply With Quote
Old 17th October 2012, 07:14 AM   #39
gwikse is offline gwikse  Norway
diyAudio Member
 
Join Date: Feb 2010
Location: Oslo, Norway
Perhaps the code could be altered in order to use the LCDuino system?

A motorized pot driver could perhaps also be an idea to have in this design (thereby having the option to have a pure analog part in the same unit, like f.inst the Alpha20 linestages) or have a proper pot with level indicator on the knob that will turn with the volume?

Edit: also I take it that it is an advantage to use the same port expanders in all the roles you need one in order to save on space in the controller since they will then use the same library?

Last edited by gwikse; 17th October 2012 at 07:18 AM. Reason: typo
  Reply With Quote
Old 17th October 2012, 01:43 PM   #40
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
I wonder how this differs from the lcduino.

the lcduino has been out for over a year now, we put a LOT of work into it and its suitable for your project pretty much as-is. why re-invent the hardware?

fwiw, the lcduino can drive 4x20 displays no problem. mounting is a bit tricky as the board is not a 4x20 sized backpack but it can be done if you really want to.

code size is a major problem with 328 arduino. the code in the lcduino1 is pretty much taking up all there is except for the bootloader

at this point, if you plan to do extensive UI stuff, I strongly suggest you go with an arduino mega. I'm considering that, myself, for 'fancy client work'.

back-end work, I still think arduinos are great and I'm now doing a 2cpu system for my cirrus vol control. by taking a lot of the device specific stuff out of the single cpu and moving into a more 'embedded' one, you free up a lot more space in the main 'ui' one.

4x20 displays also are getting closer and closer to small touch screens or even the mini composite vga displays (backup camera displays for cars). a rasp pi and one of those would make a SUPER user interface. and then a back-end arduino can do most of the very low level work that you may not want to do at the linux side.

anyway, what you describe as your project is already done and essentially the lcduino. I think it makes sense not to redo the hardware but to update the firmware and leverage the hardware design that is already deployed, debugged and available for easy purchase.

what I'm saying is that amb and I put a HUGE amount of effort into this with the assumption that the DIY community would be able to just use it and not have to keep re-inventing it. I'd really like to see people use what we put SO much of our spare time into, rather than see yet another controller project (that is nearly identical) fragment the market even more.
__________________
My Photostream:http://www.flickr.com/photos/linux-works/
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ES9018 - I2C interface vt4c Digital Line Level 0 4th August 2012 01:12 AM
Samsung 1602VFD For CDROM Controller & Remote Volume Controller slowgay Swap Meet 2 22nd November 2008 02:44 PM
I2C controller for Audio DSP elnec Digital Source 6 15th February 2008 10:58 AM
I2c Amdio Digital Source 9 29th April 2007 12:05 AM
I2C Controller abid_rehan Digital Source 1 21st October 2004 10:02 AM


New To Site? Need Help?

All times are GMT. The time now is 06:56 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