Synchronization primitives in Miosix

A small and backwards compatible change in Miosix 1.61 made me think about low-level synchronization primitives, and the fact that doumentation on how to use them was lacking. So, here’s a page dedicated to this topic.

Better code completion for Miosix

For those who are using Miosix with the Netbeans IDE, there is an interesting new feature: support for configurations. Netbeans is the IDE I’m using to develop Miosix, and the kernel comes with a folder containing a Netbeans project to manage its sources. While code completion in Netbeans is good, the IDE often got confused by the existence of multiple supported architectures, so code completion would not work for resolving symbols in the board support packages, at least until now.

Now a new configuration has been added for each supported board, with the predefined macros reflecting those in Makefile.inc, so that code completion now works also for board specific files.

To select the board you’re currently using, right click on the project, and select your board among those listed under “Set Configuration”. Note that this does not eliminate the need to edit the Makefile.inc to build the kernel for a specific board.

Miosix 1.60 is out

Latest changes include preliminary support for the STM32F4 microcontrollers, and the stm32f4discovery board.

Using a DMA capable SPI as an LCD controller

What if you have a graphic display without an embedded controller, and you want to drive it with an ARM microcontroller? Turns out that if a DMA is available, the task is not so impossible as it first seems.

If you’re interested, read the article on my website here.

Mxgui

Ok, here’s the new library for Miosix: Mxgui. As the name suggests, it’a a GUI library for microcontrollers, designed to work with the Miosix kernel.

Source code is here, while documentation here.

What can it be used for? 3D rendering on a microcontroller, for example.

Mxgui examples from fede.tft on Vimeo.

Serial port classes moved to Gitorious

When I first published this article about using serial port with C++ I didn’t expect it to become one of the main reasons people visit my website. Over time, thanks to many comments, bug reports and suggestion, the serial port classes have been modified significantly, to the point that releasing them in a .tar.gz file is no longer a good idea.

I’ve therefore decided to create a git repository at http://gitorious.org/serial-port where you can get the latest version of my serial port classes.

Improving battery lifetime of Le Dominoux

Some time ago I saw on Hack a Day this post about Le Dominoux, an electronic based version of dominoes. At first it didn’t seem much fun, but watching the video I quickly changed my opinion.

In the end, the author also measures the power consumption of the device when the led is not lit, showing it’s around 100uA, and it’s from there that I thought this little device might be improved a bit.

Now, since this device was designed for a 555 contest, the author had to use a 555 IC, and given this constraint I think he has done a good job in optimizing it for low power, using a CMOS variant of the 555 and high brightness leds.

But set aside that constraint, it would be easy to optimize it event further. First of all let’s check the battery lifetime of the original device. Since the power cosumption when the led is lit (probably 5 to 10mA) differs greatly from the standby value of 100uA, battery lifetime largely depends on how much you play with it, but an upper bound is easy to calculate, and it’s 200mAh (CR2032 battery capacity) / 100uA = 2000h / 24 = 83 days. This isn’t very good since even if you almost never play with it, after ~80 days the battery is dead.

One possibility to improve it is to use standard 40xx CMOS logic gates to design the one shot timer, like this:

The fun of CMOS gates is that other than being very versatile, they draw next to zero current when they’re not switching. I built this circuit to measure the power consumption, ant that’s the result:

As you can see, it is drawing just 4uA. The actual standby current depends on how much light is shining on the phototransistor. For example in the dark it draws just 1uA, while if a bright light is pointed at the phototransistor it draws up to 300uA, which is 3V(battery voltage) /10K(R3). This happens also in the original author’s schematic, since the input stage with the phototransistor and the 10K resistor is the same, so that’s no worse than the original circuit. Anyway, in normal ambient light conditions very few light reaches the phototransistor, and the current is very low, around 5uA.

This gives an upper bound to the battery lifetime of 200mAh / 5uA = 40000h / 24 / 365 = 4.5 years!

Last notes about this circuit:

• it uses the same number of components as the original one, just replaces the 555 with a 4011.
• you have to connect pin 7 of the 4011 to ground, and pin 14 to Vcc, even if in the schematic these connections are omitted.

Fail over fail

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 http://openid.net/get-an-openid/ 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

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:

./configure
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…

Update:

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++

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);
pixel.red=min(255,pixel.red+10); //Increase red color of pixel
img.set_pixel(0,0,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:

img.write("new_image.png");

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