Latest: FreeRTOS V7.1.1 was released May 1, 2012. View the change history.

Quick Start

Supported MCUs

Books & Kits

Ecosystem

Contact & Support

FreeRTOS+ Ecosystem Showcase

Trace:
Run-time analysis tool

IO:
read(), write(), ioctl() interface

CLI:
Command line interface

Nabto:
Webserver in 1K, see how

TCP/IP:
Low cost pre-ported libraries

Safety:
TUV certified RTOS for MCUs

Sponsored Links

Last site update May 11 2012

Advertise here?

Xilinx MicroBlaze Port
Demonstrated on a Spartan-6 FPGA,
using the Xilinx ISE Design Suite (Embedded Edition)
[RTOS Ports]

Xilinx Spartan 6 SP605 development board

This MicroBlaze port is produced using version 13.1 of the Xilinx ISE Design Suite (Embedded Edition), supports version 8.10 of the MicroBlaze soft processor core, and was developed and tested on a Spartan-6 FPGA based SP605 Evaluation Kit. It represents a major FreeRTOS port upgrade, and replaces the pre-existing older port, that was developed on a Virtex-4 FPGA.

The demo includes an embedded web server implementation that uses version 1.4.0 of the lwIP TCP/IP stack. The web server's server side include (SSI) functionality is used to serve pages that include dynamic task and run-time statistic information.

There are two ways of using FreeRTOS in the Xilinx SDK environment:

Using a stand-alone BSP
A stand-along board support package (BSP) is a library generated by the SDK that is specific to the hardware design (the FPGA configuration). It contains software drivers for the MicroBlaze soft processor itself and all the peripherals included in the design, but it is not FreeRTOS aware. FreeRTOS can be used with a stand-alone BSP by building the FreeRTOS source files as part of the application that references the BSP library. The demo application described on this page does just that.
Using a FreeRTOS BSP
A FreeRTOS BSP extends the stand-alone BSP described above to also include the FreeRTOS source files. FreeRTOS can be used with a FreeRTOS BSP without having to include the FreeRTOS source files as part of the application that references the BSP library. The demo application described on this page does not use a FreeRTOS BSP, but a separate documentation page is provided that describes how a FreeRTOS BSP is generated and used, and how the SDK can automatically generate a complete (but simple) FreeRTOS example application that makes use of a FreeRTOS BSP library.

Creating FreeRTOS BSP packages and applications in the Xilinx SDK

Using the Xilinx SDK to create a Hello World style FreeRTOS application that uses a FreeRTOS BSP

Finally, the FreeRTOS Eclipse Kernel Aware Debugger Plug-in can be used with the Xilinx SDK to assist with debugging FreeRTOS applications.

FreeRTOS kernel aware debugger plug in viewed in the Xilinx SDK

IMPORTANT! Notes on using the MicroBlaze soft processor core RTOS port

Please read all the following points before using this RTOS port.

Source Code Organization
- Preparing the project directory
The Demo Application
Configuration and Usage Details
Creating and Using FreeRTOS BSPs (links to a separate page)

Source Code Organization

The FreeRTOS download contains the source code for all the FreeRTOS ports, and every demo application. That means it contains many more files than are required to use the MicroBlaze port, or the official MicroBlaze demo application. See the Source Code Organization section of this web site for a description of the downloaded files, and information on creating a new project.

The directory structure used by the demo application is shown and described below. The root MicroBlaze_Spartan-6_EthernetLite directory is itself located in FreeRTOS/Demo.

 
MicroBlaze_Spartan-6_EthernetLite
    ¦
    +-KernelAwareBSPRepository   File repository used to integrate FreeRTOS into the SDK
    ¦
    +-PlatformStudioProject      The XPS project used to create the hardware bitstream
    ¦
    +-SDKProjects                The various SDK projects
        ¦
        +-RTOSDemo                   The demo application project itself
        ¦
        +-StandAloneBSP              The BSP library code
        ¦
        +-HardwareWithEthernetLite   The hardware project

Notes relating to the directory structure:

The SDK project used to build the demo application is stored in the SDKProjects/RTOSDemo directory. This is the only project that needs to be built explicitly to generate the demo project executable. The other two SDK projects (the BSP library and the hardware project) are dependencies of the RTOSDemo project, so are built automatically when required.
The StandAloneBSP library project was created by the SDK specifically for the hardware configuration. As it is a stand-alone library, it does not include the FreeRTOS source files, and the FreeRTOS source files are instead includes as part of the RTOSDemo application. A separate web page is provided that describes the use of a FreeRTOS BSP, which does include the FreeRTOS source files, and so removes this need for the FreeRTOS files to be included directly in the application being built.
The XPS (hardware) project contained in the PlatformStudioProject directory does not need to be opened or modified, unless you specifically want to change the hardware configuration. The RTOSDemo SDK (software) project does rely on files exported from the hardware project, but the export process has already been completed, and the exported files are already stored in the SDKProjects/HardwareWithEthernetLite directory.

Preparing the Xilinx Software Development Kit (SDK) project directory

Eclipse projects can be either standard makefile projects, or managed make projects. The projects provided in the demo application are managed make projects. This in turn means that either:

All the source files needed to build the project must be located under the folder/directory that contains the project file itself, or
That the Eclipse workspace (note workspace, not project) needs to be configured to locate the files elsewhere on the hard disk.

Option 1 is used in this case. To that end, the directory FreeRTOS/Demo/MicroBlaze_Spartan-6_EthernetLite/SDKProjects/RTOSDemo contains a batch file called CreateProjectDirectoryStructure.bat that will copy all the required FreeRTOS source files into sub directories inside the demo project directory. The batch file is intended for use on Windows hosts. Linux users will need to create an equivalent script file, or inspect the provided batch file in order to then manually perform the same copy operations. [NOTE: There is no need to run this batch file while the demo project is provided in a separate zip file - it will be required when the demo project is included in the main FreeRTOS.org download.]

CreateProjectDirectoryStructure.bat must be executed before the SDK project is imported into the Eclipse workspace.

The MicroBlaze Demo Application

Functionality

The SDK project contains two build configurations, one called Blinky, which creates a very simple starter example, and one called Full, which creates a comprehensive example:

Build configuration Description

Blinky This is a very simple starter example. It creates two tasks, one software timer, and also uses a button interrupt.
The two tasks communicate via a queue - the queue send task, and the queue receive task. The queue receive task toggles an LED each time it receives a value.
Pressing any user button (SW4, SW5, SW7 or SW8) will generate an interrupt, the service routine for the interrupt resets a software timer before turning an LED on. The software timer has a five second period, and when the five seconds has expired, the software timer callback function turns the LED off again. Therefore, pressing a button will turn the LED on, and the LED will remain on until a full five seconds pass without a button being pressed again.
The Blinky build configuration uses the main-blinky.c source file.

Full This is a comprehensive demo that creates lots of tasks, queues, semaphores (of various types) and software timers. It also includes the embedded web server.
The Full build configuration creates a lot of tasks from the set of standard demo tasks. The standard demo tasks don't perform any particular function. Their purpose is firstly to test the FreeRTOS port, and secondly to provide examples of how to use the FreeRTOS API functions.
Additional tasks created by the Full build configuration include:

Register check tasks
These two tasks test the kernel context switch mechanism by first filling each MicroBlaze register with a known and unique value, then repeatedly checking that the value originally written to the register is maintained in the register, for the lifetime of the task. The tasks execute at the lowest possible priority (the idle priority), so are preempted frequently. The nature of these tasks necessitates that they are written in assembly.

A "Check" software timer and callback
The Check timer is an example of a very simple watchdog type timer. It monitors all the other standard demo tasks, and the register check tasks, and provides visual feedback as to the system status using an LED.
The period of the check timer is initially set to five seconds. The check timer callback function checks that all the standard demo tasks, and the register check tasks, are not only still executing, but are executing without reporting any errors, then toggles an LED.
If the check timer discovers that a task has either stalled, or reported an error, then it changes its own period from the initial five seconds, to just 200ms. Therefore, if the LED toggles every five seconds, no issues have been discovered, whereas, if the LED toggles every 200ms, an issue has been discovered in at least one task. The last reported issue is latched into the pcStatusMessage variable.

lwIP task
The lwIP task executes the lwIP TCP/IP stack, and executes the embedded web server. The network configuration required to use the embedded web server is described in the network setup section of this page. The pages served by the embedded web server are described in the expected behaviour section of this page.

Hardware setup

The demo application includes tasks that send and receive characters through a UART. The characters sent by one task must be received by another. An error condition is flagged if any character is missing, or received out of order.

There are two common ways of ensuring that every transmitted character is also received. The first is to use a loopback connector that links the transmit pin to the receive pin. The second is to connect the UART to an echo server. The SP605 hardware uses a UART to USB converter, removing the possibility of fitting a loopback connector. Therefore, in this case, the UART must be connected to an external echo server. During development, the free (Windows) Comm Echo utility was used for this purpose. Comm Echo can be downloaded from http://www.serialporttool.com/CommEcho.htm.

The required network setup is described in the following section.

The demo application uses the LEDs and buttons that are built onto the SP605 hardware, so no further hardware setup is required.

Network setup

The IP address assigned to the SP605 hardware is set by the constants configIP_ADDR0 to configIP_ADDR3. These are specified at the bottom of the FreeRTOSConfig.h header file (located in the FreeRTOS/Demo/MicroBlaze_Spartan-6_EthernetLite/SDKProjects/RTOSDemo directory) Constants that define the MAC address and the NET mask are located in the same place of the same file.

The IP addresses used by the web browser and the SP605 hardware must be compatible. This can be ensured by making the first three octets of both IP addresses the same. For example, if the web browser computer uses IP address 192.168.0.1, then the SP605 development board can be given any address in the range 192.168.0.2 to 192.168.0.254 (other than any addresses that already exist on the same network).

The MAC address assigned to the SP605 must be unique on the network to which it is being attached.

Importing the demo application project into the SDK Eclipse workspace

To import the Xilinx Software Development Kit (SDK) project into an existing or new Eclipse Workspace:

Select "Import" from the SDK "File" menu. The dialogue box shown below will appear. Select General->Existing Project into Workspace, as shown in the image.

The dialogue box that appears when "Import" is first clicked
In the next dialogue box, select FreeRTOS/Demo/MicroBlaze_Spartan-6_EthernetLite/SDKProjects as the root directory. Then, make sure the RTOSDemo, StandAloneBSP and HardwareWithEthernetLite projects are checked in the "Projects" area, and that the Copy Projects Into Workspace box is not checked, before clicking the Finish button (see the image below for the correct check box states).

Make sure that RTOSDemo is checked, and "Copy projects into workspace" is not checked
Once all three projects have been imported, the project explorer window of the SDK IDE will appear as below.
Remember that only the RTOSDemo project needs to be built explicitly, and that the XPS project used to generate the hardware project is also provided in the FreeRTOS/Demo/MicroBlaze_Spartan-6_EthernetLite/PlatformStudioProject directory.

All three projects imported into the workspace

Building the demo application

Ensure that CreateProjectDirectoryStructure.bat has been executed, and that the project has been correctly imported into the Eclipse workspace.
Select the required build configuration. To select the active build configuration (the build configuration that will actually get built), first right click on the RTOSDemo project name in the Project Explorer window of the SDK IDE, then select the required pop up menu items as shown in the image below.

Selecting the active build configuration using the pop up menus in the Xilinx SDK IDE

Note: The two build configurations each include and exclude different files in their respective builds. For example, the Full build configuration builds main-full.c, and the Blinky build configuration instead builds main-blinky.c. The Eclipse Project Explorer window should show an icon with a cross through it to indicate which files are excluded from the active build configuration. However - this particular functionality does not appear to be working correctly. Changing build configurations will ensure the correct files are built, and the correct files are excluded, but the Project Explorer windows will not necessarily update its icons correctly.
Select 'Rebuild All' from the IDE 'Project' menu. The application should build without any errors or warnings. The StandAloneBSP project will also get built, as it is a dependency of the RTOSDemo project.

Running the demo application using the SDK tools

Ensure the SP605 hardware is powered up, and that its JTAG port is connected to the host computer.
The Spartan-6 FPGA needs to be programmed with the bitstream from the SDK hardware project before a software project can be downloaded. To program the bitstream into the FPGA, first select 'Program FPGA' from the SDK IDE 'Xilinx Tools' menu, then, in the Program FPGA dialogue box, select the .bit and .bmm files found in the SDKProjects/HardwareWithEthernetLite directory. This is shown in the image below.

The dialogue used to program the FPGA
After the FPGA has been programmed, select 'Debug Configurations...' from the IDE 'Run' menu.
In the dialogue box that appears, highlight "Xilinx C/C++ ELF" in the tree of targets on the left hand side, then click the "New Launch Configuration" speed button. The speed button is highlighted by the red square in the image below.
A new debug configuration will be created that will already be named to match the build configuration being used. The automatically generated name is highlighted by the yellow rectangle in the image below.
Ensure the correct application file is being used - Blinky/RTOSDemo.elf for the Blinky build configuration, and Full/RTOSDemo.elf for the Full build configuration. The application file entry is highlighted by the green rectangle in the image below.
Click the "Debug" button to commence debugging.

Creating a debug configuration

The Blinky and Full build configurations require separate debug configurations, and care must be taken to select the correct debug configuration each time a new debug session is started.

Expected behaviour

The Full build configuration will behave as follows:

The LEDs marked DS4, DS5 and DS6 are under the control of the standard demo 'flash' tasks. Each will toggle at a fixed frequency, with LED DS6 using the fastest frequency, and LED DS4 using the slowest frequency.
The LED marked DS3 is under the control of the 'check' software timer. DS3 will toggle every 5 seconds if no errors have been reported, or every 200ms if a standard demo or reg check task has ever reported an error. This mechanism can be tested by shutting down the comm echo server, or unplugging the UART cable, and in so doing deliberately causing the comm test tasks to fail.
The embedded web server behaviour is described in the following section.

The Blinky build configuration will behave as follows:

The LED marked DS6 is under the control of queue receive task. It will toggle each time the queue receive task receives a value, which will be every 200ms.
The LED marked DS5 will turn on when any of the user buttons SW4, SW5, SW8 or SW9 are pressed (assuming it was not already on). Five seconds after one of the buttons was last pressed, the LED software timer will turn LED DS5 off again.

Using the web server

The top of each served page includes a menu with links to the other pages.

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)

The served web pages

task stats page served by the lwIP embedded web server on the Spartan 6 FPGA.jpg

The served task statistics page - showing the
state of each task running in the system - including
the tasks stack high water mark

task run time stats page served by the lwIP embedded web server on the Xilinx SP605
The served run time stats page - showing
how much CPU time each task has consumed

The third served page shows a large JPG image.

FreeRTOS Kernel Configuration and Usage Details

Callback functions that need to be supplied by the application

void vApplicationSetupTimerInterrupt( void );
This is an application defined callback function used to install the tick interrupt handler. It is provided as an application callback, rather than being an integral part of the kernel port layer, because the kernel will run on lots of different MicroBlaze and FPGA configurations - not all of which will have the same timer peripherals defined or available.
vApplicationSetupTimerInterrupt() must install the kernel defined function vPortTickISR() as the tick interrupt handler.
The official demo application includes an example implementation of vApplicationSetupTimerInterrupt() in main-full.c and main-blinky.c. The example implementation uses the AXI Timer 0 as the tick interrupt source. If an AXI Timer 0 peripheral is available on your hardware platform, then the example implementation can be used without modification.
void vApplicationClearTimerInterrupt( void );
This is an application defined callback function used to clear whichever interrupt was installed by the the vApplicationSetupTimerInterrupt() callback function. It is provided as an application callback because the kernel will run on lots of different MicroBlaze and FPGA configurations - not all of which will have the same timer peripherals defined or available.
The official demo application includes an example implementation of vApplicationClearTimerInterrupt() in main-full.c and main-blinky.c. The example implementation complements the example implementation of vApplicationSetupTimerInterrupt() found in the same files by clearing the interrupt generated by the AXI Timer 0 peripheral. If your application does not modify the provided example implementation of vApplicationSetupTimerInterrupt(), then the provided example implementation of vApplicationClearTimerInterrupt() can also be used without any modification.

Implementing an interrupt service routines (ISR)

Functions that implement ISRs are normal C functions, but must conform to the following prototype.

void ISRFunctionName( void *ISRParameter );

Context switching from an ISR

It is common for an ISR to cause a task to leave the Blocked state. For example, consider the case where a task processes data that arrives on a queue. When the queue is empty, there is no data to process, and the task might opt to enter the Blocked state to wait for more data to become available. If an ISR then sends data to the queue, the task would automatically leave the Blocked state as the queue would no longer be empty.

If an ISR causes a task to leave the Blocked state, and the task that leaves the Blocked state has a priority that is higher than or equal to the currently executing task (the task that was interrupted), then a context switch should be performed in the ISR to ensure the ISR returns directly to the newly unblocked, higher priority task. The ISR will have interrupted one task, but returned to another.

The macro portYIELD_FROM_ISR() is an interrupt safe version of taskYIELD(). It takes a single parameter that, if none zero, will indirectly cause a context switch to occur. Below is an example use of portYIELD_FROM_ISR(), which is taken from the file serial.c in the official demo application:

/* Note that this function is called from the UART interrupt handler, it is not
itself an interrupt handler, so its prototype does not have to match that 
required by all interrupt handlers. */
static void prvRxHandler( void *pvUnused, unsigned portBASE_TYPE uxByteCount )
{
signed char cRxedChar;
portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;

    /* While there are characters to process. */
    while( XUartLite_IsReceiveEmpty( xUartLiteInstance.RegBaseAddress ) == pdFALSE )
    {
        /* Obtain the next character. */
        cRxedChar = XUartLite_ReadReg( xUartLiteInstance.RegBaseAddress, 
                                       XUL_RX_FIFO_OFFSET);
        
        /* Place the received character in the received queue.  If writing to the
        queue causes a task to leave the Blocked state, and the task has a
        priority equal to or above the priority of the interrupted task, then
        xHigherPriorityTaskWoken will automatically get set to pdTRUE inside the
        xQueueSendFromISR() function itself. */
        xQueueSendFromISR( xRxedChars, &cRxedChar, &xHigherPriorityTaskWoken );
    }

    /* Call portYIELD_FROM_ISR(), passing in xHigherPriorityTaskWoken.  If
    xHigherPriorityTaskWoken was set to pdTRUE inside xQueueSendFromISR(), then
    calling portYIELD_FROM_ISR() here will cause the ISR
    to return directly to the newly unblocked task.  If xHigherPriorityTaskWoken
    has retained its initialised value of pdFALSE, then calling 
    portYIELD_FROM_ISR() here will have no effect. */
    portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}

Installing and enabling an ISR

The following functions are provided for installing, enabling and disabling interrupts (in the interrupt controller) respectively. The Xilinx BSP library functions that have similar functionality must not be used.

An example of how to use these functions is contained in the implementation of vApplicationSetupTimerInterrupt(), which is contained in both main-full.c and main-blinky.c. Another example is contained in the implementation of prvSetupHardware() in main-blinky.c.

/*
 * Installs pxHandler as the interrupt handler for the peripheral specified by 
 * the ucInterruptID parameter.
 *
 * ucInterruptID:
 * 
 * The ID of the peripheral that will have pxHandler assigned as its interrupt
 * handler.  Peripheral IDs are defined in the xparameters.h header file, which 
 * is itself part of the BSP project.  For example, in the official demo 
 * application for this port, xparameters.h defines the following IDs for the 
 * four possible interrupt sources:
 *
 * XPAR_INTC_0_UARTLITE_1_VEC_ID  -  for the UARTlite peripheral.
 * XPAR_INTC_0_TMRCTR_0_VEC_ID    -  for the AXI Timer 0 peripheral.
 * XPAR_INTC_0_EMACLITE_0_VEC_ID  -  for the Ethernet lite peripheral.
 * XPAR_INTC_0_GPIO_1_VEC_ID      -  for the button inputs.
 *
 *
 * pxHandler:
 * 
 * A pointer to the interrupt handler function itself.  This must be a void
 * function that takes a (void *) parameter.
 *
 *
 * pvCallBackRef:
 *
 * The parameter passed into the handler function.  In many cases this will not
 * be used and can be NULL.  Some times it is used to pass in a reference to
 * the peripheral instance variable, so it can be accessed from inside the
 * handler function.
 *
 * 
 * pdPASS is returned if the function executes successfully.  Any other value
 * being returned indicates that the function did not execute correctly.
 */
portBASE_TYPE xPortInstallInterruptHandler( unsigned char ucInterruptID, 
                           XInterruptHandler pxHandler, void *pvCallBackRef );


/*
 * Enables the interrupt, within the interrupt controller, for the peripheral 
 * specified by the ucInterruptID parameter.
 *
 * ucInterruptID:
 * 
 * The ID of the peripheral that will have its interrupt enabled in the
 * interrupt controller.  Peripheral IDs are defined in the xparameters.h header 
 * file, which is itself part of the BSP project.  For example, in the official 
 * demo application for this port, xparameters.h defines the following IDs for 
 * the four possible interrupt sources:
 *
 * XPAR_INTC_0_UARTLITE_1_VEC_ID  -  for the UARTlite peripheral.
 * XPAR_INTC_0_TMRCTR_0_VEC_ID    -  for the AXI Timer 0 peripheral.
 * XPAR_INTC_0_EMACLITE_0_VEC_ID  -  for the Ethernet lite peripheral.
 * XPAR_INTC_0_GPIO_1_VEC_ID      -  for the button inputs.
 *
 */
void vPortEnableInterrupt( unsigned char ucInterruptID );

/*
 * Disables the interrupt, within the interrupt controller, for the peripheral 
 * specified by the ucInterruptID parameter.
 *
 * ucInterruptID:
 * 
 * The ID of the peripheral that will have its interrupt disabled in the
 * interrupt controller.  Peripheral IDs are defined in the xparameters.h header 
 * file, which is itself part of the BSP project.  For example, in the official 
 * demo application for this port, xparameters.h defines the following IDs for 
 * the four possible interrupt sources:
 *
 * XPAR_INTC_0_UARTLITE_1_VEC_ID  -  for the UARTlite peripheral.
 * XPAR_INTC_0_TMRCTR_0_VEC_ID    -  for the AXI Timer 0 peripheral.
 * XPAR_INTC_0_EMACLITE_0_VEC_ID  -  for the Ethernet lite peripheral.
 * XPAR_INTC_0_GPIO_1_VEC_ID      -  for the button inputs.
 *
 */
void vPortDisableInterrupt( unsigned char ucInterruptID );

Exception handling (for advanced users only)

To enable FreeRTOS exception handling, first the MicroBlaze itself must be configured to include exception handling functionality, and second configINSTALL_EXCEPTION_HANDLERS must be set to 1 in FreeRTOSConfig.h. Setting configINSTALL_EXCEPTION_HANDLERS to 1 will cause both the code and data space consumed by the kernel to increase.

The following functions are provided to install the FreeRTOS exception handler, and process an exception when it occurs respectively. The functionality of the FreeRTOS exception handler itself is described in the comments above the function prototypes found in portmacro.h, and replicated below.

An example implementation of vApplicationExceptionRegisterDump() is provided in both main-full.c and main-blinky.c.

/*
 * vPortExceptionsInstallHandlers() is only available when the MicroBlaze
 * is configured to include exception functionality, and 
 * configINSTALL_EXCEPTION_HANDLERS is set to 1 in FreeRTOSConfig.h.
 *
 * vPortExceptionsInstallHandlers() installs the FreeRTOS exception handler
 * for every possible exception cause.  
 *
 * vPortExceptionsInstallHandlers() can be called explicitly from application
 * code.  After that is done, the default FreeRTOS exception handler that will
 * have been installed can be replaced for any specific exception cause by using 
 * the standard Xilinx library function microblaze_register_exception_handler().
 *
 * If vPortExceptionsInstallHandlers() is not called explicitly by the 
 * application, it will be called automatically by the kernel the first time
 * xPortInstallInterruptHandler() is called.  At that time, any exception 
 * handlers that may have already been installed will be replaced.
 *
 * See the description of vApplicationExceptionRegisterDump() for information
 * on the processing performed by the FreeRTOS exception handler.
 */
void vPortExceptionsInstallHandlers( void );

/*
 * The FreeRTOS exception handler fills an xPortRegisterDump structure (defined 
 * in portmacro.h) with the MicroBlaze context, as it was at the time the 
 * exception occurred.  The exception handler then calls
 * vApplicationExceptionRegisterDump(), passing in a reference to the completed
 * xPortRegisterDump structure as its parameter.
 *
 * The FreeRTOS kernel provides its own implementation of
 * vApplicationExceptionRegisterDump(), but the kernel provided implementation 
 * is declared as being 'weak'.  The weak definition allows the application 
 * writer to provide their own implementation, should they wish to use the 
 * register dump information.  For example, an implementation could be provided
 * that writes the register dump data to a display, or a UART port.
 */
void vApplicationExceptionRegisterDump( xPortRegisterDump *xRegisterDump );

RTOS port specific configuration

The kernel and demo behaviour can be customised using the configuration constants contained in the file FreeRTOS/Demo/MicroBlaze_Spartan-6_EthernetLite/SDKProjects/RTOSDemo/FreeRTOSConfig.h. The majority these configuration constants are used for all FreeRTOS ports, and are described on the Customisation page of this web site, and in the FreeRTOS Reference Manual.

The following constants are specific to this port:

/* If configINSTALL_EXCEPTION_HANDLERS is set to 1, then the kernel will
automatically install its own exception handlers before the kernel is started,
if the application writer has not already caused them to be installed using the 
vPortExceptionsInstallHandlers() API function.  vPortExceptionsInstallHandlers()
is described on this web page. */
#define configINSTALL_EXCEPTION_HANDLERS 1

/* configINTERRUPT_CONTROLLER_TO_USE must be set to the ID of the interrupt
controller that is going to be used directly by FreeRTOS itself.  Most hardware
designs will only include on interrupt controller, so can use the same setting
as shown here.  XPAR_INTC_SINGLE_DEVICE_ID is itself defined in the xparameters.h
header file, which is part of the Xilinx BSP library project. */
#define configINTERRUPT_CONTROLLER_TO_USE XPAR_INTC_SINGLE_DEVICE_ID

Memory allocation

Source/Portable/MemMang/heap_3.c is included in the MicroBlaze demo application makefile to provide the memory allocation required by the real time kernel. Please refer to the Memory Management section of the API documentation for full information.

heap_3.c uses the standard malloc() and free() functions, called from within a scheduler lock section, to make them thread safe. The total available heap size is set at the top of the linker script located in the \Demo\MicroBlaze_Spartan-6_EthernetLite\SDKProjects\RTOSDemo\src directory.

[ Back to the top ] [ About FreeRTOS ] [ Sitemap ] [ ]

Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2012 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOS^TM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOS^TM and FreeRTOS.org^TM are trade marks of Real Time Engineers Ltd.