The LCDuino-1 I/O processor
Mar 14, 2010 at 10:55 PM Post #346 of 403
Quote:

Originally Posted by cobaltmute /img/forum/go_quote.gif
Detented encoders can get ugly.

I've got my own working Arduino code that drives a PGA2311 from a rotary encoder on interrupts. I used a 24 PPR, 24 detent encoder as my first test. The problem is that if you actually look at the maps, 1 pulse != 1 detent. Over 1 detent on that encoder, 1 would be getting 4 interrupts using both encoder channels. I've made it work so that one detent equals 1 step, but the code drops alot of readings. Working with interrupts, there was no way I could can spin the encoder fast enough that the Arduino couldn't keep up.

Now that was a $2 mechanical encoder. It works well enough, but there is a nice 32 detent, 8 PPR optical encoder at Mouser for $20 that I'm going to order for when my PCBs come in. The datasheet shows that it should not have that issue.



If you set the interrupt to detect only rising of one channel then you only read one interrupt per detent.
 
Mar 14, 2010 at 10:59 PM Post #347 of 403
Quote:

Originally Posted by Juaquin /img/forum/go_quote.gif
Yeah, I'm not sure about the smoothness or how fast it'll move, but I'm thinking an ATTiny2313 (for the two interrupts) with a little bit of software, just enough for interrupt handling and throwing some data at the main processor. Hopefully that'll catch most of the turns, especially without the abstraction layer of the Arduino library. If anyone has suggestions for good encoders I'm all ears. I mostly like the idea because you don't have to worry about mismatch between the IR input and the state of the pot, or use a motorized pot.

To be clear, I'm mostly doing this for myself so although I'll make the design available for all (if I can come up with a good one), I don't expect it to be an "official" part of the LCDuino project. Don't listen to anything I say because I'm probably wrong
biggrin.gif



I think this chip is designed to do that http://www.lsicsi.com/pdfs/Data_Shee...183_LS7184.pdf
 
Mar 15, 2010 at 12:50 AM Post #349 of 403
Quote:

Originally Posted by glt /img/forum/go_quote.gif
I think this chip is designed to do that http://www.lsicsi.com/pdfs/Data_Shee...183_LS7184.pdf


Looks good, but do you have a source where these could be found consistently and in quantity? I found a couple one-offs here and there, but unless Mouser/Digikey/Newark/etc sell them consistently it wouldn't help much to design something around it.

The ATTiny2313 might not be built specifically for the job, but it's cheaper (than the LS7183's I can find), easily available, and easily hacked/reprogrammed.
 
Mar 15, 2010 at 1:07 AM Post #350 of 403
using a general purpose and small sized cpu would be a good idea, I think. the code could be extended and adapted to the purpose, as designs change. adaptability is worth something.

if that chip could be an i2c player (slave) and have enough internal buffering so that it might 'compress events' and burst that summary up to the host upon i2c query, that would be cool as hell and a nice way to offload the UI details of RE's.

if there are any existing (good) protocols (between host and the RE subcontroller chip) it would be good to consider reusing one rather than inventing a new one.


edit: I just looked at that pdf. it does not have an i2c interface, it does not have any kind of buffering (that I could find), it does not compress events and its mostly a realtime converter of quadrature to 'pulses'. that may be useful in *decoding* it but I'm not sure that it offers enough of an acceleration to make it useful. slightly, but we can do better with a custom and small cpu, I think.
 
Mar 15, 2010 at 3:56 AM Post #351 of 403
Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif
using a general purpose and small sized cpu would be a good idea, I think. the code could be extended and adapted to the purpose, as designs change. adaptability is worth something.

if that chip could be an i2c player (slave) and have enough internal buffering so that it might 'compress events' and burst that summary up to the host upon i2c query, that would be cool as hell and a nice way to offload the UI details of RE's.



i2c would be easy because libraries already exist for the Arduino and ATTiny's. Then just send an update every 20ms or so with the counter (positive or negative) of all the RE inputs during that 20ms. That'll take the load off the Arduino, especially with respect to interrupts, while still allowing good volume control, I think. I'll breadboard it together over spring break and see what happens.
 
Mar 15, 2010 at 4:56 AM Post #352 of 403
Quote:

Originally Posted by jtostenr /img/forum/go_quote.gif
What are the dimensions of the board?


Currently the δ1 board driver section is 3.2" wide and the attenuator section is 4.8" wide. Both are 2.6" deep. This is not cast in stone, and may change in future revisions.
 
Mar 15, 2010 at 4:00 PM Post #354 of 403
there will be standard firmware and it I believe you will be able to get chips preprogrammed with the code on it. so its simply a matter of hooking up 5v, running some cables as documented and that's it.

we will compile a few sample BOM listings for common configs (8 relays, half db steps; 7 relays, 1 db steps, etc) and this will make picking your resistor sets easier. you can create your own but you don't have to; you can use one of the standard ones.

use of the device will be simple and will work similar to other ones.

but if you want to customize things, that's where all this extra stuff comes into play. but its entirely optional; the system is designed to be simple to install and use, by default. its still just a fancy volume control with line-in connectors and line-out connectors
wink.gif
 
Mar 15, 2010 at 4:16 PM Post #355 of 403
Quote:

Originally Posted by vixr /img/forum/go_quote.gif
crap... I was hoping to put this on my B22...its quickly getting waaay over my head. sigh...


Vixr, there has been a lot of talk here about the "what-if"s, like rotary encoders and other possibilities that would require you to do some engineering of your own, including firmware.

However don't let that talk confuse you. Getting this all to work in a standard manner won't be much more complex than using a regular stepped attenuator. It will be just the matter of stuffing the LCDuino-1 and δ1 boards (the arduino chip will be available pre-programmed) and connecting power, ground and some other wires.
 
Mar 15, 2010 at 5:27 PM Post #357 of 403
Quote:

Originally Posted by Olli1324 /img/forum/go_quote.gif
Will remote control operated volume be supported upon release? (i.e parts requirements, firmware changes if necessary)


Yes.
 
Mar 15, 2010 at 5:39 PM Post #359 of 403
Quote:

Originally Posted by Olli1324 /img/forum/go_quote.gif
Will remote control operated volume be supported upon release? (i.e parts requirements, firmware changes if necessary)


the system is designed around the 'learning-receiver' method; this means that it should work with most existing remotes and you go thru a guided learn dialog when you first configure the system and teach it which buttons on YOUR remote you want to be volume-up, down and so on.

so, that's one less part you have to order or worry about
wink.gif


as for firmware, we'll have some standard releases and, like any software, there will be interim updates or bugfixes as needed. as a user, you are free to use the as-shipped firmware or try newer versions as they come out. at any time, you can also roll-back to older versions, safely, if you wish. the controller chips are in the $5 range (give or take) and one strategy is to keep one chip with 'as shipped' firmware and another as a playground. that way you can always bump the playground chip's version up and test it out; but not have to wipe it and reflash it to revert. I sometimes have older firmware 'saved' in a spare chip since its pretty quick to just swap chips and mark one as 'production' and one as 'latest beta'.
 
Mar 15, 2010 at 10:40 PM Post #360 of 403
Quote:

Originally Posted by amb /img/forum/go_quote.gif
Vixr, there has been a lot of talk here about the "what-if"s, like rotary encoders and other possibilities that would require you to do some engineering of your own, including firmware.

However don't let that talk confuse you. Getting this all to work in a standard manner won't be much more complex than using a regular stepped attenuator. It will be just the matter of stuffing the LCDuino-1 and δ1 boards (the arduino chip will be available pre-programmed) and connecting power, ground and some other wires.



sweet! I have a pretty good AMB labs collection going and this is real tip of the spear stuff...I'm gonna buy one and give it a shot.
 

Users who are viewing this thread

Back
Top