fnInterruptMessage

[neil]

Hi Mark,
  I have a task that has to do 1000 checks, but instead of doing them all in one task I was thinking of seperating each check by using the fnInterruptMessage command. After each check I would call fnInterruptMessage, then do the next one , and so on until all 1000 are completed.

After the fnInterruptMessage is called, will the task be called straight away or is it put at the back of the list of tasks to be carried out?

Neil

[mark]

Hi Neil

The next task scheduling is always after all other task have had the chance to run (back of the list). But, since you effectively put an event in teh input queue make sure that you don't call it while in the read loop otherwise it will immediately service it without quitting...

However you can do the same thing by switching your task to polling mode. This means that it will also be run on each scheduling loop. After you have done all checks you can then switch back to event driven mode. This saves posting the interrupt messages (but doesn't result in a specific interrupt event on each entry).

        uTaskerStateChange(OWN_TASK, UTASKER_GO);     // switch to polling mode
        uTaskerStateChange(OWN_TASK, UTASKER_STOP); // return to event driven mode

Both methods should however result in much the same effect.

Regards

Mark

[neil]

Hi Mark,
  Thanks , I will do the state change method.

Within the UTASKTABLEINIT , I set the task as follows:
const UTASKTABLEINIT ctTaskTable[] = {
    { "SampleChannels", fnSampleChannels, SMALL_QUE, (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_STOP},
  ...
}

How do I know what to set the QUEUE_TRANSFER too? I have set it to small.

Regards
Neil

[mark]

Hi Neil

The queue size depends on what you expect the task to receive in terms of messages (eg. an interrupt event required 5 bytes). If you don't actually need any input queue you can set it to 0. Otherwise it should have enough space to hold the maximum expected number of messages (and their expected sizes) to be received before they can be handled. If there is no (more) queue space available a message will be lost, so this should be avoided with a small reserve margin.

Regards

Mark