 STR750 Evaluation Board
|
|
STR750 Evaluation Board
|
This STR750 ARM7 demo application is pre-configured for execution on the STR750 EVAL evaluation board from ST Microelectronics (instructions are provided should you wish to use an alternative development board).
The RTOS port and demo application presented on this page require the Raisonance RIDE IDE interface to the GNUARM GCC toolchain. An RLink In-circuit debugger and programmer is required to program the microcontroller flash directly from the RIDE IDE.
The processor peripheral library provided by ST was used to facilitate development.
As downloaded this demo application does not demonstrate the use of co-routines. See the co-routine documentation page for information on how co-routine functionality can be quickly added to this demonstration.
See also the FAQ My application does not run, what could be wrong?
The demo RIDE project included for the STR75x GCC ARM7 port is called RTOSDemo.prj and can be found in the Demo/ARM7_STR75x_GCC directory. This file should be opened directly from within the RIDE IDE.
The Demo/ARM7_STR75x_GCC/ST library directory contains the components of the ST peripheral library that are used by the demo application.
The standard 'ComTest' tasks send and receive characters on UART0. The characters sent by one task need to be received by the another - an error being flagged if a character is received out of sequence or missed all together. A loopback connector is required on UART0 of the evaluation board for this functionality to operate (simply connect pins 2 and 3 together on the serial port connector labelled CN4).
The demo application utilises the LEDs built onto the evaluation board so no further hardware setup is required.
The project contains 4 folders:
IMPORTANT NOTE: The startup files and linker scripts utilised by this project have been modified from those contained in the Raisonance RIDE distribution. Only the files contained in the Demo/ARM7_STR75X_GCC/SystemFiles directory should be used.
The two files serialISR.c and portISR.c contain interrupt service routines and therefore must be compiled into ARM mode. All other files will be compiled into THUMB mode.
IMPORTANT NOTE: To achieve this the project options applied to serialISR.c and portISR.c are different from those applied to all other files. If you edit the global project project options (using the 'Options' | 'Project' menu option) then the special options applied to these two files will be lost and must be reset manually. Failure to do this will prevent the project from building.
To ensure portISR.c and serialISR.c are compiled into ARM mode:
The 'print' task is the LCD 'gatekeeper'. That is, it is the only task that should access the LCD directly so is always guaranteed exclusive (and therefore consistent) access. The print task simply blocks on a queue to wait for messages from other tasks that wish to display text on the LCD. An arriving message unblocks the task, which writes the message contents to the LCD, before blocking once again. This functionality is included for demonstration purposes even though in this application there is actually only one task that generates display text.
The 'check' task is responsible for ensuring that all the standard demo tasks are executing as expected. It only executes every three 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 'print' task for display on the LCD.
When executing correctly the demo application will behave as follows:
"Pass" being displayed on the LCD indicates that the check task has never detected an error occurring in any task. The position of the text is shifted slightly each time it is displayed to provide a visual indication that the check task itself is still executing. The error detection mechanism can be tested by removing the loopback connector from the serial port while the demo is running, following which the "Pass" message should change to "Fail".
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.
An interrupt service routine must be written as an ARM mode C function.
For example:
void vAnISR( void )
{
/* ISR C code goes here. */
/* Clear the interrupt within the peripheral here. */
}
Often you will require an interrupt service routine to cause a context switch. For example a serial port character being
received may wake a high priority task that was blocked waiting for the character. If the ISR interrupted a lower priority
task then it should return immediately to the woken task. This can be performed by simply calling the macro portEND_SWITCHING_ISR() from
within the service routine, as demonstrated below:
void vAnISR( void )
{
/* ISR C code goes here. */
/* Clear the interrupt within the peripheral here. */
/* Pass in true to cause a context switch, or false to return
to the interrupted task. */
portEND_SWITCHING_ISR( pdTRUE );
}
See the function vSerialISR() within Demo/ARM7_STR75x_GCC/serial/serialISR.c for a complete example.
User defined interrupt routines must replace the ST provided stubs within Demo/ARM7_STR75x_GCC/SystemFiles/ctr0_str75x_FreeRTOS.s.
NOTE! : The processor MUST be in supervisor mode when the scheduler is started (vTaskStartScheduler is called). The demo applications included in the FreeRTOS.org download switch to supervisor mode prior to main being called. If you are not using one of these demo application projects then ensure Supervisor mode is entered before calling vTaskStartScheduler().
The stack size of each necessary operating mode is configured using constants defined within Demo/ARM7_STR75x_GCC/SystemFiles/STR75x_COMMON_FreeRTOS.ld. It is not necessary to configure a stack for User/System mode.
SWI instructions are used by the real time kernel and can therefore not be used by the application code.
Copyright (C) 2003 - 2008 Richard Barry
Any and all data, files, source code, html content and documentation included in the FreeRTOS.org distribution or available on this site are the exclusive property of Richard Barry.
See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Richard Barry.
