Task "Flapping"

nobody wrote on Friday, December 09, 2005:

Hello,

I have a task that ‘flaps’ in the following
fashion:

run 1 - takes ~ 800 us
run 2 - takes ~ 40ms
run 3 - 800us
run 4 - 40ms…

Any ideas on what makes a task flap like this?

I’ve checked my tick isr - it’s ok.

I’m using FreeRTOS in preemptive mode - and I
don’t have any other tasks with the same priority
as the task that ‘flaps’ - the “flapper”
is the highest priority task in the system.

Thanks In Advance.

nobody wrote on Saturday, December 10, 2005:

Some questions:

+ Which processor are you using?  Is there a cache?

+ Can you provide more details on the structure of the task - just an outline if you can’t provide the code itself?

+ Does the task block on any event?

+ What other interrupt routines are running.

Thanks.

nobody wrote on Saturday, December 10, 2005:

MSP430 - no cache - at least not that I’m aware of in the architecture.

Simple task -

task()

{

for (ever)
{

xTaskDelayUntil()
call some stuff  (ADC functions)

}
}

Just blocks on vTaskDelayUntil()

Timer, UART0, Idle - that’s about it.

Thanks.

nobody wrote on Saturday, December 10, 2005:

Does the ADC stuff poll for a conversion complete?  Maybe you can time the ADC stuff to see if this is the problem.

Other than that, check the parameters to xTadkDelayUntil() are as per the demo.

nobody wrote on Sunday, December 11, 2005:

Yes, the ADC stuff does poll.  Do you think I should change this to an ISR?

I thought the polling time would be somewhat of a constant - not that it would vary by 39.2 ms - maybe I’m wrong.

I thought the ADC’s on the 430 were much faster than this…  even running at 1024 sample&hold - you’re only talking about something around 128us
if running at 8MHz - correct?  So the 800us looks
like more than enough time unless this is some sort of glitch.

Thanks In Advance.

nobody wrote on Sunday, December 11, 2005:

also - parameters to xTaskDelayUntil() are ok.

Thanks.

nobody wrote on Sunday, December 11, 2005:

The ADC should be much faster than that - but I think this is the place to start looking for the problem.  Take some timings and see what you get.

nobody wrote on Tuesday, December 13, 2005:

Allrighty - will do and will report back…

nobody wrote on Tuesday, December 13, 2005:

ADC code is taking 8.4ms…seems a bit slow.
This includes getting the ADC12MEM and saving it off…

nobody wrote on Tuesday, December 13, 2005:

Code that does the actual measuring is taking
304 us - seems more reasonable.  I guess there’s
too much time being taken in moving this around
in memory.

I’m going to see what can be done to speed off how
this gets from ADC mem to program mem…