Introduction
With the explosion of Ethernet networks, the need to provide Ethernet connectivity for embedded designs is becoming more common. Networking provides a convenient, standardized means of connecting a wide diversity of systems from software development tools, to point of sale systems, to the much anticipated "smart house". Even IBM has seen the light and is offering robust Ethernet connectivity for their popular AS/400 midrange computers.

Whether it's a ROM emulator, a cash register, or a network connected coffee pot, the embedded systems designer is faced with the challenge of providing basic Ethernet connectivity while keeping the system cost at a reasonable level.

This technical bulletin explains how to provide Ethernet capability for such designs using the Am186 family of microcontrollers together with the Am79C940 Media Access Controller for Ethernet (MACE). It illustrates a simple, low cost hardware solution combining these devices.

Of course the hardware is just the start of the solution. The popularity of Ethernet as a system connectivity solution lies in the universal acceptance of the Internet Protocol standard. Compliant Ethernet devices rely on the services of IP, TCP, UDP, and other well understood and readily available protocols. Therefore, this article will also discuss software issues as well as sources for device drivers and protocol stacks.

Hardware Connection

Figure 1 shows the basic block diagram of a complete Ethernet solution for an embedded microcontroller application. The figure shows how to interface the Am186ES to a MACE. The 186ES is a high performance 16 bit microcontroller available in speed grades from 20MHz through 40MHz. The integrated peripherals and glueless interface to memory make it an ideal solution for embedded Ethernet devices. The MACE is a highly integrated slave type Ethernet controller incorporating the logical MAC and PHY layer (Manchester encoder/decoder and 10BaseT transceiver). The 16 bit interface makes connection to a x186 style local bus very straightforward.

The microcontroller section consists of the 186ES, Flash, and SRAM. The Ethernet section consists of a PAL for glue logic and the Am79C961A PCnet-ISA II. The design takes advantage of the Bus Mastering capability of PCnet-ISA II to achieve high performance and low system cost, while reducing the amount of software overhead on the processor.

The microcontroller section consists of the 186ES, Flash, and SRAM. The Ethernet section consists of a PAL for glue logic and the Am79C940 MACE. The design relies on the integrated DMA channels on the Am186ES to provide a high performance solution data movement solution between the MACE and the microcontroller.

Support circuitry such as the RS-232 interface, Ethernet isolation transformers, and an RJ45 connector for 10Base-T are not shown. This circuitry is covered in other application notes available from AMD. A complete collection of these notes can be found in the "Embedded Network Applications Design Guide Kit", available from your AMD representative or AMD’s 1-800 literature request line. Just ask for PID# 20397A.

The important design observations and assumptions are as follows:

1. A1 of the microcontroller bus is connected to A0 on the MACE processor interface. Thus all access to the MACE’s internal 8 bit registers will be sixteen bit accesses from the microcontrollers perspective. The least significant byte of such accesses will contain the valid 8 bit data. The MSB can be ignored. The MACE register chip select (/CS) is connected to /PCS3 on the microcontroller.
2. Accesses to the MACE’s fifos are accomplished via the 186ES DMA channels. One DMA channel is responsible for transmitting data and the other for receiving data. Both DMA channels should address PCS2. For receive operation, DMA channel 0 should have its source address set to PCS2, and its destination address set to the buffer memory address supplied by software. For transmit operation, DMA channel 1 should have its source address set to the supplied buffer memory address and its destination set to PCS2. /PCS2 is connected to the MACE’s Fifo Data Strobe (/FDS). Thus both DMA channels address the Fifos on the MACE. A term in the PAL equations ensures that R/W* on the MACE is driven correctly during these accesses.
3. 1 wait state must be inserted for PCS2 and PCS3 cycles when using a 40MHz 186ES. Both EDSEL and /TC are pulled up on the MACE. This will result in 2 cycle MACE timing, which is equivalent to 4 186ES clock cycles. Since the PCS signal does not go active until the middle of the first 186ES bus cycle, it takes a total of 5 186ES bus cycles to complete a MACE transaction.
4. /EOF issupplied to the MACE during writes according to the setting of PIO25. For transmit operations, the MACE device driver should set the transfer counter for the write DMA channel to 1 less than the number of actual words to write. PIO25 is set to a 0, meaning /EOF is inactive. After the DMA channel is started and the MACE begins transmitting, a DMA terminal count interrupt will occur. In the ISR for this event, PIO25 is set to a 1, and the DMA channel is set up to transfer one more word. /EOF will be active during this transfer, and the MACE will recognize the end of the transmit packet.
5. The design shown uses two separate clock sources, one for the microcontroller and the 20 MHz source for the MACE XTAL1 and XTAL2 inputs. If your design deviates from this arrangement, care should be taken to ensure that you still meet the stringent requirements for an external clock source for the MACE. Improper Ethernet chip clocking can be a major source of equipment incompatibility, and is usually very difficult to track down as the cause of equipment malfunction.

Non-volatile Storage
Many Ethernet applications require some type of writeable non-volatile memory, usually for IP addresses, or other configuration specific setup information. Accesses to the non-volatile are typically infrequent, being done mostly at power up time, or when the end user makes a configuration change.

A popular method for storing this type of data is with a EEPROM. Parallel EEPROMs can be connected to the address and data bus and driven with one of the available chip selects. For serial EEPROMs, it is relatively easy to use the PIOs to implement a serial interface. A driver for such a PIO style serial interface is simple to write.

Of course non-volatile data could also be stored in FLASH. This has the advantage of not requiring another package, which can help keep costs down. Software would be required to manage the task of writing the saved data to the flash device.

Software Considerations
In addition to the application software, an embedded Ethernet design requires at least Ethernet drivers, almost always a network protocol stack, and probably a real time operating system. There are a variety of sources for this software, some of which are listed below.

Drivers, Protocol Stacks, and RTOS Support
Choosing a protocol stack is a matter of matching design requirements and budget to the available sources. Freeware stacks are available that reduce initial costs but can take a lot of time to get working and may suffer from terrible performance. At the other end of the spectrum, vendors such as Epilogue offer a wide range of high level protocols (such as RMON) as well as porting and integration services. High end stacks may cost more, but are worth it if performance and time-to-market are critical.

All commercial protocol stacks have a few target dependent modules that provide independence from hardware drivers and real time operating system APIs. To interface to a new hardware driver or RTOS, only these interface modules need to be changed, so that generic calls like send_packet or task_wait are replaced by the calls specific to the given driver and RTOS. This means that you can use pretty much any protocol stack with any combination of hardware drivers and real time OS. Most stacks also come with drivers for the most common Ethernet chips and interface modules for the most popular RTOS’s. Also some stacks come with a very simple "psuedo-RTOS" which implements rudimentary task switching. If your needs are simple, these nano-kernels may work just fine. And of course you can always integrate a home grown RTOS.

Here is a short list of protocol stack vendors.

• Shareware/freeware RTOS's
• For freeware protocol stacks, download PacketDriver Packet Driver is not a TCP/IP stack itself, but if you unzip the file and look at software.doc, you will find a lengthy list of various protocol stacks (including several TCP/IP packages) and other applications that support Packet Driver, many of which should be suitable for embedded applications.
• Another key stack concept is hardware independence. Since each layer communicates with the layer below it through a well defined calling interface, no assumptions are made about how the lower layer accomplishes its conversation with its peer on the other side. What this means is that PPP (Point-to-Point Protocol), which is a serial protocol typically used with modems over dial-up phone lines, can be substituted in place of Ethernet. And FTP still works exactly the same way regardless of the physical layer protocol used. Please see any of the widely available TCP/IP references for more detail.

Other references:

1. Books
• For those who are would like to learn more about Ethernet or networking in general, here is a list of references. This is far from a complete list of references, but is intended to offer a few places to start looking.
• "TCP/IP Illustrated" by W. Richard Stevens, Addison-Wesley Publishing ISBN 0-201-63346-9.
• "Internetworking" by Mark A. Miller, M&T Books (1-800-533-4372), ISBN 1-55851-143-1. A good general overview, including wide area communications.
2. Magazines
• Looking in the classifieds of "Embedded Systems Programming" (Miller Freeman, 1-800-829-5537), a user will find numerous advertisements for protocol stacks, RTOSs, emulators, etc. This magazine also has a number general embedded articles for worthwhile reading. It is a must for any embedded developer. An article on selecting an RTOS appeared in the April ‘96 issue.)
• Of course, a user should consult "EE Times" (CMP Publications, Inc., ). This is a weekly publication providing an abundant of information on the current state of the electronics industry, including occasional in depth articles on networking and embedded applications as well as advertisments for all types of electronics services and products.
3. WWW
• This is a very informative "subway map" of a wide range of networking tutorials and resources, including a link to the original TCP/IP tutorial RFC (request for comment).
• User Groups- comp.arch.embedded, or comp.protocols.tcp-ip

PAL equations
;PALASM Design Description
;---------------------------------- Declaration Segment ------------
TITLE 186ES to MACE Glue Logic
DEVICE 16V8

;---------------------------------- PIN Declarations ---------------
PIN 1 clka ;clk from 186EM
PIN 2 pcs2_ ;peripheral chip select from 186ES, DMA to/from MACE
PIN 3 psc3_ ;peripheral chip select from 186ES, regular cs to/from MACE
PIN 4 pio25 ;from 186ES, used to drive EOF on DMA writes
PIN 5 dtr_ ;data direction from 186ES, used to generate rw_
PIN 6 rdtreq_ ;receive DMA request from MACE
PIN 7 tdtreq_ ;transmit DMA request from MACE
PIN 8 int_ ;interrupt request from MACE
PIN 13 int0 ;interrupt request to 186ES
PIN 14 drq0 ;receive dma request to 186ES
PIN 15 drq1 ;transmit dma request to 186ES
PIN 16 fds_ ;Fifo data strobe for mace
PIN 17 eof_ ;EOF for mace
PIN 18 rw_ ;read/write for mace
PIN 19 sclk ;clka/2 for MACE
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
;
int0 = /int_ ; invert the interrupt pin
drq0 = /rdtreq_ ; invert the receive dma request
drq1 = /tdtreq_ ; invert the transmit dma request
;
fds_ = pcs2_ ; MACE fifo data strobe is /pcs2
rw_ = /dtr_*(/pcs2+/pcs3) ; build rw_ from the chip selects and dtr_
;
eof_ = /pio25 ;eof follows the sense of pio25 when enabled
eof_.TRST = /fds_ * dtr_ ;enable eof as an output on fifo writes
;
sclk.clkf = clka
sclk := /sclk ;divide the 186 clock by 2 to get a 20mhz clock for the MACE