ADVANCED TECHNIQUES FOR DESIGN ENGINEERS
■ BY FRED EADY
SHUFFLING THE TCP/IP STACK
Just a few minutes after finishing up last month’s ZeroG column, I realized
that the seemingly simple 16-bit PIC24FJ128GA006 microcontroller design
contains a ton of potential. I’ve been doing some really deep thinking about
how to tap that potential. So this month, in addition to shuffling bits in the
Microchip TCP/IP stack, we’re going to perform some soldering iron surgery.
WALKING THE MICROCHIP
The Microchip TCP/IP Stack is designed to accommodate
all of the currently available Microchip Ethernet products.
However, the Microchip TCP/IP Stack architects also
realized that when it comes down to hardware designs,
not everyone would be following Microchip’s yellow brick
road. So, they left some really obvious back doors and
windows open for those of us skipping around in ruby red
slippers behind a little yip-yip dog.
Although the PIC18, PIC24, and PIC32 families of
microcontrollers are supported by the TCP/IP Stack, the
16-bit PIC24FJ128GA006 we used in the ZG2100M
support role is not directly supported in any of the Stack
templates. Recall that during the design of the ZeroG
support hardware, we attempted to address the ZeroG
module in a similar manner to other 16-bit microcontrollers
supported by the TCP/IP Stack. So, when we could, we
used the same microcontroller I/O pin-to-ZG2100M-
scheme as laid out in the Stack’s configuration files.
Regardless of our copy cat ways, one of the very first
things we need to do is inform the TCP/IP Stack that we
are “different.” We can identify ourselves to the stack
components by way of the Stack’s HardwareProfile.h file.
Here’s how the Stack architects have allowed us to
// Choose which hardware profile to compile for
// here. See the hardware profiles below for
// meaning of various options.
54 May 2010
Choosing a hardware profile entails removing the
comment prefix (//). Naturally — to avoid compiler
apocalypse — we should only select a single profile from
the list. The PIC24FJ64GA004 PIM is designed to mount
in the Explorer 16 Development Board’s PIM socket.
However, due to the PIC24FJ64GA004 PIM module’s
significantly different pin mappings, this particular PIM has
its own set of stack definitions. Most of the other Explorer
16 Development Board PIMs are supported by the TCP/IP
Stack under the EXPLORER_ 16 definition. These devices
include the PIC24FJ128GA010, the PIC24HJ256GP610,
the dsPIC33FJ256GP710, the PIC32MX360F512L, the
PIC32MX460F512L, and the PIC32MX795F512L PIMs.
The Microchip 32-bit microcontroller starter kits are also
supported by the TCP/IP Stack. The PIC32MX starter kits
supported under the PIC32 STARTER KIT definition include
the PIC32MX360F512L Starter Kit, the PIC32MX460F512L
USB Starter Board, and the PIC32MX795F512L USB
Starter Kit II. There’s even specialized stack support for the
PIC32MX795F512L Ethernet Starter Kit board.
YOUR_BOARD is really our board, which is the
ZeroG PIC24FJ128GA006 Trainer we constructed last
month. If we had not defined a chunk of target hardware,
the Stack will get up on its donkey and start making
assumptions while looking for clues as to what
microcontroller it will be compiled to drive. The most
obvious place to begin looking is in the area of MPLAB
IDE that specifies the microcontroller type to the IDE.
Obviously, our life with the Stack is much easier if we
don’t allow it to go donkey walk-about.
According to Schematic 1 and the ExpressPCB layout
in Figure 1, the ZeroG - PIC24FJ128GA006 Trainer has a
couple of user-accessible LEDs hanging out there on I/O
pins RC13 and RC14. As my mom would say, “That’s nice.”
However, our stack application doesn’t know about them
unless we tell it that they are available. The same Stack
ignorance holds true for the clock frequency that is driving
the Trainer’s PIC24FJ128GA006 microcontroller. When we
defined our Trainer to the Stack earlier, we were also given