I tried this out, it works great. Now my next question is how can I
maintain functionality provided by the crossworks ctl_api (i.e. the
ctl_set_isr function)? I tried to add some code that uses this, but
the ISR is never called. The VECTORED_IRQ_INTERRUPTS define seems to
screw this up.

It seems as though calling vTaskStartScheduler() (regardless of
whether its before or after my initialization code) changes the VIC
initialization crossworks has done. However, by not calling
vTaskStartScheduler() ISRs don't return properly and the processor
hangs. I have been studying the users manual and crossworks IRQ code,
but have not been able to figure out why these problems occur. Any
help should be greatly appreciated.

--- In l..., "FreeRTOS Info" wrote:
>
> >I like your idea of suspending then resuming the task. Calling resume
> >from a timer hook will immediate switch the context to the resumed
> >task and not have to wait until the next tick? Similairily, calling
> >suspend immediately switches context? This is not clear from the
> >documentation on those pages.
>
> The task with the highest priority that is able to run is the task
chosen to
> execute. If you suspend a task it cannot run (it is suspended) so a
context
> switch occurs to find a task that can.
>
> 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 like your idea of suspending then resuming the task. Calling resume
>from a timer hook will immediate switch the context to the resumed
>task and not have to wait until the next tick? Similairily, calling
>suspend immediately switches context? This is not clear from the
>documentation on those pages.

The task with the highest priority that is able to run is the task chosen to
execute. If you suspend a task it cannot run (it is suspended) so a context
switch occurs to find a task that can.

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 had arm/thumb interworking set to yes everywhere in my project, and
it wouldn't compile. Adding an explicit THUMB_INTERWORK solved the
problem, thanks.

I like your idea of suspending then resuming the task. Calling resume
from a timer hook will immediate switch the context to the resumed
task and not have to wait until the next tick? Similairily, calling
suspend immediately switches context? This is not clear from the
documentation on those pages.

--- In l..., "FreeRTOS Info" wrote:
>
> >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

>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

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

>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

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

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

>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

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