PIC32 MultiMedia Board (MMB)

You may know MikroElektronika from their big development boards for PIC, AVR and ARM microcontrollers; you may even own one. I have one of those boards too, the EasyPIC4 that measures about 19 by 23 cm. This is pretty big and not something that you would use in a project. You can develop your project on it, but you have to build your own hardware if you want to actually use it in an application.

They also do some smaller boards. One particular interesting one is the PIC32 MultiMedia board (MMB) and I managed to get one to play with. For some reason the PIC32 does not get a lot of attention, but maybe this board will change that? It is about 9 by 12 cm and well thought out. On the solder side it has a 320x240 pixel TFT display with touch screen, a mini joystick, 6 LEDs and a temperature sensor. On the component side live all the other parts: the PIC32, the power supply and connectors. It has a power socket, a 9-pin RS-232 connector, an SD-card connector, a mini-USB male and a full-size USB host connector, a microphone input (mono) and a stereo headphones output. There is also an ICD programming port and there is room for an MRF24J40MA ZigBee module from Microchip. All the connectors are on the two sides (top & bottom) of the board, the left & right edges have each a row of holes for pin headers so that you can piggyback another board in case you need one.

When you power the board (with a USB cable f.i.), it does a slideshow of some nice photographs. That is all that it does, but it is pretty hypnotizing: butterfly, flower, tree, chameleon, city, oh… butterly again.

The CDROM labeled “software” does not contain development tools. It has a large amount of examples and documentation, but not only for this board, but for all the MirkoE boards. As I happen to have an ICD3 pod I decided to reprogram the board with the Mandelbrot demo. Loading the precompiled HEX file into the board was easy once the ICD3 pod was done reconfiguring itself. Manipulating the joystick now starts the Mandelbrot demo. With the joystick you can scroll in four directions and pushing it zooms in. It is reasonably fast.


Loading the example code in MPLAB was a bit more problematic as the example makes use of some libraries that were not where they were supposed to be. However, after a bit of relocating files I managed to compile the Mandelbrot demo.

The demo is actually a Microchip demo and a well informed source told me that the reason for this is that the board was originally designed by Microchip, but was outsourced to MikroElektronika due to a lack of resources at Microchip. I have seen a Microchip movie demo on this board, but I do not have the code yet.

There is also a test program on the CDROM. Loading this will light up all the LEDs and fiddling with the joystick you can skip, pass and fail certain tests.

More demos are available on the web page for this board. They let you play Rubik's cube or listen to Boney M and Freddy Mercury. BTW, make sure that the two jumpers behind the headphones socket are in the "UP" position, i.e. closest to de board edge, otherwise you will not hear anything. (See the manual if in doubt.)

One negative point: when I tried to insert the headphones with a jack of the right (3.5 mm) diameter in the headphones socket, the whole thing came off. Luckily it didn't cause any damage to the parts behind it, but it was clearly a case of bad joints. Before inserting anything, check the joints and resolder if necessary. This is probably also a good idea for the microphone socket.

I have tried most of the other demo's too and they are pretty nice. One demo showing off the Microchip graphics object layer gives a good impression of the possibilities of the graphics library.

Conclusion: if you want to give the PIC32 a go, this is definitely a good starting point. The board is reasonably priced ($150) and you could do some nice things with it. I do not really see why you would want to make an MP3 or MP4 player out of it, but transforming it into a DSO or a logic analyzer would sure be an interesting project. The touchscreen with the graphics library allows for very slick user interfaces.

USB 2.0 drop-in for legacy DB9 RS232 connector

It is official! FTDI launches a USB 2.0 module to replace DB9 RS232 connector on legacy boards.


I was given a sneak preview of this module during the Embedded World show at Nuremberg (see here) and immediately felt that this was going to be a killer product.

The module features a standard USB “mini-B” type connector in a module that fits the PCB footprint of a standard 9-pin DB9 connector. The module offers a fast and simple method to add USB 2.0 connectivity to any existing PCB board that has a DB9 RS232 connector.

Two modules are available to replace male or female DB9 connectors. They contain all the electronics needed to carry out the conversion between RS232 and USB. The modules are based on the popular FT232R USB 2.0 to serial UART converter IC from FTDI, which handles the USB protocol conversion. The FT232R device converts from USB to a serial UART interface, which is then level-shifted into RS232 signal levels, within the module. Power to the module is supplied by the USB connection. The modules support a maximum transfer rate of 1 Mbits/s on the RS232 interface.


The DB9-USB-RS232 modules are supplied complete with FTDI's royalty free drivers, which enable a device to be integrated as an additional, (virtual) COM port into an existing software application. The range of drivers includes Microsoft WHQL certified drivers for Windows based operating systems, drivers for Linux and Mac OS operating systems.

Pricing for DB9-USB-M (male) and DB9-USB-F (female) starts at $22.04 for single quantities.

Further information on the DB9-USB-RS232 modules is available on the FTDI website.

Fast prototyping with mbed

Tipped off by my friend Gregory I recently bought an LED panel with 32x64 two-color pixels (that is a total of 4096 LEDs!, ref. DE-DP100 from Sure Electronics). I wanted to make some sort of message board out of it, but I was not sure what would be the easiest way. And then suddenly it struck me: why not use an mbed module? The mbed module would offer me programming in C/C++ and a USB file system that would be perfect for storing message files written on a PC. mbed is for fast prototyping and this would be a nice project to see if mbed’s promises would hold true.

Although the LED panel is supposed to run from 5 V and an mbed module from 3V3, studying the LED panel’s PCB revealed that it was built with HC logic only and so it should be possible to run it from 3V3. That was one problem out of the way, no level shifters needed, and I hooked up the mbed to the LED panel with just 12 wires. Note that the mbed module itself is powered from the USB port.


The LED panel has an SPI-like interface and is rather easy (albeit a bit bizarre) to control. It took me some time to figure out that the datasheet provided by the vendor had the CLK and the LATCH lines swapped, but after that I was able to put pixels where I wanted them and in the color of my choice (red, green, orange and black).


The next step was to add a font so that I could write text. If you have ever bitmapped a font you know how tedious a work that is, so I turned to the web. A quick search found me a freeware utility called The Dot Factory and 10 minutes later I had a C source file ready with all the printable characters from an 8-point Arial font (but that could have been any of the fonts available on my PC). That is so much faster than doing it by hand! Another 15 minutes of coding later I was able to print a string on the display anywhere I wanted.

Now I needed a way to get text from a file on the display, together with some commands to control the way the text would be shown. This meant adding an mbed file system object to my code (1 line). Of course I wanted text scrolling, color & position control so I decided to use an INI file for this. A new search on the internet found me a neat little C library named inih that turned out to be very ergonomic: importing and integrating it into my mbed project took a mere 5 minutes; I am definitely going to keep this library!

The final task now was to implement text scrolling properly. This was actually not too difficult using a cheat and thanks to the way the font was implemented. About one hour later I had it all working the way I wanted.


This is the point where features started creeping in. It would be nice to have several pages of text, scrolling should be possible in both directions, scroll speed per line, etc., etc. This is also the point where I started wasting time. Add feature, compile, check, change, compile, check, change, … After some hours of this I decided to stop and freeze the project; you have to draw the line somewhere.

The result is pretty satisfying. The message board can now display seven pages of four lines of text. For each line you can specify a color, an (x,y) position and a scroll speed and direction. Two global parameters allow you to control overall scrolling speed and display brightness, but these are not so useful. I added a push button to browse the pages. Watch this short video to see the result.



The mbed environment really helped to finish this project quickly, the hardware is ridiculously simple and the software is pretty small. The executable is 51 KB and needs 5.5 KB of RAM (mainly for message storage). All in all I think I spend about one day cooking this up, that’s not too bad, isn’t it?

You can download the source code from here.

Porting code...

...or how to waste lots of time.

Writing portable code is more than just sticking to strict ANSI-C. If you look at the sources of programs or libraries that compile on different platforms, you will find lots of ifdef statements that provide the portability. It is actually pretty difficult to write portable code.

Currently I am into ARM development and I try to target just one OS: mine, on one platform: mine. But I want to use different compilers. I try to write code as portable as possible, without adding compiler specific things, but that just isn’t possible, especially when you target an embedded platform.

Initially I developped some code for GCC. Then I decided that it would be nice if I could use the Keil uVision tools as well. Getting my GCC code to compile with the RealView compiler (used by the uVision tools) was not too difficult, but getting it to work, was.

The problems were caused by, as always, the interrupts. In my code a timer and a UART use interrupts. With the GCC tools both worked fine, with the Keil tools only the UART worked. Uh oh... long debug hours ahead...

I remembered that the GCC code had an interrupt wrapper in the startup code, so all I had to do was to replace the Keil startup code with the GCC startup code. Easier said than done, because it turned out that the Keil assembler did not like the GCC assembly code. This code was definitely not tool-portable (even though the origin of the code clearly was Keil.).

Right, forget about GCC’s special interrupt code, let’s do it the Keil way. I found a Keil timer example that worked on my platform and I copied the code across to my GCC code and … it did not work. I examined the assembler code generated by the compiler for both cases and noticed that the entry and exit code was not the same depending on if the code was integrated in my GCC code or in the Keil example. Yet it was the same C-code, verbatim, since I copied it across, remember?

Or was it?

After stripping down my GCC code (and many hours of hair tearing) I finally discovered that the GCC code had defined away the __irq keyword! Aaargh! So that’s why I didn’t get the right entry and exit code for my ISR!

OK, so I quickly fixed this and now everything would work, right? Wrong!

Obviously there was another problem. My code was now working a bit, but it hung in a delay function. This delay function waited for the timer to reach a certain value before continuing. After some debugging I found that the problem was not so much the delay function itself, but returning from it, it made the program crash. Hmm, that smelled like stack problems.

To make a long story short, the hanging was caused by a function call from within the timer ISR to update a 10 ms timer. After many more debugging I finally found the reason: it was the example code that I had copied! The example proudly mentioned that it handled nested interrupts and I thought that that was mighty fine. But as it turned out, the way the example handled nested interrupts it could not handle function calls from within an ISR... Once the nested interrupts disabled, my Keil code finally worked as my GCC code.

In the end I did not have to make a lot of changes to my original code to port it to a different compiler. It was enough to set the include paths right, define away a GCC __extension__ keyword, add a wint_t typedef, re-allow the __irq keyword and disable nested interrupts, but these last two took me many hours to figure out. At least I now finally understand why the GCC startup code has this special interrupt handling code...

The InterSceptre is almost ready!

It has been a busy period the last few weeks and I did not have the time to update this blog. Although it is still a rather busy time, I decided to write something anyway because I started working on the prototype of the InterSceptre.


Click for a better view. Notice the valid data on the LCD.

I received the PCB and the parts last Tuesday and I assembled the board. Even though the board is not very complicated, there are a lot of things to test. The first tests are promising. The power supply is fine and the board runs from 3V3 or 5V. There are three different 5V entry points (2x USB & one external power supply) and switch over between these inputs works without resetting the Sceptre board (or the PC).

Also working is the I2C port with discrete level shifter. It is discrete because I tried to avoid SMD parts on this board and through-hole integrated level shifters are hard to find. To test it I use the Pocket Terminal which is part of Elektor project 080253 Running-in bench. This terminal is supposed to run from 5V, but the Sceptre runs from 3V3, so I2C communication is incompatible. The level shifter fixes this and the fact that I can write to the terminal and read its keys means that all is working fine.

The four multiplexed DAC outputs are working, which is cool. I can control them with the rotary encoder on the terminal.

Not tested yet are the RS232 & RS485/DMX512 ports, the MIDI interface, the JTAG port, the SPI port and the digital I/O. The SPI port is particularly interesting as the board has space for a WIZnet WIZ812MJ internet module (not mounted for the photo, it should go next to the power connector). The digital I/O is hanging from the I2C bus and some direct from the processor. This is also true for the ADC inputs, so I suppose they will work.

As you can see from the photo, the InterSceptre was designed to fit a standard box from Teko. I did this because this way you can use the Sceptre-InterSceptre combination as a nice stand-alone device. You could only mount the interfaces you need and away you go.

The InterSceptre

This blog will also be used to inform you about the Sceptre, the open source & hardware ARM7-based 32-bit fast prototyping platform as published in Elektor. In the Pages box on the right of this article you will find a link to a special Sceptre page. All information about updates will be posted there; it is sort of the project’s home page.

The Sceptre is my baby and (for the moment) I do all the development for it. Currently I am working on an extension I/O board on which you can plug a Sceptre so that it can talk to the rest of the world. At the same time my goal is to make this board as universal as possible so that it can also be used with other microcontrollers. Except for its name, InterSceptre, and some component print this I/O board will not be Sceptre specific.

The InterSceptre is due for the June issue of Elektor and I am almost done with the circuit diagram. The board will feature lots of communication interfaces: 2x RS-232, 2x RS-485 (so RS-422 is possible too), MIDI in/out, DMX-512 (OK, that’s just RS-485 with a different connector), a WIZnet module for Internet connection, SPI, PS/2 and I2C. USB is available on the Sceptre itself, but a dedicated USB connector for ISP/serial comms will be on the InterSceptre. I also added a JTAG connector and a 4-way multiplexed DAC (the LPC2148 used on the Sceptre has a 10-bit DAC). To stay flexible the board will have a 25-pin DB connector to give access to the ADC inputs and PWM outputs, and some other GPIO.

All of this can of course (unfortunately) not be used at the same time, but I am confident that it will be useful anyway for many applications.

The universal side of the board is also emphasized by its power supply and it will work with 5V and 3V3 systems. The Sceptre is a 3V3 system but 5V tolerant and I will soon show you how you can use it with a 5V I2C controller.

Contrary to the Sceptre, the InterSceptre will only use easy to solder (change/replace/remove) through-hole parts so mounting it will be possible for anyone capable of holding a soldering iron.

That’s all for now folks, I have a PCB to draw.

It's a tactile green embedded world

Last week I visited Embedded World 2010 in Nuremberg in Germany. Nuremberg is a nice city with a mediaeval city center and even though I had a hotel room right on the main market place, I did not see much of the town because of the show. The show was pretty big, more than 700 exhibitors spread out over three halls and allthough I spent two full days there, I did not have enough time to see everything.

The main theme of the show was green electronics. Lots of companies showed off green products, low-power boards and microcontrollers. Although low power electronics is very important, there were not many real green novelties. Microamps per megahertz is the most common term now and several manufacturers claim that their products have the lowest number. Unfortunately these numbers are difficult to compare, because one manufacturer talks about a 32-bit controller whereas another is talking about an 8-bit controller. Actually uA/Mhz is not a good measure, it would be better to use something like uA/MIPS or so. Energy Micro, a company that I didn't know before, won the Embedded World award in the category Hardware. Their EFM32 32-bit MCU (ARM Cortex-M3) consumes 180 uA/MHz (running at 32 MHz and 3V).

Another big thing these days is touch technology. In the coming years everything will be tactile, if we can believe the Embedded World exhibitors. Personally I am a bit weary of touch interfaces. At the end of the seventies touch keys were hot too. Being a poor student I had recovered a third-hand color TV with touch keys for the channel selection. These keys were very sensible to weather conditions and my TV changed station randomly, especially when humidity was high or when I really wanted to see something. One day this TV caught spontaneously fire and I finally got rid of it, but that's another story.

Now I have a monitor with touch keys. I also have a cat. It has happened several times that the cat changed the settings of my monitor in a completely random way just by striking the tactile surface of the monitor. I guess I’ll just have to wait until the touch craze has passed before I buy any new kit.