This example is part of the "Ethernet Throughput in NXP's Microcontrollers" article.
The goal is to measure an estimated Ethernet throughput, and compare different scenarios
in order to understand the factors that influence ethernet performance.

Scenario 1 - "Ideal" scenario:
In this case, the test sets up the descriptors' data buffers with the test's pattern, and only the 
TxProduceIndex is incremented 50 times (each for every packet to send) in order to trigger the frame 
transmission. In other words, the application is not considered at all, and even when this is not a 
typical user's case, it will provide the maximum possible Throughput in transmission. 

Scenario 2 - "Typical" scenario:
This case represents the typical case in which the application will copy the data into the descriptors
data buffers before sending the frame. Comparing the results of this case with the previous one, we can 
see how the application is affecting the overall performance. This case should not be considered as the 
actual EMAC Throughput. However, we are considering it here just to show how non-optimized applications 
may lower overall results giving the impression that the hardware is too slow.

Scenario 3 - "Optimized" scenario:  
This test uses DMA in order to copy the application's data into the descriptors' data buffers. This case 
considers a real application but using optimized methods which effectively take the advantage of the 
fast hardware. 

Tests Conditions:

MCU:  LPC1768 running at 100MHz
Board:  Keil MCB1700
PHY chip:  National DP83848 (RMII interface)
Tool Chain: Keil uVision 4 v4.1

Code running from RAM
TxDescriptorNumber = 3
Ethernet mode:  Full Duplex - 100Mbps

Test Description:

In order to get the maximum Throughput, we are sending 50 frames of 1500 bytes each one, consisting on 75Kbytes 
of payload (useful data). In order to measure the time this process takes, we are setting a GPIO pin (P0.0) just before 
starting sending the frames and we are clearing this pin as soon as we finish with the process. In this way, 
using a scope, we can measure the time as the width of the generated pulse at the P0.0 pin. We are connecting 
the board with a PC using an Ethernet cross cable. The PC runs a sniffer program as a way to verify if the 
50 frames were sent and the data is correct. We use a specific pattern in the payload so it can be easily 
recognized if there is any error. In case the 50 frames arrived at the PC with no errors, the test is considered valid.

Example Configuration:
In file "config.h" configure (using Configuration Wizard) the desired scenario.
Optionally, the number of frames to send and the frame size can also be modified from this file.
