Sound controlled lamp

That’s a project I’ve done long time ago, but never talked about it in my website.

Here is the link.

OLED displays are getting better every day

OLED is a display technology that attracted me from the beginning.

The advantages are:

• Wider viewing angle (near 180 degrees)
• Lower response time (order of microseconds, not milliseconds like LCDs)
• Better contrast compared with LCDs
• Power consumption depends on the actual number of pixels lit, so it can be lower than LCDs
• Piexls directly emit light, no need of a backlight
• Can be made flexible

I used OLED displays in two of my projects, the multi function watch, which uses a 96×64 pixel monochrome yellow OLED, and the Miosix player, with a 128×128 pixel 262K color OLED, and can confirm the advantages of this technology.

However, the reason of this blog post is this video I found on youtube:http://www.youtube.com/watch?v=f8S8tbQMp2k. It looks like another advance in OLED technology. Other than being flexible, it has another advantage: it is much more resistant than an LCD. I hope it will be mass produced soon

Using C++ on microcontrollers code size tricks

I posted a new article on my website.

It talks about some tecniques to minimize the code size when using GCC and C++ with microcontrollers. It also includes a fully functional template project for an LPC2138 microcontroller.

GCC optimization flags

Recently I was talking to a friend of mine who is doing his thesis on parallelizing software on the CELL processor (the one used in the PS3). When benchamrking they found a program that runs nearly four times faster if compiled with the -O3 option. I’ve always specified optimization flags in my projects, and I was aware that they speed up the code a lot, by I was surprised by that figure: four times faster, and without changing the source code!

So, I decided to write a blog post about it. First, let’s start with GCC basics. To compile a C++ file you usually type:

g++ -c file.cpp
g++ -o file file.o

The first line compiles the source code int an object file (file.o), and the second performs the linking step.

To specify an optimization flag, you add -OX to the compiler, were X can be 0,1,2,3 or s; like this:

g++ -O3 -c file.cpp
g++ -o file file.o

Ok, but what optimization flags to choose?

When debugging code, it is necessary to use -O0, which is the equivalent of passing no optimization flags. This is because optimizations confuse debuggers that have difficulties in single stepping your code. (Of course, if you want to debug your code with gdb, you’ll want to enable debugging data, by passing the -g option to the compiler)

When you are releasing your application, it is time to enable optimizations. My advice is to choose the optimization flags in this way:

• By default, use -O2. It makes your code run fast enough for most applications.
• If your application need to run very fast, use -O3. This increases the size of the executable file (for example, because it might perform loop unrolling), but it makes it run faster.
• If you need to minimize the executable size, use -Os plus the -s option that strips from the executable everything except what’s really necessary.

Supertux, cheating at the source code level

Who said that there are no games for Linux?

Other than running games for windows through Wine (as well as nearly any other .exe file), there are many games that run natively on Linux.

I don’t play much, but I’ve personally tried Sauerbraten and Supertux, both of which have been suggested to me by admiral0, a member of the POuL.

Supertux is a nice game, but I’ve found it a bit too difficult to play, especially some levels where there are these flying enemies, identified in this picture:

So, to finish this almost-impossible level, I decided to cheat

And since I’m a programmer, I thought that the easiest way to cheat was to alter the game’s source code It did not take much time to download the 0.3.1 beta release (which was the version I was playing) and find what to modify.

The code that makes these enemies attack from the sky is defined in

src/badguy/zeekling.cpp

and is the should_we_dive() member function of the Zeekling class.

Just replace the function’s body with a

return false;

and recompile. The game becomes a little bit easier, and I successfully completed the level

FPGA!

This is a quick post, more information will follow later. I’m entering the world of reconfigurable hardware

Here’s an image of the FPGA board I’ve designed:

It has an xc3s200 spartan 3 FPGA. It’s not one of the newest nor one of the biggest FPGAs around, but you can synthesize a Microblaze 32bit CPU in it and still have room for other logic.

And there are more good news: Xilinx provides a version of their IDE for Linux, and I even managed to program the FPGA using my JTAG cable and urJTAG.  Here’s an image of urJTAG correctly recognizing the two chips in the JTAG chain:

Until now I’ve only written two simple VHDL programs, one that does an and gate, which is probably the equivalent of the “Hello world” for an FPGA, and one that divides the 50MHz clock on the board by 2^26, and uses the resulting ~1Hz frequency to blink a led. Both work as expected on the FPGA board.

So many interesting things to do, and so little time to do them… it’s 27 September and on 30 September I’ll have to go back to university… This year I had to write my thesis, and that resulted in no spare time during summer…

Miosix kernel released

After one year of development in the spare time, I released the Miosix kernel under an open source license.

I published the kernel source code, the schematic of the Miosix board, the doxygen documentation, instructions for compiling the kernel, and my thesis.

Read about it here: http://www.webalice.it/fede.tft/miosix/index.html.

Which *wrt is best for you

In this post I’m talking about Linux-based alternative firmwares for wifi routers, like the Fonera. Since there is more than one, I’ll present the three most widely known, explaining their advantages and disadvantages.

First of all, why would somebody want to change the default firmware that comes with the router? The primary reason is: more features. Some advanced features like QoS might not be available in the original firmware. It is also possible tu run a small webserver on the router and, if it has an USB host port, a bittorrent client can be installed.

As I said, there is more than one firmware. This blog post will concentrate on DD-Wrt, OpenWrt and X-Wrt.

Let’s start with DD-Wrt. This is a firmware designed for end users, it has a good web-based user interface for managing settings, and is relatively feature-rich. The key point is that the set of features is decided for you by DD-Wrt. The filesystem of the router is not writeable, so you can’t install other applications, and you also can’t remove applications you don’t use to save some FLASH memory space.

Pros:

• Simple to use, good web UI, good documentation
• Adds many features to your router

Cons:

• Limited room for customization, due to the read only filesystem
• When installed, the router password is set to a default value, this might cause a security hole if the user is inexperienced/lazy and does not change it
• Not good for developers. The read only filesystem does not allow to install custom application, the development tools for this firmware are not very developer friendly

Now let’s examine the second choice: OpenWrt. This firmware is the opposite of DD-Wrt. By default, it comes with a minimal set of packages, not even a web based UI (even if it can be installed later). All configuration is done through SSH and a shell Update: it looks like newer releases of OpenWRT come with a minimal web based configuration interface, called LuCI. It has a writeable JFFS2 filesystem, with transparent compression enabled, so that installed applications need a minimum FLASH space. To install applications, you use the opkg package manager. This combination allows to customize the firmware the way you want, by installing only what you need. The repository is incredibly full of packages, see it for yourself here. You can find anything from CTorrent to aircrack to asterisk and even php. From a developer point of view, things are even better. If you have a computer running Linux, you can install the buildroot-based development system. You can choose from the full development system that allows you to modify the kernel and build custom firmwares, or only the SDK for application development.

Pros:

• Fully customizable, with a writeable filesystem and package manager
• Really large number of packages
• Good documentation on its website
• The first time is installed, it asks you to set the root password. There is no default password
• Developer friendly

Cons:

• Not good for end users/noobs. Configuration is done through a shell.

Now, the last firmware, X-Wrt. This is just OpenWrt with a web based UI installed by default. It is not a fork, since the two projects proceed together. This means that all the advantages of OpenWrt are the same for X-Wrt. Developers can even use the OpenWrt development tools to target X-Wrt too.

Pros:

• All the advantages of OpenWrt
• A web based UI for configuration makes it good also for end users

Cons:

• The web UI takes up some FLASH memory. If you have a router with very little FLASH, it will limit the number of applications you can install
• The quality of the web UI is a bit behind the one of DD-Wrt, even if it is improving

Personally, I find X-Wrt to be the best compromise between features and simplicity, and that’s why I’m using it on my Fonera. Also, I’ve tried the development tools and they work well, but maybe I’ll talk about them in detail in another blog post…

First steps with CMake

When building something I usually either let an IDE handle the build process, or write makefiles manually. Both solution work, but have drawbacks. IDEs allow you to forget about how code is built, but create some sort of IDE lock-in, since switching to another IDE becomes difficult. Makefiles solve this problem, but are a bit too low level, and writing makefiles for complex projects is tedious.

So it’s a while I’ve been searching a better way. The most known alternative is autoconf and automake. If you’ve compiled some software on Linux you’ll be familiar with the

./configure <options>
make
make install

way of doing things. However, these tools have the main problems of being built mostly with shell scripts. If you plan to support only Linux this is not an issue, but it becomes a bigger trouble if your program needs to be compiled on windows too, where bash is not available by default.

Recently I’ve found CMake, and it looks interesting. First it’s the tool used to build KDE4, and this means it’s well suited even for large projects, second it claims to work equally well on Linux, Mac and Windows. And lastly, its syntax seems simple and high level.

I’ve started with the documentaton on its website, and in 15 minutes I’ve been able to compile an example program. The example program is made of three files, main.cpp, foo.cpp and foo.h.

The first step to create a CMake project is to write a file named CMakeLists.txt. Its content is this:

cmake_minimum_required (VERSION 2.6)
project (HELLO)

add_executable (hello main.cpp foo.cpp)

The first line is a requirement for a new version of CMake. The second specifies the name of the project, and the third tells CMake to create an executable named hello by compiling the files main.cpp and foo.cpp. Really simple.

Like autoconf and automake, CMake doesn’t compile the code directly, instead it generates a makefile. The steps to compile the example program are to open a shell in the directory where the source files and CMakeLists.txt are, and type:

mkdir build
cd build
cmake ../
make

This is because with CMake it is recomended to keep the build directory separated from the source directory. To remove the generated files it is either possible to type “make clean” or simply to delete the build directory.

It is still early to say if I’ll use CMake for my projects, after all I’ve just started using it for 15 minutes, but it surely looks interesting.

Serial ports and C++

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

I’ve added a new article to my website. You can read it here. This article explains how to interface with serial ports from C++. Applications include communicating with an Arduino, the Fonera or any microcontroller. It presents four classes to access serial ports, starting from simple string read/write to advanced asyncronous I/O.

All the code is based on the Boost.asio library, so the code is portable across operating systems.

If you have comments, or find bugs, post them as comment to this blog post.