recommendation on task prioritization

[stevech]

The ZBasic program I've developed works perfectly except for one thing: one of the tasks that must run every 250mSec sometimes does not. This happens when other tasks are sending a lot of data (about 5 lines of text, about 30 chars per line) out the hardware uart at 19.2K. Creating this uart output does a lot of formatting of numbers, etc., so there's quite a bit of math. I did code up a special console.output which does a sleep if it's hogging RAM, as shown below, but it didn't cure the problem.

I'm looking for suggestions on how to prioritize this one special task. Each time it runs, it does very little code, no calculations, then again calls waitForInterrupt().

I have been assuming that preemption in task scheduling would save my bacon, as they say.

EDIT: I also have two tasks that interrupt 300 times per second. At each interrupt, they increment a counter and that's all. My issue is that every 1/4 second a task is checking to see how many interrupts happened - and the number is too small. It makes more sense, since the numbers are small, that in that 1/4 or more second that too many of the 300x2 interrupts per second were lost.

I don't have any lockTask() sections that do I/O that might block. I do use lockTask() for one line of code in the task that wakes up upon interrupt so that it's manipulation of the integer is assuredly atomic.

[dkinzer]

The Console.WriteLine() may be causing the problem. This routine, along with Debug.Print and Console.Write(), essentially locks the calling task until the string is completely transferred to the queue. The default output queue is fairly small - it only has space for a few characters. That means that, worst case, the call will require (N * 10) / baud seconds to complete. At 19.2K baud, each character requires 0.5mS to transmit.

In comparison, an interrupt at 300Hz represents a period of 3.3mS. Waiting for the outputting more than 6 characters or so will cause you to miss servicing at least one of the two interrupts.

You may be able to solve this problem by defining a generous output queue and using OpenCom() to assign the queue to Com1. If the queue has plenty of space each time Console.WriteLine() is invoked it will copy the data to the queue and return immediately rather than having to wait for most of the characters to be transmitted.

[stevech]

Thanks for the comments, Don...
I'm doing the serial output from main(); the two tasks that loop on WaitForInterrupt() 300 times/sec are of course not main, and they do no serial I/O. So I hopefully assummed correctly that if main() blocks on console.write, this would not add latency to the two high rate tasks.

As I read the the documentation, the tasks sleeping on waitForInterrupt() will be put in the head of the ready-to-run queue in the scheduler. Literally? Always ahead of all others? And if I do a locktask() right after waitForInterrupt(), does that task risk being rescheduled due to that system call?

[dkinzer]

[dkinzer]

[stevech]

an "interrupt task" is one suspended in a WaitForInterrupt(), right? Once that task resumes, it is an ordinary task, right?

So it will preempt even a locked task. Hmmm. This makes exclusion a bit more tricky than I had done. I hate to see the interrupt task loop and delay on a semaphore to get mutual exclusion with another task that is accessing the same multi-byte datum.

secondly, please clarify for this code

call waitForInterrupt()
call lockTask()

if the second line of code could cause the (interrupt task?) to lose control and be preempted by the scheduler.

( I'm feeling like we're talking about a heavy duty RTOS on a minicomputer here, rather than an itty bitty 8 bit micro)

[dkinzer]

[stevech]

thanks - now off to er, improve my design!

[spamiam]

I have been following this thread with some interest. I have not been brave enough to attempt multiple high-rate interrupt tasks, along with complicated foreground math and comm.

I am not sure I understand the essence of your problem.

It sounds as if you are losing interrupts in the 300Hz inputs

This seems to be due to latency plus the console functions locking (all?) interrupts. Is this correct?

I do not understand how a higher-level task locking will help in this instance. Is one 300Hz task interrupting the other? Or is the console comm function locking out everything, including the high rate interrupts.

Have you considered the possibility of skinning the cat in another way? Maybe use the counter functions of a timer? I think you may have said that all the timers are in use, so it may not be possible. Plus, you might have only 1 timer available anyway!

-Tony

[stevech]

The challenges I'm facing are two:

1. 300 interrupts per second times two sources = 600 task schedules per second. I've tried to code each task to be as brief as possible.

2. Each task that awakes from waitForInterrupt() has to alter global variables. I'm trying to figure a way to provide atomic access and mutual exclusion between the interrupt task and any other task. After the interrupt task is scheduled to awake and run, it is like any other task. So it can be preempted without a lockTask(), adding more overhead.

The 300 x 2 interrupts/sec are produced by external hardware.

So what I did is move code into the "interrupt response" task that was previously in a different task, making the interrupt longer to run and then sleep again, but eliminating the need for exclusion. I think.

I am still seeing lots of lost interrupts when some task does console.write. One or two lines of output doesn't hurt; but 5 or 10 causes the interrupt counters to show that 1/4 of the interrupts were missed. A sleep() for each line of text didn't help. It's acting like the waitForInterrupt() task either isn't preempting the other task, or there is too much scheduler latency for what I'm trying to do at the VM code level.

In my application, this doesn't hurt. But for academic curiousisty, I'm trying to understand.

I may be asking too much of the VM - 600 task schedules per second is a lot. And meanwhile, the AVR is also getting 1024 interrupts/sec (I think) for the real time clock. Now those interrupts are no doubt handled in tight assembly language inside the VM, but it is a lot of context switching for the humble little microprocessor.

as to skinning the cat another way... I should revisit, but as I recall, there was no way to count pulses from two different streams

[dkinzer]

[spamiam]

[stevech]

how about this idea...

each of my 300Hz signals comes from an opto-isolator's NPN transistor output. Currently, the emitters are grounded and the collectors connect to the INT0 and INT1 pins.

If I connect each emitter to a different output bit of the AVR, I can tri-state the output to disable the transistor. Then, I connect the collectors together and tie these to the timer's external clock. Now I should be able to choose which pulse train goes into the counter (without adding chips).

The flaw in this might be that the Vce of the transitor adds to the Vout(Low) of the AVR and this might be too high of a voltage to qualify as a logic zero. Have to read the data sheets.

[spamiam]

It sounds as if it wil work. I would assume that "low" would be as high as 0.7V x 2 = 1.4V. I think that this still qualifies as "low" for the AVR hardware.

Does this mean that you are interested in only one interrupt source at a time?

-Tony

[dkinzer]