context switching

[Jake]

The split-int-priority scheme is a good idea. How do you disable the Salvo so that it does not interfere with the interrupt and then give control back again? Are there any examples you have that shows how this can be done? Can this be done with the demo version of Salvo?

[aek]

Hi Jake.

quote:

---

How do you disable the Salvo so that it does not interfere with the interrupt and then give control back again?

---

See page 10 of RM-MCC18.PDF

quote:

---

Are there any examples you have that shows how this can be done?

---

We haven't written an App Note that illustrates this yet, sadly. You'll have to ruminate over what I wrote below

quote:

---

Can this be done with the demo version of Salvo?

---

No, as per below, we can build you a custom Salvo Lite lib that does this, for your eval purposes. So, pick a library that you like (like sfc18sft.lib, or something) and we can build you one that only disables low-priority interrupts. See the Libraries chapter of the Salvo User Manual on using custom libraries.

------------------

[This message has been edited by aek (edited January 07, 2004).]

[Jake]

I'm using the sfc18sfa.lib so please modify this one for me. Thanks for you help.
Can I get a quote for the Salvo LE version?

[aek]

Hi Jake.

sfc18sfa-clc1.lib is on its way ...

See the Libraries chapter of the Salvo User Manual on how to use the library and the associated salvoclc1.h header file, and where to put the files ...

Also, please note that you'll need Salvo Pro to generate your own custom libraries, and for custom library support.

------------------

[This message has been edited by aek (edited January 07, 2004).]

[Jake]

So what you're saying is I'll need to get the Salvo Pro to do what I'm trying to do. The LE will not allow the interrupt to be controlled?

[aek]

Hi Jake.

Yes, because you need access to the Salvo source code (Pro only) in order for the changes in OSPIC18_INTERRUPT_MASK to have an effect on all of the Salvo services that are in the libraries.

------------------

[Jake]

How fast is the context switch from task to task? I'm running the PIC18F4320 at 24Mhz and the fastest it seems to switch is 100uS. Does that seem right? Does the switching slow down as I add more and more tasks?

[aek]

Hi Jake.

Which compiler?

100us @ 24MHz is too slow, I think. PICC-18's fastest context switches are around 100-150 cycles (IIRC), and MPLAB-C18 ones will be slower because there are some additional functions involved.

For example, Salvo's demod1 application (unfortunately, a Salvo Pro build only) gets around 2500 ctxSw/s @ 4MHz when built with PICC.

The issue of context-switching speed is rather complex, as it's dependent on the compiler used, the task's priority, and whatever operations are required to complete the context switch (e.g. re-enqueuing a task into the eligible queue).

Your best bet to evaluate the context-switching speed is to create your own Salvo Lite test application, with carefully selected breakpoints and task definitions, and then get numbers from that. The "space" of available configurations is simply too large for us to create a meaningful set of benchmarks.

I would also suggest that a focus on context-switching speed is missing the point (somewhat). In a cooperative system like Salvo, your task-to-task switching speed will be greatly influenced by what you're doing in the task itself, and so the context-switching speed is not as useful a metric as it is in a preemptive RTOS.

Note also that in a well-written Salvo app where at any moment, most of the tasks are waiting or delayed, and only a small number are eligible to run (and none sit around and just OS_Yield()), the context-switching time approaches the ideal (one task only) because the rest of the system is idle, waiting for an event to happen.

Salvo on the PIC is our most popular distribution, and context-switching speed is pretty much a non-issue with existing users.

------------------

[Jake]

I'm using the MPLAB C18 v2.20 compiler. This is what I'm trying to do. Inside the OSIdlingHook() I'm putting the PIC to sleep and waking it up to sample an A2D input every 100us. The signal I'm sampling is 10kHz. It has a 120us "hi" header then toggles every 50us. When the pic wakes up and detects a "hi" it signals a valid signal. Then the scheduler switches to the task needed to sample the rest of the signal. But the 100uS switch time would cause me to miss some of the signal. This signal cannot be missed it should have the highest priorty. Should I just put everything in OSIdlingHook() instead of creating a new task? That doesn't seem right.

[aek]

Hi Jake.

Hmmm .... here's the deal. We recommend that one set Salvo's timer ticks to a minimum of 2,000 instruction cycles, with a preferred value of 10,000 instruction cycles. That way, Salvo's overhead is dwarfed by the time between ticks. Now, your application doesn't use delays (AFAIK), but the idea is still applicable -- you need some "processing headroom" to let Salvo do its stuff (worst-case timing), and high-rate continuous interrupts (that cannot tolerate substantial interrupt latency) are generally incompatible with this approach.

100us @ 24MHz is 600 instructions on the PIC18. With ISR overhead, etc. that's not enough "instruction cycle margin" for you to pass on control of the program to Salvo -- you will get bitten sooner or later. Sooner, likely.

You're right to put the PIC to sleep from within the OSIdlingHook().

If you were sampling at 100Hz or even 200-500Hz, then the task-based approach would probably work. But you're at 10kHz, and that's just too fast.

So, what you would do instead (and this is what many of our PIC18 customers do) is dedicate the high-priority interrupts to handling stuff like a 10kHz int, and configure Salvo to only disable (and therefore only interact with) low-priority interrupts. That way, you pass off the high-speed stuff to ISRs and it runs without any interference from Salvo, and then you do the lower-speed stuff with Salvo (e.g. RS-232, user interface, etc).

Salvo's libraries for PIC18 are built by default to disable GIEH and GIEL. If you want, we can build you a custom Salvo Lite library that just disables GIEL -- let me know which one you want if you want to evaluate it thusly.

------------------