Compiling and testing ETHTEST,
the example code
You will need to download a copy of the driver. Do this by clicking here. ETHTEST is a program that will send an echo
reply (ping response) back to the originator. The program only implements
certain portions of the TCP/IP stack, and is only being implemented in a
crude form to allow a ping and an ARP response. Any 'real' program will
need to use a more robust stack. The program will only correctly return
any echo request packet that has 32 bytes of data in it. Any other value
will not get returned correctly.
Due to the many flavours of compilers in the market place for the 8032/52
compatible microprocessors, you will probably need to tailor the code to
get it to compile on your compiler. The major changes will be the pseudo
commands that you compiler uses for internal processing, such as DB, DW,
EQU etc. You will need to use the manual that came with your compiler to
modify the code accordingly.
Once the code compiles in your development environment, there are some
minor configuration changes to adapt the driver to your hardware and network
configuration. Make the following changes:
ETHTEST.ASM
- Change BaseProg variable to the location of the where the
program starts executing (program offset). It is 2000h by default which
is where my development board starts executing its downloaded program.
Normally, this will be 0000h if you are using an EPROM.
- IPAddr1, IPAddr2, IPAddr3, IPAddr4. Change these values to
the IP address that you want the NIC to use. These are set to 192.168.3.6
by default. If your computer does not have any TCP stack loaded, or configured,
leave this as the default (192.168.3.6), then change the IP Address of
your computer to 192.168.3.1, with a subnet mask of 255.255.255.0. See
the manual that came with your operating system for the instructions on
how to do this.
- In the Begin: block during the initialize sequence, you will
need to change the value loaded into TH1 to reflect the reload value required
to set the serial baud rate. The program is configured for a 7.3728MHz
crystal with a baud rate of 19200, 8, n, 1. You may have to change the
PCON.7 bit if you do not need to double the baud rate.
8390.INC
- Set the IOAddr byte to the hi order byte of the address of
where the network card is. IE, in the code as supplied, the NIC can be
addressed at address 6300h, therefore, the IOAddr is set with
63h. Another example: Assume that you have configured the NIC in you PC
to have an IO Address of 0200h. You have configured the hardware of your
microprocessor to split the XDATA area into 8K chunks. If you put the third
address space created by the decoder attached to the AEN pin of the NIC,
then any address in the 4000h -> 5FFFh will activate the AEN pin of
the card. Since the card has been set to use IO Address 0200h, then the
card can be be activated at 4200h. The value of IOAddr is then
42h. Note that the card will also be found at other phantom addresses,
but we need not concern outselves with this.
The next three items refer to an address in XDATA where there is RAM. The
software is written for a 8K RAM chip located at 0C000h
- Set the HDR value to the location in RAM where you want the
received data buffer to exist. It must be on a page boundary, ie the lower
byte of the word adress must be 00h.
- Set the TXBuffer to the location in RAM where you want the
transmit buffer to exist. This should be a minimum 0700h bytes different
then the HDR variable. The reason for this is because the normal
Maximum Receive Unit (MRU) of a packet is 1500 or so bytes. The difference
between the buffers can be smaller so long a no packets longer than the
difference between these buffers arrive at the NIC. This must also be on
a page boundary.
- SAPROM. This holds the location in XDATA memory, where the
MAC address of the NIC is stored. It needs to be 32 bytes long. It may
reside anywhere in memory.
Once the above changes have been made, compile the program. If all goes
well, load the code into your project and run. If all is well, you should
get a screen that says:
|
Probing for card...Card Found
MAC Address of card: 00-80-C8-18-40-F9 |
Note that the MAC address WILL NOT be the same as the numbers displayed
above, but will be a different six (6) digit number. You will probably see
this number printed on the NIC somewhere.
If you did not see the above screen, click here.
The above screen signals that the microprocessor has found the NIC, and
has sucessfully initialized it. We should now be able to ping the IP address
of the NIC and get a reply. Follow the instructions below for your operating
system:
Windows 95, 98 or NT
Open a command prompt window (Start - Programs - Command prompt, or START
- RUN - COMMAND).
Type ARP -a. This displays the computers IP Address to MAC Address
table. Now type
ping <IPADDRESS set in code>, ie: ping 192.168.3.6.
There should be some echo replies being displayed on your screen.
Type ARP -a again. This time in the list, you should see the
IP address you entered into your code, along with the MAC address of the
network card you are using.
If you didn't get any ping replies, restart your machine and see if it
improves. I have have found that this has helped resolve some connectivity
issues.
Macintosh
Download MacTCP Ping from here
if you do not already have it. Run the program. Enter the IP Address of
your microprocessor. Change the packet data size from 56 bytes to 32. Press
START PING. You should see some replies.
Linux/Unix
You may need to confirm with the MAN pages the command to change the default
packet size. For Red Hat linux the command is ping 192.168.3.6 -s 32.
If all is OK, then continue to return to the tutorial
home page.
Doh - I didn't the the
screen as shown!
If you did not see the screen as shown above, then there could be several
areas that may have caused the problem:
- If you have garbage on your terminal, then the serial baud rate has
not been calaculated correctly
- If you get a message saying that it cannot find the card, it will come
up with one of these messages.
- NoCardFound - Unable to locate, or communicate with a NIC. Chances
are the IOADDR equate does not correspond to the page boundary that the
NIC is on.
- NoResetAck - Found a card, but did not get a return an acknowledgement
to the reset function. Same symptons as for NoCardFound.
- NoIRQFound - Found a card, can communicate with it, but no acknowlegement
to an interrupt. Check to make sure that the IRQ number programmed into
the NIC, and the line that you have attached to the microprocessor are
the same. Also, make sure that the interrupt is active and enabled.
Home |
