|
|||||||||||||||
Tern E-Engine 80x186 RTOS port
|
|||||||||||||||
|
The demo application creates twenty five tasks - consisting predominantly of the standard demo application tasks (see the
demo application section for details of the individual tasks).
In addition a further four tasks are repeatedly dynamically created and deleted (by the standard "death" demo).
When executing correctly the demo application will serve the web page shown on the left. The page will automatically refresh every second. The table lists each task under control of the RTOS scheduler, along with the tasks:
The count of the number of idle task execution loops originates from the idle task hook, which is defined in HTTPTask.c. The tick count should increment at the rate specified by the configTICK_RATE_HZ constant, defined in FreeRTOSConfig.h. Finally, main() also creates a "check" task. The check task monitors all the other tasks in the system. If the check task discovers a potential error in any other task a red error message will be displayed. If no errors have ever been detected "No errors detected" is displayed. This mechanism can be tested by removing the loopback connector on COM2, and in so doing deliberately generating an error. |
Configuration and Usage Details
HTML Pages
As downloaded only a single dynamically generated page is returned, as hard coded within HTTPTask.c. However, the Tern development kit includes a compact flash driver for the E-Engine controller which could easily be integrated into the RTOS demo. This would allow standard HTML pages to be created and written to a flash card from a Windows host, then served from the E-Engine controller. In addition, the FreeRTOS download includes the uIP source code. uIP includes a very simple cgi type function that permits pages that include dynamic data to be easily created.FreeRTOS has made some modifications to the uIP stack since this demo was created. See the Embedded Ethernet Examples List page for more information.
Task status table
The table displayed on the served web page is interesting for demonstration purposes, but as it is necessary to leave the RTOS scheduler disabled for an extended period during its creation it is not recommended for use in production applications.
Interrupt service routines
For simplicity the RTOS scheduler context switching mechanism relies on the compiler generated interrupt service routine prologue and epilogue code. It is therefore essential that each ISR that can cause a context switch has identical entry and exit code. As a result of this an ISR that can cause a context switch cannot define any stack variables directly in the ISR function. A simple way around this is to have the top level ISR function call another lower level function, for example:
/* This is the lower level function called from the top level
ISR function. */
int iCalledFunction( void )
{
/* Variables can be declared here. */
int iSwitchRequired = false;
/* ... ISR code goes here ... */
/* Assume the ISR code necessitates a context switch. */
iSwitchRequired = true;
return iSwitchRequired;
}
/* This is the top level function in which variables cannot be
declared on the stack. This is the function installed on the
vector. */
void __interrupt prvISRFunction( void )
{
/* Variables cannot be declared here! */
/* Call the lower level function to do the work. */
if( iCalledFunction() )
{
/* If the called function necessitates a context switch
then call portEND_SWITCHING_ISR() immediately prior to
exiting. */
portEND_SWITCHING_ISR();
}
}
This mechanism is demonstrated by the serial port and WIZnet drivers included in the E-Engine demo application.
Declaring variables used by the ISR as static would probably have the same effect.
Interrupt service routines that do not cause a context switch have no special requirements.
i2Chip Driver
The i2chip driver included in the download is a slightly modified version of the driver supplied by Tern Inc (the modification being the inclusion of the semaphore in the interrupt service routine used to unblock the HTTPTask). This driver was not written for a multitasking system and is therefore not optimised for use with FreeRTOS.org. Efficiency gains could be obtained by:- Selecting which interrupts should wake the HTTPTask, and which should not. Currently any event wakes the HTTPTask, even if there is no processing to be performed.
- Removing the polling of status bits within the driver code that is outside of the ISR, and instead using a more state machine orientated organisation between the ISR and task code.
Floating point
The Borland floating point libraries are not reentrant and should not be used with the RTOS scheduler. Information on how to make them reentrant is fairly well documented, information on which can be found on the web.
RTOS port specific configuration
Configuration items specific to this port are contained in Source/Demo/WizNET_DEMO_TERN_186/FreeRTOSConfig.h. The constants defined in this file can be edited to suit your application. In particular - the definition configTICK_RATE_HZ is used to set 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.Each port #defines 'BaseType_t' to equal the most efficient data type for that processor. This port defines BaseType_t to be of type short (16 bits).
Note that vPortEndScheduler() has not been implemented.
The RTOS Tick interrupt uses timers 1 and 2. Using a fast tick rate will remove the requirement to prescale the timer, and therefore use only timer 2.
Optimisation
The 'Global Register Allocation' optimisation option appears to break the code.
NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.
Meet Richard Barry and learn about running FreeRTOS on RISC-V at FOSDEM 2019
Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.
View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.
FreeRTOS and other embedded software careers at AWS.
