You can find the repository here:
hg clone http://bitbucket.org/corfr/stm32template

• Just clone it, and you will have the “base”
• Then edit the Makefile to specify your PROJECT_NAME
• Eventually change TC_PREFIX to specity the path of your toolchain
• Run make to make the project, then make program to program the target.

To debug the project, you can run make debug to launch openocd. Then you will have to connect to the openocd server on port localhost:3333 .

Without GUI for gdb, just do:

arm-none-eabi-gdb --eval-command="target remote localhost:3333"

It should run gdb in command line and connect to the target (you must have openocd running along).

I’m used to Eclipse, so I use Zylin CDT plugin with Galileo. Make a new debug configuration using “Zylin embedded debug (Native)” base, and in the “Commands” tab, put “target remote localhost:3333″ in Initialize. In “C/C++ Application”, select the .axf file.

The project is configured to work with the Amontec JTAGkey and is just setting up USART2 (on board serial port) and blinking Status LED.

I’m opened to any suggestion for that template, feel free to comment.

You can also find other templates, like that one from outroot STM32 Project template for HD devices.

You can see the howto here.

While being a very cheap board, the mini2440 has also great features, but since the MCU used (Samsung S3C2440) is made for consumer products like phones or GPS, is does not implement any CAN driver.

As I needed one, I built this small card. I guess the design is really easy to understand cause, well … it’s really simple, but it might be useful to some people. Feel free to comment or modify the card, just don’t sell it.

This article is not finished, I publish it now cause I’ve been writing it for few months (since march 2009 …) and I guess there is already some interesting informations for advanced users, but this is a WIP. I will resume it and add stuff if people are interested and when I have time, and I’ll also try to answer comments the best I CAN

Hardware

The board has a IO extension port of 34 pins, which make it possible to access to:

• +5V and GND : we can power something
• an SPI interface
• some GPIOs

The S3C2440 feature an SPI interface, which is a slave-master bus that allow the MCU to drive peripherals.

Since I didn’t had much time to develop this, the main purpose of this card is to re-use what’s available. On linux, the socket-CAN project intend to provide a socket way to access CAN controllers. Few drivers are available, one is for Microchip MCP251x CAN drivers, which provide an SPI interface. As SPI drivers for linux are available in the kernel, and as MCP2515 drivers are provided by the socket-CAN project, I decided to use it.

The Mini2440 provide few IO ports in order to add peripherals, but they’re not standardized. On the Mini2440 schematic we can see that an SPI port is available on the 34 pins port, that’s the one I used.

The 34 pins connector is quite hard to find since it is not really a common one. I didn’t manage to find one on Farnell/RS/… : the only one I found on Farnell was a Harwin model, but really had too tiny holes, don’t order it, it won’t work. However, I did find another connector on Harwin, the M22-7141742, it’s a 2mm 34pins header which fit great with the board connector. I asked for samples on the harwin website and received it two days latter, they provide a really great service and quality products.

The CAN connector is not a standard one, in our bot we had another norm using a 10 pin header instead of an expansive DB-9.

I made the schematic and PCB under Protel DXP, cause it’s a standard in my school (hopefully not for long, we are switching to Eagle this year). I can eventually make the schematic and PCB under Eagle with a DB-9 connector if there is demand for it. I’m not yet comfortable with Eagle though, if someone can do that I would be happy to edit and add his content (and credit them of course).

Schematic:

PCB:

Software

I used Embdebian and Angstrom on my board, I guess you should not have any problem using the board with another distro as long as it has a linux kernel

The software part relies on 2 things:

• SocketCAN
• Linux Kernel

(Mini2440 Kernel Repository & news)

I just heard that the mini2440 repository for the kernel has been merged into the official repository, but in order to work you just need kernel sources with Mini2440 support.

Then you will have to modify the machine definition to configure the SPI interface. As you will see, this is not very clean as we need the driver’s header to be included, and as the SocketCAN project is not part of the kernel … But well, it works.

Here is some kind of patch I made, you should be really careful and understand what happens. As the kernel is in active developmental, I can’t say that it won’t broke in a few days.
NB: All that somehow explain why I didn’t do a real patch, cause if you don’t understand why you’re copy/pasting this code, you’re going down.

arch/arm/mach-s3c2440/mach-mini2440.c

// This is ugly, but I didn't find any other clean way as socketcan is external to the kernel
#include "/path/to/socketcan/kernel/2.6/include/linux/can/platform/mcp251x.h"
 
/* SPI / CAN MCP251x support */
static void mini2440_set_cs(struct s3c2410_spi_info *spi, int cs, int pol) {
int pin;
 
switch(cs) {
case 0:
pin = S3C2410_GPG2;
break;
default:
printk("BUG in %s, wrong CS %d\n", __FUNCTION__, cs);
return;
}
 
s3c2410_gpio_setpin(pin, pol);
s3c2410_gpio_cfgpin(pin, S3C2410_GPIO_OUTPUT);
}
 
static struct s3c2410_spi_info mini2440_spi_pd = {
.num_cs         = 1,
.set_cs         = mini2440_set_cs,
};
 
int mcp251x_setup(struct spi_device *spi)
{
printk(KERN_INFO "MINI2440: Loading MCP251x setup\n");
s3c2410_gpio_pullup(S3C2410_GPG9, 0);
return 0;
}
 
static struct mcp251x_platform_data mcp251x_info __initdata = {
.oscillator_frequency = 8000000,
.board_specific_setup = &mcp251x_setup,
.model = CAN_MCP251X_MCP2515,
.power_enable = NULL,
.transceiver_enable = NULL,
};
 
static struct spi_board_info mini2440_spi_board_info[] __initdata = {
[0] = {
.modalias      = "mcp251x",
.platform_data = &mcp251x_info,
.irq           = IRQ_EINT17, /* GPG9 */
.max_speed_hz  = 2*1000*1000,
.chip_select   = 0,
.bus_num       = 0,
.mode          = 0
},
};
 
...
 
static struct platform_device *mini2440_devices[] __initdata = {
...,
&s3c_device_iis,
&mini2440_audio,
&s3c_device_spi0
};
 
static void __init mini2440_init(void)
{
...
 
/* turn LCD on */
s3c2410_gpio_cfgpin(S3C2410_GPC0, S3C2410_GPC0_LEND);
 
/* Init SPI */
s3c_device_spi0.dev.platform_data = &mini2440_spi_pd;
i = spi_register_board_info(mini2440_spi_board_info, ARRAY_SIZE(mini2440_spi_board_info));
printk(KERN_INFO "MINI2440: SPI p_d set %i\n", i);
 
...
}

In order to compile the kernel, you must have a SocketCAN repo somewhere on your host computer. You must change the path of the include line to a valid mcp251x header.
Then after preparing your kernel for your board as usual, you should install SocketCAN.

I’m not gonna enter in the details to make this piece of board, there is plenty of information on the Internet that explain how to make PCBs if you don’t already know.
Check carefully that there is no short circuit or anything though, it won’t do any good to your mini2440.

Ok so now you should connect the board to the Mini2440. Be careful to do that before powering the board, I’m not sure hot plugging it would be a good thing =)

Then you have to load the mcp251x module.

In order to configure the can connection, you have to push your can network bitrate into the proc filesystem.

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

I guess WordPress is pretty good for doing such thing, and it took me less than half an hour to install it, as for now I can’t say I’m really disappointed since there is also nice some cool themes available (I’ll try to customize one as soon as I have some time, which is really not any time soon)

BTW, I’m a French student, in my fourth year of studying at ISEN Toulon. I like few things like OpenSource, OpenHardware, Linux, OOP and embedded dev, and that’s mainly what this blog is going to talk about.

Hope you’ll find things interesting in it