Archive for December, 2009

Simple Minix 3 driver

Friday, December 25th, 2009

I have made a simple driver for Minix 3 (Tested on Minix 3.1.4, should work on 3.1.5).
This driver controls the caps lock led by writing: write a 0 to /dev/capslockled to turn it off and a 1 to turn it on. Note: this driver is not thread safe as it might interfere with the TTY driver.

The driver can be downloaded here.

OpenLaserFrag Base System PCB designs finished

Friday, December 25th, 2009

I have finished the designs for the OpenLaserFrag Base System modules.
20 set’s of PCB’s are ordered.
The design files will be published as soon as the PCB’s arrive.

OpenLaserFrag Base System PCB's

3.5″ TFT module driven by XMOS processor

Friday, December 25th, 2009

I have recently bought an 3.5″ TFT module (18 bit, 262K colors) from ebay. The TFT display is mounted on a PCB with all data lines fanned out to 0.1″ connectors. The display is (i think) a Crystalfontz CFAF320240F-T-TS (datasheet). The display has also a touchscreen.
The PCB has a SPI touchscreen controller, SD card holder and place to solder a SPI flash chip.
The LCD controller is a Solomon SSD2119 chip.

You can interface the display using a parallel 8080-series bus using either 8 or 16 bits or SPI using 3 or 4 wires.
This is limited by the PCB, the controller can also do 9/18 bit parallel 8080-series bus and 8/9/16/18 bit parallel 6800-series bus.

I have hooked this display up to my XMOS XC-1 development board and i am using the 16 bit 8080 interface.
The controller starts up in 16 bit mode (65K colors). I am currently still using this mode as it is way more efficient than the 18 bit mode because i am using a 16 bit parallel bus. My initial code can refresh the display with about 50FPS. My code is nowhere near mature at the moment and i am planning to write a driver for it, which i will publish later.

color test

color test

Video playback on Nokia 6100 display

Friday, December 25th, 2009

Using a XMOS processor and a FTDI vinculum embedded USB host chip i have managed to play video on a nokia 6100 (knockoff) display with a frame rate of 16.66 FPS.

Playing 2012 trailer at 16.66FPS (the RAW file was created for 12FPS and thus the movie plays a little bit too fast):

Playing Family Guy at 16.66FPS

I have converted the video to still images and converted them to a 12 bit RAW format.
The RAW file is uploaded to an USB stick with FAT16 file system.

The FTDI vinculum chip can reads from the USB stick and also implements the FAT16 file system, so the XMOS processor can easily open and read/write files without having to take care of the file system or USB stack.

The concept of the FTDI vinculum is very good, only the implementation could be a lot better.
The vinculum chip is in fact just a microcontroller with special USB hardware and runs a firmware.
There are several firmwares available for somewhat different functionality.

Unfortunately these firmwares (I only used the VDAP firmware though) aren’t that stable.
For example the SPI interface seems to have a bug which makes it totally unusable.
I have been able to read from the SPI interfaces but when i try to write to it the device locks up.
How do i know that the device locks up? Normally if you remove or add an USB device (USB stick) it will write a message to the transfer buffer that can be read. However when it locks up it does not responds to removing/adding a device and you will not read any new data.

Luckily the chip has two more interfaces: UART and parallel.
They both seem to work as expected. I have used the parallel interface because it can have higher transfer rates (The UART is limited to 3Mbit/sec).

Now the vinculum chip has two different protocols: a human optimized ASCII protocol (extended command set) and a machine optimized ‘binary’ protocol (short command set). Unfortunately this machine optimized protocol isn’t that machine friendly at all and in fact is just a shortened ASCII protocol.

Unfortunately my code is nowhere near mature so i won’t publish it at this moment.
Besides that the vinculum chips is limited to about 400KB/sec (good for 16FPS with 25KB RAW frames).
I think a SD card will be a better solution to play video from a RAW format.

Nokia 6100 display driver (PCF8833 controller) for XMOS processors

Friday, December 25th, 2009

I have created a driver for the Nokia 6100 (knockoff) display using the NXP PCF8833 controller.
This driver is targeted at the XMOS processor architecture.
This driver is largely based on Jamie P. Lynch’s driver.

For more information and downloading the project see my project page on XCore Exchange, the community for XMOS processor enthusiasts.


Color test

Real-time Minix 3

Friday, December 25th, 2009

I’ve been working on a real-time Minix 3 distribution as i have posted about a while ago.

The results of this project can be found on the following website:

In short the following was accomplished:

  • Rate-Monotonic scheduling
  • Earliest Deadline First scheduling
  • Run-time switching of real-time scheduler
  • Prioritized message passing
  • Semaphores

Gyroscope as Human Interface Device

Friday, December 25th, 2009

For a small electronics contest (Dutch)  i’ve made a gyroscope based device that can interface with a PC as an USB HID keyboard. The intention is to use this device with your feets as extra input device for First Person Shooter games.



I’ve used the Sure Electronics XV-3500CB gyroscope module. This module has both an analog output and an onboard ADC which has an I2C interface. I have only used the analog output but using the onboard ADC converter might be better (less noise).

I hooked this module up to an Atmel AVR ATmega8 microcontroller running at 12MHz.
The analog output of the gyroscope module is connected to one of the ADC converter channels of the ATmega8. The ATmega8 has no USB interface. Instead of using a hardware USB interface i used a bit bang software USB stack. The PHY of this interface is just a few resistors and two zener diodes to keep the potential of the USB data lines under 3.6V (the microcontroller is USB powered and runs at 5V).

Schematics can be found here.

Gyroscope module and microcontroller

Gyroscope module and microcontroller

Gyroscope module and microcontroller

The firmware that runs on V-USB a software USB stack for Atmel AVR microcontrollers. This software stack is only able to do USB 1.1 low speed (1.5mbit/s). This is not very fast but more than enough for sending some key strokes to the PC.

More specific my device is based on the HIDKeys example project. This examples project takes input from 17 buttons and sends key strokes to the PC when the buttons are pressed. I modified this project to use results from the ADC (and thus the gyroscope) as input instead of buttons. If the gyroscope is moved to the left, a particular key stroke is send to the PC and the same happens for moving to the right. Due to the fact that the device emulates a keyboard it is very easy to use it in games. Just bind the two different keys that the device can send (left/right) to the functions in the game configuration!


The device shows up as USB HID device:

Leaning in Medal of Honor: Allied Assault:

Turning in Medal of Honor: Allied Assault:

Look mom, without hands!

Status LED’s:

My project can be downloaded here and used under the GPLv2 license.

The ZIP file contains the following:

  • Schematic
  • Source code firmware
  • Hex file firmware
  • Altium Designer work files for schematic, PCB (not finished) and lib
  • Used datasheets

Salt water battery powerin Atmel AVR

Monday, December 7th, 2009

For a small electronics contest i made a salt water battery (Dutch). To demonstrate the battery i used an Atmel ATtiney2313 which blinks a LED. I’ve also tried to use a NE555 based blink-a-led, unfortunately the NE555 drew too much current.

The salt water battery has 18 cells and i used copper and alluminium electrodes. The copper electrodes are made of desolder wick and the alluminium electrodes are alluminium foil.

Setup of the expiriment

Setup of the expiriment

The danger of typo’s in a switch statement in C

Tuesday, December 1st, 2009

A typo in a case label or default label inside a switch statement can result into normal labels without the compiler complaining. This can introduce serious and hard to find bugs. This will happen in the following two situations:

1. The space in case<space><number>: is forgotten.
2. Any typo in the default: label.

Consider the following code:

/* A typo in the case labels or default label in a switch statement
 * can result into a normal label in the following situations:
 * 1. The space in case<space><number>: is forgotten.
 * 2. Any typo in the default: label.
 * What mostly happens is that the statements under the wrongly typed case label
 * will be part of statements under the case label above. These statements
 * usually end with the break statement and thus the statements under the wrongly
 * typed case label will never be executed.
 * Author: Bianco Zandbergen, november 2009      
#include <stdio.h>
int main(void)
    int i = 0;
    int t1 = 0;
    int t2 = 0;
    switch(i) {
        case 1:
            printf("Case 1\n");
        case2: /* A typo in 'case 2:' results into a normal label */
        defaultt: /* A typo in 'default:' results into a normal label */
    /* lets test if we can jump to these labels */
    if (t1 == 0) {
        t1++; /* avoid looping */
        goto case2;
    if (t2 == 0) {
        t2++; /* avoid looping */
        goto defaultt;
    return 0;

While it is correct that the compiler does not complain (a label can be put anywhere), i think it would be wise if the compiler generates a warning when using the default options.

Output of gcc 4.3.4 on GNU/Linux with the code above:

bianco@box ~/temp/label $ gcc -o label label.c
bianco@box ~/temp/label $

Output of Borland C++ compiler 5.5.1 on Windows with the code above:

C:\dev\C\labels>bcc32 label.c
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland