[linuxworks]

some LCD-less LCDuino-1 work, here:

underside:

what I did here was to build a partial LCDuino-1 and leave out the clock chip, crystal for RTC and pin headers for the LCD module.

this base config can be used as a 'cpu engine' to power simple projects. in this case, I wanted a display-less motor pot IR controller. just real, real simple - an IR receiver that uses 4 volume control buttons (same fast/up, slow/up, etc style) and controls a motorized pot. for now, that's it and that's all I want for this application (its going inside a b22 amp build).

what's new is that I populated the data pins (analog and digital) with headers and created a lower 'motherboard' for the cpu module to sit on. I was going to add screws to the bottom of the board but the tension of all those pins, really just self-hold the thing in place. I added hex spacers just to keep the module a little more stable.

the cpu module feeds thru the 'useful pins' to the motherboard, below. there, the dirty work is done (bwahaha...)

this is where I would plan to have 'application specific' stuff; in my case, a motor-pot controller chip (h-bridge). that's all the 'application' that I need for now but if I needed some relays or push button interfaces, I could make use of the port expander (PE) chip that's sitting on the main green board and meant to be the LCD interface but now can be used as 8 bits of i/o (leds, buttons, buzzers, whatever is a 1 or 0 state).

to program the module, just lift it out of its motherboard and connect the magic $20 cable (lol) to the 6 pins on the LCDuino-1. same as you would if it was bolted to the back of the LCD. I decided not to run 'programming wires' to the back of the chassis for software upgrades since this app won't need upgrading very often. when it does, I'll pop the cover, remove the module and upgrade software out of the box then replace the module and put the cover back on. it will clean up the interior wiring and make a cleaner build, I think.

3 connectors are neede: power-in, IR-in, motor-out. that's it in my simplistic application. power comes in at the top/left and motor wires simply go from the bottom right molex (near the L293D chip) to the motor on the pot.

I need to add a soft 'config' button (like the reset button that is on the green board) to be used to trigger 'learn mode'. even though there's no LCD module, I still plan to support some kind of simple learn mode with even just a single led as the 'ok, go on to next button' indicator. primitive but I want to have some kind of support for learning the vol up/down remotes and not demand that an LCD be installed.

so, this is a demo of using the LCDuino-1 board in a non-lcd way and also how you can feed thru the important pins to a motherboard, below, for the real app-specific work. this way you make the module on top very generic and even replaceable if it goes bad.

 

[ujamerstand]

Good to see that this thread is still alive and kicking! One of the things I can see myself doing with this is to use it as a stand-by module, where it can serve as a rather expansive clock while the amp is off, and when IR detects the ON signal, it'll turn the amp on. And its been a while since prototyping started, so I wanna ask: Prototypers, how's the progress?

and how's the relay attenuator going?

 

[TimmyMac]

Someday I've gotta build a softbox. Do you have a macro ring flash too?

 

[linuxworks]

Quote:

Originally Posted by TimmyMac /img/forum/go_quote.gif Someday I've gotta build a softbox. Do you have a macro ring flash too?

no, I don't use those. those are direct light and direct light often creates shadows that you don't *want*.

I just use a 12" cube made of frosted plexiglass and have lights shine on the outside, creating a diffused light inside.

update on progress: after some hardware debugging I finally found my circuit bug in the relay attenuator (I was not giving 5v to one of the 2 PE chips; missed running that wire on my proto board). I now have a 2 chip version (each PE is now individually addressible) and that will let me work on the new algorithm (staggered writes to each of the bits on each side of the relay; then 'relax' the bits after the relay has clicked in). it seems to basically work right now but needs some tuning. at least I found my hardware error and this lets me progress in the firmware direction (finally)

here's a snapshot of the unit in operation with one PE chip showing 'vol' and the other showing '~vol' (binary complement). look close and you'll see there is motion blur in the volume pot knob; this is real. the motor was 'catching up' to the value that was loaded into the lcd display and the camera shutter was set on a slightly longer duration.

 

[linuxworks]

also what has been keeping me busy is finishing up my 3ch b22 build. this was the first time I tried to integrate some digital control stuff in an amp like this. I have the MVC version (motor vol control) of the LCDuino on the bottom/left corner of the photo (slightly hidden by the chassis):

it has an IR receiver that sits inside the red bezel on the chassis (that came from an incandescent light that I gutted and just kept the red jewel)

that controls the motor pot and all the digital stuff stays entirely out of the way of the analog things. I haven't heard any 'cpu noise' in this arrangement.

 

[glt]

What is the topology of the relay-based attenuator?

 

[linuxworks]

the topology is the same that many use, r/2r. it is a common config.

what is not as common is using latching relays and that requires more timing and on/off steps in software. but the gain is that once 'runup' finishes, all current can be removed and the relay bank retains its settings thru power cycles even with no cpu help.

I'm playing with the idea of strobing the bits in the 8bit byte and timing each relay to keep it biased long enough to latch stably but not longer than it needs (thus freeing up a current sink). just like you can strobe the segments in a 7seg led display (those old things, lol) you can do the same kind of thing with relays if they are latchers.

one PE chip would have 8 bits going to one 'side' of the relay bank and the complementary PE chip would manage the remaining pins on that relay bank. that way you can send a 00 or 11 to them and have them 'do nothing' but you can send 10 and 01 to them to get them to latch in A or B states. you can even high-Z the lines after you are 'done'.

this is the kind of thing I'm experimenting with at the moment.

 

[glt]

R/2R, yes, common implementation. The non-latching relays is an excellent improvement. Are you optimizing by minimizing the number of resistors used in any one level or strictly adhering to the db level?

 

[linuxworks]

not trying to keep R count down. I honestly don't think that's an area that's worth splitting hairs over.

keeping power down (and heat) is a goal, though.

 

[glt]

Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif not trying to keep R count down. I honestly don't think that's an area that's worth splitting hairs over. keeping power down (and heat) is a goal, though.

I remember I worked out the attenuation for all the possible combinations of resistors in a spreadsheet and if one goes about picking the resistor configuration for the desired -db levels, one could see that near the target attenuation level there were close enough values where the number of resistors was smallest. Can't argue if there is sonic differences though

 

[linuxworks]

its very possible to 'carefully pick' the R and # of relays you want. then have the software do tricky stuff to get whatever db levels and steps (even if non-linear) you want.

I don't care about those details. yet.

what I care about is the ability to get 'at' the relays and control their latching behavior on a per-relay (bit) level. if you can do that, the rest is just software magic that can be figured out later (lol).

its a lot more chips to have 2 PE channels (PE chip and relay driver chip) but I think the extra control it gives you -may- pay back. maybe not but I'd rather have it and learn I don't need it than the other way around

 

[ujamerstand]

Hey Linuxworks, if one would like to go all out, and attach as many devices to the LCDuino as possible; how many devices can a single ATMEGA328P support before performance starts to degrade?

Might it have enough processing power to handle three MCP23008 (1 for input select, 2 for balanced relay attenuator), one of these, a rotary encoder, IR receiver, and possibly more?

On a side note, where did you get your flat cable wires from? It's hard to find them in small amounts.

 

[linuxworks]

Quote:

Originally Posted by ujamerstand /img/forum/go_quote.gif Hey Linuxworks, if one would like to go all out, and attach as many devices to the LCDuino as possible; how many devices can a single ATMEGA328P support before performance starts to degrade? Might it have enough processing power to handle three MCP23008 (1 for input select, 2 for balanced relay attenuator), one of these, a rotary encoder, IR receiver, and possibly more?

I have not tried more than 2 PE chips at once but the limit would be a combo of a few things. addressing is one issue; each chip family has a base i2c address (that you can't change) and then usually 2 or 3 user bits that you can set. that gives up to 8 (for 3 bits) devices *of that chip family* on the same i2c bus before you run out of addr's for that family. you can also pick other chip vendors and you get a new bank of addresses you can use when talking to *those* chips. so addressing is not a huge problem but one to be aware of.

you can also mux the control lines so that you create the illusion of having multiple source i2c control buses. don't know if you'd ever need to do that, but its possible (like adding a 2nd serial port, same kind of soft-serial hack but for i2c).

it will also depend on how much time you spend with the device. some devices take 2 bytes to write to their outputs and some take a single 'write-a-byte' style commands. I would think that, at the same speed, the write 1 byte PE chips are going to take less bus time than the 2 byte PE chips (the mcp style you refered to needs 2 bytes at a time to write).

another issue is 'what are you DOING in the big control polling loop?'. I'm scanning the IR receiver and picking apart actual 38khz waves and making 1's and 0's from them and storing that in an IR-rx buffer. that needs quick turn-around time. if you are also polling and writing to many PE chips, you now could take longer to ID an IR keypress or even miss one, entirely. I don't know how many things you can poll and still do 'IR in software' like the arduino does, today.

if things get more and more complex, I would look to defer processing or concentrate it in some other subsection and send 'summary and interrupts' to the main cpu. a webserver or client could be an example where a single arduino can't really do web i/o AND other things at the same time, well. so going multiple cpu may be the only effective way to go. and then you have to have the cpu's talk to each other and that's yet another comms bus

(what was the question, again?)

lol

Quote:

On a side note, where did you get your flat cable wires from? It's hard to find them in small amounts.

I think digikey had some in spools. I occasionally find it at my local surplus store but only on rare occasions. and I've never found good teflon or non-melt insulated ribbon cable ;(

 

[ujamerstand]

So the performance depends on the number of devices fighting for the access to I2S bus, where the potential bottleneck might occur? Also, it depends on the processing time on the input devices, decoding an IR signal and Interpreting user input from the rotary encoder both takes a lot of CPU cycles (lots of loops); where IR decoding takes the most CPU cycles out of all the activities that one might do with an LCDuino-based preamp.

I honestly don't think the I2S bus should be a problem, unless one starts to feed audio signals through it. I am stupid. I am only thinking in terms of what I want to do. (Who knows, one might feed audio signals through it and control LEDs based on the beats or something.) But for an average user of LCDuino, I can only imagine a source controller, one attenuator board or two, and LCD output. When user input is being polled, I2S bus will be used by no more than 3 devices, ie, 1 LCD screen, and 1 or 2 attenuator device for SE or balanced operation, or 1 LCD screen and 1 source selector. If LCDuino executes command like attenuator1 -> attenuator2 -> LCD -> repeat. I don't think there would be any visible lag in the output.

On the other hand, I never thought about how processor intensive a task might be. One might want to reevaluate the priorities of different devices based on how CPU intensive it is.

Quote:

(what was the question, again?)

No worries, your answer is exactly what I need.

I guess somebody just has to try them all out until they get start to see laggy screen display or stuttering volume turning... Can't wait till LCDuino is in production! Please don't make me wait long enough to build my own on perfboards.

 

[ShaneP]

i2s is only used for audio afaik. i2c is a separate bus and is used for commands and other i/o.