I don't use an RTOS because...

On Sat, 15 Jan 2005 08:32:01 +1100, Mike Harding
<mike_harding@nixspam.fastmail.fm> wrote:

>On Fri, 14 Jan 2005 16:14:25 +0000, Ian Bell <ruffrecords@yahoo.com>
>wrote:
[...]
>>99.999% of C library functions are irrelevant for small embedded systems so
>>what's to write?
>
>Agreed.
>
>I very occasionally use sprintf if there is an LCD but
>otherwise can't think of anything.

Ermmm...

strcpy?
strcmp?
strlen?
memcpy?
memset?
memcmp?
size_t?
offsetof?
ato(i|l)?
strto(l|ul)?
NULL?
assert?
ctype.h?
limits.h?
stdint.h?

sprintf is usually too large for the applications I work on.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

<posted & mailed>

Paul E. Bennett wrote:

> Elder Costa wrote:
> 
>> I have followed the thread with a great dose of interest. Though a small
>> system can be implemented with an infinite loop running the main tasks
>> and some interrupts to handle asynchronous events, I wonder how one
>> could handle more complex systems with no RTOS (or at least a
>> multithread cooperative scheduler) without getting into a big messy
>> buggy code. I guess it is not an mission impossible but I cannot see
>> clearly how to achieve it without a great effort and cost.
>> 
>> Thus I would appreciate hearing from you folks about the alternatives to
>> an RTOS, with some links to code or concepts if possible.
> 
> For the vast majority of embedded system control tasks you are likely not
> to really need a RTOS. Others have hinted that cooperative schedulers are
> simple to implement and can provide the necessary for a wide range of
> applications. I will add that progressing to a pre-emptive scheduler is
> not that much more difficult either (may be 4 or 5 pages of code rather
> than just one).
> 

But it is worth noting that there is a significant lowering of reliability
as soon as you move to a pre-emptive system.

Ian 
-- 
Ian Bell

Dave Hansen wrote:

> On Sat, 15 Jan 2005 08:32:01 +1100, Mike Harding
> <mike_harding@nixspam.fastmail.fm> wrote:
> 
>>On Fri, 14 Jan 2005 16:14:25 +0000, Ian Bell <ruffrecords@yahoo.com>
>>wrote:
> [...]
>>>99.999% of C library functions are irrelevant for small embedded systems
>>>so what's to write?
>>
>>Agreed.
>>
>>I very occasionally use sprintf if there is an LCD but
>>otherwise can't think of anything.
> 
> Ermmm...
> 
> strcpy?
> strcmp?
> strlen?

The above are extremely application dependent.

> memcpy?
> memset?
> memcmp?

There is never enough memory in a small embedded system for these to be
necessary.

> size_t?
> offsetof?
> ato(i|l)?
> strto(l|ul)?

Again extremely app dependent

> NULL?

This is a LIBRARY FUNCTION???

> assert?

Most definitely not.

> ctype.h?
> limits.h?
> stdint.h?

Nope.

> 
> sprintf is usually too large for the applications I work on.

Damn right it is.

Not to mention that A) most of the c library functions are so generalised
they contribute only bloat and B) it's bad enough finding bugs in you own
code without having to sort them out in the vendors Clib.

Ian

Ian
                  
-- 
Ian Bell

"Mike Harding" <mike_harding@nixspam.fastmail.fm> wrote in message
news:7begu0hs4og1ejke64f2s9r204riip0lrg@4ax.com...
> I very occasionally use sprintf if there is an LCD but
> otherwise can't think of anything.

Well, the moment you do 32 bit arithmetic on an 8-bitter, most likely a
library function is called...

Meindert

"Ian Bell" <ruffrecords@yahoo.com> wrote

> But it is worth noting that there is a significant lowering of reliability
> as soon as you move to a pre-emptive system.

Why?

-- 
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

Ian Bell wrote:

>But it is worth noting that there is a significant lowering of 
>reliability as soon as you move to a pre-emptive system.

I don't like them.  They are great for systems where you will
be running code that someone else wrote (example: desktop PC),
but if you control all of the software a cooperative scheduler
is usually batter than a preemptive scheduler for real-time.
Then again, perhaps I just haven't run into the kind of problem
that they solve; we all have limited experience.

On Fri, 14 Jan 2005 21:52:19 GMT, iddw@hotmail.com (Dave Hansen)
wrote:

>On Sat, 15 Jan 2005 08:32:01 +1100, Mike Harding
><mike_harding@nixspam.fastmail.fm> wrote:
>
>>On Fri, 14 Jan 2005 16:14:25 +0000, Ian Bell <ruffrecords@yahoo.com>
>>wrote:
>[...]
>>>99.999% of C library functions are irrelevant for small embedded systems so
>>>what's to write?
>>
>>Agreed.
>>
>>I very occasionally use sprintf if there is an LCD but
>>otherwise can't think of anything.
>
>Ermmm...
>
>strcpy?
>strcmp?
>strlen?
>memcpy?
>memset?
>memcmp?
>size_t?
>offsetof?
>ato(i|l)?
>strto(l|ul)?
>NULL?
>assert?
>ctype.h?
>limits.h?
>stdint.h?

Very rare that I would use any of the above.

If I want to copy memory (for example) two pointers usually do
the trick.

>sprintf is usually too large for the applications I work on.

It "usually" is for me too - that why I said " very occasionally"
but a number of compilers provide cut-down versions.

Mike Harding

On Sat, 15 Jan 2005 02:51:23 +0000, Guy Macon
<_see.web.page_@_www.guymacon.com_> wrote:

>Ian Bell wrote:
>
>>But it is worth noting that there is a significant lowering of 
>>reliability as soon as you move to a pre-emptive system.
>
>I don't like them.  They are great for systems where you will
>be running code that someone else wrote (example: desktop PC),
>but if you control all of the software a cooperative scheduler
>is usually batter than a preemptive scheduler for real-time.
>Then again, perhaps I just haven't run into the kind of problem
>that they solve; we all have limited experience.

Even with a simple foreground/background cooperative monitor, you
would have to call the monitor from the background task at frequent
intervals to check if the foreground task needs to be run (as a result
of external events and interrupts). In some complex low priority
background task, there is always the risk of failing to yield often
enough. 

However, in a pre-emptive system, you can put any complexity into the
lowest priority task (just above NULL task or as the NULL task
itself), without ever worrying about the execution times. This task
could even be written by programmers without multitasking experience.

Of course, you have to be very careful how often and for how long the
higher priority tasks execute, but as these are small and simple (or
at least they should be, the higher the priority is), this is not a
serious problem.

Paul
    

>Subject: Re: I don't use an RTOS because...
>From: "Meindert Sprang"

>"Mike Harding" <mike_harding@nixspam.fastmail.fm> wrote in message
>news:7begu0hs4og1ejke64f2s9r204riip0lrg@4ax.com...
>> I very occasionally use sprintf if there is an LCD but
>> otherwise can't think of anything.

>Well, the moment you do 32 bit arithmetic on an 8-bitter, most likely a
>library function is called...
>

Yes the maths library is the most usefull part.

Paul E. Bennett wrote:
> Elder Costa wrote:
>
> > I have followed the thread with a great dose of interest. Though a
small
> > system can be implemented with an infinite loop running the main
tasks
> > and some interrupts to handle asynchronous events, I wonder how one
> > could handle more complex systems with no RTOS (or at least a
> > multithread cooperative scheduler) without getting into a big messy
> > buggy code. I guess it is not an mission impossible but I cannot
see
> > clearly how to achieve it without a great effort and cost.
> >
> > Thus I would appreciate hearing from you folks about the
alternatives to
> > an RTOS, with some links to code or concepts if possible.
>
> For the vast majority of embedded system control tasks you are likely
not
> to really need a RTOS. Others have hinted that cooperative schedulers
are
> simple to implement and can provide the necessary for a wide range of

> applications. I will add that progressing to a pre-emptive scheduler
is not
> that much more difficult either (may be 4 or 5 pages of code rather
than
> just one).
>
> Alternatively, you can take a harder look at the application
requirements
> and decide to distruibute the problem over more processors (as one
other
> poster has already indicated). This keeps each individual embedded
> controller simpler no matter how complex the application seemed to
be. This
> sort of system factoring does have quite a big win. It may not suit
every
> part of the application but the parts it doesn't can be hived off
into
> another networked unit that contains a suitable RTOS for that part of
the
> application.
>
> The wins in factoring the system across multiple platforms are that,
with
> an adequately resilient interface spocification for each unit you can

> individually test the sub-functions in isolation to ensure they work
before
> geting them together. It also helps the position by allowing multiple
small
> (surgical) teams to work towards the common overall system goal.
>
> --
> ********************************************************************
> Paul E. Bennett ....................<email://peb@a...>
> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
> Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
> Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
> Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
> ********************************************************************

Distributing the problem over more processors simplifies each
controller, but you still have to make the total system work. It seems
your just moving the complexity somewhere else (interface
specification) and not really making the total system any less complex.