VGA Hardware Project

Some background information first: everybody has to participate in a small project for technical computer science during the course of their studies at my university. Usually it’s just a small project done by a team of three students.

I was lucky though and had good marks in the final exams of TCS in the first term and was offered to participate in a bigger project where we actually worked with hardware and had bigger team sizes too (about 10 people usually).

The project started in my second term (spring 2008) and due to us being quite lazy students and being not pressured from the faculty itself, we only started really working on the project in our summer vacation which explains why it was only finished in January 2009.

The aim of the project was roughly to display _stuff _on a monitor by programming an AVR microcontroller as well as an FPGA. We further had a working networking interface (using an old 10 MBit Ethernet card) to retrieve the stuff we should display.

We had to write everything (from the Clients to access/connect to our hardware to the VGA signal output code) on our own (except for the uip network stack on the AVR microcontroller).

The hardware (which we didn’t have to put together¹) looks like this:

We actually started working on and off during the second term, but getting everything setup and running (the FPGA people could probably fill books with horrible stories about Xilinx…) took quite some time and we were incredibly happy when we were able to connect to the AVR via telnet for first time and make the little LEDs on the FPGA flash in a pattern.

More than half a year later we were quite happy to produce images like the one below on the screen though:

The Features

As you can read above the whole project didn’t really have a specific outline, it was more like throwing hardware at us and telling us to get creative (and get something done, too, obviously :-)).

We settled on some features when we really started to implement everything and had a better intuition about what is possible and what is not:

• Java Client to communicate with the hardware

• AVR server code only to communicate with the client and network card and transmit/pass through data to the FPGA

• FPGA displays the data on the screen (as 80x40 ASCII output on a resolution of 640x480 at 60 Hz)

• Fixed color and font tables (ASCII charset and the usual DOS terminal colors)

• Custom font and color tables can be sent, too

• AVR has a built-in web interface and can be accessed like a website and offers a small Web Client to send and display text messages on the screen (using the default colors and the usual ASCII charset)

• Java Client has editors for all three content types (font, color, screen) and can show a preview

• Java Client has an Image Converter that can take arbitrary images and create custom font, color and screen data to show them in the best way possible

• AVR can also output log/debug messages as html in the web interface². Click here and here or here for examples :-)

Moreover there is some unfinished stuff like a hardware emulator to test the Java client with (which was never properly finished) or a batch testsuite to send messages without having to use the Java Client³ or the prototype Java Client and the first version of the client (different codebase from what I’ve heard) etc. etc.

You can download the code for the AVR and its subprojects (testsuite, emulator) here.

The Final “Product”

First, let’s take a look at what you see after you power everything up:

ETI is the abbreviation for Introduction to Technical Computer Science and GP4 is our internal project title.

Next we have photo of the old terminal we were using to display debug information from the AVR (I spent hours reading it while debugging):

Let’s take a look at the web client now:

The Java Client is more awesome though.

A few pictures showing the client and the output on the screen:

I’ve prepared a litttle slideshow with more pictures:

The Development

We were a team of ten students, which is quite huge (at least for my taste - and it also turned out to be quite difficult to manage). Three of us volunteered to be the official project leads, i.e. the people responsible for keeping an eye on everything, organizing meetings and being the contact persons for Dr. Acher from the TCS chair.

We initially divided ourselves into 3 teams: an FPGA team, an AVR team and a Java Client team. The Java Client team and the FPGA one were the biggest ones, because we thought most of the work had to be done there (and that turned out to be true), while the AVR team only consisted of me (doing all the C programming for the project) and Andreas Hubel who wrote the HTML/JavaScript code for the web client amongst other things. In retrospect the AVR was a lot of work, too, and, of course, underestimated by me, because I thought passing along information from A (the Java Client) to B (the FPGA) could be done in a day, which was not true.

A big chunk of the project was done in 3 days during our summer vacation when we all met and locked ourselves up in the lab and worked on the project from 9 am to 9 pm⁴. The rest was coded during various afternoons and sometimes weekends in our third term.

The Team(s)

Java Client:

• Martin Klenk
• Fabian Immler
• Andreas Lang
• Lucas Louca

AVR:

• Andreas Kirsch
• Andreas Hubel

FPGA:

• Jan Seeger
• Niko Demmel
• Andreas Hubel
• Fabian Otto

Documentation:

• Lucas Louca
• Markus Lachinger
• Andreas Lang

2 Project Leads

As you might notice in the end we had another dedicated team that created the documentation for the project and we actually only had 2 project leads.

I was one of the project leads and responsible for 20%⁵ of all emails sent around⁶ and had a lot of fun organizing meetings, writing long emails and trying my best not to annoy people too much :-)

What Went Right⁷

• Communication was okay and surprisingly good most of the times.
• We decided to setup a CMS and Subversion Repository early-on.

Jan installed Trac on his server which did both) and the included MediaWiki was really helpful for collecting information and getting everybody up-to-date. We also had a Who-is-Who page with a portrait photo of everybody and their contact details (ICQ, AIM, mobile number, etc etc) which was really helpful quite a few times⁸.

• The FPGA team made extensive use of Pair Programming to come to copes with VHDL and a huge state machine that was responsible for the AVR communication back end.

• We actually spent some time prototyping things and working everything out before hacking the final code together (though, of course, lots of prototype code wasn’t rewritten but just kept and still lives in the current codebase :().

• We had a lot of fun and some crazy time together (both good and bad times with weird bugs and long debugging sessions)

• All of the planned features worked in the end.

What Went Wrong

• Organizing people is very difficult.

• Keeping the team together even more so.

• The team was a bit too big with some people idling more than others, because the project could have (arguably) been done by (say) 6 people probably.

• We changed bits of the communication protocols a few times, which wasn’t very nice, because code had to be rewritten (and sometimes even the design had to be changed).

• Debugging was a huge PITA in general.

• Even more R&D would probably have been beneficial in retrospect.

What I’ve Done on the Project

• Project Lead⁹
• Wrote all of the AVR C code (3500 LOCs)
• Implemented a small HTTP server (a very primitive one)
  
• Implemented a generic state machine for the server which allows to add new message handlers easily
• Talked to both the FPGA and Java Client people to figure out how to get data sent back and forth

What I’ve Learnt

• Organizing stuff and trying to make everybody stay on the ball is a lot harder than it sounds
• It also needs a lot of time
• Even a team of 10 people is huge
• If somebody doesn’t really do anything, don’t wait for a happy ending. Confront people as soon as you notice that and don’t let it drag on (—do it in a nice way though).

This is something I’ve learned the hard way in the end, and it’s biggest annoyance in retrospect, because some people worked their asses off, while other(s) did not at all..

• Low-level hardware programming is always crazy, because you’re limited in your choice of debugging tools¹⁰ and you experience weird bugs sometimes that no one can even remotely explain (at first).