The "power" button is just connected to a port IO pin-- PORTD.3 and the LED connects to PORTD.4DavidEtherton wrote:Clay, what's the power button actually supposed to do? I could have sworn it actually cycled power on the SparkFun demo that shipped with it (which I've long since flashed over). For that matter, I thought the LED's were under user control as well.
I know it can be read from software (and I emulate it now for maze demo happiness).
Power (and LED) control is thus 'cooperative' with the MCU. On the earlier baseboards I had a circuit that toggled power to the module in hardware, but after some discussion I decided it would be useful to have one "always available" input. (That way if we wanted to have things like "press and hold X seconds to force the bootloader to start" or "press and hold when you apply power to do Y" we'd have it available and without any knowledge of what/if controllers were attached, etc.) The LED was also going to be hard-wired to power, but it was super useful for ("real") hardware timing experiments and as a trigger for external debug hardware (logic analyzer, scope, etc.) and I'm a sucker for little pulsing "powered, but sleeping" type indicators.
If you want to emulate them-- check the DDRD (Data Direction Register, PORT D) for if they're configured as an input or output (input in the case of PORTD.3, output in the case of PORTD.4). The PORTD output register for bit 3 will be set to '1' for the power switch (to enable the internal pullup resistor). PORTD.4 is a current sink, so the LED will light when the bit is '0' and turn off when the bit it '1'.
The "ESD Attack" hex file drives the LED and reads the power switch for testing. I didn't want to go mucking about in the kernel to get true low-power sleep mode going, so instead when the power switch is toggled I just disable the NTSC encoder clock output to turn off the video.
(Sorry for the slow reply-- off visiting my folks for Christmas!)
-Clay