THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

INTRODUCING THE PACKET WHACKER

Part 2: Setting a Course with Code
by Fred Eady

Start ı Packet Whacker Utilities ı Receiving Packets ı Who ARP You?ı Ping ı UDP ı TCP ı FIN ı Sources and PDF

RECEIVING PACKETS

Sending packets from the PICDEM.net using a Packet Whacker is something that really needs to be done. However, sending information and not receiving information in return or vice versa is illogical and goes against the basic rules of Internet protocol. With that thought, one of the first things you want to do is write some code to the receive packets. Keeping it logical, Iıll call the receive packet function get_packet.

The get_packet function is kicked off as a result of the signal condition of the RTL8019AS INT0 pin as seen by the PICDEM.netıs PIC pin RC0. The RTL8019AS initialization code in Listing 4 sets up the RTL8019AS control registers to bring the INT0 signal into play. With the Packet Whacker strapped for Jumper mode and with no RTL8019AS jumper pins connected or pulled high, the RTL8019AS jumper pins that would be read in Jumper mode are all internally pulled low and, thus, read as low during NIC startup. The "all low" condition of the jumper pins places IRQS0-IRQS2 at 000 and selects INT0 as the NIC interrupt request line.

Within the same register (CONFIG1), the IRQEN (IRQ Enable) bit defaults to high on powerup. Leaving this bit high forces the INT0 line to go high when the NIC is requesting an interrupt. The final INT0 initialization step is performed in Listing 4 by loading the NIC interrupt mask register (IMR) with a value (0x11) to unmask the PRX interrupt bit and enable the "received with no errors" interrupt. The bit set in the high nibble of the IMR enables the buffer overrun interrupt, OVW.

After the NIC initialization code completes successfully, the main function of the PICDEM.net firmware goes into a tight loop, keeping an eye on the PIC pin interfacing the NICıs INT0 line. The instant INT0 goes high, supposedly a good packet has been received into the RTL8019ASıs receive buffer ring. Remember that the OVW (overflow) interrupt is also activated and the seemingly good thing suddenly turns into a bad thing. The only way to determine whoıs who in interrupt land is to investigate the situation using the contents of the RTL8019ASıs interrupt status register (ISR).

Following the detection of the interrupt and the initial read of the NICıs ISR, the OVW and PRX bits are checked to determine what action to take next. The overrun condition is handled by a canned routine called overrun. I call it canned because it is a direct order from the DP8390 datasheet as to how to code it. For now, letıs take the PRX path, which leads us back to the get_packet routine in Listing 5 .

Look back at the dcrval definition in Listing 4. Bit 4 (ARM) of the dcrval variable is set. By setting the ARM bit, the Send Packet command, which automatically takes a packet off the receive buffer ring, can be executed. Thatıs the first order of real business in the get_packet code. This is accomplished by writing 0x1A to the NICıs command register, CR. Because the packet page header bytes arenıt part of the original incoming packet and are added by the NIC for housekeeping, I decided to read them into their own buffer area. This arrangement makes it easier to keep up with the packet buffer contents as they are not mixed in with receive buffer administration data contained in the four packet header bytes.

The latest version of the CCS PIC compiler includes built-in functions to assemble 16- and 32-bit words from combinations of bytes. On the reverse side of that, bytes can be extracted from the 16- and 32-bit words by simply providing a byte offset (0, 1, 2, and 3, with 3 representing the MSB) into the multi-byte word. The resulting machine code is really tight and the ability to manipulate 32-bit words greatly simplifies writing Packet Whacker checksum firmware.

For instance, in Listing 5, after reading the 4-byte packet header, I use the CCS function make16 to combine the high and low length bytes of the packet header into a 16-bit word that I use as a counter value to track removal of bytes from the NICıs receive ring. Various parts of the Packet Whacker code also use the make8 function to place the high and low bytes of a 16-bit value into 8-bit buffer areas. The beauty of this is that the bit shifting you would normally code is eliminated in the compilerıs built-in make functions.

There is another contiguous 96-byte RAM area in the PIC16F877 that I could allocate to increase the packet buffer size. Because the packets the PICDEM.net will be working with wonıt be extending beyond the 96 bytes already allocated, I didnıt exercise that option. To use the extra space I would have to keep up with which incoming packet field sits at which end of either of the 96-byte buffer boundaries. To ensure I donıt overflow the PICıs buffer area, I limit the storage of data to a total of 96 bytes by reading (removing from the NIC receive ring) and discarding any data above the 96-byte limit. Knowing the constraints, I write my application code to adhere to the 96-byte policy, but other participants on the LAN will certainly be sending packets much larger than 96 bytes. By just discarding what it canıt buffer, the Packet Whacker can exist on a real-world LAN and work without the worry of being overloaded by superfluous traffic from other devices.

After the PICDEM.net is on a LAN, it can be overwhelmed by incoming traffic if it canıt discern which traffic is addressed to it. In the RTL8019AS initialization code (see Listing 4), the MAC or hardware address for the PICDEM.net was loaded into the NICıs physical address registers (PARs) as 0CCINK. If the Packet Whacker/PICDEM.net combination is going to play in the Internet world, it will need an IP address as well. Chances are the Internet device that wants to communicate with the PICDEM.net will know the PICDEM.netıs IP address but wonıt have a clue as to what the MAC address stored inside the PICDEM.netıs RTL8019AS is. To make contact with the PICDEM.net, the remote Internet device must know both. Fortunately, the founding fathers of Internet gave us a way to solve this problem. The remedy is called ARP.

PREVIOUS • NEXT