|
|
The demo presented on this page uses:
FreeRTOS has made some modifications to the uIP stack since this demo was created. See the Embedded Ethernet Examples List page for more information.
The FreeRTOS Cortex M3 port includes a full interrupt nesting model. Interrupt priorities must be set in accordance with the instructions on the Customisation page for correct operation.
See also the FAQ My application does not run, what could be wrong?
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.
Connect the STM3210C evaluation board to a computer running a web browser either directly using a point to point (crossover) cable, or via an Ethernet switch using a standard Ethernet cable.
The IP address used by the demo is set by the constants configIP_ADDR0 to configIP_ADDR3 within the file FreeRTOS/Demo/CORTEX_STM32F107_GCC_Rowley/FreeRTOSConfig.h. The MAC address and net mask are configured within the same header file.
The IP addresses used by the web browser computer and the STM32 development 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 development 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).
During its initialisation, the demo application accesses IO port configuration from within more than one task. This raises the possibility of problems related to re-entrancy (or lack of it). No attempt is made to guard against this. If this proves problematic then place the initialisation library calls inside critical sections.
The LCD driver uses a polled SPI interface. Currently the LCD gatekeeper task is configured to execute at a medium priority - resulting in lower priority tasks not getting any processing time while the SPI interface is being polled. The task can be configured to execute at the lowest priority, but this results in visibly slower LCD updates. A much more efficient solution would be to re-implement the driver to make use of the DMA and be event driven.
The following tasks and tests are created in addition to the standard demo tasks:
A 20KHz periodic interrupt is generated using a timer to demonstrate the use of the 'configKERNEL_INTERRUPT_PRIORITY' and 'configMAX_SYSCALL_INTERRUPT_PRIORITY' configuration constants. 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 LCD 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 kernel can be configured so as to have no impact on higher priority interrupt processing.
The 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 about 8 clock cycles.
The LCD task is a 'gatekeeper' task. It is the only task that is permitted to access the LCD directly. Other tasks or interrupts wishing to write a message to the LCD send the message on a queue to the LCD task instead of accessing the LCD themselves. The LCD task just blocks on the queue waiting for messages - waking and displaying the messages as they arrive.
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 be discovered within a standard demo task the 'check' function will write an error to the LCD (via the LCD task). If all the demo tasks are executing with their expected behaviour then the check task writes PASS and the maximum measured jitter time in nano seconds to the LCD (again via the LCD task). The jitter time is measured within the high priority interrupt test as described above.
The check function executes within the context of an interrupt service routine so is a good example of how using a gatekeeper task to control the LCD permits even interrupts to output LCD messages.
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 served RTOS stats page showing status information on each task in the system. |
 The served run time stats page showing the processor utilisation of each task. |
The IO page provides a simple interface that permits data to be sent to LED 4 and LCD on the development board.
The check box permits the state of LED 4 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.
The TCP Stats and Connections pages display run time networking information.
This sets the frequency of the RTOS tick. The supplied value of 1000Hz is useful for testing the kernel functionality but is faster than most applications require. Lowering this value will improve efficiency.
See the kernel configuration documentation for full information on these configuration constants.
The lowest priority on a Cortex M3 core is in fact 255 - however different 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 'portBASE_TYPE' to equal the most efficient data type for that processor. This port defines portBASE_TYPE to be of type long.
Note that vPortEndScheduler() has not been implemented.
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. An example interrupt service routine called vMAC_ISR() is provided in FreeRTOS/Demo/CORTEX_STM32F107_GCC_Rowley/webserver/emac.c. This should be used as a reference example.
Note that portEND_SWITCHING_ISR() will leave interrupts enabled.
