Automon Kernel Considerations

Automon Architecture

Automon Architecture

The Automon kernel will be responsible for all the lower level ELM327 serial communication. It will provide a easy to use interface to communicate with any ECU encapsulating all ELM327 commands.

One of the design issues problems I am encountering is that not all responses from the ELM327 are “simple”.  Most sensor commands result in a few bytes represented in hexadecimal and you apply a formula to get the actual human result in volts, rpm, degrees etc. Some results however are bit encoded. For example a request to Mode 3 of “03” without a Pid results in a stream of bytes, with the first byte meaning how many DTCs are present and the remaining types of DTCs, where each is encoded to a special type, P, U, B codes etc and which are pending or not is also encoded into the bytes. I wanted to create a generic PID base class but the complications is causing problems. I want to allow the user to provide proprietary codes as well. To do this I would read the codes from a file but how do I specify the formula and the logic in the formula if it exists? – For example, some formula’s have, If Byte B == 0xFF (all 1s), then it means this, other wise take byte A and do something else. One solution would be to using scripting. QT provides a useful scripting engine in the QScript module. I might look into this and get a better understanding of it.
Alternatively, if I want to make my system less flexible, I could create a Sensor class and derieve each sensor over writing a “convert formula” method so each class of sensor has its own defined formula.
Since the data structure holding these is so vague and none standard across all sensors, I thought XML would be a great way of representing this data for parsing later.

Today I managed to convert my GUI prototype app into one that can handle a QList<Sensor> of sensors. I also implemented a way of how frequent sensors get updated. For example, RPM,MPH are the main ones that change down in milliseconds but something like coolant temperature would only need to be checked maybe every few sensor cycles. A sensor cycle is where my serial comm thread iterates through a list of sensors. Every time it comes to a sensor, it evaluates if it time to check that sensor, otherwise skip to next. This makes adding sensors quite handy. I also created signals in my sensors, so once their value changes, they automatically emit a signal with the new value. This is very useful since I can connect sensors to GUI slots very simply. Here is an example:

sensor = new AGenericSensor();
sensor->setEnglishMeaning(“Engine Revolutions per minute”);

sensor2 = new AGenericSensor();sensor2->setEnglishMeaning(“Engine Coolant Temperature”);


connect(sensor, SIGNAL(changeOccured(QString)), this, SLOT(updateLCDText(QString)));
connect(sensor2, SIGNAL(changeOccured(QString)), this, SLOT(updateLCDText(QString)));

Automon Design

I decided it was time to actually start designing Automon and stop playing around with proof of concepts. The way I am going to approach this project is to develop a library separate from the GUI that will act as the kernel so to speak. It will provide an object oriented interface to the ELM327.

I spent a while writing down what methods would be needed and soon realised that this project might be a lot bigger than thought! However, it should be do-able. It will be a soft real time system, where timing will be down to milliseconds.

Here is an idea of a class to interface Automon. Just very basic idea at moment. It will probably change quite a bit from this.

Interface Class Diagram

Interface Class Diagram

Received my EOBD Simulator

ElmScan and Simulator

ElmScan and Simulator in Action

KWP2000 Simulator

KWP2000 Simulator

Today I received my ECU EOBD simulator from Turkey. It only took a day to get here! – very fast delivery.
It didn’t come with a transformer to plug it in so I looked up the data sheet for the power specifications. It requires a 12VDC supply with 500mA current. I purchased one in my local electrical store and this done the trick grand.

The device works great. It has 5 variable sensor values, RPM, MPH, Coolant Temp, o2 Sensor Voltage and MAF. Other PIDs are also on board with fixed values. It includes a DTC switch that allows you to turn on the MIL along with logging a few DTCs. It even includes freeze frame data and a VIN. Resetting the MIL and erasing the DTCs works perfectly by sending down a mode 4 request.

This should make life a lot easier now as I won’t have to be in the car much. But when I get into a proper testing phase, I’ll do weekly tests on my car and maybe another OBD II standard car to ensure that it works on them.

The device is one version of the OBD II protocols, KWP2000 (Keyword Protocol). It is in a lot of European Cars including my MG. Ideally I should probably have chosen a board that had a different protocol. The ELM327 can handle all.

Tuesday, February 10th, 2009 ELM327 Interface No Comments

First GUI Prototype using ElmScan 5 & QT/E 4

GUI Prototype

GUI Prototype

So today I finally decided to create a GUI application that would display the revs. The photo above is taken of the TS7390 connected to the ElmScan 5 USB and my car’s DLC. Even though it is USB, it actually creates a virtual com port so my code didn’t need to be changed from past code. The chip that does this virtual com port emulation is the FT232RL from FTDI. This is supported in Linux kernels > 2.6.9 which mine satisfies. More information from:
The code took me about and hour or two, but I did have the QT serial stuff already done so that would have taken quite a bit more. This is only a prototype and cannot be used in any way in the final product. I am only doing proof of concept that I can in fact read from serial while updating a GUI.

I noticed that if I reduced the refresh rate to 1/4 of a second, things got funny, it was missing bytes etc so the revs were all over the place. It seem to be perfect at about 300ms but that means refresh rate is only ~3Hz. This is actually quite noticeable when you rev up high quickly in neutral but on the road I’m guessing as you rev gradually in normal driving circumstances that it won’t look so bad.
However, the product is not a problem with my program to the ELM327, the serial part is fine. It is a limitation of the OBD side and my car is using KWP2000/ISO 14230 so I will have to figure out more timing details on this protocol. Other protocols such as CAN should be OK speed wise but I will have to investigate more into that.

MGs/Rovers – Not 100% EOBD/OBD II Compliant

The ElmScan 5 tool I received a few days ago from seemed a little strange. I attempted to connect it to my laptop and the car and communicate with it but I kept getting interface not found.
I tried hooking it up with hyper terminal to the virtual USB com port and as soon as I made a connection, the power LED on the scantool would go.
I found it quite strange that none of the other LEDs were even attempting to light. Doing some research, I discovered that when you plug the scantool into the ECU, that a LED sequence should occur to show correct operation of it.

I spoke to one of the main guys at and he was quite surprised since each tool is tested fully before it leaves the warehouse (excellent QA from that company).

So the ElmScan was not getting power, but how is it that my other ‘fake’ ELM327 device gets power and my hand held fault code reader gets power. I was told by the guy I was talking to that the ElmScan uses pin 5 of the DLC connector as ground and pin 16 to get power. Doing more research into the pin outs, it appears Pin 16 is Battery power and Pins 4 & 5 are grounds, chassis ground and signal ground respectively. I had a +12 voltage across Pins 16 and 4 but nothing across 16 and 5. This clearly was the problem.

EOBD DLC Connector

EOBD DLC Connector

So then I got out my volt meter and investigated. I had a +12 voltage across Pins 16 and 4 but nothing across 16 and 5. This clearly was the problem.

Voltmeter used

Voltmeter used

The guy I was speaking to from kindly gave me a hint suggestion to short jumper 1 on the ElmScan. This means that it will take Pin 4 as the ground which is all my car will offer as ground. Opening the tool was surprizingly simple, no glue or anything. I took the circuit board out and grabbed a jumper from old computer parts and placed it on the create the short.

ElmScan 5 USB with JP1 set

ElmScan 5 USB with JP1 set

Alternatively if you don’t have a spare jumper, you can soldier the pins together with a piece of wire.

I hooked it up to my OBD connector on the car and it worked instantly. I loaded up the software and connected USB just to be sure and it connected fine. The tool was sending out 4 samples a second which isn’t too bad. When I revved the engine, the response time was satisfactory. As far as I know the more parameters that I add to request, the slower the response will be but I’ll have to investigate that over the next few weeks.

So in fact MGs/Rovers don’t seem to be 100% EOBD/OBD II compliant – only on a physical level though. Most scanning hardware would work but some don’t and the reason is that pin 5 is not used by MGs/Rovers.

ECU/EOBD Simulator

KWP2000 Simulator

KWP2000 Simulator

Today I decided to look for a proper OBD II/EOBD simulator. This would save so much hassle as I wouldn’t have to be going out to the car every second checking if a change made works. Further more, currently my SBC is plugged into a mains so it awkward getting it powered up in the car.

I decided to go with the KWP2000 protocol simulator as this is the same one in my car. I guess I really should pick another one and get tested on both types but I can simply just plug into another car later on anyways.

The one I went with cost 99 euro and is on this page:

This project is costing me a fortune! – Hopefully everything will pay off in the end now. and their ElmScan 5

ElmScan5 Serial Version

ElmScan5 Serial Version

Today I received a genuine ELM327 Tool (ElmScan 5 ) from These guys kindly offered me a free one worth 130 dollars since I was doing it for my final year project. Unfortunetely they sent me the USB version and I wanted the RS232 serial version so I may send this back. Technically though it should work away by using /dev/ttyUSB0 since the kernel is 2.6 and supports the FT232RL chip that is in the USB version that gives a virtual USB com port.

Anyways I think I’ll be better off going with all serial at this stage just incase it causes problems down the line so might send it back to them. Thanks Vitaliy!

Scantools are located here: It is important to buy the ELM327 Scantools from here as ones on ebay and other places are generally fake replicas and do not work fully. Poor quality etc. I know myself since I bought one for 50 euro and it gives up randomly.

Tested Console Program to Read Revs on TS7390

Reading RPM Successfully!

Reading RPM Successfully!

In MG with Automon

In MG with Automon

It worked!

First of all I had to cross compile QExtSerialPort for ARM Linux. To do this I downloaded the tarball, unzipped it to my home directory. I set my PATH variable to point to qmake in QTEmbedded-4.4.3-arm. Then I ran qmake and make and it successfully compiled for ARM. In the build folder there is a and and few more. I copied all up to /usr/local/lib on my Device.

Next I ftp’d my project from windows to vmware, the one I discussed previously. I had to modify the .pro project to the new location of qextserialport libraries (in my home directory) and I had to add an extra line: libs += /home/donal/qextserialport/build -lqextserialport. I also had to modify the main.c file to point to /dev/ttyAM1 which is COM1 on the board. Then I navigated to my test folder and done a qmake followed by make and resulted in a automon binary. Doing file automon , I confirmed that it was an ARM binary. I ftp’d this up to my device.

I set the whole lot up in my car as you can see in the pictures above. Connecting the ELM327 to COM1. I ran the automon program off the device redirecting the output to the screen by doing

$ cd /home/eclipse
$ ./automon > /dev/tty0

And out comes the revs in the car perfect. It only does a snapshot every 1/2 second but it is enough for me now. Now I have done all my proof of concepts. Just to build the project now in QT!

QT Embedded 4.4.3 and TS-7390 Color Depth Issues

The colour display on the TS-7390’s screen wasn’t very good. It seemed no red or green could be displayed.
I copied the compiled version of QT3 on and this seemed to display colours ok?

So what was up. I discovered that QT4 was detecting my board as 15 bit colour depth but QT3 didn’t support it. So it assumed it would use 16bits (RGB 565 (5 bits for red, 6 green and 5 for blue).
I contacted technologic and they confirmed that my board was actually 16bits (RGB 565) but the least significant bit of green was ignored. A handy way of supporting RGB555 and RGB565. But this extra padding bit was in the middle where as QT4 expects it as the MSB or LSB of the 16bits.
This is the layout of the TS-7390: RRRRRGGGGGXBBBBB where X is the ignored bit by the TS7390.

Looking into the sources I discovered /src/gui/embedded/qscreenlinuxfb_qws.cpp. In it there is a setPixFormat function. Here I tried forcing it to QImage::Format_RGB16.

void QLinuxFbScreen::setPixelFormat(struct fb_var_screeninfo info)

Re compiling and deploying it, it made no difference. So then i decided to do a whole series of qDebugs in qscreenlinuxfb_qws.cpp and qscreen_qws.cpp. The result was interesting. It still claimed to be using 15 bits when infact 16.

After a lot of investigation I discovered it was detecting the green length as 5 when infact should be 6 so i forced it to 6.
In qscreenlinuxfb_qws.cpp line 309 (before the grayscale = vinfo…..) enter this line: = 6;

re compiled and everything working fine. Note I think the modification of the setPixFormat is still required.

And that was it, perfect colour. I hope it helps someone else that has the same problem.

Deploying QT Embedded 4.4.3 on the board

From a few blogs ago I successfully compiled QT/E 4.4.3. It installed in my virtual machine at /usr/local/Trolltech/QtEmbedded-4.4.3-arm/.
On the board use the following commands:

$ mkdir -p /usr/local/Trolltech
$ chown -R eclipse:eclipse /usr/local/Trolltech

In Xbuntu:

$ cd /usr/local/Trolltech
$ scp -r QtEmbedded-4.4.3-arm/ eclipse@

“” is required on the board. I obtained this from the precompiled binaries of QT3 on Place this file in /usr/local/lib

On the board:
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/linux-arm/lib/:/usr/local/lib:/usr/local/Trolltech/QtEmbedded-4.4.3-arm/lib/
$ export QWS_MOUSE_PROTO = Tslib

It is best to put these in /root/.bashrc so they get automatically entered for each user session.

Since QT/E writes to frame buffer it will mess the output of IceWM. I done a sudo apt-get remove icewm and removed x11 similarly. You can do it temporary by doing a ps -A and checking the process id of IceWM and doing a kill <psnumber>
To run the program, it requires a server program but if it is the server itself you use the -qws option. For example:
$ cd /usr/local/Trolltech/QtEmbedded-4.4.3-arm/examples/widgets/analogclock
$ ./analogclock -qws

Now the problem with the output is the colours are all messed up. It seems no green and red can be displayed. This took days and days to sort and this is all explain in my next blog.

Installing TSLib and Calibrating it

From previous blogs, I successfully cross-compiled TSLib. It installed it in /usr/local/linux-arm. So on my board I created a similar path. Since I am doing a secure copy up, I need to give /usr/local/linux-arm a new owner (eclipse).

$ mkdir /usr/local/linux-arm
$ chown -R eclipse:eclipse /usr/local/linux-arm

In VMWare:
$ cd /usr/local
$ scp -r linux-arm/ eclipse@

Now TSLib requires environment variables set up. Edit /root/.bashrc and add these lines:

export TSLIB_FBDEVICE=/dev/fb0
export TSLIB_TSDEVICE=/dev/input/event0
export TSLIB_CALIBFILE=/etc/pointercal
export TSLIB_CONFFILE=/usr/local/linux-arm/etc/ts.conf
export TSLIB_PLUGINDIR=/usr/local/linux-arm/lib/ts

Do a switch user to load these
$ su

Now open /usr/local/linux-arm/etc/ts.conf file and delete all lines and add this:

module_raw input
module pthres pmin=1
module variance delta=30
module dejitter delta=100
module linear

(Make sure that there are no empty lines above or below)

Now to calibrate the device navgiate to the bin directory and run the program. It will display on screen points to tip. Once it is calibrated it will create a file /etc/pointercal. Don’t touch this file. If it fails to create it, ensure neccessary permissions on /etc to allow it. DO NOT CREATE a blank file before hand or you will get a segmentation fault.

$ cd /usr/local/linux-arm/bin
$ ./ts_calibrate

And that is all to installing and configuring TSLib.

Modified SD Card – More Space!

So today I bought a new USB card reader so I could work on partitioning my new SD card with a bigger root filesystem partition. The one that comes by default is something around 400MB and its 90% full which is no use to me.

To do this I downloaded this file: Bunzip2’d it and with my usb card reader in VMWare (/dev/sdb) I wrote the new image to it using command: dd if=512mbsd-aug252008.dd.bz2 of=/dev/sdb. Perfect, out comes my card and bootable but the paritition is too small! I mounted the final partition (mkdir /mnt/filesystem; mount /dev/sdb4 /mnt/filesystem) and created a tar of all the files to back up. I then downloaded Gparted (sudo apt-get install gparted) and used this to delete the last parition (the rootfs) and create a new one using all the unalocated space. Ends up close to the 2GB as the other paritions small. Only problem is that jfs was not option to format with which is what we need. I continued anyways.
Note: That you can use fdisk (sudo fdisk /dev/sdb) with option d to delete the final partition and create new one to the full size.
Next we must make sure that our partition has jfs file system so I downloaded the jfs_mkfs tool that comes part of jfsutils (sudo apt-get install jfsutils). I also enabled jfs support in the kernel by modprobe jfs. (I think that was it from my head). Next unmount the partition (umount /mnt/filesystem). Change file system to jfs (sudo jfs_mkfs /dev/sdb4) and after this remounted like above. Now I untarred all my files back onto the partition.

I think there are probably errors in the file system but you can run a check yourself on them.

Tuesday, January 27th, 2009 Embedded Linux, Single Board Computer 1 Comment

Problems backing up the SD Card. 2GB card = 1GB

Spent a good bit of time wasting there attempting to create a bootable SD with Linux for the SBC.
First I wanted to create a backup of the current SD card so I can put it aside in case anything goes wrong. This proved a little awkward.

I am using VMWare so I have to use a external USB card reader since VMWare doesn’t have access to my internal one. I opened up a terminal window and went to the /dev folder in search of what my USB card reader name is. After bit of investigation it was clearly under /dev/sdd. To create an image of the card I placed my card in the card reader and done a dd -if /dev/sdd -of ~/sdimage.img. This took a bit of time and it finally stopped without errors with a 1GB result. This looked kind of strange to me since it was a 2GB card. I didn’t take anymore notice of it and just tried it out. The SBC screen stayed black and every 10 seconds would attempt a reboot. Clearly it wasn’t booting from SD properly (even though I assumed it would at least boot from NAND Flash). I opened the card in my VMWare machine again and done a fdisk /dev/sdd. Using the p option to print the partition details it gave a few errors about partitions ending on incorrect cylinders. With more investigation I worked out fdisk was reporting my card as 1GB. I tried the original card and I got exactly the same result.
I couldn’t use my internal card reader since not accessible to VMware and I didn’t want to try any windows copying utilities since I’d eventually have to get it working in VMWare anyways. So I rebooted and booted into Kubuntu’s Live CD and done fdisk in there. The card was reporting correctly at 2GB. I done a new copy of the image (storying to my mounted C Drive) and then wrote it back out to the new SD Card and all is well!

I was actually given a USB Card reader in the development kit and I haven’t tried it yet but I’m sure it will work so I will be able to use VMWare and create a new image for the SD card with better partition sizes as currently there’s no hope of storing anything on with the partition being 90% full.

So tomorrow I am going to re size the FS partition and copy over the QT/E binaries and have a go getting that working. I am guessing it won’t go smoothly though especially with tslib and all but nothing really goes smoothly in this project. Learning a lot though so that counts.

Monday, January 26th, 2009 Embedded Linux, Single Board Computer No Comments

Cross Compiled QT Embedded – Step by Step

Well after a few hard days of figuring out stuff I finally got a compiled version of QT Embedded for ARM. I haven’t loaded it onto the device yet as I need to mess about with partitioning the SD card to get a bigger partition. I bought a new SD card today to back up the current one which I’ll be doing later on. 29.99 Euro – what a rip off!
Anyways so the past few days were crazy, frustrating but I finally got there. I set up my whole environment in a virtual environment using VMWare. I installed Xubuntu giving 512MB ram to it, 12Gig hard drive (however I did run into space issues further down but I deleted stuff that was not necessary to make room) and added a borderlands 3 split screen to optimize the work  and time.

So first of all I had to install a tool chain. I tried building my own one using binutils and gcc+glibc/newlib sources but it was impossible to even get to the stage of having a bootstrap gcc “c” compiler. There isn’t too much information on building a compiler with modern sources,  now most people just download binary cross compilers such as the ones on codesourcery: I downloaded this and successfully built a helloworld program but moving it onto my board and executing it resulted in an “Illegal Instruction” message which obviously meant the cross compiler is compiling for a slightly different processor architecture even it be ARM. This could be to do with Debian Etch compiled for OABI instead of EABI. As far as I know most modern compilers are using EABI (Embedded Application Binary Interface). This means specifies a different file format to that of Old ABI (OABI). The EP9302 processor supports both modes but it is possible the version of Debian has being compiled as OABI meaning EABI instructions be incompatible and that’s the reason I get an Illegal Instruction message. I did run the file command on the binary file and it reported correctly, being an ARM executable so it definitely cross compiled for ARM.

Anyways I moved onto the Windows cross compiler with Eclipse that came on the SD card and I could successfully compile but same problems, Illegal Instruction. There was however a hello example called helloworld-aobi so I attempted to compile this but ran into problems. It uses Cygwin to execute gcc in a linux environment but paths got mixed up and I didn’t want to spend anymore time on it since I will be compiling QT Embedded on Linux in VMWare.

The SD card came with a pre-compiled toolchain, crosstool-linux-gcc-3.3.4-glibc-2.3.2-0.28rc39.tar.bz2. So i moved this into Xubunto and tar xvjf <the bz2 filename> and moved the contents into /usr/local/opt/crosstool/arm-linux. The bin directory in this are the actual tools we require so this needs to be added to the PATH environment variable. Instead of entering it everytime I edited my bash init file .bashrc with VI (vi ~/.bashrc) and entered the line export PATH=$PATH:/usr/local/opt/crosstool/arm-linux/bin in the top of the file. Note you better off doing same for root’s one so type su and enter root password. Then edit /root/.bashrc and enter the line here too. Reason for this is I found when you run sudo you in root mode and the environment variables don’t reflect so compiler’s may not be locatable.

So I created simple hello world C and C++ programs in my home directory and compiled using arm-linux-gcc for C and arm-linux-g++ for the C++ file. arm-linux-gcc helloworld.c -o helloworldc.out and arm-linux-g++ helloworld.cpp -o helloworldcpp.out. Compilmation was successful so I moved my two binaries to the home directory of Linux on my device. This can be done by exiting “fastboot” mode using consoleo (using the JTAG board connected to the pins and hyperterminal 115200/N81. Type exit at the linux prompt and the device will boot from the SD card. Now we can ftp from VMware to with user pass eclipse/eclipse. So I placed the files in the home directory (root on FTP). Using telnet to I navigated to /home/eclipse and chmodded the two files to 755 to be able to execute. (chmod 755 <filename>). The owners of this file are now eclipse but telnet logs in as root (with no password) so there should be no problems. Executing the programs ($ ./helloworldc.out) I got my printf of hello world so everything is ok. Now for QT Embedded.

Setting up QT Embedded was a Pain. First of all I need to install QT in order to compile the virtual frame buffer device used to display the QT/Embedded programs on my host x86 (not target). I then compiled QT/E for my host. These steps were ok but it got a bit tricky when I needed to cross compile.

Here are the steps I took anyways, hope they work for someone out there as well. Some steps may be unnecessary such as tmake but do it in case – I came across somewhere about it so installed it just in case. I’m not pretending to be an expert here or anything but these steps may help anyways. If you have any problems, drop me an email or comment and I’ll try give a hand. It is quite a lonely procedure and finding documentation is tough so if problems encountered you must be able to troubleshoot them yourself.

(These stsps are done on Xubuntu in my virtual machine. Note the building steps can take many hours to complete. My username here is donal, obviously replace this with your own)

$cd ~
$ mkdir -p project/downloads/qt_embedded
$ mkdir -p project/sysapps/host
$ mkdir project/sysapps/device
$ cd ~/project/downloads/qt_embedded/
$ wget
$ wget

$ cd ~/project/sysapps/host
$ tar -xzvf
$ tar -xzvf ~/project/downloads/qt_embedded/qt-x11-opensource-src-4.4.3.tar.gz
$ export QT4DIR=~/project/sysapps/host/qt_embedded/qt-x11-opensource-src-4.4.3/
$ export QTEDIR=~/project/sysapps/host/

// Few requirements
$ sudo apt-get install libx11-dev libxmu-dev libpng12-dev
$ sudo apt-get install libxtst-dev
$ sudo apt-get install build-essential

$ cd $QT4DIR
$ export QTDIR=$QT4DIR
$ export PATH=$QTDIR/bin:$PATH
$ echo yes | ./configure -prefix /usr/local/qt4
$ make
$ sudo make install
$ mkdir $QTEDIR/bin
$ cp bin/uic $QTEDIR/bin/
$ export TMAKEPATH=$TMAKEDIR/lib/linux-g++
$ export QMAKESPEC=$QTDIR/mkspecs/linux-g++
$ export PATH=$PATH:/usr/local/qt4/bin
$ cd ~/project/sysapps/qt_embedded/host/qt-x11-opensource-src-4.4.3/tools/qvfb
$ qmake
$ make
$ sudo cp ../../bin/qvfb /usr/local/qt4/bin

close terminal to clear envs created earlier
open new one

$ export QTEDIR=/home/donal/project/sysapps/qt_embedded/host/qt-embedded-linux-opensource-src-4.4.3
$ cd $QTEDIR
$ export QTDIR=$QTEDIR
$ export PATH=$PATH:$QTDIR/bin
$ echo yes | ./configure -prefix /usr/local/qte4 -qvfb
$ make
$ sudo make install

//test framebuffer:
$ /usr/local/qt4/bin/qvfb

create new console/terminal window

$ cd ~project/sysapps/qt_embedded/host/qt-embedded-linux-opensource-src-4.4.3/examples/draganddrop/draggibleicons
$ ./draggableicons -qws //QTE needs sever, -qws means this application is the server, while for other application as games the use of other server sevices fom sites as is a great option for this.

===================Cross compiling QT/E==================

new terminal

Step1: for tslib and autoconf support download and install in own computer

$ cd ~/project/downloads
$ wget [site was down so alternative location]
$ wget
$ cd ~/project/sysapps/
$ mkdir tslib
$ mkdir autoconf
$ cd autoconf
$ tar xzvf ~/project/downloads/autoconf-2.63.tar.gz
$ cd autoconf-2.63
$ ./configure
$ make && sudo make install
$ cd ../../tslib/
$ tar xzvf ~/project/downloads/tslib-1.0.tar.bz2
$ cd tslib-1.0
$ sudo apt-get install automake //seems to be needed
$ sudo apt-get install libtool  //seems to be needed
$ sudo ./
$ ./configure CC=arm-linux-gcc CXX=arm-linux-g++ PLUGIN_DIR=
/usr/local/linux-arm/plugins -prefix=/usr/local/linux-arm -host=arm-linux

I got an error during the make procedure about malloc and to resolve problem i found by editing config.h was the solution

$ edit config.h and comment out #define malloc rpl_malloc
$ make
$ sudo make install

Ensure that cross compiler is locatable
$ arm-linux-g++
if says no input files you sorted, else “export PATH=/path/to/cross/compiler:$PATH”

Use Qmake to create target specification

Note at this stage I was running out of space (df command said. I found that the host folder was about 6 gigs (du -s -h host) so I deleted all contents in this (rm -r ~/project/sysapps/host)

EDIT: Note!!!! – The TS7390 is a 16bit colour device but techically it is 15 bits. It ignores the least significant bit of the green bits. Its arrangement is: RRRRRGGGGGXBBBBBB so infact its RGB 565 but QT Embedded detects it as a 15 bit device since it gets 5 bits back for the length of the green colour. You will get dodgy colour here. Please look at one of my latest blogs on the hack on how to fix the colour before compiling.

$ cd ~/project/sysapps/qt_embedded/device
$ tar -xzvf ~/project/downloads/qt_embedded/qt-embedded-linux-opensource-src-4.4.3.tar.gz
$ cd qt-embedded-linux-opensource-src-4.4.3
$ export QTDIR=$PWD
$ echo yes | ./configure -embedded arm -xplatform qws/linux-arm-g++ -no-qvfb -depths all -qt-mouse-tslib -qt-kbd-usb -I/usr/local/arm/tslib/include -L/usr/local/arm/tslib/lib
$ make
$ sudo make install  //Installs in /usr/local/Trolltech/QT-Embedded-4.4.3-arm/

I havn’t tested this but doing a file command on some binaries in the demo example folders it said ARM type so that’s good at least. However doing file in the bin folder for qmake I got Intel 386 binary which definitely won’t work on the board but as far as I know these are not required anyways as only using libraries. Now to get this onto the board. The whole size of the folder is only 78MB so nice and compact. I bought a SD card to back up the other so now I will go messing about getting this on.

First test with QExtSerialPort and the ELM327

Today I decided to write a simple console application that would read the RPM of my vehicle in real time.

Obtaining the RPM of the engine requires sending a Mode 1 PID of 0C to the ELM327. By default the ELM327 echos back the command to you along with the result to confirm that the command you sent was received correctly by the IC. To turn off this echo, you must first send a ATE0 command to the IC. Any internal configurations that is done to the IC is done via AT commands so once the ELM327 receives an ‘A’ followed by a ‘T’, it will interpret the following as internal configuration and not send the command to the ECU on its bus. Next after doing that I continuously sent the command “010C” to get a result (in hex) from the ECU.

The ELM327 won’t execute the command you sent until it reaches a carriage return bytes ‘x0D’ so this is appended to the string I send.

The response will always be: 1st byte the mode + 40, so we should get our first byte as “41” and the next will be the PID of “0C”, the following bytes are the ones we want to interpret. The ELM327 separates each bytes with a character space for readability but this can be turned off using “ATS0” but I will parse by these spaces.

My program worked successfully, however the timing was an issue. I done a continuous while loop with a sleep of 500ms in between using QThread but anything less, the response came out of line and I got a result of 0 rpm. By right using the sleep is not the correct implementation. I should be using QTimer and creating a slot that gets called periodically on a timer signal. I will work on timing later but I am happy just to get a real time output even if there is a second delay between each output. Newer versions of the ELM327 supports an adaptive timing feature that I will exploit later on to get more samples per second thus making it more real time.

I used the strtol function to convert the hex bytes to decimal equivalents which is quite useful. Below is the output of my car as I varied the throttle.

Simple RPM program I made

Simple RPM program I made

QT and QExtSerialPort

So I’ve successfully compiled and built the QT framework on my Windows Laptop using MinGW C/C++ compiler and installed QT Creator 0.9 alpha as my IDE. I originally got complimation working with Eclipse but opted for QT Creator as it looks handy since it made especially for QT.

I am not going to go straight into coding without designing my program first, what is needed etc so I decided I’d be best working out how to do serial I/O. Serial I/O is very simple on Linux since everything on Linux is a file! /dev/ttySxx is usually the file associated with the serial charactor device. But this is no good on my Windows PC so I searched for a POSIX based Serial I/O class or library. Luckly a POSIX library for Serial Comm was developed for QT. The project is located at I downloaded version 1.1 to see how easy it would be to do serial communication.

So I took at a look at the QT project file and saw TEMPLATE = lib so this project builds a library what is expected. I navigated to the directory and done a qmake to create the Makefile and a mingw32-make.exe to build the library using MinGW and QT. (I had to set my path to ensure that all the minGW bin utilities were found system wide set PATH=%PATH%;C:\MingGW\bin. After the building I found two files in the build folder: qextserialport.dll and libqextserialport.a.

Built files of QExtSerialPort

Built files of QExtSerialPort

So now it was time to create a project and test it.

I created a test QT console project. I copied the two library files into the root directory of my project. I also copied in the required header files that are required by the compiler during complimation time. All these files are found in the QExtSerialPort root directory. There’s a few of them there. So now ready to start using them.

To use the files wasn’t as easy as just including the header file, qextserialport.h. I also had to modify the QT Project file in order to include the library for use:

I had to include these few lines:

INCLUDEPATH += C:/Documents and Settings/Donal/Desktop/Applications/qextserialport-1.1/qextserialport
QMAKE_LIBDIR += C:/Documents and Settings/Donal/Desktop/Applications/qextserialport-1.1/qextserialport/build

LIBS += -lqextserialport

I wrote some basic code to open the serial port and send a command to the ECUEmu program. I had problems opening the com port, (Com13) however. Under further investigation it is actually \\\\.\\COM13 i had to use as the port name since it > Com 8 ( However, I changed my USB->Serial adaptor to COM8 (a free one) to save hassle in other programs that only allowed to select from 1 – 8.

The code is as follows:

#include <QtCore/QCoreApplication>
#include <QtCore/QString>
#include <qextserialport.h>
#include <iostream>

using namespace std;

int main(int argc, char *argv[])
QCoreApplication a(argc, argv);

PortSettings portSettings;
portSettings.BaudRate = BAUD9600;
portSettings.DataBits = DATA_8;
portSettings.Parity = PAR_NONE;
portSettings.StopBits = STOP_1;
portSettings.FlowControl = FLOW_OFF;
portSettings.Timeout_Millisec = 0;

QextSerialPort* port = new QextSerialPort(“COM8”,portSettings);

bool res = false;
res = port->open(QextSerialPort::ReadWrite);

qDebug(“Connection failed!!\n”);

QString message(“010C\r”);
int total = port->write(message.toAscii(),message.length());
qDebug (“Total written = %d”, total );

return a.exec();


QExtSerialPort Test Program

QExtSerialPort Test Program

Friday, January 16th, 2009 QT Embdedded Programming 7 Comments

In search of an ECU emulator

Having to be in close proximity of your car all the time, within a metre of the ECU is not very practical for me so I’ve two options: Find a Software Emulator that will emulate the ELM327 interface or else set up a physical ECU standalone out side of the car.

The idea of setting up a standalone ECU was interesting and doing some research into the MEMs ECU system of my MG I figured out the input and output pins of the ECU.

Rover/MG ECU I/P & O/Ps

Rover/MG ECU I/P & O/Ps

Looking on Ebay I didn’t see many offers for ECU’s that are modern enough to support OBDII protocol so done a little searching for emulators.

I came across this site: ECU Emulator (ECUEmu) is a handy piece of software that simulates or more emulates the actions of the ELM327 chip and the Jeff interface. I came across Jeff’s interface previously but opted out for the ELM327 as it supported much more. The ECU emulator requires that you have two computers, each with serial port. ECUEmu attaches to one and you can use hyperterminal at the other end to get the ELM327 > prompt.  I attempted to create a virtual emulated port pair using com0com but unfortunately it didn’t seem to work with ECUEmu. Fortunately though I have 2 usb->serial adaptors for the laptop and a null modem cable so I done a loop back between the two. Laptop->USB->Serial->nullmodem->Serial->USB->Laptop. I set up ECUEmu on one side and used the default settings for hyperterminal on the other (9600, 8N1). I got a prompt. Next to test it, I set the value of the engine RPM to 1A1Ch  and done a look up using hyper terminal by typing in hex 010C (Mode 01 with PID code of 0C. Click here for more details). The returned value then was 2 bytes, 1A1C. The 1A1C is the value we set above and to convert this to a real value you use the conversion formula: ((A*256)+B)/4. Here A is the decimal equivalent of the first byte 1A h (26) and B is the decimal equivalent of the other byte 1C  (28)  so we get ((26*256) + 28/4) = 1671 so our value for RPM is 1671rpm at least it should be!. To confirm I opened up a OBD Program and connected it to the com port associated with the other end of the null modem cable. The results I obtained from it did indeed match so success!

ECU Emulator Output and Hyperterminal

ECU Emulator Output and Hyperterminal

So there I have it, an obtained RPM value from the ECU Emulator. This should save a lot of trouble and not having to be next to a car all the time.  However by the looks of the program it only supports OBD Mode 0, these values such as RPM, Speed etc. I’ve to figure out how to test Diagnostic Trouble Codes (DTCs) as well. This may require me to set up a proper ECU later on and simulate something like a miss fire, how I’ll do that I’ve no idea.

Modes of OBD

There are 10 modes specified by SAE J1979 OBD standard:

  • $01. Show current data
  • $02. Show freeze frame data
  • $03. Show stored Diagnostic Trouble Codes
  • $04. Clear Diagnostic Trouble Codes and stored values
  • $05. Test results, oxygen sensor monitoring (non CAN only)
  • $06. Test results, other component/system monitoring (Test results, oxygen sensor monitoring for CAN only)
  • $07. Show pending Diagnostic Trouble Codes (detected during current or last driving cycle)
  • $08. Control operation of on-board component/system
  • $09. Request vehicle information
  • $0A. Permanent DTC’s (Cleared DTC’s)

(Taken from Wikipedia)

I will be mainly dealing with the first few modes.

So I will still require the use of a ECU at some stage and some way of simulating changes of values. I believe by hooking up a 12volt power supply and doing the neccessary groundings that I should be able to get something up and running. However, without any sensors I will get readings of 0volts, 0rpm etc so I may have to develop a variable sensor, probably a variable resister, that will change the resistance on the circuit to simulate changes in coolant temperature for example. Some day however I’ll get around to that.

First real look at my SBC

My 7390 SBC Front View

My 7390 SBC Front View

Rear View

Rear View

So today I decided to take out my single board computer that I purchased for my project. It is the TS-TPC-7390. More details can be seen here.

Starting the device required me to wire in the transformer that came separate, but apparently it is important to get the polarity correct as there is no safety circuit on the board!? – Amn’t convinced with such an expensive device not having such features but I amn’t willing to find out either!

The device boots up to a Linux GUI in around 1.5 seconds as they claim with a nice start up tune and Technologic Systems logo. The desktop environment is IceWM, which is light weight. Obviously a big one like KDE would not work in such a device with the limited storage and memory capacity.

I was hoping the response from the touch screen would be a bit better as it requires quite bit of pressure on it to get an interaction. I tapped on the start button of IceWM and navigated around to have a look at what was available on the device. Nothing really that fancy, firefox was about the most compicated thing there and that didn’t even load! – It is actually Iceweasal – another version of firefox without all the proprietary logos etc so its free to ship. In the System Utilities folder, there was a Virtual Keyboard which is quite useful for input but really slow to use. Unfortunetly don’t have a USB keyboard with me so decided I had to figure another way of interacting with this device!

On the documentation it says that the device is preconfigured with IP address of, so I set my computer in the same subject range and attempted to telnet into it. It worked no bother and no root password either! Doing a uname -r, it is clear that it is Debian linux that is running on the device, Debian Etch to be percise. An issue of free command confirmed that 64MB ram was actually on this device with about 15MB free, but most of this is taken up by the WM which I won’t have in my project.

An 2GB SD card comes with the SBC (plugged into its slot) which contains images of Linux and a whole ready made cross complimation setup using Eclipse. This card can be hot swapped unlike CF so I took it out and stuck it into my card reader to have a look to see what was on it. It was not readable by 2 of my card readers both on different PCs so I thought something up so. At first I thought it must be because a none native Windows FS but this didn’t make since since Eclipse on it was one for Windows. I stuck it into my SBC again to see if I could read it from Linux. Doing a ls on /dev I could see sdcarddata, sdcarddata1 – sdcarddata4. This suggested to me that there was 4 partitions on the device and looking at the documentation I confirmed this. The first was a 1.5Gig that contains all the files I am looking for so I created a mount folder /mnt/donal/ and mounted the SD card using the command mount /dev/sdcarddata1 /mnt/donal -t vfat. This worked fine and I could view the contents.
I tried taring the whole folder but no room!. I set up a FTP server on my laptop and tried pushing items across. This worked fine for individual files but I wanted recursively to do everything but this doesn’t work with the standard ftp utility in Linux. Next option was SCP so I set up a SSH server on my computer creating an account for the SBC. I could successfully send all files to a home folder on my laptop using the command scp -r * donal@ This transfer took almost 30 minutes but finally I got everything I wanted.

The next thing I was interested in looking at was connecting to the device using a serial connection. Looking at the inittab file, it writes the Kernel output to /dev/ttyAM0 which is the console port of this device. This is accessible by connecting a JTAG board to the SBC’s JTAG connector. I used a null modem cable then from that to my laptop and set the correct settings on hyperterminal (115200, 1S No Parity, 8Data No F/C). I got an output to hypterminal and could enter commands to the shell prompt. Least now I know my USB->Serial adapator works but there are issues with these when timing is involved due to the extra abstraction hardware layer associated with USB.

There were 2 more ports, COM1 and COM2 available on the board. I connected the Serial adapator to the pin outs on the board for COM1 and connected to the null modem. I hadn’t a clue of the baud rate etc for it so I guessed 9600 with the standard 8N1 & no F/C. So how would I test it? – There are no terminal utilities on the SBC. So what i thought of was doing a simple echo and redirecting it to /dev/ttyAM1 so I issued the command echo “Hi Donal!\r” > /dev/ttyAM1 and this worked perfectly so now I know my ports are working.

I created a file using touch hello but the file wouldn’t remain after a restart which suggested to me the NAND Flash was read only. This also lead me to believe there was no swap file and I confirmed this too. This is why firefox froze when loaded I’m guessing! – I will have to investigate if possible to mount a partition from a SD card and link a SWAP to this device. However, will 6MB/S be fast enough I don’t know! – Either way I am going to use the SD card for writing settings and logging data from Automon.

I think that was enough messing with the SBC for now, next I will have to look at how to get QT on it or even re compile a smaller debian image with QT/Extended binaries installed. I think that may be something that I’ll do later down the road though.

Wednesday, January 14th, 2009 Single Board Computer No Comments

What is Automon?

Hi There,

I am Donal, a 4th Year software student from the Cork Institute of Technology ). The title of my course is Software Development with Computer Networking so it is pretty much 2 courses in one: Networking/Telecommunications + Software Development.

I am creating this blog to keep track of my daily progress on my final year project (FYP) : vehicle remote starter , think of it as a diary to keep track of daily events, it will make the writing of my final report a bit easier!

Automon will be an embedded ARM touch screen device that will be mounted on the car’s dashboard and connected into it’s ECU reading real time information such as vehicle speed, coolant temperature etc. The device itself will be a TS-TPC-7390 Single Board Computer (SBC). More details can be found at

A quick summary of the device:

  • 200Mhz ARM9 CPU
  • 64MB SDRAM
  • RS232, USB, 10/100 Eth ports
  • 7″ Touch Screen

What the project will involve

Automon will be developed using the QT (“Cute”) framework from Nokia (formally Trolltech). This is an open source framework that is quite powerful looking. I have to learn this framework on the fly. A special version of QT, QT/Extended or Qtopia will be what I’ll use on the actual device. This will allow me to write directly to the frame buffer (/dev/fb0) on embedded Linux making my application independent of a window manager such as X11 saving quite a bit of resources!

Communication directly to the ECU would require intermediate hardware and signal processing that I don’t have time to do and plus considering there are multiple OBD protocols (3 main, 5 flavors) it would just not be practical. So instead I will be using the ELM327 IC. Datasheet found here: I can communicate with this chip using a serial interface using AT commands.

As stated above the device will be a SBC but since it is ARM driven, cross compiling will have to be done. This can be a tricky process and especially with QT libraries included.

Below is some more details on parts of my project.

Project Background and Introduction

The automotive industry is moving towards more intelligent forms of transport. Currently vehicles are able to sense one another and alert users or even the car’s control system of dangers that may exist ahead. Vehicles use real time sensor data to determine such dangers or failures that may occur. The rationale behind this project is to demonstrate the use and interpretation of these sensor values and display them to Electronic Manufacturing Services in a meaningful way. All vehicles must implement a standard form of diagnostic reading, OBD (Onboard Diagnostics) which allows all sort of cars to be communicated with using a standard reading device. In addition to this, cars have their own proprietary protocols as well for communication with expensive diagnostic equipment that usually only services one type of car. Generally these proprietary protocols provide a lot more detailed information of what is happening in the car. This project will not deal with such protocols as this will be a limiting factor to which vehicles AutoMon will be able to communicate with.

Onboard Diagnostics (OBD)

OBD is a term in the automotive industry that refers to a car been able to self diagnose itself and provides users or mechanics with the necessary information to gain an understanding of what is wrong with the engine or its sub systems. In 1996, the OBD specification was made mandatory for all cars sold in the United States. This was in an effort to encourage manufacturers to produce more efficient vehicles reducing emissions. OBD II is an improvement over OBD with better capabilities and standardisation. By 2001, the European Union made OBD II mandatory for all petrol vehicles sold in the European Union.

AutoMon will communicate with the car using OBD II and its connector that is standard across all vehicles. Different protocol implementations are existent, 5 to be precise. Investigations into ways in which to communicate with all 5 protocols together were done, and two solutions exist, both of which are an integrated circuit (IC), the ELM327  and the BR16F84-1.07

Prototype of what will look like

Prototype of what may look like

Tuesday, January 13th, 2009 General Information No Comments