EiED Online>> Building A One-Chip Web Server

Freescale's MC9S12NE64, or NE64 for short, is one of the first microcontrollers to incorporate an on-chip Ethernet media-access controller (MAC) and physical layer (PHY), making it possible to build a single-chip Web server. I was able to program a system based on the DEMO9S12NE64 kit (Fig. 1). Running about $199, the kit includes a special version of Metrowerks CodeWarrior development tools for the HCS12.

Freescale has built a sample as well, also shown in the figure, that consists only of the chip and an RJ-45 Ethernet jack. This version still requires power, but it is compact enough and uses such a small amount of power that the NE64 could be powered via Power over Ethernet (PoE).

The NE64 incorporates a 16-bit, 25-MHz HCS12 processor, a 10/100-Mbits/s Ethernet MAC/PHY, 64 kbytes of flash, 8 kbytes of RAM, an eight-channel, 10-bit analog-to-digital converter, and serial interfaces including two SCI ports, one I2C port, and one SPI port. The Ethernet MAC has two input buffers and one output buffer. The 112-pin LQFP version has 70 I/O pins, while the 80-pin TQFP-EP has 38 I/O pins. Both versions have 10 additional input-only pins. Up to 21 pins can be used for wakeup interrupts.

The demo kit hides the NE64 inside a hard plastic case. It features a couple of pushbutton and slide switches along with some LEDs and a potentiometer. The serial port, next to the RJ-45 Ethernet connector, can be used with a built-in serial monitor. On the opposite side, a 40-pin connector provides access to most but not all of the I/O pins. This allows the demo kit to be connected to external devices, providing a less expensive development tool compared to the development kit that's about twice the cost of the demo kit. The demo kit also includes a power supply and cables.

Getting It Running The kit is a somewhat disjointed collection of hardware, tools, and documentation. A few printed pages tie everything together, including a short Quick Start Guide. But it takes a little patience and reading to understand what's included and its location.

The kit's preprogrammed demo program exercises the LEDs, switches, pot, and network connection. The source code for the demo program and other sample applications are included along with the source for the on-chip serial monitor program. These can be compiled and downloaded using the CodeWarrior Development Studio for Motorola (now Freescale) HCS12. A special edition comes with the package, although you need to register it to work with applications that have more than 32 files at once, such as the initial demo program.

The initial setup and test took just a few minutes. In fact, it took as long to reconfigure Windows with a matching IP address for the PING test.

Soft Side Installing CodeWarrior was the next step. It was a typical Windows install, although I didn't register it immediately. This caused a "gotcha" later as I moved from simple applications to applications with more than 32 files. The CodeWarrior installation process was straightforward and included debug support for a simulator, the serial interface, and the P&E Microcomputer Systems' USB Multilink, which provided access to the Background Debug Mode (BDM) port on the NE64. We'll look at this extra option later, as it is not part of the demo kit. The demo kit also came with the latest HCS12 Service Pack.

CodeWarrior offers Freescale's Processor Expert, which generates configuration files based on the type of processor, including the NE64. There also is an evaluation version of Encirq's Encirq 3e Database Tools along with three TCP/IP stacks, including OpenTCP, Treck Inc., and CMX MicroNet. The Treck and CMX stacks are evaluation versions that offer features not found in the free stack. For example, the CMX MicroNet stack is extremely compact with features like zero-copy buffer support.

CodeWarrior makes some actual development work possible now. I started with some simple I/O chores before moving on to the network interface. Using the serial monitor was easy. CodeWarrior simply has a selection for dealing with a serial link. I just had to direct it to COM3, where I had a Silicon Labs USB-UART Bridge eval unit connected. The download and debug speed was not fast as with most serial monitors, but it was more than sufficient for small applications that would fit into the NE64.

While testing the network support, I bumped into the late registration problem, because the demo application uses lots of header files. It was easier to modify a working application than to start from scratch. I did move on to try out the other network stacks after getting some basic TCP traffic moving between the PC and the demo unit. The CMX stack was full featured but limited by time (30 minutes) and packet. A system reset also resets the time limit, so it is not really a problem from an evaluation standpoint. Treck included three prepackaged CodeWarrior projects. One was a very nice CGI Web server demo. The CMX demo wasn't as complex, although the CMX Web server does have comparable services.

CMX licenses its products, such as the MicroNet TCP/IP stack and Web server, on a per product developed at a site basis. Only the MicroNet stack came with the demo. CodeWarrior is licensed on a per seat basis. Contact Treck for licensing details.

Overall, there was more than enough network support to get a decent TCP- or UDP-based application up and running. It was definitely worth examining the CMX and Treck CDs, though the choice of protocol stacks and add-ons will be application- and project-specific. I won't even try to go into all the variables here.

The serial monitor eats up about 2 kbytes. It's protected memory, so you don't have to worry about overwriting it. For that, I had to get into some hardware debugging.

Hard Debugging Freescale sent along P&E Microcomputer Systems' USB Multilink (Fig. 2). This isn't part of the main demo kit, but the box does have a hole to access the BDM header. BDM has some significant advantages over the serial monitor. First, you can reprogram all of the flash memory, including overwriting the serial monitor. Also, debug features operate faster and with more power than via the serial monitor. Finally, BDM provides access to the chip when things really go wrong.

From a development standpoint, using the BDM interface was simply a matter of plugging it into the USB and BDM ports and then selecting it on the configuration menu. CodeWarrior was already set up to handle the P&E BDM interface. It was definitely a joy to use compared to the serial monitor, even though there was little difference in breakpoint or memory access functionality. It also gives back 2 kbytes of flash memory. This is significant when you consider the 64-kbyte on-chip memory and the amount needed for a network protocol stack and the application on top of that. You can comfortably fit simple applications into 32 kbytes, but expect to be pushing the upper limit in many other applications. You can get a lot of functionality into 2 kbytes.

Although you probably wouldn't use the BDM interface for a general evaluation, it is a tool that would make sense for production work. The P&E box will handle any 16-bit HCS12 or 8-bit HCS08 Freescale processor, so it's a good investment.

What's Missing? Not much. The kit definitely has everything necessary to do a decent evaluation and even some major application development, assuming the kit's I/O connections are sufficient for external peripherals. PDF files come with a complete description of the NE64 and the entire kit. This includes a bill of materials (BOM) and schematic. It's just a matter of finding the right files.

It would be nice to have a coordinated installation for all the add-on options like the CMX and Treck tools. But they're supplied by third parties, so it's not surprising that it takes a little more effort to get things installed and running. Even with the current setup, it's possible to run through a pretty good evaluation of the hardware and software in a couple days max.

One thing on the wish list is network debugging support in the monitor program, but I suspect that it would definitely push past the current 2 kbytes used for the monitor. Meanwhile, I need to reprogram the flash with the serial monitor and demo application so that the system goes back into the box in a known state.