Re: So... What are the alternatives? Was: I don't use an RTOS because...

From: Steve at fivetrees (steve_at_NOSPAMTAfivetrees.com)
Date: 01/23/05 

Date: Sun, 23 Jan 2005 22:41:32 -0000

"Nicholas O. Lindan" <see@sig.com> wrote in message
news:8jTId.5008$cZ1.186@newsread2.news.atl.earthlink.net...
> "Steve at fivetrees" <steve@NOSPAMTAfivetrees.com> wrote
> > Years ago I designed PID temperature controllers. There were several
hard
> > real-time requirements, including:
> > - Sample rate was 4 (or 8) samples per second;
> > - Ratiometric ADC system;
> > - Measurement accuracy depended directly on the;
> > accuracy of the *time* spent measuring each input;
> > - Comms was RS485;
> > - Front-panel key activity had to be "snappy";
>
> Damn, that sounds familiar. I ran the development of the CE
> Taylor MicroScan/Fulscope/ERC - later the ABB Commander - line of PID
> controllers/recorders/recording controllers. What controller were
> you working on?

Company was West Instruments (then part of Gulton Industries, now part of
Danaher), and the product line was the West 3000 series - came out in
'84/'85, IIRC. I also worked on bits of various other product lines (2072,
Octet et al), but the 3000 series was my baby. The 3400 version was the
first 1/8-DIN micro-based self-tuning controller in that price range (around
£100), I'm told.

A while back I visited the West facility here in the UK for the first time
in many years, and was disconcerted and flattered to discover that many of
their product range were derived in some way from the West 3000 series, but
3 or 4 generations on. Suddenly I was a great-great-grandfather. I've rarely
felt so old.

> Started with an 8051 and an RTOS written in PLM/51 as the translation
> of one written in assembler for the 8x86.

Oooohhh... I *really* wanted PLM/51, but never managed to convince my boss
to let me move up out of assembler. Even then, code maintenance was a
problem, and I could see PLM/51 helping in that respect...

> I think the 'OS' part of the 'what is an RTOS?' debate is "_can_ you
> extract the scheduling code so it has nothing of the application
> in it and apply it to another application?"

Yes, I'd tend to agree. However - this is perhaps part of the whole issue of
code re-use. I typically do re-use the last version of my co-op scheduler as
the basis of a new design; thus it is continually improved and refined. It's
not a separate entity, and I typically do re-structure chunks of it to suit
the new application. So, to answer your question: yes and no ;).

This seems to me to be (or at least it's been my experience that it's)
typical for practical code re-use - source code gets re-used and refined
over time at source level. I think part of my distrust of commercial RTOSs
lies in the fact that they try to be all things to all people, a jack of all
trades (and arguably master of none). I tend to prefer to adapt something
that's proven and simple rather than buy in something that's unknown (to me
and my application) and complex. Apart from anything else, the learning
curve is easier - and there's plenty to bite you in a commercial RTOS (ask
NASA ;)).

That's got me thinking - actually, my problem is not with commercial RTOSs
per se - it's with 3rd-party code in general. I've just not had a lot of
luck with it. It's that old code quality issue I keep wittering on about....
<sigh>

Steve
http://www.fivetrees.com