You need some kind of program to communicate between a PC and the RS232-connection of the 515/535-mainboard.

With the onboard monitor program you can check 80C535/C515-registers, internal and external RAM etc. Also you can upload Intel-Hex-files to the 515/535-mainboard.


Using the 515/535-mainboard with the Windows95 HyperTerminal. If you use Windows 95 you can use the HyperTerminal to communicate with the 515/535-mainboard. For uploading HEX-files but also to use the Monitor program.

You should have the following settings:

File/Properties
Connect using Direct to Com1
Bits per seconds 9600
Data bits 8
Parity None
Stop bit 1
Flow control None

 

Settings/ASCII Setup
Line delay 100 milliseconds
Character delay 5 milliseconds

Send line ends with line feeds

Transfer
Send Text File...
Files of Type *.*

You should send HEX-files
Every line should start with :
The last line should be :00000001FF
followed by a line with :

To start your program on address 8000
you should enter at the prompt J8000


For Procomm Plus 4.0 I have made a upload-script. In the text you will read how to run this script from within Bascom-8051

upload.was

Like in the upload.was-file as comment is mentioned, you should call Procomm Plus (PW4.EXE) with the parameters upload.was and {file}. You should put use Hex-file to on.


Here you can find Telix for DOS


Or what about driving the 515/535-mainboard over a TCP/IP-network, like the Internet!!

Here some rough examples for TCP/IP-interfacing to a comport written in Visual Basic 6.0. You can use Telnet to connect to this Server80C535 with port 535. Com-port settings are 9600 baud, no parity, 8 bit, 1 stop bit.

You can test the connection on your own machine with Telnet, connect to address 127.0.0.1 (local host) with port 535. You should have started Server80C535 and start TCP/IP and serial communication. All commands should go from the Telnet-screen to the Server80C535-screen to the RS232-poort.

Server80C535


Ethernet-info in detail....

Packet Whacker and uIP

uIP-AVR is a port of Adam Dunkel's uIP - A Free Small TCP/IP Stack - to the Atmel AVR series of microcontrollers. Louis Beaudoin did a great job by porting this TCP/IP-stack to the ATMega161.

Louis' webpage can be found here:

http://www.embedded-creations.com/projects

I have used a port of uIP version 0.60 and it supports communication over Ethernet using the RTL8019AS NIC.  The current version interfaces with the NIC through either the External SRAM interface, or through general I/O ports, and has been tested with the ATmega161, ATmega163 and AT90S8535.  The RTL8019AS NIC controller can be purchased along with the necessary support components in a PCB module called the Packet Whacker, from www.edtp.com

The schematic can be found here, it is made by EDTP.

avr_whacker_sch.pdf (zipped)

The source-code for AVR-GCC and ImageCraft-C can be found here, it has a module to drive a LCD.

uip_avr_163.zip

If you check the picture on the index-page, under the packet whacker I have put the crystal, two capacitors, a reset switch and two led's. One for the power and one connected to a spare pin of the Atmega163.

Have also made a version for Bascom-AVR which can be found here (finished)
At this moment the size of the code is
8958 bytes leaving more then 7 kBytes in the Atmega163 for user code.

Put HW-stack on 128, SW-stack on 128 and framesize on 128.

Packet Whacker.udp.bas

If you download the EDTP testpanel then you can test the UDP-traffic from PC to Packet Whacker

If you want to extract the information of the UDP-packet you can add a subroutine called extract_udp with the next information:

 
Sub Extract_udp
Hulp1 = Udp_len + 1
' Print "Length udp-packet is " ; Packet(hulp1)
Hulp1 = Packet(udp_len) + Packet(hulp1)
Hulp1 = Hulp1 + 34 ' 43 - 9 start of UDP-string minus header
For X = 43 To Hulp1
Print Chr(packet(x));
Next X
Print
End Sub

 

In the UDP-subroutine, before the call to echo packet, you put the line
call extract_udp

On the screen you can follow the UDP-traffic.


A overview of the first 56 bytes of a ethernet-packet:
  ARP IP ICMP TCP UDP
1 Destination
MAC-addr. 1
Destination
MAC-addr. 1
Destination
MAC-addr. 1
Destination
MAC-addr. 1
Destination
MAC-addr. 1
2 Destination
MAC-addr. 2
Destination
MAC-addr. 2
Destination
MAC-addr. 2
Destination
MAC-addr. 2
Destination
MAC-addr. 2
3 Destination
MAC-addr. 3
Destination
MAC-addr. 3
Destination
MAC-addr. 3
Destination
MAC-addr. 3
Destination
MAC-addr. 3
4 Destination
MAC-addr. 4
Destination
MAC-addr. 4
Destination
MAC-addr. 4
Destination
MAC-addr. 4
Destination
MAC-addr. 4
5 Destination
MAC-addr. 5
Destination
MAC-addr. 5
Destination
MAC-addr. 5
Destination
MAC-addr. 5
Destination
MAC-addr. 5
6 Destination
MAC-addr. 6
Destination
MAC-addr. 6
Destination
MAC-addr. 6
Destination
MAC-addr. 6
Destination
MAC-addr. 6
7 Source MAC-
address 1
Source MAC-
address 1
Source MAC-
address 1
Source MAC-
address 1
Source MAC-
address 1
8 Source MAC-
address 2
Source MAC-
address 2
Source MAC-
address 2
Source MAC-
address 2
Source MAC-
address 2
9 Source MAC-
address 3
Source MAC-
address 3
Source MAC-
address 3
Source MAC-
address 3
Source MAC-
address 3
10 Source MAC-
address 4
Source MAC-
address 4
Source MAC-
address 4
Source MAC-
address 4
Source MAC-
address 4
11 Source MAC-
address 5
Source MAC-
address 5
Source MAC-
address 5
Source MAC-
address 5
Source MAC-
address 5
12 Source MAC-
address 6
Source MAC-
address 6
Source MAC-
address 6
Source MAC-
address 6
Source MAC-
address 6
13 Packet
type 0
Packet
type 0
Packet
type 0
Packet
type 0
Packet
type 0
14 Packet
type 1
Packet
type 1
Packet
type 1
Packet
type 1
Packet
type 1
15 hwtype 0 version and
length
version and
length
version and
length
version and
 length
16 hwtype 1 tos tos tos tos
17 prtype 0 packet-
length h
packet-
length h
packet-
length h
packet-
length h
18 prtype 1 packet-
length l
packet-
length l
packet-
length l
packet-
length l
19 hwlen id 0 id 0 id 0 id 0
20 prlen id 1 id 1 id 1 id 1
21 op 0 frag-offset 0 frag-offset 0 frag-offset 0 frag-offset 0
22 op 1 frag-offset 1 frag-offset 1 frag-offset 1 frag-offset 1
23 shaddr Time to live Time to live Time to live Time to live
24 sipaddr Protocol Protocol Protocol Protocol
25 thaddr Header
checksum h
Header
checksum h
Header
checksum h
Header
checksum h
26 tipaddr Header
checksum l
Header
checksum l
Header
checksum l
Header
checksum l
27   Source
address 0
Source
address 0
Source
address 0
Source
address 0
28 Source
address 1
Source
address 1
Source
address 1
Source
address 1
29 Source
address 2
Source
address 2
Source
address 2
Source
address 2
30 Source
address 3
Source
address 3
Source
address 3
Source
address 3
31 Destination
address 0
Destination
address 0
Destination
address 0
Destination
address 0
32 Destination
address 1
Destination
address 1
Destination
address 1
Destination
address 1
33 Destination
address 2
Destination
address 2
Destination
address 2
Destination
address 2
34 Destination
address 3
Destination
address 3
Destination
address 3
Destination
address 3
35 IP-data Type Source
port h
Source
port h
36   Code Source
port l
Source
port l
37 Checksum h Destination
port h
Destination
port h
38 Checksum l Destination
port l
Destination
port l
39 Id h Sequence-
number 3
Length h
40 Id l Sequence
number 2
Length l
41 Sequence
number h
Sequence
number 1
Checksum h
42 Sequence
number l
Sequence
number 0
Checksum l
43 ICMP-data Acknowledge
number 3
UDP-data
44 ICMP-data Acknowledge
number 2
UDP-data
45 ICMP-data Acknowledge
number 1
UDP-data
46 ICMP-data Acknowledge
number 0
UDP-data
47 ICMP-data Header
 
UDP-data
48 ICMP-data Flags
 
UDP-data
49 ICMP-data Window h
 
UDP-data
50 ICMP-data Window l
 
UDP-data
51 ICMP-data Checksum h
 
UDP-data
52 ICMP-data Checksum l
 
UDP-data
53 ICMP-data Urgent-
pointer h
UDP-data
54 ICMP-data Urgent-
pointer l
UDP-data
55 ICMP-data TCP-data
 
UDP-data
56 etc. etc.
etc. etc.
etc. etc

A UDP-packet in detail:

Mac header (Ethernet II)  
Destination:  00 00 C5 0E EC 5A (MAC-address)
Source:  30 42 45 4E 30 31 (MAC-address)
Type: DoD IP 08 00
IPv4 header  45
Version = 4 = IP-version  
Header length = 5 * 4 = 20 byte  
Type of service   00
Total length (60 bytes)   00 3C
Identification = 7172    1C 04
Flags and fragment offset = 0  00 00
Time to life = 128 hops (sec.) 80
Protocol = 17 UDP  11
Header checksum = 0x9A89   9A 89
Source      IP = 192.168.1.101   C0 A8 01 65
Destination IP = 192.168.1.110   C0 A8 01 6E
IP Options = None  
   
UDP header  
   
Source port = 7 echo    00 07
Destination port = 5002  13 8A
Length = 40 bytes  00 28
Checksum = 0x6711 (Correct)   67 11
Data (32 bytes) 30 39 3A 35 32 20 31 31 3A 34 35 20 74 65 73 74
  09:52 11:45 test
  20 74 65 73 74 20 74 65 73 74 20 74 65 73 74 20
  test test test

 


The guided tour

No article on Internet basics can do without a guided tour of the technology, from the bit-shifting protocols to the higher level scripts. I am not going to cover this in any detail, as there is plenty of information around in books and magazines. What I have done is a quick tour of the basic concepts involved, with special relevance to a  microcontroller-based implementation. The main source for detailed specifications are RFCs (Request for Comments). The text contains the reference number that relate to the topic. RFCs can be found on the internet by searching under "RFC".

Ethernet

On the back of your computer there may be a network connector. Look for a BNC socket with a coaxial cable (remember RG-58U?), or a flat cable ending in something looking like a plastic telephone connector. In most offices, these wires just disappear down the back of the desk only to reappear at some obscure room at the end of the corridor. Most office workers will know this place. They will tell you this is where the computer technician hides when nobody can find him in the building.

Ethernet is one of the main survivors among a number of similar technologies developed in the 1970s and 80s, possibly because of its ‘low tech’ simple and reliable approach. The coaxial cable ‘thin wire’ version (also known as 10Base2) is widely used in low end applications. 10Base2 is simplicity in itself; all workstations are connected together in daisy-chain fashion with a 50-ohm terminator at each far end. Data packets are just bursts of current fed into the impedance of the wire, and are read as voltages by the receivers. Transmitters fire bursts more or less without the knowledge of any other transmitters. Collisions (i.e. when two generators feed the wire at the same time) are detected by an abnormal rise in the voltage on the wire as two or more currents superimpose. Each transmitter then waits for a certain random time before attempting to transmit again.

The flat or twisted cable variation (known as 10BaseT) uses separate wires for transmit and receive; this gives better error immunity and simpler driver circuitry at each end. However, workstations cannot just be connected to each other, they need to be connected to a central ‘hub’, which acts more or less like a repeater or distributor. Other methods are available, working on similar electrical principles. In terms of speed, two main flavours are available, 10MHz and 100MHz. 10MHz is the most popular in many small office and home environments as it is easy to install, and the cables are easily cut and crimped. We shall only be using the 10MHz version here.

A speed of 10MHz sounds appealing when considering using a LAN for interfacing to external I/O devices. Reality is different; one must consider the inefficiencies of any start-stop burst protocol, plus gridlock effect caused by collisions and other users sharing the network. There is much good and bad statistics around showing relationships between usage and throughput. Just as on today's motorways, you can experience holdups at the most obscure times and for no apparent reason. Anybody designing equipment using a network for data transfer must be well aware of this. As a conservative estimate, just one PC and one interface (no other users) should be able to exchange data at between 70% to 90% of the full advertised speed. Throughput decays drastically when more users are on the network at the same time. The sensormag article in the reference includes some charts and calculations plus a pointer to an excel program to estimate these delays.

In terms of hardware support, there are dedicated Ethernet interface chips available from various manufacturers. Most are compatible with a standard generic architecture (NE2000) and implement a standard 8 or 16-bit data bus interface, compatible with most CPU addressing schemes. Access to the chip is done via a number of internally paged registers, usually arranged as sixteen I./O or memory locations. Most chips can be directly connected to a CPU memory bus, or even directly to a PC bus edge connector. The blocks of data being transferred are stored in FIFO memory, as a buffer area for the different speeds between the LAN and the rest of the system.

Using the chip involves first initialising a number of registers to set the various operating modes, e.g. 8 or 16-bit transfers. Then using a loop (or an interrupt routine) to wait for a ready data register flag denoting that so many bytes of received data are present on the FIFO buffer. On transmission the system places its data in another part of the RAM buffer, and sets a flag, which is usually reset at the end of transmission.

More detailed information on the workings of Ethernet interface chips can be found in manufacturer data sheets. Unfortunately, there doesn't seem to be much information available on the Internet apart from some National Semiconductor data sheets (see reference).

Protocols, addressing and payloads

Ethernet data packets (better known as frames) cannot be of just any size. If we were to do some simple calculations involving the maximum distance between workstations, the speed of light in coaxial cable and various other timing considerations about collision detection, we would work out that frames cannot contain less than 46, and no more than 1,500 payload bytes each

Every Ethernet packet or frame has a header consisting of a 6-byte source address, a 6-byte destination address, and a 2-byte protocol identifier. This is then followed by the payload, which as mentioned before, can only have between 46 and 1,500 bytes.

On reception of a frame without errors, this payload is ‘peeled off’ and passed on to the rest of the system. The protocol identifier field specifies which type of protocol is being carried by the payload. For example, 0x806 denotes an IP message.

The payload itself will have its own header and payload part, which are dealt with by the next layer in the chain. This is the concept of protocol ‘layers’. 

It is important to know that Ethernet data bursts or frames are completely independent of each other. Frames are fired like bullets out of a gun, and, apart from a collision detection mechanism during transmission, what happens to them afterwards is of no further concern to the transmitter. In other words, the Ethernet network layer does not provide for any global form of flow control or error protection. At the other end, received frames are checked for consistency by calculating their CRC. Frames arriving with errors are simply dropped or ignored. It is up to the higher layers to provide for any form of flow control and error protection.

It is also relevant to note that the source and destination addresses are ‘hardware’ addresses. Known as Media Access Control (MAC) numbers, they refer to 6-byte patterns uniquely associated with each Ethernet card and usually assigned at manufacture. In practice the address is stored in a separate serial EEPROM memory chip on the actual PC card. Blocks of addresses are assigned by the IEEE to each manufacturer, so when you buy your PC card, it will have its own unique number stored in it. You can always change this number if you wanted to, and apart from some simple restrictions (the first byte in the sequence must have a ‘1’ and a ‘0’ as its lower significant bits), any number can be used as long as there are no clashes with other cards in your network.

It is not practical to rely on fixed hardware addresses when managing a real computer network. Therefore, a more flexible form of addressing is used. This addressing scheme consist of four byte sequences (known as ‘IP’ addresses). They are displayed for human consumption as four decimal numbers, e.g. ‘192.168.0.1’.

In a computer network, each workstation is allocated its own IP address, maybe once only by the network manager, or dynamically at various times by a program in the network server. Each workstation with an Ethernet card will also have its own hardware MAC address.

The four byte IP address means nothing to the Ethernet card. Ethernet frames contain only MAC addresses as destinations. Sending a packet of data to a remote location requires knowing its MAC address.

If we connect a black box into a network containing our controller and data logger, we must allocate it an IP address, and notify everybody else of it. But how does the rest of the network know what our hardware MAC address is, and how to access us? This is why we need to know about ARP.

For more on Ethernet and IP, see RFC894.

ARP

As mentioned before, the payload in an Ethernet frame can carry formats other than IP. One such format is ARP, ARP is a simple query-response packet protocol used to match workstations hardware addresses and IP addresses.  ARP stands for Address Resolution Protocol.

In a typical network, computers spend a small part of their time sniffing each other, that is, sending short probe packets too see who else is around. This is usually done on a regular, or on a ‘need to know’ basis. The ARP protocol is used for just that. It makes use of a special MAC ‘broadcast’ destination address (0xFFFFFF). Broadcast messages are accepted by all Ethernet stations on the network. The broadcast message basically says, "Hey out there, anybody with IP address 190.168.0.15?" The one and only station having this IP address allocated will then reply with a packet stating its hardware MAC address.

In Windows, each computer builds up and maintains a local table of IP vs MAC address pairs. Before sending a message to another station, the table is consulted and if there is no entry, an ARP query message is sent out. The table is dynamically maintained, flushed and refreshed every few minutes.

To see this in action, open a MS-DOS box in your computer. Now enter "C:>arp -a". This will display the current IP/MAC address pairs for all the local machines in your network. You may see nothing, especially if there was no recent network activity (remember the tables are dynamic and flushed every few minutes). Next, enter "C:>ping 192.168.0.15", (or the address of any other station in your network), and wait to see any replies, then try "C:>arp -a" again. Assuming our prototype controller is connected to the network, the screen will show "192.168.0.15   4E-54-54-50-49-43"  We exist!!!

Any embedded Ethernet controller must include some form of ARP reply processing in order to respond to ‘who are you?’-type requests made by other stations on the network. The controller also needs to include methods for querying other workstations in the network for their MAC addresses (ARP requests). This is one of a number of necessary overheads that push up the amount of code required in the controller, but are essential for the proper operation in a shared network.

More on ARP can be found in RFC 826. The next topic of interest is IP, the ‘other’ relevant format carried by Ethernet frames.

IP

IP forms the backbone of all TCP and UDP messaging.  IP stands for Internet Protocol. Like the rest, each IP packet (better known as datagrams) has itself a header and a payload component. RFC 791 is the basic document describing IP. The most important items of information carried within the IP header are the source and destination IP addresses. For local communications between two stations in a local loop, the IP address in the IP header and the MAC address in the Ethernet frame header just preceding it will correspond to the same workstation computer. This may sound like unnecessary repetition, but this pairing is required for routers, where the fields will be different. There are other various fields including a checksum, a fragmentation pointer, a protocol code for the payload, and the payload itself.

Like Ethernet frames, IP datagrams are independent of each other and contain no in built error protection or recovery. So why is IP necessary? IP is the common layer above all hardware dependent transport mechanisms. Irrespectively on how the devices are electrically connected together, fibre, radio, phone lines, all data blocks end up as compatible IP datagrams.

The job of IP is to get the data block to its destination. Its main contributions are addressing, routing and fragmentation  Remember how Ethernet frames had a limited byte size range? Similar limitations also apply to other transport mechanisms: optical fibre, satellite links etc. IP allows datagrams to be chopped (fragmented) into shorter sections of the right size for transmission and vice versa: short sections packed into single, longer datagrams.

The method employed for fragmentation is relevant for embedded systems. Fragmented datagrams include a ‘pointer’ indexing the position of the first byte of their data payload in an imaginary 64kb data buffer. Therefore, each IP datagram contains exact information about the position and size of their payload within this imaginary buffer. This allows for fragmented datagrams to be received out of sequence. A receiver accumulates datagrams until they all neatly fit into a contiguous block.

It follows that fragmented IP datagrams are not completely independent of each other. This will introduce a time element in any system. A receiver for example, has to consider when to give up waiting for missing out of order packets, and dump any previously stored.

Fragmented datagrams cause problems with small embedded systems. In theory, a receiver needs to allocate a 64kb buffer for every first out of sequence datagram received. This means one buffer for every different open socket (or channel) being serviced. This is impractical for small RAM limited systems. One practical solution is to disallow or ignore fragmented IP datagrams. This may not be much of a problem if the transactions involved are small, eg for a a small data logger. However, there may be problems for systems dealing with long streams of block-encoded data such as voice or video. Fragmentation is not much of a problem with TCP (see later on) as TCP can be engineered to use small segments to start with.

In a typical situation, an embedded system may need to deal with many sources or originators. Datagrams may be arriving from more than one source at the same time. The microcontroller will need to keep track of all, keeping state variables for each contact, to ensure the right replies are sent back to the right originators. In a PC this is easily handled using concurrent threads. Small microcontrollers do not have such niceties.

Three types of IP payloads are of interest to us: ICMP, UDP and TCP.

ICMP

ICMP stands for Internet Control Message Protocol. This is not a protocol used to transfer messages but rather to provide a kind of internal maintenance messaging service. One of the most common uses for ICMP is a service known as PING. This is a method where a workstation can query another by transmitting a special short ‘ping’ message and wait for an echo response (think of submarine echo sounders). More on this later. Suffice to say that any embedded implementation should incorporate facilities for echoing any PING commands received.

ICMP replies are also commonly sent in response to failed UDP datagrams. An embedded application should also incorporate simple facilities for responding with ICMP ‘unobtainable’ messages. ICMP is documented in RFC 792, 950, 1812, 1122, 1191 and 1256.

UDP

UDP stands for User Datagram Protocol. UDP is a simple Transport Layer Protocol, it is a connectionless, unreliable protocol with no error or flow control mechanisms. In effect, UDP is nothing more sophisticated than an IP datagram with an extra addressing field: a port number. A port number is an interesting concept. If a workstation has an IP number allocated to it, how can different processes or programs in the workstation communicate at the same time? The answer is using ports. Workstation "192.168.0.31" can use port 21 to Telnet to another workstation, use port 80 for web access and use port 27 for file transfers. Think of telephone extensions working off a main private exchange number. UDP is fully described in RFC 768.

Sending a UDP message is somewhat like sending a postcard to a friend, a simple ‘shoot and forget’-type protocol. It can be very reliable in networks that are reliable to start with such as LANs and is normally used for simple file transfers, remote booting of PCs or anywhere where a failure to receive is not a disastrous issue, or one that can be simply compensated by a repeat transmission later on. Because of this simplicity, UDP is a simple protocol to implement in an embedded application. Simple error recovery can be implemented at the user level, this can take the form of mindless repetition to a simple ‘ACK’-based datagram response. Writing the software at the PC end is also easy.

Our controller uses UDP to demonstrate simple read and write to a parallel and the analogue port, also for simple data connection to and from the user serial port. UDP is an effective protocol for developing special user applications.

TCP

TCP stands for Transmission Control Protocol. TCP is a totally different kind of fish to UDP or to any of the protocols described previously. TCP is a connection (point to point) oriented, reliable, byte stream service. TCP is where all error protection and flow control is carried out. The main document for TCP is RFC 793. With additional information in RFC 896, 1122, 1323 and 2018.

Traditionally, error and flow control in telecommunications was handled at the lower layers. It was recently discovered that low layer error handling is not as effective as higher layer handling. This is one of the reasons why the layers below TCP do no need to provide any form of error or flow management.

 

In UDP, stations just shoot packets at each other. TCP requires the two stations to establish a ‘connection’ first. Once the connection is established, data can flow from one station to the other. Opening a connection is done by sending specially flagged segments (in TCP, a packet or unit of information is called a segment) that are used to synchronise counters and timers at either end. 

TCP requires all data to be acknowledged. Rather than acknowledging each segment individually, TCP uses a pointer scheme where the receiver acknowledges the position of the index or pointer of the last reliable block of data received. Each segment thus carries a block of data plus an index pointer into an imaginary array of bytes, that is, where the data block belongs in the array.

This scheme is very convenient as it allows segments to arrive out of order. There is no need to acknowledge every segment received, a single ack can be sent for more than one transmission segment received. Both transmitter and receiver also operate a ‘data window’ scheme telling a transmitter how many more bytes the receiver is willing to accept, this provides a form of data flow control.

By constant adjustment of the windows and delays, TCP can be tuned to provide an efficient flow mechanism tuned to a particular channel's characteristics. In such a channel, the transmission line is nearly constantly active all the time, with very few ACKs sent back. You could see efficient and inefficient TCP in action by observing the TX and RX lights on a modem. Inefficient TCP is when both TX and RX flash or flicker in opposition, with periods of no activity in between. Efficient TCP is when the RX light is nearly constantly on (denoting a nearly constant flow) with the occasional flicker of the TX ‘ACK’ light.

The standard software method uses a state transition table, linking ‘actions’ with ‘states’ and ‘events’, plus a data control block to store all variables for each particular connection (a.k.a. socket). In normal practice a server (or listener) opens a new thread for every open connection request received from a client, this thread is maintained until the connection is closed. The state table is described in detail in RFC 793.

Implementing the full set of TCP requirements in an embedded system is not trivial. Including each and every combination of events, states and actions will readily inflate the program and data memory space already at short space in a micro. In addition, threads are not easily implemented in the smaller devices. Fortunately, some simplifications can be made by taking a number of assumptions, for example, long-term connection coherence and resilience to repeated and/or missing data. Depending on the use it is put to, it is perfectly possible to implement a perfectly workable ‘lite’ version of TCP in an embedded processor.

TELNET,  HTTP, FTP SMTP et al

These are higher level Application Protocols. They were designed for specific end-to-end purposes (e.g. FTP for file transfer, SMTP for mail, HTTP for web access) and have one thing in common. They work by sending and receiving streams of bytes (usually ASCII characters) down an already opened TCP connection.

In terms of implementation, these are relatively simple. One just needs to generate the right sequence of characters (maybe even using a BASIC-like program), as long as there is an existing TCP open channel into which one could pipe the characters. Implementing a simple web server is nothing more than a program that receives an ASCII serial stream, senses for special character sequences, and sends back another sequence of characters.


BenBus-RS485-protocol
can be found behind this link.