System for Inter Net Display

Firstly, it's got a crap name. It doesn't matter what it is yet, but please send in ideas for better (ruder/funnier) names. Note that this work does also utilise the Manchester University Fast Framebuffer technology.

So! Dr. Jim et al. and sidekick Chesney have been slaving away making CS124 lab boards for teaching ... things on.

I decided to utilise the technology available to get my ARM and hardware skills up to speed in a fun and entertaining way. (Actually to be precise I was slacking off and found doing this more fun than Real Work.)

IP stack

Wrote a small IP stack for the board. The board contains:

An Atmel AT91M40800 CPU which is basically an ARM7TDMI with 8K internal 32-bit ram
(a minimum of) 512K of external SRAM
A CS8900A 10baseT ethernet MAC
Two blue LEDs (by far the most important part)
One Xilinx Virtex XCV300 FPGA with up to 4MB SRAM (VRAM here)
One Xilinx Spartan XCS10XL FPGA
An alphanumeric LCD
A load of flash, some other LEDs, some buttons and switches... (and a clock generator... pffft.)

The interrupt-driven ethernet driver passes packet buffers to an IP-interpereting thread, which will then wake and schedule various client threads to do things with the data. A small realtime thread scheduler implements pre-emptive prioritised thread switching and semaphore/timeout sleepingness.

The IP stack itself is quite minimal; ICMP ping is implemented (400uS ping times) and UDP clients are supported. A TFTP thread fetches a kernel upon bootation across the network. An LCD thread accepts UDP packets containing (usually rude) messages from people armed with my magic sending perl script.

IP + TFTP + Ethernet driver + ARP + LCD + serial + scheduler comes to about 6.6K of ARM code, so fits in (fast) internal RAM. [There needs to be space for data and stacks for each thread, too, so the 8K space is actually quite tight.]

IP stack update:

Initially it was TFTPing files at about 35K/sec. I attributed this slowness to the scheduler wasting time and low bus bandwidth etc. etc., when in reality it was attributed to my dumbness (or bleary-eyed coding). Instead of the scheduler choosing the highest-priority thread, it chose a random thread so the idle thread would end up running much of the time. It's amazing what a typo will do; having fixed this the code transfers data at a respectable 530K/sec. :-)

VGA TFT driver

I hacked a quick driver in the Virtex FPGA to clock out data in the Virtex's external SRAM onto a 640 x 480 9-bit colour LCD panel. The framebuffer data is accessed through the Virtex from the ARM.

So...?

Now it TFTPs an image from a server straight into VRAM, so it gets displayed. How lovely! The TFTP thread accepts a `restart' packet that forces the thread to re-fetch another image from a supplied filename, so the images can be changed at any time. Takes 1/4 second to download one.

I want to hang this on a big glass window with four TFT panels hanging off it, with a single ethernet cable running to it, displaying STUFF. Do submit (hahaha) images that you think will look good on a badly-dithered VGA 8-bit Blue2Blue1Green2Green1Green0Red2Red1Red0 palette.

High res low colour, low res high colour