Embedded Web Server for the CR16
National Semiconductor
Jeff Wright
11
extension of IP addresses to 128 bits (to accommodate the quintillions of additional IP
addresses required when we link up with Mars).
·
IP fragmentation
Don’t confuse an IP fragment with a TCP segment; an IP fragment is a piece of a TCP segment
whose size precludes it from being transmitted over a network in one piece. The Internet
Protocol was designed to be independent of both the underlying Data Link protocol and the
overlying Transport protocol. This flexibility is critical because of the large numbers of
incompatible Transport and Link layer protocols. However, this independence carries with it
certain difficulties, one of which is how to transmit a datagram whose size exceeds that of the
underlying Link layer’s MTU (see above). To accommodate this eventuality, an IP should be
capable of fragmenting a segment (should its size exceed this MTU) into multiple datagrams,
each of which is small enough to fit comfortably into the underlying network’s frame…simple.
Not really. In fact the RFC’s recommended procedure is to avoid all this nastiness by first
determining the underlying MTU (frame size) by what is termed a path discovery mechanism,
and reporting this limit to the transport layer ahead of time. Since managing the transmission
of fragmented datagrams requires considerable effort, most IP’s enthusiastically comply,
However, all IP’s MUST be capable of accepting and reassembling incoming fragmented
datagrams (also an unsavory proposition, and consequently, happily “de-implemented” by most).
IP includes two provisions for managing this process:
1.
Every datagram is assigned a number, indicating the segment to which it belongs. All
fragments belonging to a specific segment would have the same id. This number is
carried the IP header’s identification field…
2.
To correctly order the fragments of a fragmented segment, each datagram contains an
offset field in its header.
Particulars of this Implementation
ü
Memory Requirements
The TCP/IP stack and embedded Web server described herein consumes less than 20K of code
space and requires approximately 2.5K of RAM. The stack operates under uC/OS-II; an RTOS
recently ported for use with the CR16B RISC core, chosen for its small kernel size and minimum
RAM usage.
ü
Stack Details
Rather than follow the “driver-based” paradigm used by some stacks, this stack adheres to a “task-
based” philosophy. (The author is well aware of the long-standing and heated ideological schism
separating each camp. While each group presents compelling arguments, both tacks possess certain
advantages and disadvantages.) Each layer is implemented as an independent task, and shared data
structures are used for inter-task interfaces. Protocol layers are scheduled by the OS according
to the layer’s priority, and the layers themselves may cause other layers to run to improve
efficiency.
