ETHERNET
PIC CONTROLLER (NETPIC) Manual
Copyright (c) 2001 EIX Ltd
Hardware - Setting up
After all the
PCB has been wired up and connected together, plug the PC ISA Ethernet card
into the socket and power the board with 5V, power consumption should be about
100mA or less, depending on the ISA card used. One of the LEDs (on PIC port C4)
should be flashing at about once per second. Connect the unit to your LAN via
the coax cable and a termination resistor if necessary.
First Tests
The board holds
all its IP addresses in EEPROM. When started for the first time, the following
defaults are loaded:
IP address 192.168.0.15
Ethernet HW address 0x455448504943 i.e. “NETPIC”
You can
reinstate these default values by holding pin C6 of the 16F877 down while
resetting the board.
From your PC,
open a DOS console box and enter:
c:>arp -a
The most likely
response could be:
Then try:
c:>ping 192.168.0.15
If everything is
working correctly, the response should be:
Pinging
192.168.0.15 with 32 bytes of data
Reply from
192.168.0.15. bytes=32, time<=10mS TTL=128
Then, try again
c:>arp -a
The response
should now be:
Internet address
Physical address type
192.168.0.15 45-54-48-50-49-43 dynamic
This will show
that our board has been recognised by the network.
Installation Problems
If you are
having any trouble, try the following.
- If the LED
connected to PIC port C5 is not flashing: Remove the ISA card, if the LED
is still not flashing, there is a problem with the PIC, crystal, or the power
supply (there isn't much else to go wrong at this point). If you have a scope
check for a 20MHz waveform at pins 13,14 of the PIC. Also ensure the reset
pin (pin 1) and port C6 (pin 25) are high, and not held low by the DIL switch.
- Run program
"877driver.exe" on your PC. Connect the serial port from your
computer to the NETPIC serial interface. Remove the ISA card and reset NETPIC
(by reapplying power supply, or bringing low the reset line (pin 1). The PC
screen should display the four characters <"">
denoting that at least the
PIC and the serial port are working. (make sure the "rx hex" tick is
reset on the PC screen) and that all the DIL switches are in the OFF position..
- Plug in the
ISA card. Reset NETPIC again.The PC screen should now display <Pp>.
denoting it has detected the 8019AS chipset. The green led on the ISA card may
flash at this stage. You may get a different pair of characters if you are
using a different card. If you get nothing, your card may not be configured
properly.
- Some of the
older ISA cards have jumper settings. make sure these are set to the 0x300
base address range, no IRQ (any will do), and 8 bit transfers.
- Reconfiguring
your card. If your ISA card is PnP (Plug and Play) and it has been used before,
it may need to be reconfigured. This is because the PnP system may have
reconfigured the card base address to other than 0x300. You should only do this
if you are fully conversant with your PC and its settings. Any mistake may
cause your PC to fail to recognise its existing network cards if there were any
present. You will need a PC with PnP enabled, ideally W95 or W98. Fit the ISA
card in one of the spare slots, and start the machine. The PnP system will
recognise the card and invite you to install it. Use the standard Windows
drivers for NE2000 compatible cards. At some stage you may be invited to change
the basic settings (if not, you can do this from the control panel). From the
basic settings, change the address range for the card to 0x300-0x30F. There is
no need to change the Interrupt settings.
Alternatively,
it is possible to hardwire one of the pins in the 8019AS to ignore PnP, but you
must consult the IC data manual, as the device is supplied in many different
package formats.
Using "877Driver.exe"
This program is
mainly used to test and configure NETPIC.
The Dialog
screen is divided into three areas:
Top Right:
General purpose buttons to select a COM port (1 to 4), clear the screen and
exit the program.
Top Left:
Transmit packet: The various buttons and options are used to generate a byte
pattern which is then sent to the PIC when clicking on the "xmit"
button. You can enter your own sequence on the long edit box (as ASCII or as
hex pairs, depending on the tick selection). Clicking or selecting any of the
other options will create pre-cooked patterns as required by the PIC. The
formats are discussed in the next section.
One of the most
useful options is "query vars", this causes the PIC to return a 20
byte sequence corresponding to its internal address settings.
Bottom: Received
data: this is displayed in both raw and "decoded" form. Use the
"clear" buttons to clear the box when it gets too full.
Using "877Demo.exe"
This program
demonstrates simple UDP communications between the NETPIC controller and
Windows. It can be used to show that the controller is working properly, 877Demo is nothing more than an advanced
version of TestEth.c. You could enhance TestEth.c, to this level of
functionality with relatively little extra coding effort.
First ensure the
NETPIC controller is set for UDP demo mode. This can be done by sending the two
byte command <CB><08> from 877Driver.exe (see above), or by setting
the DIL switch to all OFF (see diagram), and resetting NETPIC.
Run 877Demo, and
ensure the IP address and the port number on the screen correspond to that used
by the NETPIC controller (usually 192.168.0.15, and port 1281).
Set some of the
bit ticks in the "remote I/O" section, and click on the "Output
to Port C", and the "Port A analogue enable" ticks as well.
Press the
"Send Request" button. This will generate a four byte payload UDP
message to be sent to the NETPIC remote at port 1281. If all is well, NETPIC will set its output ports (light the
LEDs), sense the voltage at the trimpot on bit 0 of PORTA, and reply with
another four byte UDP datagram to the PC.
The PC will decode the reply and display the analogue voltage on the
screen.
NetPicDemo first
sends an ARP packet to the controller to find its hardware address, then
continues by sending the UDP datagram with 4 bytes of payload data.
BASIC OPERATION OF CONTROLLER
General Software operational sequence (refer to the following flow diagram)
On Power on:
If just after
reset, port C6 is low, the following defaults are installed in the EEPROM.
hmaddr 0x4E4554504943 i.e. "NETPIC"
Ipmaddr 0xC0A8000F i.e. "192.168.0.15"
gstatus 0x00 57600bps, demo mode
Otherwise, The
above are loaded from the previously stored EEPROM:
hmaddr My hardware MAC Ethernet address 6 bytes
ipmadd My
IP address 4
bytes
gstatus Current setup conditions
The following
variables are also loaded from EEPROM, and are usually stored as a remainder
from the last operation performed
htaddr Last destination HA address
contacted
iptaddr Last destination IP address
contacted
The DIL switch
is read, and internal flags are set as follows:
SW7 Serial
port speed: off= 5700 on=2400
SW6 Start
up mode off=UDP demo on=transparent mode
SW5 not
used
The program now
enters an endless loop, sensing the input Ethernet buffer and waiting for user
characters on the serial port. The LED heartbeat lamp is flashed every second
or so to show the unit is operational.
There are three
relevant ""Events" a this point:
Receiving a data packet from the
Ethernet wire
Receiving a character from the
user's serial port.
Internal timer counter overflows or
reaches end count.
1 when a frame
has been received into the Ethernet buffer:
Refer to the
figure above for the internal data flow. This flow is controlled by bit flags
in ram location gstatus.
If bit flag gstatus,0 is set:
The received
frame is sent to the user output serial port in encoded form (see section on
packet encoding for the actual format), no other processing is done on incoming
data . This option is useful for using the device as a simple network monitor.
Two other flags are also relevant for this option: if bit flag gstatus,4 is set, only the first 64
bytes of every frame are sent to the serial port (e.g. headers only and to
avoid sending long data blocks). If bit flag gstatus,1 is set, the Ethernet chip will accept all frames i.e. not
just those addressed to it. This feature is known as "promiscuous
mode". This allows all data in the network to be accepted by the chip.
If bit flag gstatus,0 is reset:
The controller
will process the incoming frame. The frame will be silently discarded if any of
the following conditions are met, otherwise the payload is passed on to the
next level::
The ethernet trailing CRC checksum
word was in error
The Frame is not a broadcast, or is
not addressed to our MAC address (unless bit flag gstatus,1 is set, in which case it will
be accepted)
The Frame type is other than ARP or
IP (codes 0x800 or 0x806)
If bit flag gstatus,5 is reset, the chip will
process incoming ARP frames, otherwise they will be ignored. ARP frames have a
type code of 0x800, and are used to determine the hardware address of a card
from a given IP address. ARP packets are usually broadcast from a remote
workstation, only the station with the correct IP address match will reply to
the ARP request with a data packet containing its own hardware address. A typical
ARP request packets is as follows:
|
0xffffff |
srceHA |
0x806 |
flags |
srce HA |
srce IP |
trgt HA |
trgt IP |
Therefore, if
bit flag gstatus,5 is reset, and the
payload packet was an ARP "request" packet, and the target IP address
matches with ours (i.e. trgtIP = ipmadd),
then
- An ARP reply is sent back.
- The single character 'A' is sent to the user
serial port. This notifies the user that an external ARP request was received.
If on the other
hand, the received packet was an ARP "reply" (usually in response to
our unit sending a previous ARP request), and both target HA and IP address
match with ours (i.e. destHA=hmaddr, and
trgtIP=ipmaddr), i.e. the received packet was:
|
trgtHA |
srceHA |
0x806 |
flags |
srce HA |
srce IP |
trgt HA |
trgt IP |
Then:
- Our destination HA address is
updated, ie htaddr=srceHA
- A single character 'a' is sent to
the user serial port
- An internal bit flag gethflag,0 is reset (this flag was set when the ARP request was called by the user).
If the received payload was an IP datagram:
If bit flag gstatus,6 is set, the IP message is sent to the user serial
port in encoded form, no further processing willl be done by the controller
chip.
If bit flag gstatus,6 is reset, the controller will process the IP message.
The IP header is checked for consistency, and packets will be discarded if the
following conditions are met, otherwise the payload is passed on to the next
stage.
IP header checksum in error
Destination IP address not same as
our IP address (ipmadd)
Protocol none of 01(ICMP), 06(TCP),
11h(UDP).
Fragmentation offset is not zero
The "more fragments" bit
flag is set.
If the IP payload is an ICMP message:
If bit flag gstatus,7 is set, the ICMP message is
sent to the user serial port in encoded form, no other ICMP processing is
performed within the chip. This feature can be used to externally process ICMP
data (for developing custom PING and traceroute type programs)
If bit flag gstatus,7 is reset, the controller will
process the ICMP message as follows:
ICMP request (type
= 0x08)
The message is echoed back to the
remote workstation as a ICMP reply packet
The single character 'H' is sent to
the user serial port.
ICMP reply
(type= 0x00)
This is usually received in response
to our PING request (see below)
The internal flag gethflag,1 is
reset (this flag was reset by our previous PING request)
The single character 'h' is sent to
the user serial port.
ICMP - other
codes
Three characters are sent to the
user serial port:
'g' followed by a type byte and a
code byte.
This allows for simple processing of
incoming ICMP error messages
Generating a PING request:
We may want to send a PING message to another workstation This can be done by sending the single character command 'H' to the serial port. This also causes the internal flag gethflag,1 to be set, which is reset on reception of a correct PING reply. As an alternative, custom ICMP packets can be generated by sending direct encoded packet data to the serial port (see section on transmission).
If the IP payload is a UDP datagram:
If bit flag gstatus,3 is reset, the contents of the
datagram are sent to the serial port in encoded form, no other UDP processing
is performed within the chip.
If bit flag gstatus,3 is set, and if the UDP packet was addressed to one of
our enabled ports, some internal UDP processing will be done: For port 0x501
(1281 decimal), The internal I/O registers in the PIC are read or written to
depending on the packets data, and a response packet is sent back to the source
with the results of the readings. This forms the basis of a simple I/O
gathering station using he few available I/O ports on the PIC (5 digital and 6
analogue).
If the IP payload is a TCP segment:
If bit flag gstatus,2 is reset: the contents of the
segment are sent directly to the serial port in encoded form, no other TCP
processing is performed within the chip.
If bit flag gstatus,2 is set, and if the TCP packet
was addressed to port 0x502, the TCP state diagram will be enabled. This allows
stream communications to and from the user's serial port.
TRANSMITTING DATA
User input
serial port data is separated into commands and transmit data. Commands are
single characters or string of characters used to set and read internal state
variables and registers. Transmit data is a string of bytes encapsulated as
packets with a special header and trailer code byte sequence. Transmit data
bytes are sent to the Ethernet chip for transmission after removal from their
packets.
Command Codes
The following
commands are available:
A Transmit
ARP request
H Transmit
PING request
Sxxxx Enter our IP address (0x53 followed by 4 bytes)
Dxxxx Enter destination IP address (0x44 followed by 4 bytes)
Bxxxxxx Enter our HA address (0x42 followed by 6 bytes)
<CB><x> Change status byte (i.e. 0xCB,0x00)
<CD><<XX> Set the TTL and TOS bytes (i.e. 0xCD,
0x80, 0x00)
Transmit Data Packets:
Blocks of data
for transmission must be prepared by the user software in the correct format
(see next section). The packet will be directed to different processing
sections depending on the protocol used. The protocol byte is the byte after
the packet first byte 0x7E:
Packet Encoding
User data
packets must be differentiated from user commands and other data. A simple
method for encapsulating blocks of data is used here. The format is very simple
and easy to encode and decode, the basic format is as follows:
|
7E |
protocol byte |
...data...... |
7F |
FF |
The first byte
is 7E hex, and denotes the start of a packet. This byte value does not occur in
any of the command codes, or within any of the data itself so it uniquely
denotes the start of a data block. Following the 0x7E is a single protocol
byte, which is used to determine what type of data follows, the options are
00 Raw
Ethernet
01 ICMP
04 TCP
+ MSS payload
05 TCP
payload
06 TCP
10h UDP
payload
11h UDP
xx Others
The data section
itself is of variable length. The terminator byte is 7Fhex, usually followed by
an optional byte FFhex (which is used to denote that the packet was OK, and not
in error), this last byte can be ignored in most cases.
Escape sequences
are used in the main data stream to ensure that payload data bytes of the form
7D, 7E or 7F are converted to byte pairs 7D5D, 7D5E and 7D5F. This will ensure
uniqueness of the header and terminator bytes.
This scheme is
similar to the method used in PPP, with the only difference that the start and
end packet markers are different (they are the same in PPP).
The user
software will need to use the following scheme for decoding received packets:
Wait till byte 7E is received, start
the buffer
Receive the next byte and save as
the protocol code.
Receive bytes, one by one
If the received character is 7D, ignore
it, and XOR the next with 0x20.
Continue doing this until byte 7E is
received
If the byte after the 7E is FE, the
packet was bad, dump it or process it regardless.
The scheme for
transmitting a packet:
At the start,
send the two byte sequence 7E followed by the protocol code,
The Transmission Protocols
Protocol=0x00 (raw Ethernet):
The packet is
sent to the Ethernet chip for direct transmission, no processing is done on the
packet (apart from removing headers, trailers and the escape pairs). Note that
these raw packets must contain full ethernet source and destination address
headers as well as the user payload: The format is as follows (after removing
7E-7F encapsulation)
|
dest HA(6) |
srce HA(6) |
frame(2) |
payload(4) |
To comply with
standard ethernet framing conventions, the packets must contain between 64 and
1500 bytes.
Protocols 0x01 (full ICMP), 0x06 (full TCP) and UDP(full 0x11)
The controller
will add a 14 byte Ethernet header (using internal HA addresses 'hmaddr' for
source and htaddr' for destination. It is assumed that the destination HA
address has been previously obtained by the user with an ARP request command.
Or a message from another workstation has been received, which will set the
value automatically. The resulting Ethernet header is as follows:
:
|
htadd(6) |
hmadd(6) |
0x800 |
IP & user payload as below |
The controller
will also add a 20 byte IP header with the values generated as follows.
|
45 |
TOS |
DG size |
|
ID |
flags & offsets |
|
|
TTL |
PCOL |
IP checksum |
|
source IP |
||
|
dest IP |
||
The controller
will use internal user defined values for TTL and TOS. The ID is internally
generated and automatically incremented for every transaction. The source IP
address is taken from ipmadd and the destination IP address from iptadd. Checksum
and other values are internally calculated.
Payload
|
User supplied Payload (ICMP/UDP/TCP) |
Depending on the
protocol used, the user will need to fill the payload with the correct
sequence. In the case of ICMP, TCP and UDP, the controller will calculate all
the checksum and size entries, there is
no need for the user to fill these fields. The fields supplied by the user must
be as follows:
User supplied
ICMP payload (protocol = 0x01)
|
TYPE(1) |
CODE(1) |
Checksum(2) |
|
Options(4*n) |
||
where:
TYPE Supplied
by user
CODE Supplied
by user
Checksum Calculated internally
Options Data supplied by the user
User Supplied
UDP datagram (protocol 0x11)
|
source port(2) |
dest port(2) |
|
UDP length(2) |
checksum(2) |
|
User data(4 * n) |
|
Where:
Source port Supplied by user
Dest port Supplied by user
UDP size Calculated internally
Checksum Calculated internally
User data Supplied by user
User supplied
TCP Segment (protocol 0x06)
|
source port(2) |
dest port(2) |
|
|
sequence
number(4) |
||
|
ack number(4) |
||
|
offset(1) |
flags(1) |
window(2) |
|
checksum(2) |
urgent(2) |
|
|
User data(4 *
n) |
||
Where:
Source port Supplied by user
Dest port Supplied by user
Seq number Supplied by user
Ack number Supplied by user
offset Supplied by user
flags Supplied by user
window Supplied by user
checksum Calculated internally
urgent Supplied by user
User data Supplied by user
Protocol 10h (UDP payload)
This is similar
to protocol 11h, but the user only provides the actual payload data for a UDP
transaction. The Controller will add not only the IP header, but also the UDP
header. The source port will be taken from tcpdport, and the destination port
from tcpsport. This protocol is used to
reply to UDP transactions whwn the UDP socket is open (by setting bit flag gstatus,3.
Protocol 5 (TCP payload)
This is similar
to protocol 6, but the user only provides the actual payload data for a TCP
transaction. The Controller will add not only the IP header, but also the
correctly formatted TCP header. The source port will be taken from tcpdport,
and the destination port from tcpsport.
This protocol is used for stream transactions when a TCP socket has been
opened (by setting bit flag gstatus,2.
Protocol 4 (TCP + OPTIONS payload)
This is similar
to protocol 5 above, but with the added facility of options added to the
header. This protocol is mainly used internally when opening a communications
and for sending extra information such as MSS limits.
Examples of Use:
Simple Network Analyser
Flag gstatus must be set to 0x03, (optionally
to 0x13 to limit data to 64 bytes per packet) . In this format, all incoming
packets will be sent to the user serial port in encoded form, (see section
on packet encoding for format).
|
HA target addr(6) |
HA source addr(6) |
frame(6) |
payload(N) |
The HA target
and source addresses are 6 bytes each, and correspond to the hardware addresses
of ours and the remote ethernet cards in the network. The special target
address FFFFFF is used for broadcast packets, usually associated with ARP
requests. The frame code identifies the format of the payload, some of the most
common codes in use are:
0x800 IP packet (including ICMP/UDP/TCP
0x806 ARP packet
The user software
only needs to perform a simple tree decoding of the packet fields for display,
including any filtering as required.
Ping/traceroute program
A traceroute
program is one that sends ICMP packets (ping) with various difefrent options
and parameters in order to find out about routers and access to a particular
destination. The most common parameters for validation are:
TTL (time to live) byte
TOS
Options: e.g. number of data
characters
Flag gstatus must be set to 0x80 The user software must ignore packets other
than ICMP ones (the protocol byte after the 0x7E header will be 0x01), and
be able to decode and process the incoming ICMP headers.
Free format UDP transactions
The controller
provides two methods for UDP transactions, depending on whether the user wants
to keep control of the headers, or wants to do transparent transactions. For
free format UDP, flag gstatus must
be set to 0x00.
|
srce port(2) |
dest port(2) |
nr bytes(2) |
checksum(2) |
payload(n) |
The source IP
address is stored in the iptadd variable. The user software needs to check the
first two bytes correspond to the port we want to receive on (they can be ignored
in a simple system). 'Nr bytes' and 'checksum' can also be ignored.
When preparing a
reply packet it should be formatted as follows:
|
dest port |
srce port |
nr bytes |
checksum |
payload |
Note that the
destination and source port numbers have been interchanged. There is no need
to enter any data for length or checksum as these will be calculated and added
automatically inside the chip.
Transparent UDP
A simpler form
of the above, where the UDP header is handled internally by the controller
and only the final payload is passed on to the user. Flag gstatus must be set to 0x08. All UDP packets arriving addressed to
our IP address, and with destination port number 0x5002 will be accepted,
the clean payload is passed on to the user via the serial port.
Free Format TCP
In a similar
way to UDP, the controller provides two methods for TCP transactions, depending
on whether the user wants to keep control of the headers, or wants to do transparent
transactions.
|
srce port(2) |
dest port(2) |
seqnr(4) |
acknr(4) |
flags(2) |
|
window(2) |
checksum(2) |
urgentptr(2) |
options(n) |
payload(n) |
The source IP
address is stored in the iptadd variable. The user software needs to check
the first two bytes correspond to the port we want to receive on (they can
eb ignodred in a simple system). 'nrbytes' and 'checksum' can also be ignored.
Transparent TCP
A simpler form
of the above, where the TCP transaction is handled internally by the controller
and only the final payload is passed on to the user. Flag gstatus must be set to 0x04. All TCP packets arriving addressed to
our IP address, and with destination port number 0x5003 will be accepted,
the clean payload is passed on to the user via the serial port.