 |
| | | | | | | | | | | General Product Information |
| | | | | | |
|
|
|
|
|
Embedded Ethernet: Am186ES and PCnet-ISA II
by Chip Freitag, August 1996
This technical bulletin explains how to provide Ethernet capability for designs using the Am186 family of microcontrollers. It illustrates a possible hardware configuration for using PCnet-ISA II in bus mastering mode. It will also discuss software issues as well as sources for device drivers and protocol stacks.
Hardware Connection
|
Figure 1 Am186ES + PCnet-ISA II System Block Diagram
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 an Am79C961A PCnet-ISA II. 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 the embedded Ethernet market. The PCnet-ISA II is a highly integrated "bus-mastering" Ethernet controller with a built in ISA bus and PHY layer (Manchester encoder/decoder and 10BaseT transceiver). The 16 bit interface makes connection to a x186 style local bus very straightforward. The PCnet-ISA II has a two features which might be useful for certain embedded networking applications, full duplex operation (thus making it possible for a combined bidirectional data transfer rate of up to 20Mbps) and Magic Packettechnology (making it possible to remotely wake up a sleeping system on an Ethernet node).
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.
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 another application note, "PCnet Family Board Design and Layout Recommendations".
The important design observations and assumptions are as follows:
- /IOCS16 is pulled up to allow 16 bit I/O cycles from the 186 to the PCnet-ISA II. 8 bit cycles are still supported however.
- Three wait states must be inserted for /MCS I/O cycles when using a 40MHz 186ES. The PCnet-ISA II requires a worse case read delay of 110ns from /IOR to valid data. For I/O write cycles, a minimum pulse width of 100ns is required for /IOW. Slower speed versions of the 186ES could use fewer wait states. The PCnet-ISA II parameters to watch for are: /IOR to data valid, minimum /IOW pulse width, and /IOR or /IOW to IOCHRDY delay. IOCHRDY will not go active for PCnet register reads and writes, but can for access to an external EEPROM.
- /SMEMR is left not connected to disable the boot PROM.
- Address decoding:
The PCnet-ISA II is memory mapped using the MCS0 signal from the 186ES. The base address for MCS0 can be selected by the MMCS register in the 186ES. The PCnet is typically addressed between 200h and 3FFh based on the values programmed into the EEPROM. The alternative to the EEPROM is to execute the standard PnP isolation protocol on the 186ES and program the PCnet registers directly.
When the PCnet has the bus, the descriptor rings and buffers are stored in main memory. CSR1 and CSR2 hold a 24 bit address that determines where the initialization block is located in memory. Obviously Adx(23:20) are don't cares since the 186 couldn't address them anyway. Adx(19:18) are not used in this reference design with 1MBit memories (256kbytes), and therefore are also don't cares. This leaves Adx(17:0) that must be programmed for the initialization block location.
The design shown uses two separate clock sources, one for the microcontroller and the 20 MHz source for PCnet ISA. 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 PCnet-ISA II. 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.
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 intial 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.
For a list of RTOS vendors, see the Fusion E86 catalog, "Embedded Systems Programing", and Marketing Bulletin 20430, "Third Party RTOS Software Vendors Committed to Support PCnet Family".
Here is a short list of protocol stack vendors.
|
Vendor
|
Product
|
Protocols Supported
|
Phone Number
|
|
US Software
|
USNET
|
tcp/ip,ftp, telnet, ping,snmp, etc
|
800-356-7097
|
|
EBS Inc.
|
RT-IP
|
tcp/ip, also ftp, telnet, ppp, etc.
|
508-448-9340
|
|
Accelerated Technology Inc.
|
Nucleus NET
|
tcp/ip
|
800-468-6853
|
|
Epilogue
|
Attache+
|
ip, udp, tcp
|
505-271-9933 |
Most of these stack vendors have separate prices for various protocol extensions. Typically, a base set includes the basic protocols like ip, udp, ping and telnet. You then pay extra for extensions like tcp, ftp, ppp, snmp, rmon, and other higher level protocols and applications. Different vendors have different combinations of up front charges and per-copy royalties. You will have to get quotes from each vendor, and compare them for your anticipated needs.
- 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.
TCP/IP 101
Protocol stacks are one of the most difficult things to understand about networking. The figure below shows a client and server communicating using FTP on top of a TCP/IP stack, using drivers for their particular Ethernet hardware. If you understood that sentence you don't need to read further.
TCP/IP (Transmission Control Protocol/ Internet Protocol) and it's associated applications like FTP (File Transfer Protocol) are arguably the most used set of protocols in the embedded world. The basic idea is that applications do useful work, while everything below them is infrastructure. A key stack concept is that levels communicate with their peers by making requests of the level below while satisfying requests from above. The client FTP, for example, converses with the server FTP by sending "data" down through its stack and up through the server stack. Additionally, each successive layer has a clearly defined task. TCP is basically responsible for end-to-end reliability - meaning that it guarantees that each packet arrives at the other end without error and in sequence. IP, on the other hand doesn't care about reliability, but instead enables global connectivity with its IP addressing scheme - that's those dotted decimal addresses like 122.1.2.3 that you've probably seen. The driver is nothing more than a software shim that allows any vendor's Ethernet solution to work with standard IP software interfaces like NDIS (Network Driver Interface Standard). The net result is that Ethernet hardware exchanges packets containing application data, a TCP header, and an IP header; all wrapped up with an 802.3 (Ethernet) header and CRC (Cyclic Redundancy Check).
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 subsituted 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:
- 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.
- 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.
- 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
Acknowledgments
A number of people contributed to this cross-divisional reference design project and to this technical bulletin. Mark Bowers, AMD Atlanta GA, did the design, including the schematics, the hardware description and the PAL equations. Sean Michaud, AMD Calabasas CA, did the schematics capture. Rick Purvis, AMD Austin TX, supplied the software guidance, including the section in this bulletin on "TCP/IP 101". Chip Freitag of EPD also supplied the software guidance as well as acquired the necessary and appropriate software packages, including stacks and drivers, for use on this reference design board. Special thanks to Carl Ching of IND for supplying valuable information and guidance.
PAL equations
;PALASM Design Description
;----------------------------------Declaration Segment ------------
TITLE 186ES PCnet-ISA Glue Logic
PATTERN
AUTHOR Mark Bowers, FAE Atlanta
COMPANY Advanced Micro Devices, inc.
DATE 3/19/96
REVISION HISTRY
; 3/19/96 MB - CREATED
; 3/28/96 MB - add 85C30 support, use 186ES
; 4/8/96 MB - included digital one-shot for sbhe_
; 5/7/96 MB - fixed mistake w/ I/O slave reads (added PCS3,
; removed rd_)
; 5/7/96 MB - added support for PCnet byte writes (added ADX0)
; 5/7/96 MB - fixed mistake on sbhe tristate
; 7/25/96 MB - took out 85C30, converted from 16V8 to 22V10, PCS3 changed
to MCS0
CHIP em_pcnet PALCE22V10
;Note DIP pinout for SSOP
;---------------------------------- PIN Declarations ---------------
PIN 1 clka ;clk from 186ES
PIN 2 lcs_ ;lower chip select from 186ES, addresses memory
PIN 3 master_ ;from PCnet, indicates PCnet has bus
PIN 4 hlda ;from 186ES, inverted to DACK* on PCnet
PIN 5 mcs0_ ;Middle Chip Select 0
PIN 6 memw_ ;from PCnet
PIN 7 adx0 ;Address Bit 0
PIN 8 memr_ ;connected to memr* on PCnet
PIN 14 rcs_ ;ram chip select
PIN 15 rd_ ;Read connected to 186 and memory
PIN 16 hlda_ ;connected to DACK* on PCnet
PIN 17 sbhe_ ;System Byte High Enable on PCnet
PIN 18 wlb_ ;Write Low Byte on 186ES
PIN 19 whb_ ;Write High Byte on 186ES
PIN 20 dwhb_ ;Delayed whb_, external N/C
;----------------------------------- Boolean Equation Segment ------
EQUATIONS
hlda_ = /hlda
/rcs_ = /lcs_ + /master_ ;lcs_ doesn't tristate on a bus hold
;The Write Byte signals are tristated when the 186ES has the bus. When
the
;PCnet has the bus, adx0 and sbhe are decoded to assert the Write Bytes.
/wlb_ = /memw_ * /adx0
/whb_ = /memw_ * /sbhe_
wlb_.TRST = /master_
whb_.TRST = /master_
|
|
|
|
|
