Page 1 of 1
How to handle trinary values
Posted: 05 February 2011, 17:17 PM
by Don_Kirby
My current project incorporates groups of 8 bi-color LEDs for a display module. Programatically, I would like to treat each group as a single item, but I am unsure how to do this. Normally, I would use a simple Byte variable with each bit representing an LED. Obviously this doesn't work with a 3-state device. A Boolean array won't work, while a Byte array would, but is wasteful of memory.
Ideally, the method I am looking for would allow for operations on the group as a whole, rather than having to cycle through individual variables.
-Don
Re: How to handle trinary values
Posted: 05 February 2011, 19:05 PM
by dkinzer
Don_Kirby wrote:Normally, I would use a simple Byte variable with each bit representing an LED.
You could use an UnsignedInteger with eight pairs of bits (either adjacent bits or one in the high byte and one in the low byte) to represent the state. Alternately, you could use two separate bytes and put the state information in the corresponding bit positions of the bytes.
Posted: 05 February 2011, 19:18 PM
by Don_Kirby
I am currently working with the latter method, which works fine, but feels a bit clunky. I'll chalk that up to the mediocre coder sitting at the keyboard...
Posted: 06 February 2011, 7:19 AM
by GTBecker
Have you designed the hardware interface yet? The bit placement would perhaps be best determined by how you control the LEDs. An integer of 8 bit pairs per group seems rational.
Two-lead or three-lead LEDs?
Posted: 06 February 2011, 9:06 AM
by Don_Kirby
The hardware is open for modification. I'm in the conceptualizing stage currently.
The choice between 2 or 3 lead LEDs is arbitrary. More importantly, reducing the required number of I/O pins required (without adding additional components) is the goal. that said, my breadboarded version is using 2 lead LED's, connected to a voltage divider to both +Vcc and ground. Logic 1 turns on one color, Logic 0 turns on the other, tristate turns both off. This method is for testing only though, as the constant current through the divider is not acceptable for the final product.
-Don
Posted: 06 February 2011, 10:05 AM
by GTBecker
How large an array? At two pins per LED, you'll be needing to multiplex the drive of a display of any consequence, I suspect.
A bipolar multiplexed persistence-of-vision LED array drive starts to sound challenging.
Posted: 06 February 2011, 10:13 AM
by Don_Kirby
The project only calls for a maximum of 2 groups of 8. for a total of 16 channels (32 individual diodes). To make the project a bit easier to prototype, I am working with only 4 channels, representing 8 diodes.
Posted: 06 February 2011, 10:42 AM
by dkinzer
Don_Kirby wrote:The project only calls for a maximum of 2 groups of 8. for a total of 16 channels (32 individual diodes).
An I2C I/O expander may provide a convenient way to drive the bi-color LEDs using two of its output pins per LED. The 8-bit PCF8574 could handle four bi-color LEDs and the 16-bit PCF8575 could handle an entire group of eight.
What is the fastest you'll be updating the LED state?
Posted: 06 February 2011, 12:04 PM
by Don_Kirby
I think a realistic value might be in the range of 100ms between updates minimum. This should provide for no discernible visual delay.
From a hardware perspective the I2C approach would be fairly easy to implement. Something like a MAX6955 would offer all of the I/O needed plus matrix key decoding and debouncing.
Without ignoring the current draw requirements, I wonder if it would more efficient, considering component counts, costs, and board design and layout, to use a microcontroller with more available I/O pins. Although I do most of my software development and hardware prototyping with a ZX24n, I was planning on a 328 for this project. Maybe a ZX40/44 would be a more direct approach to handle the I/O requirements.
Posted: 07 February 2011, 7:42 AM
by spamiam
Don_Kirby wrote:Without ignoring the current draw requirements..
Remember, the uC can sink more total current than it can source. Each I/O pin is (as I recall) good for 20mA sink/source, but the total current it can source is limited (less than driving all I/O pins at full current).
Just FWIW
-Tony
Posted: 07 February 2011, 9:05 AM
by Don_Kirby
I had always treated that rule as if the limit were the same in either direction. Is this not true?
Posted: 07 February 2011, 10:40 AM
by spamiam
Don_Kirby wrote:I had always treated that rule as if the limit were the same in either direction. Is this not true?
I had thought so, but I have been informed that sinking current is only subject to the individual pin limit, not the total budget. The budget applies to sourcing current.
I'd have to look at a representative datasheet to be sure. Maybe Don can confirm this.
-Tony
Edit:
I just looked at the ATMega328 datasheet.
It indicates
1) 40mA MAX per pin
2) 200mA max on the VCC
AND GND pins.
So this would suggest that my statement is WRONG. the limits for sink and source are THE SAME. Sorry. I could have sworn that the uC can sink more than it can source....
-T
Posted: 07 February 2011, 12:27 PM
by dkinzer
spamiam wrote:I have been informed that sinking current is only subject to the individual pin limit, not the total budget.
Note that aggregate limits apply to porta A and C taken together and ports B and D taken together. The footnotes in the "D. C. Characteristics" section of the mega644P datasheet say:
3. Although each I/O port can sink more than the test conditions (20mA at VCC = 5V, 10mA at VCC = 3V) under steady state
conditions (non-transient), the following must be observed:
1.)The sum of all IOL, for ports PB0-PB7, XTAL2, PD0-PD7 should not exceed 100 mA.
2.)The sum of all IOL, for ports PA0-PA3, PC0-PC7 should not exceed 100 mA.
If IOL exceeds the test condition, VOL may exceed the related specification. Pins are not guaranteed to sink current greater
than the listed test condition.
4. Although each I/O port can source more than the test conditions (20mA at VCC = 5V, 10mA at VCC = 3V) under steady
state conditions (non-transient), the following must be observed:
1.)The sum of all IOH, for ports PB0-PB7, XTAL2, PD0-PD7 should not exceed 100 mA.
2.)The sum of all IOH, for ports PA0-PA3, PC0-PC7 should not exceed 100 mA.
If IOH exceeds the test condition, VOH may exceed the related specification. Pins are not guaranteed to source current
greater than the listed test condition.
Further, in the "Absolute Maximums" section, the maximum current for Vcc and Gnd is listed as 200mA.