Olin Lathrop wrote: >I didn't say it wasn't possible, only that it was not a good idea. Your own >statement confirms this if I understand it right. I assume by 2500 context >switches you mean that the tasks are doing nothing but immediately yeilding >the processor to the next task. If so, that means it takes Salvo 400 >instruction cycles to switch between tasks. This sounds VERY high. I have >occasionally used macros for this on the 16C family, and I doubt they even >take 40 instructions. Your assumptions are somewhat correct -- here are the corrections: 1) The demo is for the base Salvo version, which uses priority queues to manage tasks. For 8 tasks doing real work (not just immediately yielding, but most of the tasks are waiting on an event or are delayed or timed out, so they don't, on average, use up too many extraneous cycles that would affect the context-switching rate), yep, the number is around 400 instructions. Salvo can also be configured to use priority arrays, in which case the numbers drop to around 120-160 cycles independent of the number of tasks. The maximum amount of time that interrupts are disabled is roughly half that. 2) I too, can write ASM or C code to make "tasks" "context switch" in 40 cycles. But not when I'm supporting priorities, multiple task states (waiting, delayed, stopped, eligible, timed out, etc.). We're talking apples and oranges here. The point of Salvo is to bring a high-level programmer's toolset (C, RTOS, integrated development environment) into the realm of the PIC in order to reduce time-to-market. >I imagine this huge discrepancy comes from the fact that you are writing a >general RTOS that has to be ready for anything, whereas my macros do just >what I need them to and otherwise get out of the way as quickly as possible. Absolutely. We wrote Salvo for the general case, and it's turning out to be extremely applicable across the board. >What this really points out is the absurdity of trying to use an RTOS on >processors like the 16xxx PIC family. Hardly -- in fact, just the opposite. But I'll let Salvo users and the chip manufacturers and tool vendors who have taken a keen interest in Salvo speak to this point. See us at ESC2001 West. As before, we'll be in the HI-TECH booth. >Your statement "fully priority-and event-based cooperative multitasking >context-switches" might leave some people with the wrong impression. Why? It does exactly what it says. And while some may take issue with "context-switch" vs. "task switch", in the case of the PIC and Salvo they are one and the same, as the PIC's context is so little (W, PCLATH, FSR, STATUS) and is transparent to the (Salvo) user. >Since the software can't access the stack on the 16xxx family, there >must be some >restrictions on your tasks. I imagine you can't "call" YIELD inside a >subroutine, right? Or do you get around the stack access problem in a >different way that results in different restritions? You're exactly right -- tasks can only context-switch at the task level (due to the lack of a general-purpose software stack on the PIC12/PIC16/PIC17), and each task must context-switch at least once. There will always be applications where Salvo, and even C, simply can't be used because you're extracting every last micro-MIP out of a PIC at the slowest possible clock speed, and absolutely no overhead can be tolerated. There are many people on this list (you included, I presume) who are eminently capable of writing such code, and their skillset is impressive. But for the rest / majority of PIC programmers, without the years of assembly-level programming that you and I have, how you get the job done is often less important than how quickly you get it done, and how you can then leverage that time against your competition, etc. That is one of the more important things Salvo brings to the table. We've encountered substantial resistance to the notion of an RTOS running on a PIC. But after people see it in action, many turn 180 degrees and run with it, pleasantly surprised at how useful a tool Salvo is. Finally, I'll close with a recent customer "testimonial", and invite anyone who's read this far to visit our website, download the demo / freeware version, peruse or even read the whole manual, and contact Pumpkin with any questions. You will need a working C compiler (currently only HI-TECH PIC C). "The new application has a core of about half of the code from the old application. It took about 2 days to convert it to Salvo and modify it for the new hardware as well as add some new bits (cpu driven multiplexed LED display instead of character LCD). It took one day to get a build (should have taken 1 hour). It took just one day to get the code running on the new hardware. Now that's a LONG way short of 8 months!!! And it is shaping up to be lean and mean - 2k words sofar for 6 tasks and 6 events and only a few more tasks to add. Well done - I am impressed with Salvo sofar. The ability to standardize the way in which multitasking applications are written and structured is very appealing to me. It enables me to incorporate important extensions to standard methodology and conventions into my iso9001 procedures manual." I couldn't have said it better myself. I hope that this post has been within the acceptable posting standards for the PICList. Regards, -- ______________________________________ Andrew E. Kalman, Ph.D. aek@pumpkininc.com -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.