Issue 153 April 2003
Test-Driving the Z8

The Z8 GOES 10/100 Mbps

After thinking things over, I decided to write the Z8F6403 code for the ASIX 10/100-Mbps Ethernet IC. By doing so, I would automatically have the basis for porting the code to the RTL8019AS because both the ASIX and Realtek parts are NE2000 compatible. Using the ASIX IC also makes the initial hardware integration process a bit easier, because I can connect the Z8F6403 development board to the ASIX development board using ribbon cable and simple IDC connectors. The Z8 Encore! development board is designed to carry a daughter expansion board; therefore, it’s not as tidy as other development boards as far as the expansion header layout. So, it looks like I’ll be making some special interface cables for this job.

I started the serious coding by taking from the excellent examples that come with the kit. As I was plodding through, I realized that the scent of AVR was starting to flow from my ZDS II project window. I use ImageCraft ICCAVR for my Atmel projects, and like the Z8 Encore! C compiler, the ImageCraft AVR C Compiler is a true ANSI implementation. After inhaling the Atmel aroma for a few minutes, it hit me as to why I had sensed the AVR in my coding. Get this—it all rotates around another C compiler that I use for my PIC projects, CCS’s PICC.

The CCS compiler is ANSI-based as well, but it’s heavily flavored with specialized functions for the PIC microcontroller family. As a result, the PIC’s I/O ports and internal registers are directly bit addressable by function. With the ImageCraft and Z8 Encore! C compilers, these bits are still directly manipulated, but not with microcontroller-specific built-in functions.

For instance, if I wanted to set the MSB on output PORTB of the Z8F6403, the C source would be PBOUT |= 0x80;. Conversely, to clear the same bit, I would use PBOUT &= ~0x80;. Using CCS’s PICC, the PIC source would read output_high(PIN_B7); to set the MSB of PORTB and output_low(PIN_B7); to clear it.

All of these differing C statements look different but do the same things. Instead of PBOUT, which is a Z8F6403 definition, PORTB is the common corresponding definition found in an AVR include file. Substitute PBOUT from the Z8F6403 include file for PORTB and you have just ported the AVR code to a Z8 Encore! microcontroller. There’s absolutely nothing wrong with the PICC implementation. If you put your mind to it, you can port PIC code to the Z86403 just as easily as you can the AVR code. You just have to do a bit more typing to get your results.

My coding afterburners are on. I can now reuse a great deal of the packet code I have created for the AVR and PIC microcontrollers to get the Z86403 on the LAN. If you stop and think about it, handling an ARP reply or sending bytes using UDP and TCP doesn’t differ in concept from microcontroller to microcontroller. Sure, you have to watch your byte ordering, but if you want to talk on a LAN using Ethernet, or use the services of the Internet, an Ethernet packet had better look like the other guy’s Ethernet packet. If you plan to travel on the Internet, your UDP/TCP/IP headers and checksums must adhere to today’s published standards.

Fortunately, I have a field-tested packet transmission/reception data structure that I can use to build the Z8 Encore! Internet code. After I write the code to allow the Z8F6403 I/O mechanisms to put the data in and get it out of the existing packet data structure, it’s a piece of cake between the I and the O. Because the packet data will reside in predetermined locations within the packet data structure, I can theoretically use my existing algorithms to do the processing. That works out perfectly.