Servo - August 2011

Meet the Swiss Army Knife of Robotics:

This month, we’re going to tailor the Microchip TCP/IP stack to drive a PmodWiFi module via one of the SPI portals of our Cerebot 32MX7. While we’re at it, we will also customize the USB Host portion of the Microchip Application Libraries and see if we can persuade the Cerebot 32MX7 to host a USB thumb drive.

Tailoring the Microchip Application Libraries involves editing the definitions within the library files to coincide with the target hardware. In the case of the Pmod WiFi, we also have to make changes to some of the network definitions. We’ve got a fair amount of work to do. So, let’s get started.

HardwareProfile PIC32_USB_ SK_DM32003_ 2_MRF24WBOM.h

The Cerebot 32MX7’s I/O pins and the TCP/IP stack hardware profile for the 32MX7 must match. Otherwise, we’ll be spitting bits into the wind through the PIC32MX795F512L’s output pins and sucking wind through the PIC’s input pins. I suggest downloading an image of the 32MX7 and Pmod WiFi schematics before we get down to business. That will make it a bit easier for you to follow the customization process. All of our input files exist in the Application Libraries. In the case of our Cerebot 32MX7 hardware profile include file, the seed file is HardwareProfile PIC32_USB_SK_DM32003_ 2_MRF24WBOM.h which is part of the TCP/IP demo application. Customization of the original files sometimes includes pruning. There’s no sense in keeping the commented PIC18 and PIC24 code when we’re compiling for the PIC32. Pruning also makes the modified code easier to read and debug. However, as with plants, too much pruning can be fatal. So, we’ll only prune when absolutely necessary.

Let’s reap the low hanging fruit. Buttons and LEDs are basic although necessary items to identify and assign to the 32MX7’s I/O map:

// Hardware I/O pin mappings
// LEDs
#define LED0_TRIS
LED1
#define LED0_IO
#define LED1_TRIS
LED2
#define LED1_IO
#define LED2_TRIS
(TRISGbits.TRISG12)  // Ref
(LATGbits.LATG12)
(TRISGbits.TRISG13)

// Ref
(LATGbits.LATG13)
(TRISGbits.TRISG14)
// Ref LED3

 (LATGbits.LATG14)
 (TRISGbits.TRISG15)
 // No such LED
 (LATGbits.LATG15)
 (TRISGbits.TRISG15)
 // No such LED
 (LATGbits.LATG15)
 (TRISGbits.TRISG15)
 // No such LED
 (LATGbits.LATG15)
 (TRISGbits.TRISG15)
 // No such LED
 (LATGbits.LATG15)
 (TRISGbits.TRISG15)
 // No such LED
 (LATGbits.LATG15)
 ((unsigned char)((LATG &
 0xF000)>>12))
#define LED_PUT(a) do{LATG = (LATG & 0x0FFF) |
((a)&0x0F)<<12;}while(0)

#define LED2_IO
#define LED3_TRIS

#define LED3_IO
#define LED4_TRIS

#define LED4_IO
#define LED5_TRIS

#define LED5_IO
#define LED6_TRIS

#define LED6_IO
#define LED7_TRIS

#define LED7_IO
#define LED_GET()

Depending on the development board, some of the Application Libraries demo applications use up to eight LEDs. The Cerebot 32MX7 only uses four LEDs. Defining only four LEDs may lead to compiler headaches. It’s a real pain to backtrack undefined LED errors. So, to avoid having to find and correct the undefined LED compiler errors, we’ll code the unused LEDs as an extension to the last valid LED.

In that the 32MX7’s LEDs are tacked physically to the most significant bits of LATG, we’ll need to change the bit masking in the LED_GET and LED_PUT macros. As you can see, the LED_GET and LED_PUT macros act on the upper nibble of the most significant byte of LATG:

// Momentary pushbuttons
#define BUTTON0_TRIS (TRISGbits.TRISG6)
 // Ref SW1
 (PORTGbits.RG6)
 (TRISGbits.TRISG7)
 // Ref SW2
 (PORTGbits.RG7)
 (TRISDbits.TRISD13)
 // Ref SW3
 (PORTDbits.RD13)
 (TRISDbits.TRISD13)
 // No BUTTON3 on this board
#define BUTTON3_IO (PORTDbits.RD13)