ES9018 I2C controller - Page 5 - 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 17th October 2012, 02:15 PM   #41
CeeVee is offline CeeVee  Portugal
diyAudio Member
 
CeeVee's Avatar
 
Join Date: Dec 2006
So what you are saying is that you could get together and revamp lcduino maybe ?
  Reply With Quote
Old 17th October 2012, 02:22 PM   #42
gwikse is offline gwikse  Norway
diyAudio Member
 
Join Date: Feb 2010
Location: Oslo, Norway
Quote:
Originally Posted by linuxworks View Post
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.
Do you have links to anyone using your controller with a TPA Buffalo DAC?

I did not think that this would be a problem, it never occured to me that this was anything other than fun DIY.

Could your code be used on an arduino in the background and the GUI related stuff be run on a rasp pi with a cool display?
Are you thinking of releasing a controller solution with more programming space and easy programming from a computer (usb instead of the FDTI cable)?

I must say that I dont think anyone wants to step on anyones toes. Many people like me have lots of ideas and throw them out like crazy, then someone takes the idea and makes it a reality (wich is partly the case with this project). The LCDuino was not considered by me due to it`s somewhat limited programming interface and that there are lots of other arduino incarnations out there but I still have not seen a 20x4 LCD piggyback solution.

Edit: I would love to see a open source LCDuino buffalo control solution using the standard LCDuino with a 16x2 display. That way I could keep the display on both my units (DAC and Beta22 / Alpha20 Headphone amp / Preamp) identical.

Last edited by gwikse; 17th October 2012 at 02:25 PM.
  Reply With Quote
Old 17th October 2012, 02:27 PM   #43
CeeVee is offline CeeVee  Portugal
diyAudio Member
 
CeeVee's Avatar
 
Join Date: Dec 2006
Quote:
Originally Posted by gwikse View Post
....
Edit: I would love to see a open source LCDuino buffalo control solution using the standard LCDuino with a 16x2 display. That way I could keep the display on both my units (DAC and Beta22 / Alpha20 Headphone amp / Preamp) identical.
Yes !!! how many DIYers here would love that....many i suspect.
  Reply With Quote
Old 17th October 2012, 03:46 PM   #44
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
Quote:
Originally Posted by gwikse View Post
Do you have links to anyone using your controller with a TPA Buffalo DAC?
I don't.

Quote:
I did not think that this would be a problem, it never occured to me that this was anything other than fun DIY.
its good karma to support the authors and it helps offset the fairly large development costs (mouser, etc) that we put into this. the code is free, the design is free (all for non-commercial use). all that we'd ask is that, if the project is close enough, that you don't reinvent the wheel and leverage an already proven and reliable product.

Quote:
Could your code be used on an arduino in the background and the GUI related stuff be run on a rasp pi with a cool display?
I think that's the best way to do any 'app', these days. the argument for a rasp pi 'ingredient' (haha, sorry) is too compelling. here's a stupid little display (attached photo) that is under $20 and could possibly be made useful if the fonts and widgets are kept minimal, so that even cheap composite will render things well enough. the pi board can run x-windows and you get fonts, colors, shapes, menus, all that stuff for free. and you also get an onboard serial port for free. plus some other ports.

you get a mature networking stack, tcp/ip security, webserver, cgi, you name it.

yes, I think any serious app should be thought of as a client/server pair with a linux front end on a cheapie board and possibly a controller back-end that does timing crititical stuff AND abstracts the vendor-specific stuff to some more abstract interface (my pref is serial and even more so, typeable ascii, if possible).


Quote:
Are you thinking of releasing a controller solution with more programming space and easy programming from a computer (usb instead of the FDTI cable)?
I like the arduino system for what it is. I don't like having usb onboard anymore since I've had to use the raw uart (as a serial port, with raw ttl) and having the usb ftdi stuff is not needed and might even be in the way. if the user wants to adapt ttl to usb, let that happen outside the box. you can choose that way. if you embed it, you are stuck with it. having things talk over serial is a big plus to me and I would not want to clog that port with a usb dongle. I also like xbees. but again, outside the box is best. send ttl out to the box and adapt that to the various things you might need.

Quote:
Edit: I would love to see a open source LCDuino buffalo control solution using the standard LCDuino with a 16x2 display. That way I could keep the display on both my units (DAC and Beta22 / Alpha20 Headphone amp / Preamp) identical.
the direction I'm going in for the current lcduino firmware is split client/server. my new vol control stuff is not going to be onboard the display system, its going to be its own embedded arduino and it will be a slave that abstracts the vendor crap^H^H^H^Hstuff and presents a more usable and friendly interface, over serial.

my suggestion is to also follow that style. create an arduino (328 is overkill but it has a lot going for it, to keep with the 328 skinnydip28 chip) that sits on the serial port, accepts user config commands and then 'does the vendor equiv' by sending i2c or spi or whatever to the dac chip.

then, that serial interface is the way you write control/display apps on the lcduino. lcduino then becomes a fancy terminal, sort of it will have some more room inside to be more of that generic control interface, and the serial thing at the other end will handle all the vendor chip programming.

what that also buys you is that you can have a 'simple' client (like lcduino) or an advanced client (rasp pi) and they would both use the same serial interface and talk to the same embedded 'proxy' arduino chip.

anyway, my 3.14 cents worth for today
Attached Images
File Type: jpg 8013333386_087eb3f9e1_z.jpg (200.0 KB, 312 views)
__________________
My Photostream:http://www.flickr.com/photos/linux-works/

Last edited by linuxworks; 17th October 2012 at 03:51 PM.
  Reply With Quote
Old 17th October 2012, 03:58 PM   #45
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
Quote:
Originally Posted by CeeVee View Post
So what you are saying is that you could get together and revamp lcduino maybe ?
I do plan to have the lcduino become more generalized and less of a direct device manager. but to do that, requires that another controller be there, somewhere, to handle the local board specific stuff.

in its v1.x state, its an all-in-1 system and its pretty maxed out, already, in code space. the only way forward, really, was to split out the functions and 'go distributed'.

so, if other projects adapt that client/server architecture, its very possible to plug and play various clients (lcduino can be one) and servers (an arduino translator for the buffalo style chips could be one) and be able to choose the interface that makes the most sense for the particular build (in some cases, NO display or buttons at all; as a lot of people are going 'all web' or all phone).
__________________
My Photostream:http://www.flickr.com/photos/linux-works/
  Reply With Quote
Old 17th October 2012, 04:28 PM   #46
Corpius is offline Corpius  Netherlands
diyAudio Member
 
Corpius's Avatar
 
Join Date: Jan 2011
Quote:
Originally Posted by linuxworks View Post
its good karma to support the authors and it helps offset the fairly large development costs (mouser, etc) that we put into this. the code is free, the design is free (all for non-commercial use). all that we'd ask is that, if the project is close enough, that you don't reinvent the wheel and leverage an already proven and reliable product.
I own an arduino and have a modified version of hifiduino for controlling my DAC, but I do not like the way that all connections to it are made. Using shields could provide some solution to it, but then it becomes to bulky for me. I have had several discusses with Gwikse about this in the past, so that's why I decided to build a solution myself and for anyone that is interested.

It's not about reinventing the wheel. Gwikse pointed out the lcduino to me, but I still have not checked it out. Besides that it is more fun for me to design it myself to suit my needs. That's the essence of an DIY project to me. I think that it is rather strange to more or less ask me not to proceed with it because it already exists. That's the same as asking anyone not to design a DAC or amplifier because there are already proven and reliable designs.
btw I did already support AMB by buying two sigma 11 PCBs. There great supplies and the lcduino is probably too, but like I said. I'd rather design it myself, because it's fun to me and it's also good for expanding my knowledge by digging into matters like AVR's, programmers, I2C, SPI etc etc.
__________________
CE-Designs.net
  Reply With Quote
Old 17th October 2012, 04:28 PM   #47
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
another really big win you get by separating the device from the UI is that, last time I checked, the ESS high end stuff was still not open and the specs were not open. if you 'wrap' that vendor stuff in user friendly serial ascii, anyone is free to talk to that instead (as a proxy) and they don't have to sign any NDA or anything with ESS.

I think that was the original turn-of for me about ESS chips. you could not really release free software about their stuff.

BUT, if some chip is fully front-ending their services, I can't see how they'd be able to say no to that new ascii interface.
__________________
My Photostream:http://www.flickr.com/photos/linux-works/
  Reply With Quote
Old 17th October 2012, 04:35 PM   #48
gwikse is offline gwikse  Norway
diyAudio Member
 
Join Date: Feb 2010
Location: Oslo, Norway
I would rather have a simple display in one unit (preforably a noritake VFD HD44780 compatible, due to poor eyesight). I love the idea of having a master unit and the others just having a controller with no display if I understand you correctly but then I dont need a LCDuino (I can just use an arduino wich has more options to link with the master controller).

The more elaborate display I would prefer to have on my smartphone (android or iphone) and use it as a remote.

Also I think you misunderstood me, I was not asking about using your entire code, only the IR learn function. So I would think that since you are so against this controller the right way to go on is to write code for that functionality over again from scratch.
And btw. the "redo" as you called it is actually a mere coinsidense, the PE chip was used due to the fact that it is in use on the lcdIOextender from elektrofunLTD and since it was in use there it became a natural choice to use in other parts of the project as well since the library could then be used for several functions.
If the LCDuino was ready to run a TPA buffalo dac I would have chosen it a long time ago. If code becomes awailable I might buy two of them, one for the Pre/head amp and one for the DAC. But as it stands now I will stay with my DACT attenuator and manual input selector on the Pre/Head amp until I see a solution that suits my needs or come up with one on my own.
  Reply With Quote
Old 17th October 2012, 04:35 PM   #49
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
well, again, if your goal is to help the ess chips be 'managed' and have a front end, I think there's a good solution that I outlined that uses existing technology and adds to it in a non-overlapping way. I would be willing to help and contribute to such a project.

if, however, your intent is to reimplement the stuff that amb and I already did and made available to the community, then I have no interest in helping the project or giving code or support to it.

I think there is space enough for all and that parts of the solution still exist and can be implemented in a complementary way. I'd like to suggest that way forward, if I may.
__________________
My Photostream:http://www.flickr.com/photos/linux-works/
  Reply With Quote
Old 17th October 2012, 04:41 PM   #50
diyAudio Member
 
linuxworks's Avatar
 
Join Date: Jul 2008
Location: santa clara, CA
Quote:
The more elaborate display I would prefer to have on my smartphone (android or iphone) and use it as a remote.
I think that's the direction the state of the art is going in. more and more, its mobile web as the first thought about 'remote control'. I still like IR and other methods, but any new development, imho, should include a 'web story' as well.

the trick is to plan for this from the very start, not shoe-horn it in later on.
__________________
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 12:32 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