Fail over fail

January 7, 2011

Even more rant this time.

To go on programming microcontrollers as I’ve always done I have to disable two programs, gpsd and modem-manager (see my previous post) because hardware manufacturers fail. The first one, gpsd is done. To fix the second one without killing/removing NetworkManager I have to contact ModemManager developers. To do so I have to register to launchpad. To do so I have to get an OpenId. To do so I have to… find a way to avoid another fail:

See on the bottom of that webpage? “Type the two words into the field below”. I’d be glad to do that if there were two words, and one field. The HTML source of the page seems to indicate that a sort of captcha is supposed to be there, bu there isn’t… and without it I can’t complete the registration…

But wait, there’s more fail:

A quick look at and I found out that since I have a wordpress blog I already have an OpenId. I tried to log in with that, but it failed. A look at the FAQs for launchpad and:

Can I log into Launchpad with my existing OpenID?

Not at this time. Launchpad is currently an OpenID Provider (OP) and not a consumer (RP).”

And that, in my opinion, is fail.

Linux today: too much plug and play

January 7, 2011

This title is probably not what you’d expect. Usually people complain for the opposite reason: they buy some hardware, connect it to Linux and it does nothing, so they have to spend time in forums to see what can be done even if manufacturers don’t officially support Linux.

In my case, it’s the plug and play system itself that is causing me problems, because it incorrectly identifies a device as another type of device…

But let’s start from the beginning. I’m an embedded developer, and therefore I deal with microcontrollers. Often, the easiest way to debug, program, and communicate with a microcontroller is a serial port. Given that serial ports disappeared from computers long ago, USB to serial adapters have been introduced to solve this problem. These are all tiny chips like the FT232 or PL2303 that connect upstream as USB and downstream as serial ports.

These chips can be used either as standalone products, like the blue dongle at the left of this picture which is PL2303 based

or directly embedded into the device. For example, the Miosix board that I designed has an FT232 on board. It’s the chip at the bottom right, next to the USB connector

Now, both these devices identify as serial ports, using the default VID and PID (which are the identifiers of the USB protocol) of the manufacturer. They do so because they are serial ports, the first one is obvious to see, but also the second, since I don’t need any program to automatically start when I plug one of those, just to sit there and wait till I open screen or minicom to watch debug messages and the like.

Now, I’ve recently upgraded my computer to Fedora 14. It works very well, except for serial ports. At first I noticed that immediately after connecting a USB/serial device, trying to talk to it resulted in errors. “Device ore resource busy”, it said. Retrying after a couple of seconds fixed this, but then it looks like the bootloader of the microcontroller (the first program that starts) has been upset by something, so the first programming cycle failed, the next one went well, and all the subsequent too. At least until the USB/serial adapter is disconnected and reattached, in this case the issue presents again.

What could it be?, I thought. Maybe a bug in the kernel driver for serial ports? It turned out to be something entirely different.

To understand what was happening, first we have to talk about crappy GPS mice and GSM usb sticks. Both have someting in common: those who manufacture the GSM/GPS module are different from people who design the final product. The GSM/GPS modules, for convenience, spit out their data through a serial port. But given that PCs have USB ports only, final product designers add an USB/serial converter into the device. Now, the issue is, that they don’t care about changing the default VID and PID of the USB/serial adapter. Therefore when plugged to a PC they appear as serial ports despite their products are not serial ports. A GPS can only understand NMEA sentences (plus some weird binary protocol), while a GSM “internet key” can only understand AT commands. And what’s worse, they require plug and play, they require a program that attaches to these devices as soon as they’re plugged in.

Linux on the other side, is growing fast even as a desktop operating system. So it’s natural that it is starting to support more and more hardware, in the easiest possible way. But how can it cope with GSM/GPS USB sticks?

Simple: for GPSes there’s a program, gpsd, that when a new device is connected, its VID and PID are checked against a list of devices, and if matches it tries to send NMEA sentences. If it responds, ok, otherwise the device is discarded. The same happens for GSM devices, there’s another program: ModemManager that does the same thing with AT commands.

But given that most devices appear as a PL2303 serial port, how can these programs know if after the PL2303 there’s a GPS unit, a GSM “internet key”, or none of these? Simple, they don’t. They try for a while to talk and if the device on the other side doesn’t seem to be what they expect, they give up.

This explains why trying to connect my USB/serial adapter to the PC and immedately open screen or minicom resulted in “device or resource busy”, while retrying a couple of seconds later worked.

The issue I’m having with the bootloader, is instead caused by the fact that these little program don’t just open the serial port and listen, they open the port and talk! The bootloader of my board probably gets upset by AT commands, or NMEA sentences or both.

But then I wonder, does a GPS unit like AT commands, or conversely, does a GSM internet key like NMEA sentences? This is trouble waiting to happen. Also on Windows, I suppose. Assume one buys a cheap GSM unit that identifies as a PL2303, and a cheap internet key that identifies too as PL2303, what does the official Windows drivers that come with them do? Conflict, I guess.

The first attempt to fix my issue has been to uninstall gpsd and modem-manager. Unfortunately, on Fedora, the whole KDE depends on gpsd, so it can’t be unistalled. I therefore contacted the gpsd developers on the mailing list. They have been very helpful in finding a workaround (they even blogged about it as I’m doing now, here), which is to download the gpsd sources and issue these commands:

make udev-uninstall

which leaves gpsd installed, but removes udev rules that cause the plug and play. It’s also interesting that if I ever buy a GPS unit I can still start gpsd manually. Nice.

The fun thing is that gpsd developers were not aware that some other opensource project, ModemManager, was lurking for the same USB VID and PIDs…

I still haven’t found a way to disable modem-manager. It is a daemon, but it auto-respawns when killed, there’s no “service modem-manager stop” and trying to uninstall it would also get rid of NetworkManager.

Ofcouse, the only way to fix the whole problem is that hardware manufacturers should change the VID and PID so that a GPS, a GSM modem and a serial port can be uniquely identified…


I found a way to disable modem-manager while leaving NetworkManager:

sudo service NetworkManager stop
sudo killall modem-manager
cd /usr/sbin
sudo rm modem-manager
sudo service NetworkManager start

Ofcourse any GSM internet key would probably stop working, but for now It’s enough. I can finally connect an USB/serial adapter and nothing is trying to speak with it by default. Finally.

Handling PNG images in C++

October 5, 2010

This blog post is about png++, one of my favourite C++ libraries.

It’s a wrapper of libpng in C++ that allows to handle PNG images so easily that you’ll never want to use bare libpng again.

All you need to start is to add these two lines in you source files:

#include "png++/png.hpp"
using namespace png;

This is the code to open an existing image:

image img("image.png");

The code to make a new image from scratch differs only in the parameter passed to image’s constructor:

image img(1024,768);

The image class has the get_pixel() and set_pixel() memeber functions to access the individual pixels:

rgb_pixel pixel=img.get_pixel(0,0);,; //Increase red color of pixel

The image height and width can be obtained with intuitive get_height() and get_width() memeber functions:

for(int i=0;i<img.get_width();i++)
    for(int j=0;j<img.get_height();j++)
        //Do something

The image can be written to file with the write() memebr function:


Also, this library is header-only. What does it means? That you do not have to compile the library to start playing with it, just exptract the library in the folder where you have your source code, and include the header file “png.hpp”, just that.

Lastly, here is an example code including CMake scripts to show the capabilities of the library. png++.tar.gz

Miosix 1.54 released

October 3, 2010

After a lot of time spent coding, here’s the new release of Miosix, my OS kernel for microcontrollers.

New features include:

  • Porting for ST’s Cortex M3 microcontrollers
  • Preliminary implementation of the POSIX thread API (pthreads)
  • Improved statistics on memory usage and debugging messages
  • Bug fixes and other enhancements

If you’re interested, download the new release here:

Digital voltmeter for power supply

October 2, 2010

This summer I finally found some time to fix my power supply.

It’s a rather old but relieable unit, and I have no intention of replacing it. Basically, it still works except for the voltage meter on the front panel. Over time, the pointer developed an offset of around 1V, which is visible in this image where the power supply is turned off. Instead of indicating exactly zero volt, the pointer is below the beginning of the scale.

This, together with the fact that today’s microcontroller require 3.3V to operate (while the voltmeter only has an 1V resolution), forced me to always use a multimeter when using it, to be able to precisely set the output voltage.

The solution I found was to simply replace the analog voltmeter with a digital one. Instead of using a voltmeter chip like the ICL7107 that usually require the measurement ground to be separated from the supply ground, these days it is easier to build a voltmeter using a microcontroller.

That’s because even the cheap and simple micros now have at least a 10 bit ADC which is more than enough for a voltage meter in the rage 3..15V (which is the range of my power supply). Since the task is easy there was no need to use an ARM microcontroller as I usually do, but instead an ATtiny26 proved more than enough, despite only having 2KBytes of FLASH and 128Bytes of RAM.

This is the result:

The circiut is simple, a 78L05 is used to reduce the 20V found in the power supply to 5V to power the microcontroller. A voltage divider made with 1% precision resistors is connected from the power supply input to an ADC capable GPIO on the microcontroller, and three LED displays show the voltage with 0.1V resolution.

The LED displays are ofcourse multiplexed so that the ATtiny, despite its low number of GPIOs, can drive the display with no other glue logic except for current limiting resistors.

Around 100 lines of C++ code keep the whole thing working.

Back online

June 21, 2010

Because of an issue with the hosting service, my website (together with other websites on the same provider) has been unavailable for three days. Now the problem is fixed and I’m back online.

Glue stick torch

June 5, 2010

Ever thought that you can make a torch using a glue stick?
Ever thought that you can hack an inductor into a transformer?

Here is the final result of a rather old project I’ve done in 2005, but never published until now.

Read the full article on my website.

Qt and serial ports

April 23, 2010

Update Jun 22, 2011 : Fixed a bug for compiling under visual studio 2010.

This is intended to be a small add-on to the article I’ve posted on my website which explains how to use boost’s asio library to interface with serial ports from C++ code. This blog post focuses on a topic not covered in the article: using serial ports in Qt GUI applications.

Since serial ports are used primarily to interface a computer with a microcontroller, we’ll focus on this case.

The additional problem that occurs when the application has a GUI is the result of two restrictions that GUI applications have:

  • The thread that runs the GUI event loop should not block for long periods of time (say, more than a second). If this happens, the GUI “freezes” and this annoys users who think the application has crashed and usually force-quit it.
  • Code that updates the GUI should not be called from threads different from the main thread.

Now, if the microcontroller never sends data to the serial port unless the computer sends a command to it, and replies are always fast there is no problem.

Let’s show a basic protocol of this kind:

  • The PC can send the command “A” to the microcontroller.
  • If the microcontroller receives “A”, it reads an ADC channel and sends the value back to the PC

As said, in this case there is no problem. A possible GUI would have a button to read the value, and a label to show the result.

Such an application can easily use the TimeoutSerial class, with code to write the letter “A” in the callback of the button, immediately followed by a read from the serial port to get the result and show it on the GUI. The timeout, set to an appropriate value (such as 500ms) would ensure that the GUI won’t freeze even if something goes wrong, and the programmer can catch the TimeoutException to show an error message to the user.

But what to do if the command takes much time to complete, say 10 seconds? In this case this simple approach won’t work, because the GUI will freeze for ten seconds with the main thread waiting for the response from the serial port.

And what to do with a protocol like this?

  • The microcontroller sends the value read from the ADC 20 times a second.

In this case the PC application should always listen on the serial port for incoming data.

Well, who has read my article will probably think of using the AsyncSerial class, which allows to register a callback that will be called every time some data arrives from the serial port.

But also this approach won’t work, because of the constraint that the GUI code can be called only from the main thread, but AsyncSerial calls the callback from a separate thread.

To show how to solve this problem I’ve written a class, called QAsyncSerial which is a wrapper class for AsyncSerial that uses Qt’s system of signals and slots. It basically emits a signal every time a line is received from the serial port, and because signals and slots are thread safe, the code works as expected.

To show everything in practice, this is a simple GUI that uses QAsyncSerial running on Linux:

This simple GUI allows to select a serial port and open it (the baud rate is fixed to 115200, 8N1 format). Once it is opened, there is a line where to write text to send to the serial port while received text is showed below.

The code of the QAsyncSerial class and of the GUI example is posted at the end of the original article (here). It is meant to be compiled with QtCreator. If you try to compile it don’t forget to edit the line “-L/usr/local/lib” in the file to point to where you have the boost libraries installed.

Last note, since the Qt libraries are cross platform, here’s the same application running on a Mac:

CMake part 3: Finding libraries

March 7, 2010

Over time, I find myself more and more interested in CMake. That’s because I write many little programs, and those that use makefiles routinely break as I switch OS.

The last one was a program that depended on libpng. When I tried to compile it on Mac OS X, it failed to find the library. That’s because on Linux is simply in /usr/lib and png.h is in /usr/include, both of which are in the compiler’s search path, so that all you need to do is add “-lpng” when linking.

But on a Mac libpng.dylib (yes, shared libraries on a Mac have .dylib extension) is in /usr/X11/lib and png.h is in /usr/X11/include that are not in the compiler’s search path, so that when compiling you need to add “-I/usr/X11/include” and when linking “-L/usr/X11/lib -lpng”.

The solution was not to keep two separate makefiles, but rather to throw away the makefile and replace it with a CMakeLists.txt

Which brings us to the question: how to link with libraries using CMake?

There are two ways, the first is the find_package command, the other is the find_library command.

Let’s start with find_package. CMake “knows” about many widely used libraries. For them, there is a script to find them in all supported platforms. So, to use a library all you need to do is find it with the find_package command. Here is a simple example of a program that uses threads and so depends on “-lpthread”, main.cpp:

#include <iostream>

using namespace std;

void *thread(void *argv)
    cout<<"Into a spawned thread"<<endl;

int main()
    pthread_t t;
    cout<<"Back in main thread"<<endl;

and here is the CMakeLists.txt file:

cmake_minimum_required(VERSION 2.6)

## Target
set(TEST_SRCS main.cpp)
add_executable(test ${TEST_SRCS})

## Link libraries
find_package(Threads REQUIRED)
target_link_libraries(test ${CMAKE_THREAD_LIBS_INIT})

As can be seen, the first parameter passed to find_package is the name of the package, the second is “REQUIRED” and means that if the library could not be found, CMake should stop and print an error message.

Once the library is found, you have to say which executable needs it (because a single CMakeLists.txt can be used to produce many executable by just using more add_executable commands). This is achieved with the target_link_libraries command that appends a library to the list of libraries an executable needs. The first parameter is the executable name, the second is the library. Note that find_library generates a variable that contains the name of the library, in this case the name is CMAKE_THREAD_LIBS_INIT. This strange name is an exception, usually all find_package scripts create a variable with the name <libraryname>_LIBRARY.

Now a more complex example: the libpng issue I talked about earlier. It is more complex because you don’t just need to add a library when linking, you also need to tell the compiler where is the png.h file when compiling. Luckily, CMake has a package for libpng that does all that, and here is the CMakeLists.txt example:

cmake_minimum_required(VERSION 2.6)

## Targets
set(TEST_SRCS test.cpp)
add_executable(test ${TEST_SRCS})

## Link libraries
find_package(PNG REQUIRED)
target_link_libraries(test ${PNG_LIBRARY})

The find_package command finds the PNG library, target_link_libraries adds the library to the list of libraries the executable needs, and include_directories adds the directory where the .h file is when compiling.

But this isn’t the end. Other than libraries there are collections of libraries. And CMake supports them too. One example are the boost libraries. There is no single to link to; instead every sub-library has its .so file. So there should be a way to link only with the desired sub-libraries. This is an example CMakeLists.txt that does that:

cmake_minimum_required(VERSION 2.6)

## Target
set(TEST_SRCS main.cpp)
add_executable(test ${TEST_SRCS})

## Link libraries
set(BOOST_LIBS thread date_time system)
target_link_libraries(test ${Boost_LIBRARIES})
find_package(Threads REQUIRED)
target_link_libraries(test ${CMAKE_THREAD_LIBS_INIT})

In this case we initialize a variable with the sub-libraries we want (boost.thread, boost.date_time and boost.system). Then we call find_package with the library name (Boost), the word COMPONENTS followed by the list of sub-libraries and as usual the REQUIRED word. Since boost.thread depends on the system’s thread library, we also use another find_package command to link with threads.

This ends the examples of find_package, but there is one last issue: what if we need a library for which there isn’t a package script? The solution is to use the find_library command. It will search in the system paths for the needed library. Here is an example that uses the command to find the Poco libraries:

cmake_minimum_required(VERSION 2.6)

## Target
set(TEST_SRCS main.cpp)
add_executable(test ${TEST_SRCS})

## Link libraries
find_library(POCO_FOUNDATION PocoFoundation)
find_library(POCO_NET PocoNet)
target_link_libraries(test ${POCO_FOUNDATION} ${POCO_NET})
find_package(Threads REQUIRED)
target_link_libraries(test ${CMAKE_THREAD_LIBS_INIT})

The find_library command takes two parameters, the first is the variable where the found library will be stored, and the second is the library name (the name is camelcase in this example because Poco libraries are camelcase, the library name is really
References: CMake wiki

Fonera 2.0N inside

February 5, 2010

It took some time but finally someone put on the web images of what’s inside the Fonera 2.0N.

Here are the links:
Printed circuit top
Printed circuit bottom

Now some details:

In the top picture you can clearly see the new Ralink chip and the FLASH memory, which has a parallel interface (the previous Foneras had a serial FLASH) so we can expect faster boot times and better read/write performance.

The bottom picture only shows the two RAM chips.

There seems to be a JTAG port (the 12 pads at the left of the top image). Even the other Foneras had such connector, but was never used since redboot and the serial port provided an easier way to reflash it.

And yes, there is also a serial port! The connector name is JP2, the 4 pin connector at the bottom left in the top pcb image. It is not populated by default, but it is always possible to solder wires directly to the pad on the pcb.

Quoting from

Serial Port is JP2.
Pins are 3,3V – RXD – GND – TXD
Configuration is: 57600 8 N 1

As I don’t have a Fonera 2.0N, I can’t try to see if it really works, buth the pinout does make sense since it says that GND is pin 3, and the bottom pcb image shows that the third pin is connected to the ground plane.


Get every new post delivered to your Inbox.

Join 29 other followers