|
Please note: Due to problems in some LPC2368 devices the MAM (memory accelerator) mode must be set to zero in order for this demo to execute correctly.
This page describes the FreeRTOS.org uIP demo running on the NXP LPC2368 ARM7 microcontroller. The demo creates a simple WEB server that can be used to both view run time information, and write data to the LEDs and LCD display on the target hardware.
The demo uses:
An alternative demo targeted at the LPC2378 using the HiTOP development tools is available from Hitex.
See also the FAQ My application does not run, what could be wrong?
The CrossWorks solution (workspace) for the LPC2368 demo is located in the FreeRTOS/Demo/ARM7_LPC2368_ROWLEY directory.
The IP address used by the demo is set by the constants uipIP_ADDR0 to uipIP_ADDR3 within the file FreeRTOS/Demo/ARM7_LPC2368_Rowley/uIP_Task.c. The IP addresses used by the WEB browser computer and the prototyping board must be compatible. This can be ensured by making the first three octets of both IP addresses identical. For example, if the WEB browser computer uses IP address 192.168.100.1, then the prototyping board can be given any address in the range 192.168.100.2 to 192.168.100.254 (barring any addresses already present on the network).
The constants uipMAC_ADDR0 to uipMAC_ADDR5 within the same file define the MAC address used by the target hardware. You must ensure that the configured MAC address is unique on the network to which the prototyping board is being connected.
The demo application uses the LEDs and LCD built onto the prototyping board so no other hardware setup is required.
The following tasks are created in addition to the standard demo tasks:
This task handles all the network processing. It will spend most of its time blocked on a semaphore - waiting to be woken by interrupts generated by incoming network packets.
This is a 'gatekeeper' task. It is the only task that is permitted to write to the LCD, thus ensuring consistent access. Other tasks wishing to write to the LCD send the string to be displayed to the LCD task rather than accessing the LCD directly.
The 'check' task is responsible for ensuring that all the standard demo tasks are executing as expected. It only executes every five seconds, but has the highest priority within the system so is guaranteed to get execution time. Any errors discovered by the check task are latched until the processor is reset. At the end of each cycle the check task sends either a pass or fail message to the 'LCD' task for display on the LCD.
When executing correctly the demo application will behave as follows:
 The served RTOS stats page |
The RTOS stats page provides run time information on the state of each task within the system - including the stack high water mark (the minimum amount of stack there has been available at any time since the task started executing). The page will reload approximately every two seconds - depending on network load.
This page is transmitted in three sections - the HTML header and menu, the dynamically generated content, then finally the HTML footer. This makes the page relatively fast to load. It could be optimised further by transmitting the entire page in one go.
The continuous reloading can sometimes make navigating away from the RTOS stats page a little tricky.
The IO page provides a simple interface that permits data to be sent to the LEDs and LCD on the MCB2300 development board.
The three check boxes permit the state of the LEDs on outputs P2.5, P2.6 and P2.7 to be set and queried. The text box can be used to write a message to the LCD, but does not query the text currently being display. Changes are sent to the target hardware by clicking the "Update IO" button.
Note that the 'check' task updates the display every 5 seconds, so any text sent from a WEB client will soon be overwritten.
The TCP Stats and Connections pages display run time networking information. Note that these pages transmit each line individually so will not load quickly. This demonstrates how memory usage can be optimised through the use of a small transmit buffer by sacrificing the achieved data throughput.
