Search This Blog

Thursday 26 June 2008

Qt for Embedded Linux

Getting the VC21RB1 working with the VC I2C example was a nice step to make. I can now get back to looking at the VC21MM1.
With the COGLinux kernel in the VCMX212 flash ROM, a few people have been asking on the VC google group whether anyone has ported some form of Linux framebuffer based GUIs across. Some suggestiongs have been Qt, Tiny-X, DirectFB. It's taken me a few weeks to check out the various window managers. Finally liking the look of Qt for Embedded Linux.
One deciding factor was a group post about someone that had ported this to another i.MX21 based device called the Chumby, blog link. I've spent the last week going through this, the Qt web site, and getting it all setup in Cygwin (and lately Ubuntu).
I've managed to get the tslib to work on the VCMX212/VC21MM1 :) But the Qt Embedded install has been quite challenging. It took me a while to determine why a cross platform compile of Qt wasn't working under Cygwin. The configure script uses uname to sort out certain paths through the configure scripts, and breaks the cross platform compile!! :( With Wubi installing Ubutu on the development laptop I'm now looking at cross compiling via that and Cygwin.
With the limited time I can spend on home-brew development, this could take (probably) a couple of months to sort out. But so far it's coming along nicely.. Watch this space for updates :) Eventually I'll start filling out the Wiki over on my Google Code page that accompanies this blog with the steps required to get Qt working on the VC21MM1.

Wubi and Ubuntu

When I grabbed a cheap Thinkpad T42 laptop off of Ebay last year I was really pleased. It came with a fresh install of WinXP which allowed me to cleanly partition the single HDD with Partition Magic. With the intention to put Fedora onto that new partition, and do all the Robot development under Linux.
In all the Computer Games companies I've worked for it has always been Windows based development (using Cygwin for HW vendor tool chains). A linux distro is something I had toyed with occasionally, but knew that for embedded work I should really jump ship and develop wholesale under Linux. It was quite annoying to find that the DVD drive on the laptop was flaky :( Anyway, alot of existing Virtual COG'ers, including the guys over at Virtual Cogs, use a Windows/Cygwin setup for VC development. I could have perservered with Fedora (mounting the ISO in Windows to install from, etc.). But didn't require anything else that Cygwin had, so moved on.
This week I came across something really special, namely Wubi :) It cleverly installs Ubuntu onto an existing NTFS/FAT partition. The only thing it changes is to modify the WinXP boot loader to GRUB, to allow for dual booting into XP and Ubuntu. Tried this out, and it works fantastically!! My dev laptop now has Ubuntu!!! :)

Wednesday 18 June 2008

VC21RB1 board comes alive..

Three posts in one day... A crowded house ;) and probably the topic of some kids docturate somewhere

Hopefully the Virtual Cogs guys aren't reading this (sorry Tarun and Dan if you are). I pushed them at the end of last year to release some example code to driver the motor controller board, VC21RB1. Huge credit to them they did release more than expected. Including a lovely way of using I2C to communicate between the VCMX212 and VC21RB1 :D

Since receiving the Virtual Cogs boards I couldn't remember if I had even tried to determine if the VC21RB1 board was working. All the other delivered boards I had tried, think this one was waiting for some test software before I tried it out. Anyway..

Last night I grabbed the VC21RB1 I2C demo code and apps from the VC wiki. Sorted out a new OpenOCD server connection to the VC21RB1 JTAG. And tried reflashing the VC21RB1 with the example code, which worked first time :) Uploaded the VCMX212 accompanying code with Hyperterminal Ymodem. And launched the Win APP to squirt commands down the USB-UART to the VCMX212, and further via I2C to the VC21RB1. I must admit I did a litte dance when that all worked first time!!! :)

The new motor controller is ALIVE!! :) Superb news. I can now have a look at connecting up some motors, etc..

EFSL (Embedded Filesystems Library)

With the issues faced with uMon FATFS (see last blog post), it was a pleasure to come across EFSL. A little confusing though. The latest stable tarball is 0.2.8, whereas the stable CVS is 0.2.9 :S I had a look at the latest development release in CVS, but looks completely different and un-worked on for quite a few months now.

As with DOSFS/FATFS it only needs three functions to be hooked in. Init, single block read (512 bytes), and similar single block write. Perfect! Just the same requirements as the CF/DOSFS interface in uMon :)

Hooking up the SD driver code was easy. Creating a simple uMon API based test app, just as easy. And bonus, it all worked first time. Result!!

Even though having SD card support within uMon is nice. It's nicer to know that with EFSL I can use that standalone or within uMon API test apps.

Back on the case...

After a nice long hiatus I'm back on the case with the Robot development :) Actually I started back a few weeks ago, but only now have found the time to update the blog :S

The Virtual Cogs guys have done a superb job creating a Linux kernel image for the VCMX212. So far I've been reluctant to delve into Linux remote source level debugging. Although it is looking increasingly likely that I should switch over to it soon. As such I've been happily delving into creating apps using the uMon API. But it has it's shortfalls;

A few weeks back someone asked on the Virtual Cogs Google group about accessing the miniSD card on the VC21BR1 board not from Linux. Something I had been looking at last year. If you boot into Linux on the VCMX212, the kernel mounts and supports the SD card. But no other support is available outside Linux, sounds like a challenge :) This was something that I wanted to get implemented myself. So I took up the mantle..

At first it looked like a daunting proposition to implement the driver. As usual I google'd as far as I could to work out what others had done before. Most of the searching pointed at setting up an SPI based SD/MMC card driver. Which was confusing at first, considering the i.MX21 processor on the VCMX212 has built in SD Host Controller circuity.

Obtaining the required documentation was quite easy. Here's some links to the pertinant docs;
http://www.sdcard.org/about/memory_card/pls/Simplified_Physical_Layer_Spec.pdf
http://www.cs.ucr.edu/~amitra/sdcard/ProdManualSDCardv1.9.pdf
http://www.freescale.com/files/32bit/doc/ref_manual/MC9328MX21RM.pdf
http://www.freescale.com/files/32bit/doc/app_note/AN2906.pdf
http://www.freescale.com/files/32bit/doc/app_note/AN3049.pdf


Using the i.MX21 SDHC on-chip module ended up being quite straight forward. Quite quickly I was sending SD commands to the card and getting responses back. Late on a Friday night during that first week of development the card sent back it's CID and CSD structures. I.e. it said 'Hello, my name is ...' :) After that was cracked, the rest progressed nicely. Slowly due to busy life etc. but certainly shaping up.

After a few weeks of the odd evening and weekend work I finally managed to get the code into a usable state. Posting my results onto the Virtual Cogs Google group;

So here's where I have got to so far;

Card Initialization;
This has been working great with Sandisk 16MB and Sandisk 1GB microSD cards. Support has been added to detect MMC, SD, SDHC, and SDIO. Only the SD path has been tested. I don't have access to a SDHC or SDIO card, so that needs further testing. Plus I don't think MMC cards fit into the VC21BR1 microSD slot, so don't envisage further work on the MMC path. I'm hoping that at least the SDHC path is correct.

Read/Write;
Single block read/write (no interrupts or DMA) has been tested in isolation. Writing 128 single blocks of test patterns works, and they can be read back correctly. Support has been added to loop across multiple blocks, but that hasn't been tested. SDHC card (and 4 bit bus) support has been added but not tested.

uMon FATFS/DOSFS;
Using the latest version of uMon (v1.15), cf functions have been added that hook into the SD init, read, and write functions. CF can initialize the SD card and provided the function hooks to DOSFS. FATFS can then be used to ls, cat, and get a file from the SD card into TFS. I came across problems using rm, qry, and put FATFS commands. put command seemed to work, but Windows (XP and Vista) complained that the file was corrupt :S So I tried a different route to test the SD init, read, and write functions...

EFSL (Embedded Filesystems Library);
I grabbed the latest stable CVS version of EFSL (v0.2.9), and updated it with Martin Thomas's upgrades (see link below). Then dropped in support for VCMX212. A simple uMon API based test program using this EFSL library, can read a text file from the SD card, and write out a copy of the file contents to a new file on the SD card. Windows can read this new text file back from the SD card :)

EFSL - http://efsl.be/
Martin's changes - http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/efsl_arm/index.html