Last year, I compete with a few teammates in the French Cup of Robotic, and our robot was extensively using CAN, because it’s a really robust and widespread network in embedded systems (and it’s true we didn’t had any trouble with it). The problem I was facing concerned how to manage all those ids and stuff in an efficient way.

I tried to find some solution on the Internet, but didn’t find any that would answer my problem without making me writing different code for the many few architectures we were using (PIC18F, dsPIC, ARM9 …).

So I wrote a small app, that used an XML file to “define” the network architecture (nodes, frames), that automatically generated IDs (using priority, node id and frame id) and exported them in a C Header using #define.

I rewrote it from scratch, implementing a lot of things that were not possible in the first version and improving the overall architecture.

This is now provided as a library under LGPL, with a few tools to exploit it easily.

So, if you have an existing CAN network, or a new one to design, and if you want to write not too static code for embedded systems, and analyze smartly the live feed of your network, CanArch might be helpful for you.

Example

So here is an XML file, it’s the “base”:

simple.xml

There is two parts:

• Configuration (conf): Network name, bitrate, types definition and id generation infos
• Network tree (network): The network is a tree with nodes (devices on the network) which have frames

Hu ? Yeah, in that file you specify the nodes on your network, and the kind of frames that each node can emit.

Then the format of each frame is specified, using types like int or enum, with a bit size that you can specify.

Then you can generate IDs using the policy you specified in the definition file, and you can export it as a C Header like this one:

graph.h

(well this is actually an export of that (graph.xml) definition file, which is more complex than the simple previous one)

And to handle all the import / export / visualization, there is a nice Qt4 app called NetworkView:

NetworkView : a Qt4 CanArch Gui

Developers

This project is fairly new, if you think you can help, I would be really glad if you do, so please contact me so we can talk about that.

There are lot of things that can be developed to improve this project, I’m thinking about a clean way to handle existing frames and interfaces (using socketcan on Linux for example).

Also, a better support for existing networks, and DeviceNet and other higher level networks based on CAN are ideas I’m thinking about, and I would be glad to share the work, cause I won’t be able to do all that while studying and with my internship coming this winter.

Download / Source

The project page on BitBucket is http://bitbucket.org/corfr/canarch/, you can download the sources from there.

EDIT: CanArch has been renamed from CanOE, since this is a trademark for the Vector CANoe software.

Framebuffer

If you compiled a kernel from the mini2440 kernel repository with the mini2440_defconfig, the framebuffer driver is loaded by default. You should see an “Armwork” logo when booting your board. If it’s not the case and you have a 7″ screen, you have to pass “mini2440=1tb” as a boot argument for the kernel ( 0 is for 320×240, 1 for 800×480 ). This has to be done in u-boot.

The framebuffer for the screen should be avaiable on device /dev/fb0, if that entry does not exist, you probably want to make it by using the following command “mknod /dev/fb0 c 29 0″. If you wonder why those numbers, well, the major “29″ is from the /proc/devices file, there you can see that the major 29 is reserved for fb character devices, and as there is only one fb on the system, the minor is 0, but if you want to make sure of that, all character devices are listed on /sys/dev/char.

If you don’t have anything in /proc or /sys or both, you should mount them by doing:

mount /proc /proc -t proc
mount /sys /sys -t sysfs

If you don’t want to be bothered with than anymore, put them in /etc/fstab .

That should be it for the fb.

Touchscreen configuration

A nice “s3c2440-ts” driver should also be loaded when booting your board, it is responsible for providing the touchscreen input.

Char device

When booting, you can see that message: “input: s3c2410 TouchScreen as /devices/virtual/input/input1″. And indeed, if you go to the directory “/sys/devices/virtual/input/input1″ (don’t forget to mount /sys), you’ll see some nice things.
In this folder, 2 directories have interesting names: event1 and mouse0, and both of them have a “dev” file in their content. They contain major:minor addresses of their character devices. Hu ?
event1 provide a “touchscreen” way to access to the touchscreen input while the mouse0 provide another abstraction that show the ts as a mice.
To access them, we have to make a node in /dev as following:

mkdir /dev/input
mknod /dev/input/ts c 13 65 # (from event1/dev)
mknod /dev/input/mice c 13 32 # (from mouse0/dev)

BTW, I kind of discovered the mouse input after doing what’s next, but I didn’t really had good results with that abstraction.

tslib

In order to exploit what’s coming from /dev/input/ts (if you do “cat /dev/input/ts”, you should see some weird characters when touching the screen ), we can use the tslib library.
I followed that howto to cross-compile it.

After the installation, you should be careful with the configuration.
About the ts.conf, I just uncommented “module_raw input”.
About the env variables, I exported as follow at first:

export TSLIB_TSEVENTTYPE=INPUT
export TSLIB_CONSOLEDEVICE=none
export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/ts
export TSLIB_CALIBFILE=
export TSLIB_CONFFILE=/usr/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/lib/ts

As you can see “TSLIB_CALIBFILE” is empty, if you put something in it, all ts_* tools will quit with a nice Seg fault …
Then calibrate your screen with “ts_calibrate /usr/etc/ts.calib” and a stylus. After that, calibration information’s will be stored in /usr/etc/ts.calib, data that you should put in the “TSLIB_CALIBFILE” env var.

If you want a more reliable configuration, put all those vars in the /etc/profile file, this will be load along with bash.

Qt Embedded 4.5

While the qt lib is a nice and heavy piece of work, cross-compiling is actually quite easy.

First you need to download the sources from Qt: http://get.qt.nokia.com/qt/source/qt-embedded-linux-opensource-src-4.5.2.tar.gz (last version here).

Untar it and then go in the directory.

First we need to provide what tools you’re going to use for cross-compiling the thing. On my host I use the toolchain provided by my openembedded installation, thus all my tools are starting by “arm-angstrom-linux-gnueabi-”. You have to modify the file

mkspecs/qws/linux-arm-g++/qmake.conf

to express what tools you want to use to cross-compile. Of course you have to do that according to your toolchain.
BTW, if your toolchain is a path that’s only in your user PATH var, you might want to put the full path to your toolchain, otherwise there will be some problems when doing “sudo make install”.

Then, let’s configure:

./configure -embedded arm -xplatform qws/linux-arm-g++ -prefix /usr/local/Qt -qt-mouse-tslib -little-endian

The -prefix is telling Qt that it’s going to be installed in /usr/local/Qt : hu ? When I first compiled Qt, I had my sd card mounted on /media/disk, so I put -prefix /media/disk/usr/local/Qt as an option. While I had no problem for the installation, I had troubles running some examples, as they we’re looking for files in the prefix path and not the real path (which is /usr/local/Qt on the board). I played a bit with the options but didn’t find a nice way to do that, that’s why I did the really ugly hack that’s following. I’m looking for a better solution, so if anyone as any, please mail me …
I simply did a symbolic link from /usr/local/Qt to /media/disk/usr/local/Qt by doing :

sudo ln -sf /media/disk/usr/local/Qt /usr/local/Qt

That’s really ugly cause cross-compilation and virtual installation should be done nicely in userspace, while here I use a system wide path to do the trick.

Then you simply have to do :

make
sudo make install

It’s going to take a while so go drink a coffee and remember those nice times when you had fun installing a gentoo from stage1 on a k6-2 …

Then unmount your sd card and boot your board.

You first have to register the Qt lib dir, this two lines should do:

echo "/usr/local/Qt/lib" > /etc/ld.so.conf.d/qt.conf
ldconfig

Then, in order to configure QWS to use the tslib driver, you have to

export QWS_MOUSE_PROTO=tslib:/dev/input/ts

as mentioned in the Qt doc.

And … that should be all.
Have fun with Qt examples, starting by /usr/local/Qt/exemples/qws/mousecalibration in order to make sure that everything is all right.

Other ressources

• Cross-compiling Qt/X11 Article on the Qt dev blog

Please comment this post, if you find any error or improvement I would be glad to take them in consideration