Olin Lathrop wrote: >You should also step back and ask yourself why you think you want an RTOS >on a PIC, and if so, what limited set of RTOS-like features you really >want. Despite the hype from Salvo and their habit of belittleing any >code that doesn't use an RTOS, it is still doubtful these are of any real >advantage on small processors like PICs. I haven't seen anything yet that >hasn't been handled quite nicely by a simple foreground event loop >architecture. The closest I've gotten to RTOS-like features is creating a >psuedo-thread for handling an input stream such as from a host via the >UART. If that's all you need, you can get it for free. See the >HOS_CMD.ASPIC module of the HOS PIC project at >http://www.embedinc.com/pic/hos.htm. >That same project also has an example of a simple event loop in the >HOS_MAIN.ASPIC module. I've been meaning to post this both here and in Hi-Tech's PICC forum, but just haven't done it. After seeing this thread, though, it's time. I can give you a real-world example of using Salvo, and it is *NOT* pretty. An EE at work insisted that he "knew how to write code", and that since this PIC was going to be controlling his hardware, the control software was just an extension of the hardware. And, to make a simple task more complex, he decided to use Salvo. Despite my objections, he was allowed to proceede. I was left writing the serial I/O and such. The economy being what it is, this EE got downsized (he was a consultant). As the only person who knew ANYTHING about this software, I was now responsible for it in it's entirety. And the bugs started showing themselves. "Phase of moon errors" that couldn't be duplicated, but had devistating results (like the EEPROM, with all the calibration data, being wiped out). This is on an 18F452, and it has a couple of known hardware errata. Armed with my "most reliable" crashing unit, I started trying to pin down what was happening. Several weeks of management being severly pissed at me, and a dozen or so debugging iterations, I had pretty much ruled out the hardware errata. From what I found, my best guess was a bad pointer or index. This software does not use *ANY* pointers, and all array indices are fully checked before use. This points right to Salvo. Salvo TechSupport was pretty useless. While I have to admit that our support period had expired, it would have been nice if the response I was given wasn't obviously wrong. Another EE at work who says he uses Salvo Lite for home projects was saying how easy Salvo was to use, but when I asked him for help, he begged off, saying that someone as smart as I was could learn all about Salvo in a couple of hours. Well, in that "couple of hours" I performed an Exorcism. I didn't have time to re-write things from scratch, but I did remove Salvo. This took two trivial state machines, a couple of countdown timers, and some re-arranging of function calls. And the real-world results? * Program sized was reduced by 20% * Memory usage was reduced by 33% * Program response delay was reduced by 50% (turnaround from end-of-receipt of RS232 message to start of reply dropped from 1ms to 500us). * All mysterious symptoms vanished (even one I hadn't associated with Salvo yet). Plus, the implicit "end-of-time" bug when Salvo's 32-bit time counter rolled over at 99.5 days vanished. Besides the cost of Salvo itself, trying to use it cost my company weeks of time and *MANY THOUSANDS OF DOLLARS*. Add in the cost of larger, faster processors to make up for Salvo's program, RAM, and processing overhead, and Salvo is just a lose/lose proposition. Bill -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads