Searching \ for '[PIC]: SALVO RTOS robot examples' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'SALVO RTOS robot examples'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: SALVO RTOS robot examples'
2003\02\26@200325 by Bill Couture

picon face
Olin Lathrop <spam_OUTolin_piclistTakeThisOuTspamEMBEDINC.COM> 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

2003\02\27@012146 by John Temples

flavicon
face
> Olin Lathrop <.....olin_piclistKILLspamspam@spam@EMBEDINC.COM> 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.

I don't think anyone would argue that it's possible to write code with
Salvo that can do things that can't be done with the traditional "main
event loop" approach.  It simply gives you a way of expressing typical
embedded programming problems in a more concise and maintainable way
than the "main event loop."

On Wed, 26 Feb 2003, Bill Couture wrote:

{Quote hidden}

Your description makes it sound like a developer of dubious
qualifications wrote bad code which just happened to use Salvo.  It
doesn't seem fair to blame Salvo for this.

> 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.

In unqualified hands, Salvo certainly gives you even more rope to hang
yourself with.  Was your consultant was calling Salvo services from an
ISR without taking the necessary precautions?  The effects of this are
no different than when non-Salvo code calls the same functions from
ISR and main code -- unpredictable, inconsistent failures.  Salvo
probably makes these kinds of programming errors more catastrophic,
since pointers get corrupted.

I have one Salvo project on an 18F6720 that's ~20,000 lines of C
(including 17 Salvo tasks plus event flags, semaphores, and message
queues) that supports a 100-screen user interface with some 2,000
user-configurable settings, serial communications, bi-directional I2C
communications with 11 other PICs, RC5 infrared decoding, and various
external interrupts.  I ran into no issues with Salvo.

{Quote hidden}

The one time I've rewritten traditional "main event loop" code from
scratch using Salvo, the code size fell from 6.1 kwords to 5.2 kwords,
even with the added "overhead" of Salvo.

I think these examples just go to show that bad code can be written
with any set of development tools.

--
John W. Temples, III

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\27@204046 by Bill Couture

picon face
On Wed, 26 Feb 2003, John Temples wrote:

> On Wed, 26 Feb 2003, Bill Couture wrote:
>
> Your description makes it sound like a developer of dubious
> qualifications wrote bad code which just happened to use Salvo.  It
> doesn't seem fair to blame Salvo for this.

I don't know about you, but when I'm suddenly responsible for code
that I didn't write, I go over it with a fine-tooth comb.

When that was done, it wasn't up to code I'd have written from scratch,
but it was pretty much bug-free and reasonably efficient.

{Quote hidden}

No, Salvo wasn't being called from the ISR, and no local variables were
in use (for those who don't know, since PICC "sees" each Salvo task in
a different call-graph, it re-uses the local variable space, unless you
use the (sorry, I forget which) compiler flag that tells it not to do
that (which makes it use more RAM).  Thus, Salvo tasks (or their
subroutines) can trash the local variables in another Salvo task).

I'm pretty good about spotting the blindingly obvious.

> I have one Salvo project on an 18F6720 that's ~20,000 lines of C
> (including 17 Salvo tasks plus event flags, semaphores, and message
> queues) that supports a 100-screen user interface with some 2,000
> user-configurable settings, serial communications, bi-directional I2C
> communications with 11 other PICs, RC5 infrared decoding, and various
> external interrupts.  I ran into no issues with Salvo.

Gee... you're re-writing Micro$oft Windoz on a PIC?  :)

(You know, that *COULD* explain a *LOT* about Windoz!)

> The one time I've rewritten traditional "main event loop" code from
> scratch using Salvo, the code size fell from 6.1 kwords to 5.2 kwords,
> even with the added "overhead" of Salvo.
>
> I think these examples just go to show that bad code can be written
> with any set of development tools.

Yes, you just proved your point very well.  And mine, to boot.

Bill

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\02\27@224049 by John Temples

flavicon
face
On Thu, 27 Feb 2003, Bill Couture wrote:

> No, Salvo wasn't being called from the ISR, and no local variables were
> in use (for those who don't know, since PICC "sees" each Salvo task in
> a different call-graph, it re-uses the local variable space, unless you
> use the (sorry, I forget which) compiler flag that tells it not to do
> that (which makes it use more RAM).  Thus, Salvo tasks (or their
> subroutines) can trash the local variables in another Salvo task).

Any calls to Salvo context-switching routines in non-task functions?
That will randomly corrupt the call stack...

--
John W. Temples, III

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


'[PIC]: SALVO RTOS robot examples'
2003\03\02@125900 by Bill Couture
picon face
On Thu, 27 Feb 2003, John Temples wrote:

> > No, Salvo wasn't being called from the ISR, and no local variables were
> > in use (for those who don't know, since PICC "sees" each Salvo task in
> > a different call-graph, it re-uses the local variable space, unless you
> > use the (sorry, I forget which) compiler flag that tells it not to do
> > that (which makes it use more RAM).  Thus, Salvo tasks (or their
> > subroutines) can trash the local variables in another Salvo task).
>
> Any calls to Salvo context-switching routines in non-task functions?
> That will randomly corrupt the call stack...

Nope, the only Salvo calls were in the task itself, not a subroutine.

And, it didn't seem that the call stack was the problem (i.e., the tasks
seemed to be working).  I kept seeing things like putting a 0x12 into a
queue in one task, and getting a 0x00 out of the queue in another task.

Bill

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamKILLspammitvma.mit.edu>

2003\03\02@133728 by Bill Couture

picon face
As an interesting note:
 I did *NOT* receive this message via PICLIST.  I saw it on Google's
 "piclist" newgroup (which several people have argued should be
 shut down...)

{Quote hidden}

The people involved between my company and Salvo were:
  1) The consultant who decided that he was going to use Salvo.
     However, as a consultant, he couldn't spend company money on
     it.  This brought in...
  2) Another EE, who had used Salvo Lite in his personal projects,
     and spent the company money on it for the consultant.
  3) Myself, who looked at the manual and Salvo Lite, wrote the
     communications, buttons, LED's and such, and gave them to
     the consultant to be added to his code.

You would have been contacted by the consultant for tech support, and
by myself after he left.  If you had been contacted by anyone else, it
would have been the other EE, whos name was on the purchase.

> 2) There was little or no response or follow-up to many of the
>    suggestions we provided as guidance and/or possible technical
>    solutions to your problems.
>
> 3) We never received any projects and/or source code that we could use
>    for inspection, sample compilation etc.

I tried what you said, and when I sent you source material, the response
I got back gave me an "off-the-wall" comment that was obviously false,
some words that "things were being done correctly", and that since our
support had expired, that this would be the last tech support I received.
This came up just short of sounding like blackmail.

This left me with a couple of options:
  1) Tell managment that we need to spend money NOW, then continue
     emails and hope that the problem could be found quickly.
  2) Tear our Salvo.

Option 2 was quicker and cheaper.  Smaller, faster, more efficient code
was just a bonus.

> 4) You were migrating from Salvo v2 to Salvo v3.

False.  While the original purchase may have been Salvo 2, we updated to
Salvo 3 while the project was still in development, and ALL compiles, etc,
were done under Salvo 3.

> So, as a matter of course, PLEASE, when requesting tech suppprt,
> provide as much information as possible (complete, zip'd projects are
> best) so that we can get to the root of your problems quickly. We have
> a whole collection of customer projects here that we used to identify
> and solve problems. Most of them are issues with Salvo configuration,
> or interrupts on targets that have non-reentrant compilers like PICC
> and PICC-18.

Sending complete projects assumes that source code can be made available
outside the company.  This is often IMPOSSIBLE.

Also, it assumes that you have the correct version of the target compiler
available.  Hi-Tech wants you to remove all previous compiler versions
when you install a later version, so the version being used by any person
in the field may not be available to you.

Bill

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu>

2003\03\02@161139 by John Temples

flavicon
face
On Sun, 2 Mar 2003, Bill Couture wrote:

> Also, it assumes that you have the correct version of the target compiler
> available.  Hi-Tech wants you to remove all previous compiler versions
> when you install a later version, so the version being used by any person
> in the field may not be available to you.

They do "want" you to, but I suspect this is just to reduce their own
support headaches rather than any actual requirement of the compiler.
I have successfully had different versions installed at the same time
in different directories.  You just update the HTC_PIC18 environment
variable to point to the directory containing the version you want to
work with.

In any event, it's very unlikely that an issue you're having with
Salvo is related to the compiler version.

--
John W. Temples, III

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu>

2003\03\02@211155 by Bill Couture

picon face
On Sun, 2 Mar 2003, John Temples wrote:

> In any event, it's very unlikely that an issue you're having with
> Salvo is related to the compiler version.

Yes, but using the same compiler version makes it much easier to
reproduce the problem.

Bill

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu>

2003\03\03@084815 by Alex Holden

flavicon
face
On Sun, 2003-03-02 at 18:37, Bill Couture wrote:
> As an interesting note:
>   I did *NOT* receive this message via PICLIST.  I saw it on Google's
>   "piclist" newgroup (which several people have argued should be
>   shut down...)

Wow, I didn't even know that existed. I just found that thread that I
previously spent an hour failing to find using the piclist.com search
engine in literally less than a minute of searching on Google Groups :)

The search page is here:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&group=comp.arch.embedded.piclist

--
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\03\03@120736 by Olin Lathrop

face picon face
> Wow, I didn't even know that existed. I just found that thread that I
> previously spent an hour failing to find using the piclist.com search
> engine in literally less than a minute of searching on Google Groups :)
>
> The search page is here:
>
groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&group=comp.arc
h.embedded.piclist

I didn't know about this either and find it rather disturbing.

I am quite sure we were promised a while back (maybe a couple of years)
that PIClist posts would be archived privately and you had to be a member
to search and access the archives.  To become a member you had to aggree,
among other things, not to spam email addresses received via the PIClist
or found in its archives.  I don't remember ever hearing that this policy
had changed, and feel quite betrayed.  All posts are apparently open for
anyone to search and mine for email addresses.

It also bothers me that posts assumed to be readable only by a selected
group of people are publicly available.  It's like having a private
conversation with a friend to find out later the friend secretly recorded
it and is playing it back to everyone else behind your back.  Whether you
said anything embarassing or not isn't the point.  It's the betrayal of
trust that matters.

I probably would have written fewer and shorter posts if I had know they
would be publicly distributed.  I will probably do so in the future.

James, could you please comment on what is going on here?


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\03\03@123845 by Alex Holden

flavicon
face
On Mon, 2003-03-03 at 17:04, Olin Lathrop wrote:
> had changed, and feel quite betrayed.  All posts are apparently open for
> anyone to search and mine for email addresses.

It looks like the email addresses are obfuscated in various randomly
chosen ways to make them hard to extract.

> It also bothers me that posts assumed to be readable only by a selected
> group of people are publicly available.  It's like having a private

They've always been publicly available- you just have to register first
(but you could use false details and a hotmail account if you wanted to
remain completely anonymous).

--
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\03\03@124055 by John Dammeyer

flavicon
face
Seems like it should be fairly easy to deal with.

First, check to see if it's really on the Usenet as
comp.arch.embedded.piclist or if that's a google name.  It does look
like it's made it onto the usenet forum comp.arch.embedded.piclist .  If
so,  contact the usenet administrators as forums require some sort of
body to create the entry.  They should have a record of who requested
that the forum be created and who is posting.

However,  this set of requests has to come from the list owner otherwise
why would google even listen?

John Dammeyer


Wireless CAN with the CANRF module now available.
http://www.autoartisans.com/products
Automation Artisans Inc.
Ph. 1 250 544 4950


> {Original Message removed}

2003\03\07@220525 by SM Ling

picon face
> Seems like it should be fairly easy to deal with.
>
> First, check to see if it's really on the Usenet as
> comp.arch.embedded.piclist or if that's a google name.  It does look
> like it's made it onto the usenet forum comp.arch.embedded.piclist .  If
> so,  contact the usenet administrators as forums require some sort of
> body to create the entry.  They should have a record of who requested
> that the forum be created and who is posting.
>
> However,  this set of requests has to come from the list owner otherwise
> why would google even listen?
>
> John Dammeyer

John,

I did a little search, found a call-for-vote for the formation of
"comp.arch.embedded" in 1995.  But could/have not found out how the sub-sub
group was being formed yet.

If you know a faster way, care to dig it out and shed some light here.
There should be many interested to know.

SM

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu>

More... (looser matching)
- Last day of these posts
- In 2003 , 2004 only
- Today
- New search...