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..