> Hi Richard. I have tried the flash demo in cooperative mode but it
> doesn't work. I have also tried to see if there is a problem with the
> interrupts, and they are NOT working in cooperative mode. I don't
> know why.
> I haven't made any changes to the kernel.
> As the interrupts are not working i think there might be a problem
> with the tick interrupt.

Which compiler are you using?

Regards,
Richard.

+ http://www.FreeRTOS.org
14 official architecture ports, 1000 downloads per week.

+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.



Start a New Thread

Hi Richard. I have tried the flash demo in cooperative mode but it
doesn't work. I have also tried to see if there is a problem with the
interrupts, and they are NOT working in cooperative mode. I don't
know why.
I haven't made any changes to the kernel.
As the interrupts are not working i think there might be a problem
with the tick interrupt.

--- In A..., "FreeRTOS.org Info"
wrote:
>
> > Yes. That's why I want to use the cooperative mode. These two
tasks
> > block on xQueueReceive() (I believe this is a blocking call). I
have
> > no other tasks running, although these two are implemented as
> > infinite loops. So they are waiting for elements to arrive on the
> > queue. When one element arrives, they should unblock, do the job
and
> > then block again waiting for another element. I have tried this
with
> > a single task, but the system behaved exactly the same. It
locked. I
> > think there might be something I'm missing...
>
>
>
> If you are blocking on the queue then this will cause a context
switch away
> from the task. If you post to the queue from an interrupt (using
the
> appropriate xFromISR() function), then this will unblock the task.
>
> Just setting the configUSE_PREEMPTION parameter should be enough.
Have you
> made any changes to the kernel code at all?
>
> Have you run some of the standard demo tasks in cooperative mode?
The
> simples to start with are the flash tasks. If you are not using
the same
> hardware as per the FreeRTOS.org demo you will first need to update
> partest.c so that it toggles the LEDs that are available on your
board.
> Once you are sure the LED toggle functions are working, try
including the
> standard flash tasks.
>
> You can test the partest.c functionality by using a very simple
loop that
> does not use the kernel - so place the following code before the
call to
> start the kernel:
>
> volatile unsigned long ul;
> for( ;; )
> {
> ____for( ul = 0; ul < 0xfffff; ul++ ); // Basic delay.
> ____vParTestToggleLED( 0 );
> ____vParTestToggleLED( 1 );
> ____vParTestToggleLED( 2 );
> ____vParTestToggleLED( 3 );
> }
>
> Once this is working, include FreeRTOS/Demo/Common/Minimal/Flash.c
in your
> build, then start the tasks from main(), so main() looks something
like
> this:
>
> int main (void)
> {
> ____/* This should call vParTestInitialise() to setup the LEDs. */
> ____prvSetupHardware();
>
> ____/* Start the standard flash demo application tasks. */
> ____vStartLEDFlashTasks( mainLED_TASK_PRIORITY );
>
> ____/* Finally start the scheduler. */
> ____vTaskStartScheduler();
>
> ____/* Should not get here as the processor is now under
> ____control of the scheduler! */
>
> ____return 0;
> }
>
>
> Does this work on you system (the LEDs should just flash at
different fixed
> frequencies)? If so then you could try some of the standard demo
queue
> functions.
>
>
> Regards,
> Richard.
>
> + http://www.FreeRTOS.org
> 14 official architecture ports, 1000 downloads per week.
>
> + http://www.SafeRTOS.com
> Certified by T as meeting the requirements for safety related
systems.
>



Start a New Thread

> Yes. That's why I want to use the cooperative mode. These two tasks
> block on xQueueReceive() (I believe this is a blocking call). I have
> no other tasks running, although these two are implemented as
> infinite loops. So they are waiting for elements to arrive on the
> queue. When one element arrives, they should unblock, do the job and
> then block again waiting for another element. I have tried this with
> a single task, but the system behaved exactly the same. It locked. I
> think there might be something I'm missing...

If you are blocking on the queue then this will cause a context switch away
from the task. If you post to the queue from an interrupt (using the
appropriate xFromISR() function), then this will unblock the task.

Just setting the configUSE_PREEMPTION parameter should be enough. Have you
made any changes to the kernel code at all?

Have you run some of the standard demo tasks in cooperative mode? The
simples to start with are the flash tasks. If you are not using the same
hardware as per the FreeRTOS.org demo you will first need to update
partest.c so that it toggles the LEDs that are available on your board.
Once you are sure the LED toggle functions are working, try including the
standard flash tasks.

You can test the partest.c functionality by using a very simple loop that
does not use the kernel - so place the following code before the call to
start the kernel:

volatile unsigned long ul;
for( ;; )
{
____for( ul = 0; ul < 0xfffff; ul++ ); // Basic delay.
____vParTestToggleLED( 0 );
____vParTestToggleLED( 1 );
____vParTestToggleLED( 2 );
____vParTestToggleLED( 3 );
}

Once this is working, include FreeRTOS/Demo/Common/Minimal/Flash.c in your
build, then start the tasks from main(), so main() looks something like
this:

int main (void)
{
____/* This should call vParTestInitialise() to setup the LEDs. */
____prvSetupHardware();

____/* Start the standard flash demo application tasks. */
____vStartLEDFlashTasks( mainLED_TASK_PRIORITY );

____/* Finally start the scheduler. */
____vTaskStartScheduler();

____/* Should not get here as the processor is now under
____control of the scheduler! */

____return 0;
}
Does this work on you system (the LEDs should just flash at different fixed
frequencies)? If so then you could try some of the standard demo queue
functions.
Regards,
Richard.

+ http://www.FreeRTOS.org
14 official architecture ports, 1000 downloads per week.

+ http://www.SafeRTOS.com
Certified by T as meeting the requirements for safety related systems.



Start a New Thread

Yes. That's why I want to use the cooperative mode. These two tasks
block on xQueueReceive() (I believe this is a blocking call). I have
no other tasks running, although these two are implemented as
infinite loops. So they are waiting for elements to arrive on the
queue. When one element arrives, they should unblock, do the job and
then block again waiting for another element. I have tried this with
a single task, but the system behaved exactly the same. It locked. I
think there might be something I'm missing...
--- In A..., "Mark Bayern" wrote:
>
> IME biggest difference between preemptive and cooperative is how and
> when the task switch occurs. Remember that in cooperative mode,
> "Context switches only occur if a task blocks, or explicitly calls
> taskYIELD()". Do your tasks explicitly call taskYIELD()? If a task
is
> just an infinite loop, it will never give up control. Preemptive
mode
> will pre-empt the task anyway. Cooperative mode will not.
>
> Mark
> On Dec 19, 2007 6:39 AM, axl_dudu wrote:
> > Hello,
> > I'm trying to run the FreeRTOS in cooperative mode. I have two
tasks
> > that block waiting on two queues. The queues are fed from two
interrupt
> > routines. They run well on the FreeRTOS in preemptive mode, but
the
> > system seems to lock in cooperative mode. The two tasks have
identical
> > priorities ( idletaskpriority+1 ).
> > I have changed the configUSE_PREEMPTION to 0 in
FreeRTOSConfig.h . Are
> > there any other changes I should make in order to run the kernel
in
> > cooperative mode?
> >
> > Thanks,
> > Tudor
> >
> >
> >
> >
> > Start a New Thread

IME biggest difference between preemptive and cooperative is how and
when the task switch occurs. Remember that in cooperative mode,
"Context switches only occur if a task blocks, or explicitly calls
taskYIELD()". Do your tasks explicitly call taskYIELD()? If a task is
just an infinite loop, it will never give up control. Preemptive mode
will pre-empt the task anyway. Cooperative mode will not.

Mark
On Dec 19, 2007 6:39 AM, axl_dudu wrote:
> Hello,
> I'm trying to run the FreeRTOS in cooperative mode. I have two tasks
> that block waiting on two queues. The queues are fed from two interrupt
> routines. They run well on the FreeRTOS in preemptive mode, but the
> system seems to lock in cooperative mode. The two tasks have identical
> priorities ( idletaskpriority+1 ).
> I have changed the configUSE_PREEMPTION to 0 in FreeRTOSConfig.h . Are
> there any other changes I should make in order to run the kernel in
> cooperative mode?
>
> Thanks,
> Tudor
> Start a New Thread