Little and big Indians
In the common computer and the microcontrollers the minimum memory locations are usually of 8 bit; but when must represent the 16bit values, must decide how are saved in memory.
A data from 16bit obviously occupies two memory location, so there are two possibilities:
- the byte less important stays at the address lower compared with MSB.
- vice versa, the byte less important stays at the address of the great memory of the two.
These two options are named Little Indian e Big Indian.
The commons computer (with processors x86) and also the PIC, using the first notation, while in the network protocols is diffused the use of the second.
The htons function duty is to convert a data at 16bit between two notations. In the article will be used and wants a lot of attention at its use.

u16 htons(u16 val){
	return (((u16)val >> 8 ) | ((u16)val << 8 ));
}

Like already saw the ERXWRPT register contains the address where the controller writes the received dates, while the ERXRDPT register, point to the address where our software reads the received dates; the zone that finds between these two addresses is interdicted to the writing, for impede the dates loss during theirs elaboration.
Told this, results necessary, end of the packet examination, the ERXRDPT register update with the address of the next packet to read (RdPt).

void freeRxSpace(){
	u16 NewRdPt;
	setBank(0);
	NewRdPt = RdPt -1;
	if ((NewRdPt > RX_BUF_END) || (NewRdPt < RX_BUF_START)) NewRdPt = RX_BUF_END;
	BFSReg(ECON2, 0b01000000);    		// decrements EPKTCNT
	writeReg(ERXRDPTL, LOW(NewRdPt));
	writeReg(ERXRDPTH, HIGH(NewRdPt)); 	// empty the buffer space
}

In this method is updated the register and is decrement EPKTCNT.
Because of a problem described in the Errata, the ERXRDPT value must be odd; we know that RdPt is for sure even
(the controller adds a padding in a way to be even), so is enough to subtract one at this value, and then control that doesn't go outside the buffer (RX_BUF_START e RX_BUF_END) limits.

Internet Protocol Suite
TCP/IP is a protocols family (Internet Protocol Suite)
widely used for the dates change
on the internet (and also intranet); this includes the known TCP protocols (4th level)
and IP (3rd level) that are the represent as well as the first to be ideates, and another
(UDP, ICMP, ARP, RARP, etc.).
These protocols occupy the 3 and 4 levels of the OSI model, so basically occupy by the transport, more or less reliable, of the Applications generates dates.

In the next page we will speak about the protocol:

• ARP : already mentioned, permeates the conversion of an IP address with a MAC address corespondent.
• IP : is a protocol of 3rd level and the base of all the Network; is indispensable for the correct forward of the packets, through the recipient IP address.
• ICMP : stays at the 3rd level, but is above IP; makes the useful functions for the forward and for the diagnostic (see ping).
• TCP : is a transport protocol very reliable (and also complex).
• UDP : is another protocol transport, but less reliable of the TCP; has the advantage to have an easy implementation and generally gives good performances.

ARP
The ARP (Address Resolution Protocol) is a 3rd level protocol, employed to the LAN networks internal, to translate the IP addresses in the physical addresses (MAC) correspondences.
We already analyzed in this page the mechanism which ties the two addresses.

The heading
This protocol isn't only for ethernet networks and IP protocol, so an ARP packet contains different fields which specify what addresses are:

At these follows a variable length dates field (which depends of the heading), that for the operation nominate will contain 4 addresses, like in this scheme:

ARP Request
The MAc address demanding packet contains, beyond the heading, the sender MAC and IP addresses, and like Target IP Address, the address you want to know of the physical address.
That's why, when an ARP packet arrives is sufficient to control the fields Operation and indeed Target IP Address which must correspond to our IP, or else we ignore the demanding.

ARP Reply
The replay packet is similar to the one already saw: it's enough to indicate in the field Operation that it treats about a replay, and refill the fields with the sender and recipient addresses.

Everything is collected in a sole function:

void processARP(){
	ARPPacket packet;
	IPAddr tmp;	
	
	encGetArray((u8*)&packet, sizeof(packet));
	packet.operation = htons(packet.operation);

	if (packet.operation == ARP_REQUEST){
		if (ipMatch(packet.TargetIP,MyIP)){
			packet.operation = htons(ARP_REPLY);
			tmp = packet.TargetIP;
			packet.TargetMAC = packet.SourceMAC;
			packet.TargetIP = packet.SourceIP;
			packet.SourceIP = tmp;
			packet.SourceMAC.b[0] = MY_MAC1;
			packet.SourceMAC.b[1] = MY_MAC2;
			packet.SourceMAC.b[2] = MY_MAC3;
			packet.SourceMAC.b[3] = MY_MAC4;
			packet.SourceMAC.b[4] = MY_MAC5;
			packet.SourceMAC.b[5] = MY_MAC6;
			MACPutHeader(packet.TargetMAC, TYPE_ARP);
			encPutArray((u8*)&packet,sizeof(packet));
			MACSend();
		}
	}
}

The ARP packet is defined:

typedef struct {
  u16          hardware;
  u16          protocol;
  u8           MacLen;
  u8           ProtocolLen;
  u16          operation;
  MACAddr      SourceMAC;
  IPAddr       SourceIP;
  MACAddr      TargetMAC;
  IPAddr       TargetIP;
} ARPPacket;