The hardware
The first thing needed was to get the analog data into a microcontroller. That's kind of tricky: the data is clocked out of the CCD at a speed of 2MHz and still is analog. The way the original hardware solved it was with a dedicated, fast 8-bit DA-converter and what seems to be a bit of dedicated hardware inside the main controller chip. I was planning on using only the ATMega88. The signal I was trying to aquire was analog, but for my purpose I could view it as a digital signal: either there is or there isn't a shadow falling on the pixel being read.
The ATMega88 actually should be quick enough to be able to read 1-bit digital signals in using only software: it can be clocked at 20MHz which, with a pixel clock of 2MHz, gives 10 instructions per pixel to read it out and store it somewhere in memory. That would mean implementing some tight assembly code routines, though. There's also another way to read in the pixels: using the SPI port. This integrated peripherial device can read in eight bits of data at once and present it to the software running on the microcontroller as a byte. This way, I'd have 80 instruction cycles to process one byte. That should be enough for even unoptimized C-code. Hardware-wise this doesn't take much components either: the analog output from the CCD can be fed directly into the SPI-datapin of the AVR; the pin will read a '1' if the analog level is high enough and '0' otherwise. The brightness input of the line-CCD can then be used to set the appropriate treshhold.
There's one other thing I had to take care of: Because the CCD doesn't work correctly unless there's a continuous clock applied to it and the SPI clock stops when the program doesn't request a byte, I had to generate the clock signal somewhere else. I used a timer pin for that: it generates a continuous 2MHz signal. When the firmware wants to read a line, it'll pulse the 'latch'-input of the ccd, which then starts to output pixel levels. These are read in by the SPI-unit, configured as a slave, and stored in memory to be sent to the computer.
All that made me come up with the following schematic:
The big chip in the middle is an ATMega88p. It runs at 3.3V, just like the line-CCD. In theory, I shouldn't be able to drive it at 20MHz (at 3.3V, that's outside of its specifications) but in practice, I never had any problems with it. The AVR controls 5 IR-leds, which are generic 850nm infrared LEDs. Because I decided to do the bulk of the processing on the PC and this was just a proof-of-concept, I decided to communicate the locations of the shadows to the PC by just using the UART and an FT232 board I had lying around. Per shadow, the microcontroller will send its location, the size of the shadow and the LED that caused it, so there's only a few bytes to send anyway.