I will address the LED question later this evening. It's a long technical explanation as to why things do what they do and unfortunately I don't have the time at the moment 
RandyT
Ok, as promised, here's an explanation why LED's shared with an input *must* light when the shared input's button is pressed.
But first you have to understand how the data lines on this particular microcontroller can be configured. Each port (8 data lines) can be configured as either:
Input: this enables internal pull-up resistors which leaves all pins on the port at around +5v when not affected by external components. When you hook up a button switch to a data line of the port in this state and the other terminal to ground, pressing the switch will complete the path of ground to the data line and drag that line down to close to 0v. The reason this doesn't create a dead short and damage something is that fact that the internal components keep this from happening. When the voltage on the data line goes below a certain threshold, the CPU will sense the change and can act upon it.
Output: In this state, the data lines are at close to 0v. When the microcontroller decides, based on logic in the firmware, that it needs to send a signal to an external device, it can raise this voltage up to about +5v. When the anode of an LED is connected to a data line in this state and the cathode is connected to ground (usually through a resistor), the CPU can raise the voltage level of the line and the LED will light.
Open-Drain or tri-state output w/high impedance input (or bi-directional): The cpu can be used as a high-impedance input or current sink. This is the method used to share an input with an LED. There is greater resistance on the port when configured in this manner, and therefore the threshold to trigger an input is lower. But as the buttons are connected straight to ground, bringing the line below this threshold is not a problem.
Now, the anodes of the shared LEDs are connected to +5v and the cathodes are connected to the data lines of the open-drain configured port. The data lines of the port are told to stay in high-impedance mode by default which keeps current from flowing through the LED to light it.
Here's where it gets a little weird. LEDs, like any diode, need about .6v of forward voltage to cause the current to flow through it, making the diode light. Once the voltage drops below this level, the diode will go dark. If the threshold of the high-impedance input is below .6v, the LED can be off, while still not triggering the input. Exactly how this is accomplished in the situation in question is not important for the purposes of this explanation.
What is important, and the answer to why the LEDs *must* light when the shared button is pressed, is contained in the explanation above and will be outlined below.
We know that:
A: The anodes of the LEDs are all connected to a common +5v source.
B: The cathodes of the LEDs are connected to individual input lines which are also connected to buttons.
C: The buttons also have one terminal connected directly to ground.
D: Since the anodes of the LEDs are connected to +5v, connecting the cathodes to ground will cause them to light.
E: Pressing the button, completes the circuit connecting both the data line and the cathode of the LED to ground.
Therefore, regardless of anything else in the circuit, bringing the input close enough to ground to signal to the CPU that a button has been pressed, will have no other option than to also illuminate the LED.
If anyone finds any flaws in the above, please let me know. Maybe there's something I'm missing.
RandyT
Home
Help
Search
Login
Register
Send this topic
Print
Topic: Advantages of keyboard encoder vs hacking gamepads (Read 9598 times)
