FreeRTOS Stellaris Web Server Demo
Using Eclipse, OpenOCD and GCC for a completely
open source development environment
[Embedded Ethernet Examples]
The demo described by this page uses…
- Eclipse Europa,
- CodeSourcery G++ Lite ARM EABI GCC development tools, and
- uIP (mini TCP/IP stack)
- The luminary micro evaluation kit for either the LM3S8962, LM3S6965, LM3S2965 or LM3S1968 ARM Cortex-M3 based microcontrollers.
FreeRTOS has made some modifications to the uIP stack since this demo was created. See the Embedded Ethernet Examples List page for more information.
Tested on the following evaluation kits (ethernet is only available on the LM3S6965 and LM3S8962):
The Europa version of Eclipse includes enhancements that facilitate cross development.
The FreeRTOS zip file contains everything required to setup the development environment, other than the Eclipse and GCC tools themselves. Please follow these instructions carefully to install and configure Eclipse correctly for use with this demo application.
The Luminary Micro evaluation kits connect directly to the host PC via a micro USB cable, removing the requirement for a separate JTAG interface device. This USB connection is used to power, program and debug the microcontroller.
Although all the tools used are cross platform – I have only tested the ARM Cortex-M3/Eclipse build on a windows host.
Upgrading to FreeRTOS V5.0.3: FreeRTOS V5.0.3 introduced the configMAX_SYSCALL_INTERRUPT_PRIORITY configuration option to the ARM Cortex-M3 port. See the RTOS kernel configuration documentation for full information on this feature.
Upgrading to FreeRTOS V4.8.0: Prior to V4.8.0 the FreeRTOS kernel did not make use of the SVCall interrupt. From V4.8.0 onwards it does. Therefore, to upgrade an older project to the V4.8.0 standard, a small edit to the startup code is required. To do this, simply install vPortSVCHandler() in the SVCall position within the interrupt vector table (contained in the startup source file). The demo projects included in the FreeRTOS download have already been updated so these can be used as an example.
Note for LM3S2965 and LM3S6965 users: The display part number changed on REV C evaluation kit boards. If you are using a REV C board then:
- In the project or makefile, delete the reference to osram128x64x4.c and replace it with rit128x96x4.c. rit128x96x4.c and rit128x96x4.h can be located within the FreeRTOS download as they are already used for other projects.
- In main.c, within the case statement at the top of the vOLEDTask() function, ensure the LM3S2965 and LM3S6965 use the rit128x96x4 driver, as per the other devices initialised within the same case statement.
IMPORTANT! Notes on using the Stellaris Web Server DemoPlease read all the following points before using this RTOS port.
My application does not run, what could be wrong?
Source Code OrganisationThe Eclipse workspace for the Eclipse Stellaris demo is located in the FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse directory. This is the directory to select when prompted for a workspace location during the Eclipse startup process. Be sure to read the Eclipse installation and configuration instructions prior to building the project.
The FreeRTOS zip file download contains the files for all the ports and demo application projects. It therefore contains many more files than used by this demo. See the Source Code Organization section for a description of the downloaded files and information on creating a new project.
The Demo Application
Demo application setupNote the comments at the head of this page regarding the selection of the correct display driver.
Connect the Stellaris evaluation board to a computer running a web browser either directly using a point to point (crossover) cable, or via a hub/router using a standard Ethernet cable. The prototyping board may also allow the use of a standard Ethernet cable when connecting point to point, but I have not tried this configuration.
The IP address used by the demo is set by the constants uipIP_ADDR0 to uipIP_ADDR3 within the file FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/webserver/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).
Each evaluation kit is pre-programmed with a unique MAC address, removing the requirement for this to be manually configured.
The demo application uses the LED and OLED display built onto the evaluation board so no other hardware setup is required.
Building the demo applicationAgain – please refer to the Eclipse installation and configuration instructions for more detailed information.
- Ensure the ARM EABI Lite version of the Code Sourcery G++ development tools is installed, and that the [install path]/CodeSourcery/Sourcery G++ Lite/bin directory is included within your PATH environment variable.
- Open the FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse Eclipse workspace from within the Eclipse Workbench.
- Ensure the FreeRTOS_ROOT variable has been configured.
- Press F7 (or select “Build All” from the “Project” menu) to build the demo application.
Running the demo applicationOnce again – please refer to the Eclipse installation and configuration instructions for more detailed information.
- Connect the Stellaris evaluation kit to your host PC using a USB cable. If this is the first time the kit has been connected then you will be prompted to install 3 USB drivers. The correct drivers are included on the Luminary Micro CD that came with the kit, alternatively they can be downloaded from the Luminary Micro website.
- Ensure an Ethernet cable is connected as described above.
- Select “OpenOCD Programmer” from the “Run | External Tools” menu – then wait for the programming to complete.
- Select “OpenOCD Server” from the “Run | External Tools” menu.
- Switch to the debugging perspective.
- Select the OpenOCD server executable within the Debug pane.
- Click the “Debug RTOSDemo” speed button (the one with the little green bug icon).
FunctionalityThe demo application creates 20 persistent tasks, and periodically dynamically creates and destroys another 2. These tasks consist predominantly of the standard demo application tasks (see the demo application section for details of the individual tasks).
The following tasks and tests are created in addition to the standard demo tasks:
- High priority interrupt test
A high frequency periodic interrupt is generated using a free running timer to demonstrate the use of the configKERNEL_INTERRUPT_PRIORITY configuration constant. The interrupt service routine measures the number of processor clocks that occur between each interrupt – and in so doing measures the jitter in the interrupt timing. The maximum measured jitter time is latched in the ulMaxJitter variable, and displayed on the OLED display by the ‘Check’ task as described below. The fast interrupt is configured and handled in the timertest.c source file. This demonstrates how the RTOS kernel can be configured so as to have no impact on higher priority interrupt processing.
The ARM Cortex-M3 core has the ability to hasten the entry into an interrupt service routine (and therefore reduce latency) by up to 8 cycles should a high priority interrupt occur while a lower priority interrupt is already being serviced. The measured jitter time should therefore be no more than 8 clock cycles.
- OLED task
The OLED task is a ‘gatekeeper’ task. It is the only task that is permitted to access the display directly. Other tasks wishing to write a message to the OLED send the message on a queue to the OLED task instead of accessing the OLED themselves. The OLED task just blocks on the queue waiting for messages – waking and displaying the messages as they arrive.
- Check function – called from the tick hook
This only executes every five seconds. Its main function is to check that all the standard demo tasks are still operational. Should any unexpected behaviour within a demo task be discovered the ‘check’ function will write an error to the OLED (via the OLED task). If all the demo tasks are executing with their expected behaviour then the check task writes PASS along with the max jitter time to the OLED (again via the OLED task), as described above.
- uIP task (LM3S6965 and LM3S8962 kits only)
This is the task that handles the uIP stack. All TCP/IP processing is performed in this task.
When executing correctly the demo application will behave as follows:
- The ‘check’ function will write “PASS” and the jitter time in nanoseconds to the display every 5 seconds.
- The target hardware will serve the web pages described below to a standard web browser (LM3S6965 and LM3S8962 kits only). To connect to the target:
- Open a web browser on the connected computer.
- Type “HTTP://” followed by the target IP address into the browsers address bar.
Entering the IP address into the web browser
(obviously use the correct IP address for your system)
Served Web Pages (LM3S6965 and LM3S8962 kits only)The top of each served page includes a menu containing a link to every other page.
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 served IO page
The IO page provides a simple interface that permits data to be sent to the LED and OLED display on the development board.
The check box permits the state of the user LED to be set and queried. The text box can be used to write a message to the OLED display, but does not query the text currently being display. Changes are sent to the target hardware by clicking the “Update IO” button.
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.
RTOS port specific configurationConfiguration items specific to these demos are contained in FreeRTOS/Demo/CORTEX_LM3Sxxxx_Eclipse/RTOSDemo/FreeRTOSConfig.h. The constants defined in this file can be edited to suit your application. In particular –
This sets the frequency of the RTOS tick. The supplied value of 1000Hz is useful for testing the RTOS kernel functionality but is faster than most applications require. Lowering this value will improve efficiency.
- configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY
See the RTOS kernel configuration documentation for full information on these configuration constants.
Attention please!: Remember that ARM Cortex-M3 cores use numerically low priority numbers to represent HIGH priority interrupts, which can seem counter-intuitive and is easy to forget! If you wish to assign an interrupt a low priority do NOT assign it a priority of 0 (or other low numeric value) as this can result in the interrupt actually having the highest priority in the system – and therefore potentially make your system crash if this priority is above configMAX_SYSCALL_INTERRUPT_PRIORITY.
The lowest priority on a ARM Cortex-M3 core is in fact 255 – however different ARM Cortex-M3 vendors implement a different number of priority bits and supply library functions that expect priorities to be specified in different ways. Use the supplied examples as a reference.
Each port #defines ‘BaseType_t’ to equal the most efficient data type for that processor. This port defines BaseType_t to be of type long.
Note that vPortEndScheduler() has not been implemented.
Interrupt service routinesIn the demo application the vector table remains in flash.
Unlike most ports, interrupt service routines that cause a context switch have no special requirements and can be written as per the compiler documentation. The macro portEND_SWITCHING_ISR() can be used to request a context switch from within an ISR.
Note that portEND_SWITCHING_ISR() will leave interrupts enabled.