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

Time for some interfacing..

Before I get onto the interfacing adventure, here's an annoying problem I faced yesterday with the CMUcam3..

I picked up a cheap PQi 256MB MMC card for the CMUcam. Got back home and took the turret assembly apart to fit the MMC card. Reassembled the turret and flashed the CMUcam3 with the 'hello-world' example project. No joy trying the initial file write test in that example. Added some printfs into the HAL driver and hello-world example, and reached a 'DOH!' moment. I hadn't formatted the MMC card for FAT :(
Took turret assembly apart, formatted the MMC card for FAT, reassembled the turret, and tried again.. Still no joy :( I had a dig around further in the mmc_driver and mmc_hardware functions. Referencing datasheets on the SPI programming of an SD/MMC card, it looks like the HAL driver has very limited implementation for MMC cards. The CMUCam WIKI and forum also mention that only certain cards work and some others that CMU guys have tried don't work. So something else to add to the todo list..

Onto interfacing fun..


With the double decker chassis built earlier in the week, it was time to have a closer look at the interfacing of the three systems; VC21 stack, CMUCam3, and uDSMC. Interfacing the VC21 and CMUCam3 should be easy. The VC breakout board has UART4 to connect to the UART0 on the CMUCam3. The issue then was how to get serial data to the Pololu uDSMC board, plus the issue of how/where to get a GPIO line to the reset pin of the uDSMC.

Re-reading the CMUCam3 datasheet lead me to a mini-Eureka moment. The LPC2106 has dual UART built in and CMU have sent UART1 through to a second IDC connector on the module (the Expansion port GPIO). It also looked like the CAM RESET (P0.15) GPIO could be used for the uDSMC reset line. The UART1 sent to the expansion port is already at TTL levels, so no need for the MAX232 line driver, freeing up valuable space for the DE-ACCM2G accelerometer board :)

I made a cable to connect the expansion port IDC socket to the breadboard (only need three lines from it, GND, CAM RESET, and TX2). Then onto changing the 'CMUCam2 emulator' example project to handle GPIO changes and UART1.


It took a little bit of work to get the CAM RESET GPIO setup. The below code is now used to initially select P0.15 as a GPIO output, pull it low for 100ms, before turning it high and keeping it high.

// CAM RESET(P0.15) bit selector
#define CAM_RESET 0x00008000
// Make P0.15 a GPIO
REG(PCB_PINSEL0) = REG(PCB_PINSEL0)&0xCFFFFFFF;
// Set P0.15 as output
REG(GPIO_IODIR) = REG(GPIO_IODIR) | CAM_RESET;
// P0.15 low, to reset motor controller
REG(GPIO_IOCLR) = CAM_RESET;
cc3_timer_wait_ms (100);
// Raise P0.15 high
REG(GPIO_IOSET) = CAM_RESET;

The UART1 setup was a lot easier. The cc3 HAL library is already setup to handle the second UART. It was then just a simple case of adding another input command to the example code. The following shows a simple way to send serial commands to the Pololu uDSMC.

cc3_uart_init (1, CC3_UART_RATE_9600, CC3_UART_MODE_8N1, CC3_UART_BINMODE_BINARY);
FILE * fp = cc3_uart_fopen(1,"r+");
if (fp == NULL)
{
printf("UART1 is dead\n");
while(1);
}
unsigned char buf[8];
// Both motors forward at half speed
buf[0] = 0x80; // Start byte
buf[1] = 0x00; // Device type
buf[2] = (0x00<<1) | 0x1; //M1 forward
buf[3] = 0x40;
buf[4] = 0x80; // Start byte
buf[5] = 0x00; // Device type
buf[6] = (0x01<<1) | 0x1; //M2 forward
buf[7] = 0x40;
for(int i = 0; i < 8; i++)
{
while((REG(UART1_LSR) & LSR_THR_EMPTY) == 0);
REG(UART1_THR) = buf[i];
}
fflush(fp);

I don't think the fflush is needed (and might not even be setup properly) because the cc3_uart_init already setups UART1 to flush it's FIFO after 8 bytes have been written to it. I need to have a further look to see if this is the write way to write out serial data via the UART registers, and whether the HAL code is behaving and thourough.

So two extra commands have been added to that CMUCam2 example firmware image. I've hooked up the 'FW' command to send the motor on commands to the uDSMC, and added the 'MR' command to CLR and SET the P0.15 GPIO line to reset the motor controller. These commands can be sent via the CMUCam3 Frame Grabber program.


Issues..
So far this 'almost' works. The uDSMC picks up the serial commands and starts turning the motors/wheels. BUT, and a big one, is that after X milliseconds (over 400ish) the P0.15 GPIO line drops half it's voltage and I guess resets/disables the uDSMC stopping the motors. Hmmmm...

Something to look at in the week.

That's all for now folks..

This weeks roundup..

Another week of chipping away at stuff. My main attention has been with the CMUCam3 module. I've been able to flash various example firmwares to the CMUCam3 and it's all working lovely.

I now have two GNU Arm tool chains on the laptop. The Yagarto GNU ARM toolchain for MX21 (ARM9) work, and the CodeSourcery "G++ for ARM EABI" one for CMUCam3 (ARM7) work. As far as setup goes; the CodeSourcery toolchain takes priority (directory PATHs, etc.), with the Yagarto one being enabled via the custom makefile scripts used for MX21 work.

I've also place an order with Technobots (UK) They were a later supplier find, stocking quite a few parts I had ordered from the US, including the Pololu parts. My original Pololu order had four round robot chassis bases, but I forgot the spacer rods on that order. So I was able to grab two sets of spacers from Technobots. The intention currently is to put the four round bases together to form two platforms. Drill through the front top one to make a place to securely mount the turret assembly, and have the top back one somewhere to put the VC21 stack. Hopefully with enough space on the bottom deck to place the motor controller board and power supplies. Then it's back to determining whether the tiny motors and gearboxes can handle that much weight. My current gut-feeling is that they can't..

Technobots have also start supplying Dimension Engineering's Accelerometer boards. So I've order from them the +-2g Buffered 2 Axis Accelerometer module DE-ACCM2G. I've been using a similar MEMS device in the Nintendo Wii development in my day job, so I'm familiar with the intricacies of analysing the noisy output from a MEMS chip (to check out the internals of a Wiimote, head over to this SparkFun tutorial). The 5g Accelerometer module from Dimension Engineering uses the same Analog Devices chip used in the Wiimote. I'm hoping the smaller 2g device is just as sensitive, if not more so.
I can't wait to get this tiny module and hook it up to the ADC on the VC21RB1. The VC Robot COG has a LPC2136 (ARM7TDMI-S) core that contains two 8-channel 10-bit ADCs. Perfect for connecting the X-Y outputs of the DE-ACCM2G accelerometer. With this hooked up on the robot it will then be able to work out it's orientation vector with respect to gravity. I'm also think about using it in conjunction with the CMUCam3 analysis to determine if the motor controller has gone crazy and needs to be reset.

Another bit of software to add to this mix is RoboRealm. I picked up a while back a very cheap USB web camera. So cheap it's default resolution is CIF (352x288), intentionally the same as the OmniVision CMOS camera sensor module used on the CMUCam3. I should be able to prototype an image processing pipeline for the CMUCam3 using RoboRealm, before moving this across to CMUCam3 firmware. Initial results from experiments in RoboRealm look encouraging, but I know it's going to be a huge effort to move any image processing pipeline routines from RoboRealm across to the very limited CMUCam3.

Finally here's a cute photo of the CMUCam3 in it's turret assembly -

Source level debugging working

After the success earlier today getting GDB to work through OpenOCD via Olimex ARM-USB-TINY JTAG connector, I thought I'd revisit Eclipse and check out the Insight debugger supplied with the Yagarto tool chain.

I closely followed Jim Lynch's Eclipse/Insight tutorial (PDF link) to get Eclipse setup with CDT, Insight, and OpenOCD. His tutorial is geared towards using an Olimex prototype board, but can be easily refactored to work with Yagarto and OpenOCD.

I setup the Virtual COGs 'touch' example within Eclipse, and also setup two external tools; namely OpenOCD (using the VC config script from the VC wiki, see previous blog post) and the Insight debugger (found in the Yagarto tool chain).

With the MX212+MM1 device connected via USB (as before) and the ARM-USB-TINY JTAG connected, it was a simple case of running OpenOCD server from inside Eclipse, then calling Insight from inside Eclipse. Insight was able to run to 'main', and then source step through the code :)

After some initial teething issues, everything now seems to be falling in to place. Very encouraging. Irrilicht here I come... :)

JTAG/GDB

Before popping out for lunch I thought I'd try JTAG/GDB debugging on the MX212. Wow, how easy :) After the shenanigans of getting the right PID setup on the Olimex ARM-USB-TINY JTAG connector XP driver, I wasn't hopefull that the OpenOCD server would be properly working. I came across the config file from VC wiki for the server and sparked it up (link to config file here). OpenOCD server looked like it was running fine in the cmd window (with the ARM-USB-TINY connected first to a USB port of course).

Making sure that JP300 and JP500 (for stack power via USB) were shorted I connected up the MX212 to another USB port on the laptop. The three LEDs on the back of the MX212 were all lit, so ready to go. Also have the VC21MM1 connected to the MX212 in my current default configuration.

Using the 'touch' VC21 example, that I know worked via uMon download, I called up the arm-elf-gdb from Cygwin. Hey-presto GDB kicks into life (thanks to the .gdbinit supplied with this example) and the VC21MM1 becomes active and the 'touch' example is running. Broke into the program in GDB and single stepped the code. All working lovely.

Now just need to go back and setup Eclipse properly for JTAG/GDB work with the MX212... And then on to looking at writing that software driver for the VC21MM1 touchscreen LCD in Irrilicht.

Virtual COGs package arrived

What a glorious day. Lewis Hamilton has taken pole position for the Japanese GP. There's rugby on the TV all afternoon. The sun has managed to break up the rain clouds. My belly is full of a big breakfast from the local cafe. And best of all; The Virtual COGs order has turned up this morning :)

Just going to start a magnified examination. They were very well packaged. Initial look seems to show no surface mount components that have fallen off in transit from Canada. If they all look good, I'll spark up the laptop and start playing with them (via USB and JTAG).

In this first picture;
Top row - VC21RB1 Robot COG, VC21BR1 Breakout COG, VCMX212 i.MX21 COG
Bottom row - VCLCD43 LCD with touch screen overlay, VC21MM1 Multimedia COG

Shopping list (part 1)

I recently came across a, relatively, new Canadian company called Virtual Cogs (http://www.virtualcogs.com/). Their VC21 series of stackable devices is superb. I'd used ARM processors before in handheld game programming, and always like their chips. So seeing them used on a VC21 stack modules got me thinking about making a robot again.

VC's Robot COG looked perfect as the main HW interface, with the i.MX212 handling the bulk of any SW processing. Throw in the Multimedia COG with touch screen, Linux running on the i.MX212, integrated JTAG, and lots of new avenues open.

So first on the shopping list is;

• i.MX212 COG (VCMX212) (Actually went for the Starter Kit)
• Breakout COG (VC21BR1)
• Multimedia COG (VC21MM1)
• Robot COG (VC21RB1)
• JTAG interface (VC21JTAG)
• Assorted connector cables and mounting hardware

The next step was Pololu's robot kits (http://www.pololu.com/). Particularly the Round Robot Chassis. Impetuously I went ahead and ordered the chassis kit, with Tamiya gearbox and assorted plates. Only later reading up on the H-Bridge used in the VC21RB1 :S More on that later.
Plus it was also later that I discovered that I could have bought them from Technobots Ltd here in the UK (http://www.technobots.co.uk/). Oh well, another supplier found...

Next up was the JTAG interface. For which I went for the Olimex (http://www.olimex.com/dev/index.html) ARM-USB-TINY and ARM-JTAG (as backup, just in case OpenOCD had trouble with the USB varient). Ordered these via Sparkfun Electronics (http://www.sparkfun.com/).

Another great find is the CMUCAM2 and, importantly, the pan/tilt turret head and servos. This time I got it from Active-Robot :) (http://www.active-robots.com/products/accessories/cmucam.shtml). Only one of these to start with, but I'll grab another further down the line.

Finally, in this first line of purchases, is a cheap laptop from eBay. Took a couple of days to win a good bid, but managed to get an IBM Thinkpad T42 for under £200.

Yay, first purchasing round is complete. Now just need to wait for it all to turn up.

In the mean time I can start at getting together all the development software required...