Pumpkin, Inc.

Pumpkin User Forums

Short Delays

If you can't make Salvo do what you want it to do, post it here.

Short Delays

Postby luben » Sun Feb 11, 2001 9:43 am


I wonder what have to do if a short delay have to be executed.. like 60uS - 100uS. This time is not enough for the SALVO kernel to return the control of the task, but this time could be used from SALVO somehow.

What I feel could be possible to do is to make something like OS_Yield() but this will not give the control to the other tasks (if they are highest priority tasks) - the time should be used for the kernel only to calculates some of it's values and then bring the control back to the same task.

With two words - some SALVO operator that don't bring the control to the other tasks, but uses the uP recources to calculate SALVO variables.

The general idea of SALVO is to bring all resources of the processor to calculate some useful data and to avoid emty wait cycles. Separating the project to multiple tasks makes this posible. But one of the cases where this is hard to do is with short delays.

Maybe my idea is still not very clear and needs some time to ripe. But it's something like OS_Yield() with this small difference that returns the control to the same task. The power of uP should be point to calculate SALVO variables. What can I even now say is that this is like OS_Yield of task with priority that's is higher then any other.

Do you have any suggestions about short delays? What have I do with this "free" time?


Posts: 324
Joined: Sun Nov 19, 2000 12:00 am
Location: Sofia, Bulgaria

Re: Short Delays

Postby aek » Sun Feb 11, 2001 10:26 am

Well, let's look at a 4MHz PIC as an example (we do most testing at 4MHz) -- a PIC16C77 running Salvo's demod1 gets about 2,600 context switches/second. So let's say that it takes roughly 400us (and therefore 400 instruction cycles), on average, do do a complete context switch from one task to another (this is with 8 tasks in various states).

60-100us is "only" 60-100 instructions. In terms of Salvo's own housekeeping, if you can call it that, there isn't much to do -- only OSTimer() gets things done that quickly. Most operations are more like 150 cycles long. Plus, an interrupt save and restore in this application is 40-60 cycles. Therefore there really isn't anything we can be doing in 60-100us that can profit from some sort of "microdelay".

Note, of course, if you don't need accurate timing (i.e. you only need a minimum delay of 60-100us), then you can leave interrupts enabled during this microdelay, and the rest of your system can do something useful. That's one of the real benefits of Salvo -- it can happily coexist with complex interrupt schemes -- it can even be a sort of "secondary process" that takes a back seat to some high-rate interrupt stuff.

The real headscratcher is what to do with delays around 1,000 cycles. That's long enough to make it attractive to code in Salvo, but it's still a bit too much overhead for efficient use of the processor. That's why we recommend system ticks of around 5-20ms for 4MHz PICs.

So I think the answer to your question is "loop with interrupts enabled in your task". That way, timer and event processing can still occur (the foreground Salvo processes), even though task scheduling (the background process) is held up.

Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Return to Coding

Who is online

Users browsing this forum: No registered users and 1 guest