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 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 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