Do 8051 MCUs really have the power for Ethernet?

This article compares data transmission rates on an Ethernet network for embedded systems based on 8051 and ARM7 microcontrollers.

This article looks at data transmission rates, over an Ethernet network, of one 8bit and one 32bit general purpose embedded system that are as similar as possible in all components other than the microcontroller itself.

The test performed is not an attempt to measure the maximum possible transmission rate.

It instead attempts to give a general idea as to the figures that could be achieved in real systems.

The transmission results are to be used to draw conclusions as to the practical uses for each system.

It does not cover the technicalities of Ethernet communication itself.

Over the past few years, there has been a market need to provide Ethernet network connectivity on embedded systems.

Used here: "embedded systems" is a term to cover a whole range of devices used in industrial and commercial environments, for example: instruments to measure quantities such as temperature and flow rate; information display systems; and ticketing systems.

To operate as a node on an Ethernet network, a system needs a physical connection, an Ethernet controller chip, and, software wise, a driver for the Ethernet controller and a TCP/IP protocol stack.

With 8bit microcontrollers nowadays containing tens of kilobytes of program memory, 8051 type microcontrollers are still commonly used in embedded systems.

This memory capacity also enables a TCP/IP stack to be implemented in software.

However, the processing power needed to run TCP is not inconsiderable.

It could be interesting to know what kind of actual data transmission rates can be achieved over an Ethernet network, from an embedded system based on an 8051 microcontroller.

This article presents figures for an 8051 based system, and for comparison, an ARM7 based system.

The 8051 system used for this test has an Atmel AT89C51ED2 microcontroller running at 22.1184MHz.

It has 64Kbyte of program memory, and 1792byte of RAM.

The ARM7 system has a Philips LPC2129 microcontroller running at 58.982400MHz via the on-chip phase-locked loop.

It has 256Kbyte of program memory, and 16Kbyte of RAM.

Both systems have the same 10Base-T, Cirrus Logic CS8900A Ethernet controller chip, with an identical device driver, running an identical TCP/IP stack.

A small application, again, identical on both systems, sits on top of the stack, and composes and sends application data, as described below.

The stack, device driver and application were all written entirely in C, with minimal porting required to compile the entire software for each system.

Each embedded system was, in turn, connected to a small 10/100Mbit/s Ethernet network via a D-Link router.

A simple application was written using Visual C++ for a Windows based PC.

The PC application used the sockets API to send and receive data on the network.

Operating as a client, the PC application had a button on its GUI to open a TCP connection with the embedded system.

Once a connection was established, text could be typed into an edit window, and sent to the remote, embedded system.

The text string "" was used as a trigger on the embedded system to initiate a series of data transfers to the client.

The embedded system, operating as a server, would listen for a TCP connection from a client.

Once a connection was established, it would evaluate any application data received, looking for the trigger "".

On receipt of the trigger, it would perform the test, which consisted of 100 iterations of the following sequence: write 1460byte of data into a buffer; send n bytes of data from the buffer to the TCP; and wait for a TCP acknowledgement from the receiving TCP.

Three tests were performed, where the number of bytes sent (n) was 1460, 750 and 100.

(1460byte is the maximum application data length of an Ethernet frame).

The scope calls for figures that could be achieved in real systems.

Real systems tend to do some work between sending or receiving data.

The work done by these systems was to write 1460byte (note - 1460, never 750 or 100) into a buffer.

The PC application performed a rudimentary check on the application data that it received, and printed the count of each one-hundredth data packet received onto its edit window.

The TCP connection could be closed manually by pressing a button on the GUI of the PC application.

Using Ethereal (a network monitoring tool), the time taken from the trigger string being transmitted from the application, to the 100th frame being acknowledged, was recorded for the results.

It should be noted here that the TCP on the PC application was not using delayed acknowledgements.

The bytes-per-second figure is for application data bytes only.

It does not include the extra 58byte per frame of header and CRC data.

The elapsed time for the acknowledgement for each frame was, on average, 155us.

For the 8051 system, with an application data length of 1460byte the test time for 100 frames was 30.51s, giving an application data transmission rate of 4785byte/s and 3.28 frames per second.

With an application data length of 750byte, the test time for 100 frames was 20.61s, giving an application data transmission rate of 3639byte/s and 4.85 frames per second.

With an application data length of 100byte, the test time for 100 frames was 11.56s, giving an application data transmission rate of 865byte/s and 8.65 frames per second.

For the ARM7 system, with an application data length of 1460byte the test time for 100 frames was 2.30s, giving an application data transmission rate of 63478byte/s and 43.48 frames per second.

With an application data length of 750byte, the test time for 100 frames was 1.32s, giving an application data transmission rate of 56818byte/s and 75.76 frames per second.

With an application data length of 100byte, the test time for 100 frames was 0.45s, giving an application data transmission rate of 22222byte/s and 222.22 frames per second.

Aside from the microcontroller itself, the hardware and software constituent parts of the two embedded systems were remarkably similar.

The output quality of the respective compiler for each system needs to be considered.

The author has no way to quantify that, but has no reason to suspect that one compiler is good, whereas the other is poor.

It can be concluded then, that the vastly superior data transmission rate of the ARM7 system can be put down solely to its extra processing power.

So, can an 8051 microcontroller be used in practice to host Ethernet-enabled embedded systems?.

Referring back to the example embedded systems, a device to measure temperature would probably need to transfer only a hundred or so bytes of data per minute.

A display system would be receiving rather than transmitting data, and a ticketing system may need to transmit and receive in equal measure, but both of them could also have low data throughput requirements.

So, working on the basis that data can be received at a similar rate as it can be transmitted, an 8051 microcontroller could be considered for implementing these three example systems with Ethernet connectivity.

If the requirements for an embedded system without an Ethernet connection can be easily met by implementing the system on an 8051 microcontroller, the data throughput requirements are low, and there is sufficient spare memory to host a TCP/IP stack, the move to an ARM based system is probably not needed.

It should be noted here that the author has no vested interest in promoting 8051 over ARM based systems.

The scope of this article does not call for a technical description of any of the constituent parts of the embedded systems, nor is it meant to compare one TCP/IP implementation over another.

But, it is worth suggesting how the result for the 8051 system could be improved.

The TCP/IP stack used for the test generates checksums for all transmitted frames (which is compulsory), and checks checksums for all received frames (which is optional).

The checksum calculations involve extensive summing of 32bit numbers, which is done in C.

By rewriting the checksum routines in assembly for the 8bit, 8051 microcontroller, the data throughput rates on the 8051 system would improve significantly.

The author would not expect such assembly routines to produce any significant improvements on the ARM system.

The transport protocol used for this test was TCP.

TCP provides a reliable transmission of data between two nodes on a network.

UDP, on the other hand, simply sends data to a destination node, without any guarantee that it arrives.

Thus, higher throughput rates can be achieved using UDP.

For systems where the data throughput requirements are high, and no one is going to die if the odd frame is lost, UDP is used instead of TCP.

An example is voice over IP (VoIP).

One standard codec used for VoIP is G.711.

Each frame has an application data size of 120byte, and, for duplex operation, a requirement of 132 frames per second.

Thus, the raw data throughput rate, for both transmitting and receiving, is 15840byte/s.

From the results, it can be interpolated that the data throughput requirements for VoIP, for this codec, could be implemented on the ARM7 system.

However, even with the higher throughput rate of UDP, and with checksum routines written in assembly, it is unlikely that this requirement could be met on the 8051 system.

Back to top