Task scheduler nightmare - please help

[UAVflightdirector]

Some kind of scheduled timing would help with various devices attached
to I2C, SPI and similar. They need millisecond type delays that do
not lock up processor resources.

A system timer that will callback a function after some delay would be
great.
There are a number of devices so there will be a number of timers.

The software already has a 1ms heartbeat timer which would be good to
re-use.
This heartbeat timer process can not be too highly loaded since it is
time critical (radio, servos etc..)

So, re-using the TTRIGGER software interrupt idea from matrixpilot
seems a good plan.

The 1ms heartbeat could have timers attached to it, triggering events
with TTRIGGER.

Then the TTRIGGER processes the events and calls the appropriate
callback function.

This is getting really messy really quickly.
It looks like I am building half of an RTOS.

I am starting to loose the plot with this task. Any help is
appreciated.

[Peter Hollands]

Matt,

Could say more about  the "Use Case"(s), that requires waiting for periods of a few milliseconds in more detail ?

I just quickly reviewed Bill's I2C magnetometer code, and was interested to see that he got by with a completely interrupt driven and  "state" based approach to that driver.

Best wishes, Pete

[Paul G.]

There are a number of ways to do this, callback's is not one of them
unless the routine is super short and then it should just be called
directly, the programming and sequence of events become critical, any
error produces a disaster. Two common ways are as follows - you can
use both at the same time.

1) In the 1 mSec timer interrupt set a whole word to 1's and let each
routine that needs one reset just its one back to 0, these can even be
combined to make a sequencer of sorts.
2) Have the 1mSec timer interrupt increment more than one timer word -
then compare for a value to call the routine and clear it in that
routine.

These check's would occur in the the routine the the processor idle's
in - waiting on interrupts or running these tasks. To some extent it
depends on just how timing critical the tasks are and how long they
take to run. May be a good idea to get a list together first so you
can map out what you need.

Paul

On Oct 30, 12:38 am, Peter Hollands <peter.holla...@gmail.com> wrote:
> Matt,
>
> Could say more about  the "Use Case"(s), that requires waiting for periods
> of a few milliseconds in more detail ?
>
> I just quickly reviewed Bill's I2C magnetometer code, and was interested to
> see that he got by with a completely interrupt driven and  "state" based
> approach to that driver.
>
> Best wishes, Pete
>
> On Sat, Oct 30, 2010 at 7:43 AM, UAVflightdirector <
>

[Crashmatt]

Pete,

I also looked through the magnetometer code. My worry is that this
technique is good if you only have one device on the bus. If you have
a few devices then things get more difficult.

Bus access:
Say there is an ADC on the bus. You have to start a conversion and
then come back some time later. It takes 100ms to convert.
Meanwhile there is the magentometer on the bus but it has to wait for
the ADC to finish.

Timing:
The baromemeter needs 60ms to startup, after which it is checked for
communication. If that fails, wait 10ms and then check again.

All of these need to be run in a low priority worker process to avoid
stalling time critical activities.

We are not hanging many devices from the ports right now. As the
sensor systems get busier, we will find more similar requirements.

A generic timer that schedules processes at reasonably accurate
intervals feel like it could be a useful tool.

I am probably trying to implement something far too complicated where
there is a simple answer. Thats why I need help and advice.

Regards Matt

[Crashmatt]

Paul,

A couple of interesting techniques there.

I would like the timer to only trigger certain events at the certain
intervals or times. For example:

LED update: 250ms repetative
Magnetomemeter update: 500ms repetative
ADC reading: 100ms delay
Unknown 1: xxms
Unknown2: yyms
etc...

Flag setting from the timer feels like the right way to do it. I am
not sure if the flags would be many variables or the flags as you
suggest. Bit manipulation on flags has a tendancy to be non atomic.

I have some code sketched out but I do not like how complex it is.

Regards Matt


On Oct 30, 11:52 am, "Paul G." <relborg2...@hotmail.com> wrote:

[Paul G.]

BCLR and INC are atomic but actually that's not the problem. The
corner case is when the instruction that's about to clear the bit or
word gets interrupted by the ISR that's going to set it again, the ISR
then return's and then the clear instruction executes and clears it.
Net result is the function runs but then misses for one full
millisecond but honestly in 99.99999% of applications this simply does
not matter and the only way this happens is if the CPU is not keeping
up anyway.

Anything that's actually attached to a module eg ADC should be
interrupt driven if possible, as in Pete's reference to the I2C module
above. You may want to start the routine from a timer if there is not
another method available but I'd try to avoid it. For example on our
boards we have the mag and accel on I2C but both chips have data ready
signals available so those are routed to interrupt capable pins, when
they have a new sample available service the interrupt in a state
machine like Bill's to get the result and start the next conversion -
that just continues forever. I know this may sound a bit counter
intuitive but remember a 33f at full speed is going to run 800
instructions during just one byte transfer on I2C so it may as well do
something constructive rather than poll a completion bit.

Updating LED's is a good one for soft timers, also sanity checks.

Paul

[UAVflightdirector]

Paul,

You are right about devices having hardware interrupts attached. That
fixes much of the problem. Soft timers might still be useful.

I now have some code built for doing soft timers:

The 1ms timer/heartbeat checks a set of soft timers. On timeout, it
sets an event.
The event handler is on a separate interrupt. This low priority
interrupt is triggered whenever an event is set.
The event handler calls a callback function for the event.
All events, callbacks and timers are registered at runtime. They do
not need coding for different builds (This bit I am happy with)
The device code registers whatever timers and events it needs.

It may not be useful but it was amusing to write.
I will distribute it when it is tested a little.

Regards Matt

[Peter Hollands]

Matt,

That sounds super. It's always satisfying to implement an idea like that into reality.

Best wishes, Pete