I’ve been playing with my brand new Arduino Uno since the beginning of this week on my Linux box. Unfortunately the Maverick (10.10) release of Ubuntu ships a version of Arduino SDK that is incompatible with Uno, looks like the package version was frozen days before the release of Uno hardware. So, the first thing I had to do was update the SDK using unstable packages from Natty (11.04). Just download and manually upgrade the from the Ubuntu website (remember to upgrade both arduino and arduino-core).
The IDE is very user friendly to casual developers and allows to write simple programs without much effort. At the first glance might look like a non-standard C/C++, although the IDE magically adds some include headers and a simple main() calling your setup() and loop() routine when you click on the Upload button. Looks like there is no way to use multiples files in your project, which is OK for small sketches.
For those who want to develop things in the traditional way using the command line, I started a CMake template for Arduino Uno. The template was written in a such way that makes possible to add support for new devices by just creating a new device profile file. There is no restrictions of using this template on other Linux distributions (or even other OS, since CMake runs on Mac and Windows), but adaptations might be needed. Patches are always welcome.
Using the Arduino CMake template
As pre-condition, you will need cmake package (duh!) and a compatible version of Arduino SDK (see Ubuntu Maverick x Uno issue above and how to fix). Only the arduino-core package is necessary for this setup.
Download the latest version of the buildsystem template:
This is a modified version of the classic Blink example, converted to a standard C/C++ (it’s really weird why the Arduino libraries are a mixture of C and C++ and not only C). This example is great because gives you visual feedback without attaching any component to the board, since there is a built-in LED on the board tied to pin 13. Because cmake it’s not a widely spread buildsystem (which is a shame for such a great tool), here are some basic instructions of how to build the project. Type this from the root of your project tree:
$ mkdir build $ cd build $ cmake .. $ make
You can either export the environment variable ARDUINO_PORT set to your device port or edit CMakeLists.txt and change the default value permanently. Mostly likely you don’t need to touch this if you are using Ubuntu Maverick and Arduino Uno combo.
Two extra targets were added to the generated Makefile for your convenience:
- make flash – Will flash your software to the device connected on ARDUINO_PORT.
- make reset – Restart your board (pretty much the same as the reset button on the board).
My favorite debugging tool is printf(). The modified version of the Blink application in the template also contains some debug output. Use minicom to read the output from the terminal:
$ minicom -b 115200 -D /dev/ttyACM0
You need to exit from minicom before flash your device again. Do that by hitting CTRL+A and then X.
Of course that by following this tutorial and using my buildsystem template you can turn your device in a useless geek-looking paperweight. Use at your own risk.
In: devel, en, linux, nerd · Tagged with: arduino, buildsystem, cmake, hack, hardware, howto, ubuntu
Write a buildsystem is always the first step (and sometimes the most boring) when starting a new software project. Qt provides it’s own tool in order to make a single build tree work properly in all supported platforms: qmake. Instead of create a qmake structure from scratch for your brand new project, this template aims to give you a solid base to rely upon, meeting some basic requirements:
Shadow build – No dirty source tree anymore after compiling your code. Build your code inside your tree is optional, you just need to create a build directory and call your project’s configure script instead. There are many situations when this is specially necessary: building the same tree for different platforms or when you source code is located on a slow storage device (such as network drives and encrypted partitions).
Automated tests integration – Test driven development is being more common every day and has proven to be an important tool to detect regressions. This qmake template provides more then a simple way to run your tests (by typing “make check”), but a visual report of your tests coverage using LCOV.
Code documentation – Developers are mostly lazy when writing documents, but not if you provide a easy and beautiful way to check the results of good written code documentation. After hitting “make doc”, a HTML page is automatically generated gathering all information extracted from qdoc3 markups of your source files.
Localization support – A modern buildsystem must provide a clever way of translators update the language files. We must remember that translators aren’t necessarily developers and they may not want to dig your code looking for translatable strings. This template provides integration with lupdate and lrelease i18n tools of Qt framework, creating all .ts files necessary to Qt Linguist.
Debugging friendly – This is quite obvious: a build system must be able to generate a debug release. And you also don’t need to install your software (at least in a Linux box) in order to run a quick and dirty test, due to some tricky linker flags.
Packaging – Your software must be redistributable, so we added a Debian packaging example to this template to demonstrate how packable this buildsystem is, specially for Debian-based system. Does anyone want to contribute with the RPM packaging?
I haven’t made tests on others platforms but Linux. I’m pretty sure of unless you are using GCC, some features such as unit tests coverage report cannot be done with the current implementation.
More information about usage can be found at the BUILD file in the git repository.
In: article, devel, en, nerd, pt_br · Tagged with: buildsystem, qmake, qt
For those who want to test a preview of Qt 4.6 with it’s recently merged animation framework and state machine, I did some patches using the packages maintained by the Debian KDE team in order to build the Qt repository HEAD. I did only few tests with these packages and seems to work fine at this moment. You should note if you install the 4.6 packages, they will replace your system packages. It’s a completely reversible operation, but I must warn you that it may break some applications such as the whole KDE and Skype, because these packages were built from a unstable tree.
If you are brave enough, build your own pacakges with these patches.