The LCDuino-1 I/O processor

[amb]

Quote:

Originally Posted by Ynis Avalach /img/forum/go_quote.gif Secondly I wanted to ask if it could be done, and if how, to install a LCDuino into a chassis with a Sigma22 and messure like 4 rails of voltages and output them on a 16x2 or a 20x4 LCD.

You'll need to scale the voltages down (with resistor dividers) so it's within the Atmel chip's A/D input range of 0-5V. The negative rail voltages need to have their polarity inverted to a positive voltage (an inverting unity-gain opamp stage, powered by a dual-rail supply, would work for each of these). The "prototype pads" area of the LCDuino-1 board is ideal for mounting the opamps and extra parts.

There are several A/D input ports, marked _An in the schematic. Connect the "normalized" rail voltages to these ports and modify the firmware to read them and display the values on the LCD. The A/D ports have a resolution of 10 bits (1024).

Obviously, this is not a "plug and play" proposition, requiring some extra hardware and firmware hacking, but is entirely possible.

 

[Ynis Avalach]

Is there a good source or way to start into arduino programming, I started with a C++ book which I will read now.
Because I have no knowledge of programming yet. I know, but it's part of my studies anyway, why don't start there, where their's a big community. It won't be that the LCDuino board will lie on my desk tomorrow. So I thought that that will be a truly awarding project, if I'll get it to work the way I plan it to work in the end.
Greetz and thanks again! Ava

 

[_atari_]

Quote:

Originally Posted by Ynis Avalach /img/forum/go_quote.gif Is there a good source or way to start into arduino programming, I started with a C++ book which I will read now. Because I have no knowledge of programming yet. I know, but it's part of my studies anyway, why don't start there, where their's a big community. It won't be that the LCDuino board will lie on my desk tomorrow. So I thought that that will be a truly awarding project, if I'll get it to work the way I plan it to work in the end. Greetz and thanks again! Ava

I really dig 'Making Things Talk: Practical Methods for Connecting Physical Objects' - ISBN-13: 978-0596510510. It is a very nice introduction to arduino from a 'How do I do this' persepctive.

'Getting Started with Arduino (Make: Projects)' is also a recommendation. But I heard from some friends it does not contain more than Making Things talk.

 

[linuxworks]

I came across this link while looking for IR senders and receivers:

Buffalo Round Micro IR Sensor - IR-350 - Smarthome

looks like a nice idea for mounting the ir receiver/sensor. but a bit expensive considering that the active part is only a dollar ;(

maybe this will get some creative ideas going? anyone have ideas on how to do something like this on-the-cheap in a DIY sense?

 

[linuxworks]

update:

just yesterday, I added support for using a linear single-gang analog pot as an input device, for controlling the volume. it has the advantage of being cheap, easy to find, takes up little space, has good feel and it points to absolute values (when you turn the knob to 12 oclock, you get the volume as halfway, etc).

I 'burned' one analog-in pin for this but I think its worth it

and it works well with the IR arrow-key style input, too. you can use both, and alternate between them if you want. if you turn the pot to some level, the volume goes to that level; then if you bump it up/down with the IR remote, it uses the last value 'seen' and operates on that. and again, the user is free to 'touch up' the knob at any point and it will take priority over the arrow keys.

the 'knob' also takes note of the min volume level and max volume level, as set by the user in the GUI. so even if you grab the vol knob and crank it to max, the system won't blast you out of your room, it will honor the user's max-vol level and never go outside the min/max range.

we're closing in on getting the beta code ready to ship and admittedly this was a last minute addition but I have to admit I like this feature quite a lot, so its going into the beta-test code base.

there is also provision for separate control of input selectors AND output selectors. if you choose name lengths of 8 chars or less, you can show the input selector device name on the top left of the display and output sel name on the top right of the display. IR buttons are assigned for direct access to the inputs and outputs.

(note, we're almost at the 6000 lines of C code-point. this stuff really adds up but there's a lot of functionality in this system)

 

[glt]

Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif update: ... and it works well with the IR arrow-key style input, too. you can use both, and alternate between them if you want. if you turn the pot to some level, the volume goes to that level; then if you bump it up/down with the IR remote, it uses the last value 'seen' and operates on that. and again, the user is free to 'touch up' the knob at any point and it will take priority over the arrow keys. ...

Hi linuxworks, what is the behaviour if you do more than "touch up"? Suppose I turn on the device and the pot is at min, then I use the remote to increase the volume to say mid-vol. If I start turning the pot, does it not increase the vol until pass the mid point?... thanks. Looking forward to looking at your code.

 

[_atari_]

Quote:

Originally Posted by glt /img/forum/go_quote.gif Hi linuxworks, what is the behaviour if you do more than "touch up"? Suppose I turn on the device and the pot is at min, then I use the remote to increase the volume to say mid-vol. If I start turning the pot, does it not increase the vol until pass the mid point?... thanks. Looking forward to looking at your code.

I personally think rotary encoders are easier for this task - because you would have to have an motor pot to keep it in sync with the real volume - which would be nice too.

So many possibilities

 

[linuxworks]

Quote:

Originally Posted by glt /img/forum/go_quote.gif Hi linuxworks, what is the behaviour if you do more than "touch up"? Suppose I turn on the device and the pot is at min

the way the logic works, today, is that only CHANGES in the pot cause the vol to change. powerup uses the last saved vol setting (that could have been gotton to via the knob or IR). if you don't touch the knob, it restores the last used value and does not 'scan' the pot unless the knob moves.

Quote:

, then I use the remote to increase the volume to say mid-vol. If I start turning the pot, does it not increase the vol until pass the mid point?... thanks. Looking forward to looking at your code.

scene: you power on and you had left the vol setting at, say, 3/4 fullscale, and so it ramps up from zero to 3/4 setting and stays there. as soon as you turn the pot, it essentially throws away any last-value and NOW takes its value directly from the percentage of the pot. so, if you had left the pot at near zero (say) and you touched it just a little, it would read the new value (still near zero, say) and then set the volume based on that.

ie, the pot always over-rides any 'increment / decrement' that the IR arrow keys previous asked for. the pot does not 'offset' or 'add' to that value, it *replaces* that value.

that's how it is now. as a first pass, unless there are better ways.

 

[_atari_]

Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif update: (note, we're almost at the 6000 lines of C code-point. this stuff really adds up but there's a lot of functionality in this system)

Is it possible to introduce 'Feature defines' since I can assume that not very much space for custom code is left?

How big is the program (in kByte)?

 

[linuxworks]

Quote:

Originally Posted by _atari_ /img/forum/go_quote.gif I personally think rotary encoders are easier for this task - because you would have to have an motor pot to keep it in sync with the real volume - which would be nice too. So many possibilities

I do plan to have a servo thing going with a motor pot and feedback on the actual position. so, with motors, you can let the pot TRACK and keep up with whatever the current number is on the lcd display. I'm envisioning some way where the user can grab the motor pot, twist it and it won't 'fight' the user, it will take its new value from that and update the display. then you go back to the IR, tweak the value up or down a bit and then *watch* the pot keep up via motor action. that stuff is still yet to be done but its planned.

rotary encoders are also supportable but I did like the idea of an absolute-reading valuator and pots do that really nicely. they are also easier to read as the code is less tricky (I've seen 'twitchy' rot encoders before and I don't like that 'feel').

 

[linuxworks]

Quote:

Originally Posted by _atari_ /img/forum/go_quote.gif Is it possible to introduce 'Feature defines' since I can assume that not very much space for custom code is left? How big is the program (in kByte)?

I have a bunch of #defines at the top and for now, that's how you turn on/off various feature subsets. you can make the unit input-selector only, output-only, both, and so on.

at some point, we want to have a single codebase (if possible!) and have the options be hardware settable (resistor programming on a spare a/d pin?) or at least via the lcd GUI.

code space is about halfway used; but one issue I'm running into is RAM usage! the learning remote eats up a lot of array space since hex key codes are stored in longwords and arrays-of-long could eat up your ram/heap space if you are not careful (I've already run into this where the code would build but not quite download or run properly and shows a mystery set of bugs due to running out of ram).

soon, I'm going to have to start optimizing the code and memory usage, which I have been putting off for quite a while, now

 

[_atari_]

Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif code space is about halfway used; but one issue I'm running into is RAM usage! the learning remote eats up a lot of array space since hex key codes are stored in longwords and arrays-of-long could eat up your ram/heap space if you are not careful (I've already run into this where the code would build but not quite download or run properly and shows a mystery set of bugs due to running out of ram). soon, I'm going to have to start optimizing the code and memory usage, which I have been putting off for quite a while, now

Good to hear.

Perhaps it is possible to store the IR keys in EEPROM.
<computer-science-stuff>
Why don you build some kind of tree map, so that you can walk it down to find the required action.
By that you can get it from EEPROM very fast (reading only out twice the bytes as used in the remote code - pure estimate - code + pointer).
setting up & writing the tree map will be an challenge.
</computer-science-stuff>

But I positively opt for one codebase. Anything else would bring you in codespace hell.

But reducing RAM footprint is essential from my point of view - since others using the LCDuino will be not so experienced in debuggin (aka guessing whats wrong) the stuff than you.

waiting eagerly for the prototype & code beta

 

[linuxworks]

Quote:

Originally Posted by _atari_ /img/forum/go_quote.gif Good to hear. Perhaps it is possible to store the IR keys in EEPROM.

I am. after the learn-sequence is complete, the array of codes is saved in eeprom. I'm using working ram to save temp values and only syncing to eeprom if the user FULLY completes learn-mode. if he bails out in the middle or lets the system time-out, no changes are made (as a safety).

I could not do that if I wrote to eeprom 'always'.

Quote:

<computer-science-stuff> Why don you build some kind of tree map, so that you can walk it down to find the required action. By that you can get it from EEPROM very fast (reading only out twice the bytes as used in the remote code - pure estimate - code + pointer). setting up & writing the tree map will be an challenge. </computer-science-stuff>

for speed, I'm using simple arrays, so that the system can quickly match the incoming hex code (longword) with one in the array.

I'm not sure I want to get too fancy in data structs, b-trees or hashes or linked lists. this is a controller and not a full cpu, afterall

Quote:

But I positively opt for one codebase. Anything else would bring you in codespace hell.

its a good goal but as you add more features, it pushes out the 'generic code base' bit by bit. something creative with overlays (?) might be nice.

one first start is to move away from static arrays and malloc them based on the feature set the user programmed. that way you don't waste storage space (in real ram) on things you'll never use or run.

another trick is to use PROGMEM to store data in flash instead of eeprom; if I start to run out of eeprom space.

Quote:

But reducing RAM footprint is essential from my point of view - since others using the LCDuino will be not so experienced in debuggin (aka guessing whats wrong) the stuff than you.

agreed; the mystery 'it wont run!' will confuse a lot of people if they start editing the code and adding things, not realizing this isn't a pentium with a gig of ram at its disposal. and the debug tools on the arduino don't tell you a lot about how much ram you have left, running out of stack space, etc.

 

[_atari_]

Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif I am. after the learn-sequence is complete, the array of codes is saved in eeprom. I'm using working ram to save temp values and only syncing to eeprom if the user FULLY completes learn-mode. if he bails out in the middle or lets the system time-out, no changes are made (as a safety). I could not do that if I wrote to eeprom 'always'. for speed, I'm using simple arrays, so that the system can quickly match the incoming hex code (longword) with one in the array. I'm not sure I want to get too fancy in data structs, b-trees or hashes or linked lists. this is a controller and not a full cpu, afterall

Yes, but if you assume, you can create a data structure in which you can compare incoming byte by bite until you reach an answer you can easily compare the incoming 'live' IR signal to the EEPROM.
I personally think tha you have not pentium at readout time, but you can take as long as you want at write time - this will not be easy.
Let's have a closer look at the code after the prototype is soldered up.

Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif its a good goal but as you add more features, it pushes out the 'generic code base' bit by bit. something creative with overlays (?) might be nice. one first start is to move away from static arrays and malloc them based on the feature set the user programmed. that way you don't waste storage space (in real ram) on things you'll never use or run. another trick is to use PROGMEM to store data in flash instead of eeprom; if I start to run out of eeprom space. agreed; the mystery 'it wont run!' will confuse a lot of people if they start editing the code and adding things, not realizing this isn't a pentium with a gig of ram at its disposal. and the debug tools on the arduino don't tell you a lot about how much ram you have left, running out of stack space, etc.

If I remember correctly, you can write it only after reboot. No matter - I think there is enough non volatile memory at hand - volatile memory is the problem.

I think the idea of getting memory with malloc is a good idea - since if you cannot malloc enough memery you still can create an error message instead of dumbly crashing.

Let the code mature by some people. It will be hard at the beginning - but there will be a good solution

 

[amb]

Update: LCDuino-1 prototype boards and parts, as well as pre-programmed microcontrollers are being shipped to the prototype team.