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
How to handle trinary values
Re: How to handle trinary values
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.Don_Kirby wrote:Normally, I would use a simple Byte variable with each bit representing an LED.
- Don Kinzer
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
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
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.Don_Kirby wrote:The project only calls for a maximum of 2 groups of 8. for a total of 16 channels (32 individual diodes).
What is the fastest you'll be updating the LED state?
- Don Kinzer
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.
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.
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.Don_Kirby wrote:I had always treated that rule as if the limit were the same in either direction. Is this not true?
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
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:spamiam wrote:I have been informed that sinking current is only subject to the individual pin limit, not the total budget.
Further, in the "Absolute Maximums" section, the maximum current for Vcc and Gnd is listed as 200mA.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.
- Don Kinzer