Hello everyone,

I am trying to figure out how to get crossworks to work with FreeRTOS.
I have been able to get the demo applications to build and run, but
now I am trying to figure out how to start my own projects with
FreeRTOS. I tried copying main.c from Demo\ARM7_LPC2138_Rowley and
stripping out everything except the LED task. I also added heap_1.c,
list.c, port.c, portISR.c, queue.c, and tasks.c to the project. Under
user include directories I added Source\include so that crossworks
could find the header files. The first problem I had was that I had
to add "#define GCC_ARM7" to FreeRTOSCONFIG.h to keep the compiler
from puking.

I can get the code to compile as ARM but it always hangs at the dabort
handler. I've read the problem is that that THUMB_INTERWORK is
defined, but I can't find where to undefine this. Can someone point
me in the right direction?

Trying to build as THUMB code I get a bunch of assembler errors like this:
C:/ARM/projects/draganfly/heli/RTOS/THUMB Flash Debug/\s2is.5t:
Assembler messages:
Error: selected processor does not support `stmdb SP!,{R0}'
Error: selected processor does not support `mrs R0,CPSR'
etc...

Is there a general proceedure (i.e what files to add and defines to
look out for) to follow when building your own project using FreeRTOS?
Can someone out there please help me with these problems?

Here is my main code:
* Standard includes. */
#include <__cross_studio_io.h>
#include
/* Scheduler includes. */
#include "FreeRTOS.h"
#include "Task.h"
#include "queue.h"
#include "semphr.h"

/* Demo application definitions. */
#define mainQUEUE_SIZE ( 3 )
#define mainLED_DELAY ( ( portTickType ) 500 / portTICK_RATE_MS )
#define mainCHECK_DELAY ( ( portTickType ) 5000 / portTICK_RATE_MS )
#define mainLIST_BUFFER_SIZE 2048

#define mainLED_BIT 0x80000000

/* Task priorities. */
#define mainLED_TASK_PRIORITY ( tskIDLE_PRIORITY + 2 )
#define mainQUEUE_POLL_PRIORITY ( tskIDLE_PRIORITY + 2 )
#define mainCHECK_TASK_PRIORITY ( tskIDLE_PRIORITY + 3 )
#define mainSEM_TEST_PRIORITY ( tskIDLE_PRIORITY + 1 )
#define mainBLOCK_Q_PRIORITY ( tskIDLE_PRIORITY + 2 )
#define mainPRINT_TASK_PRIORITY ( tskIDLE_PRIORITY + 0 )

/*-----------------------*/

/*
* Simply flashes the on board LED every mainLED_DELAY milliseconds.
*/
static void vLEDTask( void *pvParameters );

int main( void )
{
/* Start the tasks defined within this file. */
xTaskCreate( vLEDTask, "LED", configMINIMAL_STACK_SIZE, NULL,
mainLED_TASK_PRIORITY, NULL );
//xTaskCreate( vCheckTask, "Check", configMINIMAL_STACK_SIZE,
NULL, mainCHECK_TASK_PRIORITY, NULL );
//xTaskCreate( vPrintTask, "Print", configMINIMAL_STACK_SIZE,
NULL, mainPRINT_TASK_PRIORITY, NULL );
//xTaskCreate( vButtonHandlerTask, "Button",
configMINIMAL_STACK_SIZE, NULL, mainCHECK_TASK_PRIORITY, NULL );

/* Start the scheduler. */
vTaskStartScheduler();

/* The scheduler should now running, so we will only ever reach here
if we
ran out of heap space. */

for(;;);
}
/*-----------------------*/

static void vLEDTask( void *pvParameters )
{
/* Configure IO. */
IO0DIR |= mainLED_BIT;
IO0SET = mainLED_BIT;

for( ;; )
{
/* Not very exiting - just delay... */
vTaskDelay( mainLED_DELAY );

/* ...set the IO ... */
IO0CLR = mainLED_BIT;

/* ...delay again... */
vTaskDelay( mainLED_DELAY );

/* ...then clear the IO. */
IO0SET = mainLED_BIT;
}
} Start a New Thread

>I am trying to figure out how to get crossworks to work with FreeRTOS.
> I have been able to get the demo applications to build and run,

Good - these should run 'out of the box' with no modifications required.

>but
>now I am trying to figure out how to start my own projects with
>FreeRTOS.
> I tried copying main.c from Demo\ARM7_LPC2138_Rowley and
>stripping out everything except the LED task. I also added heap_1.c,
>list.c, port.c, portISR.c, queue.c, and tasks.c to the project. Under
>user include directories I added Source\include so that crossworks
>could find the header files.

>From the documentation: "To ensure the correct development tool setup
(compiler switches, debugger format, etc) it is recommended that new
applications are created by modifying the existing demo
projects.........When writing your own application it is preferable to use
the demo application makefile (or project file) as a starting point. You can
leave all the files included from the Source directory included in the
makefile, and replace the files included from the Demo directory with those
for your own application. This will ensure both the RTOS source files
included in the makefile and the compiler switches used in the makefile are
both correct. "

It sounds like you have in effect done this the other way around - started
your own project then added in the FreeRTOS.org code. This means you will
not necessarily have the correct startup code or pre-processor definitions.

>The first problem I had was that I had
>to add "#define GCC_ARM7" to FreeRTOSCONFIG.h to keep the compiler
>from puking.

This definition is included as part of the demo project setup so the demo
project will compile without it. It does not really matter where you add
the definition - in the project or in the source files.

>I can get the code to compile as ARM but it always hangs at the dabort
>handler. I've read the problem is that that THUMB_INTERWORK is
>defined, but I can't find where to undefine this. Can someone point
>me in the right direction?

The crash is most likely due to incorrect startup code. The scheduler can
only be started from Supervisor mode, the demo application startup code
switches to Supervisor mode prior to calling main(). THUMB_INTERWORK is
also defined (or not depending on your configuration) within the project
file itself, not in the source code.

>Trying to build as THUMB code I get a bunch of assembler errors like this:
>C:/ARM/projects/draganfly/heli/RTOS/THUMB Flash Debug/\s2is.5t:
>Assembler messages:
>Error: selected processor does not support `stmdb SP!,{R0}'
>Error: selected processor does not support `mrs R0,CPSR'
>etc...

The portISR.c file must be compiled as ARM code.

Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * * Start a New Thread

Richard,

Thanks for the quick response. I suspected all along my problem was
due to some simple things like that. I haven't got a chance to try
this out yet, I spent most of today trying to figure out Kalman
filters (not simple). Hopefully I'll get to it tomorrow.

Greg

--- In l..., "FreeRTOS Info" wrote:
>
> >I am trying to figure out how to get crossworks to work with FreeRTOS.
> > I have been able to get the demo applications to build and run,
>
> Good - these should run 'out of the box' with no modifications required.
>
> >but
> >now I am trying to figure out how to start my own projects with
> >FreeRTOS.
> > I tried copying main.c from Demo\ARM7_LPC2138_Rowley and
> >stripping out everything except the LED task. I also added heap_1.c,
> >list.c, port.c, portISR.c, queue.c, and tasks.c to the project. Under
> >user include directories I added Source\include so that crossworks
> >could find the header files.
>
> From the documentation: "To ensure the correct development tool setup
> (compiler switches, debugger format, etc) it is recommended that new
> applications are created by modifying the existing demo
> projects.........When writing your own application it is preferable
to use
> the demo application makefile (or project file) as a starting point.
You can
> leave all the files included from the Source directory included in the
> makefile, and replace the files included from the Demo directory
with those
> for your own application. This will ensure both the RTOS source files
> included in the makefile and the compiler switches used in the
makefile are
> both correct. "
>
> It sounds like you have in effect done this the other way around -
started
> your own project then added in the FreeRTOS.org code. This means
you will
> not necessarily have the correct startup code or pre-processor
definitions.
>
> >The first problem I had was that I had
> >to add "#define GCC_ARM7" to FreeRTOSCONFIG.h to keep the compiler
> >from puking.
>
> This definition is included as part of the demo project setup so the
demo
> project will compile without it. It does not really matter where
you add
> the definition - in the project or in the source files.
>
> >I can get the code to compile as ARM but it always hangs at the dabort
> >handler. I've read the problem is that that THUMB_INTERWORK is
> >defined, but I can't find where to undefine this. Can someone point
> >me in the right direction?
>
> The crash is most likely due to incorrect startup code. The
scheduler can
> only be started from Supervisor mode, the demo application startup code
> switches to Supervisor mode prior to calling main().
THUMB_INTERWORK is
> also defined (or not depending on your configuration) within the
project
> file itself, not in the source code.
>
> >Trying to build as THUMB code I get a bunch of assembler errors
like this:
> >C:/ARM/projects/draganfly/heli/RTOS/THUMB Flash Debug/\s2is.5t:
> >Assembler messages:
> >Error: selected processor does not support `stmdb SP!,{R0}'
> >Error: selected processor does not support `mrs R0,CPSR'
> >etc...
>
> The portISR.c file must be compiled as ARM code.
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> + http://www.SafeRTOS.com
> for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
> Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * *
> Start a New Thread

Okay, I have been able to compile a new application (as ARM and
THUMB) by creating a copy of the demo project. I would still like
to know how to set up my own projects to use freeRTOS, mostly
because I think it will keep things organized better vs repeated
copy of the same project files. Is the proceedure for doing this
documented somewhere?

You mentioned the startup code places the MCU in supervisor mode
upon calling main(), but from the projects I have viewed the startup
files used appear to be those that are included with crossworks.
Where are the changes made? Probably more project defines I suppose.

--- In l..., "FreeRTOS Info" wrote:
>
> >I am trying to figure out how to get crossworks to work with
FreeRTOS.
> > I have been able to get the demo applications to build and run,
>
> Good - these should run 'out of the box' with no modifications
required.
>
> >but
> >now I am trying to figure out how to start my own projects with
> >FreeRTOS.
> > I tried copying main.c from Demo\ARM7_LPC2138_Rowley and
> >stripping out everything except the LED task. I also added
heap_1.c,
> >list.c, port.c, portISR.c, queue.c, and tasks.c to the project.
Under
> >user include directories I added Source\include so that crossworks
> >could find the header files.
>
> From the documentation: "To ensure the correct development tool
setup
> (compiler switches, debugger format, etc) it is recommended that
new
> applications are created by modifying the existing demo
> projects.........When writing your own application it is
preferable to use
> the demo application makefile (or project file) as a starting
point. You can
> leave all the files included from the Source directory included in
the
> makefile, and replace the files included from the Demo directory
with those
> for your own application. This will ensure both the RTOS source
files
> included in the makefile and the compiler switches used in the
makefile are
> both correct. "
>
> It sounds like you have in effect done this the other way around -
started
> your own project then added in the FreeRTOS.org code. This means
you will
> not necessarily have the correct startup code or pre-processor
definitions.
>
> >The first problem I had was that I had
> >to add "#define GCC_ARM7" to FreeRTOSCONFIG.h to keep the compiler
> >from puking.
>
> This definition is included as part of the demo project setup so
the demo
> project will compile without it. It does not really matter where
you add
> the definition - in the project or in the source files.
>
> >I can get the code to compile as ARM but it always hangs at the
dabort
> >handler. I've read the problem is that that THUMB_INTERWORK is
> >defined, but I can't find where to undefine this. Can someone
point
> >me in the right direction?
>
> The crash is most likely due to incorrect startup code. The
scheduler can
> only be started from Supervisor mode, the demo application startup
code
> switches to Supervisor mode prior to calling main().
THUMB_INTERWORK is
> also defined (or not depending on your configuration) within the
project
> file itself, not in the source code.
>
> >Trying to build as THUMB code I get a bunch of assembler errors
like this:
> >C:/ARM/projects/draganfly/heli/RTOS/THUMB Flash Debug/\s2is.5t:
> >Assembler messages:
> >Error: selected processor does not support `stmdb SP!,{R0}'
> >Error: selected processor does not support `mrs R0,CPSR'
> >etc...
>
> The portISR.c file must be compiled as ARM code.
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> + http://www.SafeRTOS.com
> for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
> Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * *
> Start a New Thread

>Okay, I have been able to compile a new application (as ARM and
>THUMB) by creating a copy of the demo project. I would still like
>to know how to set up my own projects to use freeRTOS, mostly
>because I think it will keep things organized better vs repeated
>copy of the same project files. Is the proceedure for doing this
>documented somewhere?

Nearly everything you need to create a FreeRTOS.org project is within the
preprocessor project options (if not everything?) of the demo applications.
If you copy these into your new project you should be successful. Also look
at the optimisation options and the include paths.

>You mentioned the startup code places the MCU in supervisor mode
>upon calling main(), but from the projects I have viewed the startup
>files used appear to be those that are included with crossworks.
>Where are the changes made? Probably more project defines I suppose.

>From memory, the CrossWorks startup files permit the initial processor mode
to be set using the preprocessor. You should see a definition
"SUPERVISOR_START" or similar within the demo application options.

You also need to ensure stacks are setup for IRQ and Supervisor modes, as a
minimum. Do not bother allocating a System mode stack as a stack is
allocated to each task individually by the kernel.

Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * * Start a New Thread

Well, I've got it to work. It turns out 3 defines are needed:
GCC_ARM7 ; SUPERVISOR_START ; VECTORED_IRQ_INTERRUPTS
Oddly enough I couldn't find these anywhere in the example project
windows in crossworks. I ended up having to search the files in the
example directory. In the RTOSdemo.hzp file I found those, why they
didn't appear anywhere in the solution/project/file properties I don't
know.

What is the purpose of the VECTORED_IRQ_INTERRUPTS define?

I can't get my project to compile as THUMB code. I've set the
portISR.c file to use the ARM instruction set, but it is still trying
to compile as thumb.

One thing I would like to have my code do is start an interrupt based
SPI read every 1ms. It seems like having a separate thread to manage
this may be inefficient since it would be running so often. This is
function is also time sensitive. What might be the best way to
schedule this?

Thanks for all your help.

--- In l..., "FreeRTOS Info" wrote:
>
> >Okay, I have been able to compile a new application (as ARM and
> >THUMB) by creating a copy of the demo project. I would still like
> >to know how to set up my own projects to use freeRTOS, mostly
> >because I think it will keep things organized better vs repeated
> >copy of the same project files. Is the proceedure for doing this
> >documented somewhere?
>
> Nearly everything you need to create a FreeRTOS.org project is
within the
> preprocessor project options (if not everything?) of the demo
applications.
> If you copy these into your new project you should be successful.
Also look
> at the optimisation options and the include paths.
>
> >You mentioned the startup code places the MCU in supervisor mode
> >upon calling main(), but from the projects I have viewed the startup
> >files used appear to be those that are included with crossworks.
> >Where are the changes made? Probably more project defines I suppose.
>
> From memory, the CrossWorks startup files permit the initial
processor mode
> to be set using the preprocessor. You should see a definition
> "SUPERVISOR_START" or similar within the demo application options.
>
> You also need to ensure stacks are setup for IRQ and Supervisor
modes, as a
> minimum. Do not bother allocating a System mode stack as a stack is
> allocated to each task individually by the kernel.
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> + http://www.SafeRTOS.com
> for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
> Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * *
> Start a New Thread

Hi,

> Well, I've got it to work. It turns out 3 defines are needed:
> GCC_ARM7 ; SUPERVISOR_START ; VECTORED_IRQ_INTERRUPTS Oddly
> enough I couldn't find these anywhere in the example project
> windows in crossworks.

GCC_ARM7 isn't a standard CrossWorks define.

SUPERVISOR_START and VECTORED_IRQ_INTERRUPS defines are both documented
in the LPC2000 startup code source which is included in the System Files
in your project.

Not only that, after you install the LPC2000 CPU Support package, how
about reading the documentation that is installed with it? You know,
there's a whole bunch of HTML which you can read. Go to Tools > Show
Installed Packages, click the Philips LPC2000 CPU Support Package
hyperlink then click the LPC2000 Support Package Documentation.

> I ended up having to search the files
> in the example directory. In the RTOSdemo.hzp file I found
> those, why they didn't appear anywhere in the
> solution/project/file properties I don't know.

Because you selected the wrong configuration?

> What is the purpose of the VECTORED_IRQ_INTERRUPTS define?

Read the documentation in the startup file and clue yourself in. Fact
is, everything is documented.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors Start a New Thread

>Hi,
>
>> Well, I've got it to work. It turns out 3 defines are needed:
>> GCC_ARM7 ; SUPERVISOR_START ; VECTORED_IRQ_INTERRUPTS Oddly
>> enough I couldn't find these anywhere in the example project
>> windows in crossworks.
>
>GCC_ARM7 isn't a standard CrossWorks define.

GCC_ARM7 tells the portable layer which port to include in the build. In
this case the ARM7 port using the GCC tools.
>> I ended up having to search the files
>> in the example directory. In the RTOSdemo.hzp file I found
>> those, why they didn't appear anywhere in the
>> solution/project/file properties I don't know.

They do appear there in the FreeRTOS.org demo. You have to select 'Common'
configuration to see them as these defines apply to all configuration. For
the tasks to run in THUMB mode you have to have THUMB_INTERWORK defined in
the THUMB configuration.

Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * * Start a New Thread

I've done a bit more playing and a bit more reading about freertos.
The problem I have now is that my demo application won't work in thumb
mode. I get a whole bunch of assembler errors unless I compile
tasks.c as ARM code. Once I do that it compiles, but still doesn't
work. What might the problem be in this case?

I would like to a function run at the same frequency as the scheduler
(400Hz). It is quick (144uS) but time critical as it run digital
filters. How would you reccomend I manage this function? I tried
setting it for highest priority and then yielding once the function is
done, but it always seemd to keep calling this same task. I suppose
this makes sense. It seems like this would be a good job for a tick
hook, but due to other stuff thats likely to be running I would like
to have this code interruptable. Would it be better just to use a
timer ISR to call this function and re-enable interrupts within that ISR?
Thanks Again

--- In l..., "FreeRTOS Info" wrote:
> >Hi,
> >
> >> Well, I've got it to work. It turns out 3 defines are needed:
> >> GCC_ARM7 ; SUPERVISOR_START ; VECTORED_IRQ_INTERRUPTS Oddly
> >> enough I couldn't find these anywhere in the example project
> >> windows in crossworks.
> >
> >GCC_ARM7 isn't a standard CrossWorks define.
>
> GCC_ARM7 tells the portable layer which port to include in the
build. In
> this case the ARM7 port using the GCC tools.
> >> I ended up having to search the files
> >> in the example directory. In the RTOSdemo.hzp file I found
> >> those, why they didn't appear anywhere in the
> >> solution/project/file properties I don't know.
>
> They do appear there in the FreeRTOS.org demo. You have to select
'Common'
> configuration to see them as these defines apply to all
configuration. For
> the tasks to run in THUMB mode you have to have THUMB_INTERWORK
defined in
> the THUMB configuration.
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> + http://www.SafeRTOS.com
> for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
> Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * *
> Start a New Thread

>I've done a bit more playing and a bit more reading about freertos.
>The problem I have now is that my demo application won't work in thumb
>mode. I get a whole bunch of assembler errors unless I compile
>tasks.c as ARM code. Once I do that it compiles, but still doesn't
>work. What might the problem be in this case?

To compile as THUMB you must:
1) Make sure portISR.c is still compiled as ARM, as is any other ISR code.
2) Define THUMB_INTERWORK.

If you miss out (2) then ARM asm will get included inline and you will get
errors assembling.

>I would like to a function run at the same frequency as the scheduler
>(400Hz). It is quick (144uS) but time critical as it run digital
>filters. How would you reccomend I manage this function?

If this really is the highest priority then use a tick hook.

>I tried
>setting it for highest priority and then yielding once the function is
>done, but it always seemd to keep calling this same task. I suppose
>this makes sense.

Yes, yielding does not block the task, so if the task is still able to run
and is the highest priority it will get selected to run again. You might
consider suspending the task when it has finished a cycle, then resuming the
task from the tick hook (using vTaskResumeFromISR()). This way the timing
is still controlled by the tick frequency, but you can play with the task
priority.

>Would it be better just to use a
>timer ISR to call this function and re-enable interrupts within that ISR?

If the function does not make use of the scheduler facilities then this is a
good option.
Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051 & PIC18 * * * * Start a New Thread