Monochrome matrix canvas and Ledcomm for Hackaday 1 kB Challenge by Matthias Koch
Light emitting diodes are fun, and sensing light with LEDs can even increase the joy. Just connect both anode and cathode to GPIO pins. The idea is to reverse charge the junction capacitance, which is subsequently discharged by photocurrent, and wait for the pin state to toggle. The brighter it is, the shorter you'll need to wait.
The idea dates back to Forrest Mims books, and the earliest publication using this idea with a microcontroller seems to be "Very Low-Cost Sensing and Communication Using Bidirectional LEDs". A description of the protocol used by me can be found on http://mecrisp.sourceforge.net/ledcomm.htm
For this Challenge, the rules clearly allow to split the 1 kb of binary over multiple processors, but demonstrating communication without controlling the whole terminal with rendering fonts and scanning keys on our own will always blow the requirements, as any vanilla terminal software will have an overall count of running bytes far beyond imagination. I could argument that I developed a standalone Serial<->Ledcomm bridge, but without a connection on its ports, it is not fulfilling anything really useful other than to test Ledcomm ranges, so therefore I decided to split my contribution to this challenge in two parts:
512 bytes go to a simple yellow 8x8 LED matrix connected to a MSP430G2452 which you can paint on with another LED or laser pointer. This canvas demo nicely shows the effect and clearly fulfills all judging criteria of the challenge. One corner pixel serves to erase the image. Before it starts, it displays a memory dump. As a small easter egg, this binary is a polyglot and will also run on a LM4F120 Stellaris Launchpad (ARM Cortex M4), just doing a bit more than what an embedded "Hello World" should do, displaying a binary counter on the RGB LED.
MSP430G2452 in 20 pin DIP package
Cathodes of a yellow 8x8 LED matrix directly to Port 1
Anodes of the same 8x8 LED matrix through eight 100 Ohm resistors to Port 2
100 uF and 100 nF capacitors across Vcc and GND
15 kOhm resistor from /Reset to Vcc
Four pin header Vcc, /Reset, Test, GND for flashing
Two pin screw terminal for Vcc and GND
The other 512 bytes are used to implement a Serial<->Ledcomm bridge on a MSP430G2553 on a classic Launchpad, which you can use to chat over a red or yellow LED. Two nodes are necessary, but they will run the same binary. At Reset, it checks the state of the button on the Launchpad, so you can choose between bright and dark mode. At least one node needs to be in bright mode for the link to synchronise. If this half fulfills the requirements of the challenge is at the mercy of the judges: Its own binary is small enough and lets you probe the distances Ledcomm may bridge, giving visual link state information, but to fully make use of this, you need a generic serial terminal emulator. On the other hand, additional functionality available beyond the challenge limits is encouraged. I had no space to implement buffers in software, so you need type slowly enough or set up a character delay in your terminal as the UART has no hardware FIFO to buffer characters while Ledcomm is transmitting.
"Schematic" for one node, you'll need two:
MSP430G2553 in 20 pin DIP package on classic MSP430 Launchpad for terminal and status
Red or yellow LED with anode on P2.0 and cathode on P2.1
The ROM bootloader section is not used, and for the "matrix paint" oscillator calibrations constants are hardwired, as there is no need for an accurate clock. To get a correct baudrate for the Ledcomm bridge, we need accurate chip specific oscillator calibration constants from info flash segment. To be fair and to compensate for the two extra bytes within the challenge limits, a NOP (which is also 2 bytes long) opcode is inserted after placing the calibration constants into the DCO registers.
* LEDs used as photodiodes
* Both binaries use a second stack for parameter passing along with the default stack for return adresses, as common in Forth language programs
* Polyglots for ARM Cortex and MSP430 can be quite easily constructed as the ARM vector table is at the beginning of the binary, while MSP430 chips expect their vector table at the end of the binary
3. January 2017