This is will eventually be a part of my GPS project, which I will get into later next week.

For now, here are the specs: an EL backlit 160×80 monochrome graphics LCD that supports text and graphics mode (I just coded for graphics mode and found a font/character pixel set online), controlled by an ATMega32. The LCD is driven by an LC7981/HD61830 controller (easy parallel interface). I’ll try to get the pinout up, including the EL connections with the inverter as soon as possible.

Pictures (no, I’m not running linux, the linux penguin just happened to be a convenient pixmap to demonstrate):

And the free source, currently coded for the ATMega32 but can be easily adapted to other uCs: avr-lc7981.tar.gz.

Alternatively, feel free to browse the images and source here: http://www.frozeneskimo.com/samsunglcd/.

It’s cross-platform (Linux, Windows, Mac OS X), and since it implements USB as firmware in the AVR, it keeps the parts count pretty low.

I’ve gotten around to building the USBasp on a perf board, since I’m too cheap for a real pcb. I have confirmed it working on both Windows and Mac OS X (and as of today Linux too), and have used it extensively the last couple of days to write an LC7981/HD61830 driver on an ATMega32 (will post this up soon) without any problems.

There is also USBtiny, which is probably the fastest way to get up and running with USB AVR programming if you already have a parallel port STK200 clone. Like the USBasp, it implements USB entirely on the AVR firmware, but is actually more of a parallel-port to USB converter (it interfaces to an existing STK200-style AVR-ISP parallel port programmer).

USBasp Perf. Board Build – click for a high-res picture:

http://www.frozeneskimo.com/electronics/wp-content/uploads/Videos/avrservo.avi

Manchester Encoding actually halves the data rate. The encoding is extremely simple, though. If you have a 1 in your data, it will be followed by a 0, if you have a 0 in your data, it will be followed by a 1. So the ASCII letter ‘A’, or 0100 0001 in binary, would be encoded as 01 10 01 01 01 01 01 10.

This allows for easy error checking- if a bit in the received data is not followed by its inverse, you know that the data is invalid. In other words, there are an equal number of ones and zeroes in the Manchester encoded data. Of course, there is that small chance that one byte of the random junk floating around is actually properly encoded, but these bytes can be avoided with a basic protocol on top of the encoding (possibly with a checksum).

Tonight I coded an implementation of manchester encoding/decoding to be encapsulated by a hardware UART from scratch. It was actually really easy, but it could probably be heavily optimized with some clever bitwise operations. I made direct calls to UART send and receive routines from the Manchester Encoding and Decoding functions so I wouldn’t have to pass around variables in main() or wherever I’m calling it from. For some reason, I wanted to write my own soft bit bang’d UART implementation, so I ended up doing that too. With the exception of optimization of the delay system, it works great.

I tested the code with a wired serial connection, and it works perfectly. Tomorrow I’ll hook up the whole wireless setup and confirm it’s working there. Other than that, I can start working on the I2C code for the digital temperature sensor that will be on my robot. After that–servo motor control (PWM stuff).

Note: my application of Manchester Encoding isn’t exactly what it officially should be used for. I’m just using it to encode/decode data blocks in order to distinguish junk data from real data, which doesn’t exactly fulfill the entire purpose of Manchester Encoding. I might also write a CRC sort-of implementation and use that instead if it takes up less bandwith (which I think it should).
One of the more important aspects of Manchester Encoding is that the clock can be extracted from Manchester encoded data from every other bit. Every bit in Manchester encoding is followed by its inverse, but in the electronics side of this, this means that there is a voltage level transition after every bit (1 -> 0 or 0 -> 1). One of the issues with digital communication over a wireless connection or a long distance connection is that the clock will often lose synchronization due to the lack of voltage level transitions (data might stay 1 or 0 for a prolonged period of time). Having a voltage level transition after every bit of data, however, means that the receiving end can precisely distinguish between each data bit and easily maintain synchronization during the data transfer.
USART, on the other hand, only synchronizes on every start bit of the packet frame. The trade-off with the implementation that I wrote is that I can use the built-in hardware UART, instead of bothering with bit banging my own serial interface with the wireless transmitters/receivers. I’ll see how this works out and whether or not it is reliable enough to stick with. Or maybe I should just enable parity in my UART connections instead of cutting my bandwith in half with Manchester encoding?, there are a few options.

Anyway, here is the code that should work for most AVR devices (with a USART): AVR Pseudo-Manchester-Encoding with Hardware UART