 |
The LM3S6965 and LM3S8962 demos creates (amongst other tasks) a simple WEB server that can be used to both view run time information, and write data to the LED and OLED display on the EVB-LM3S6965/EVB-LM3S8962 evaluation board.
Click to see live WEB pages served from an LM3S6965 Cortex-M3 microcontroller.
[A non standard port number is used which may be blocked by some proxy servers and fire walls.]
There is a separate documentation page describing how to build and debug the GCC version of this demo using the Eclipse Workbench and OpenOCD. Both of these tools are open source.
The demo uses:
The V4.3.0 version of the IAR Cortex M3 port introduced the configKERNEL_INTERRUPT_PRIORITY configuration parameter. This parameter permits the interrupt priority used by the kernel to be configured such that the kernel activity will never delay a higher priority interrupt. See the Configuration and Usage section of this page for more information.
From FreeRTOS.org V4.7.1 all IAR projects for ARM devices are saved using the IAR Embedded Workbench V5.x format and will not open from V4.x versions. FreeRTOS.org V4.7.0 and earlier are still available from SourceForge and can be used with Embedded Workbench V4.x.
Upgrading to FreeRTOS.org V4.8.0: Prior to V4.8.0 the FreeRTOS.org 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.org 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:
See also the FAQ My application does not run, what could be wrong?
IAR project files
Keil uVision project files
Connect the EVB-LM3S6965 or EVB-LM3S8962 development 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_IAR_Keil/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 evaluation kits read their MAC address from their internal memory, removing the need for this to be manually configured.
The demo application uses the LED and OLED display built onto the prototyping board so no other hardware setup is required.
The EVB-LM3S6965 / EVB-LM3S8962 is powered, programmed and debugged through the single micro USB connector. You will be prompted to install various USB drivers the first time a USB connection is made between the evaluation board and a PC. The required USB drivers can be obtained from the Luminary Micro CD, or from the Luminary Micro WEB site.
The LM3S2965 and LM3S1968 demos do not require any specific configuration.
The project includes a bitmap that is built into the binary. This increases the binary size and at some optimisation levels will take the build size above the 32K limit of the Embedded Workbench Kickstart edition. If this becomes an issue then the code size can be reduced by excluding the bitmap from the build (by removing the inclusion of the header file bitmap.h within main, and comment out the call to OSRAM128x64x4ImageDraw() within the same file).
The demo application is too large to be built using the uVision evaluation software, therefore a licensed copy is required.
The IAR demo was adapted for use with the Keil development tools by Luminary Micro (thanks guys!) and I am unable to test the port myself. The FreeRTOS.org port itself is identical to that used for pre-existing Keil/Cortex-M3 demos.
The following tasks and tests are created in addition to the standard demo tasks:
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 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 8 clock cycles.
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.
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.
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 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 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.
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.
This sets the interrupt priority used by the kernel. The kernel should use a low interrupt priority (high numeric value), allowing higher priority interrupts to be unaffected by the kernel entering critical sections. Instead of critical sections globally disabling interrupts, they only disable interrupts that are below the kernel interrupt priority.
This permits very flexible interrupt handling:
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.
Note that portEND_SWITCHING_ISR() will leave interrupts enabled.