I have wondered for a while why the various C compilers available do 
not provide a simple multitasking environment. I gather you have to 
go to 3rd party sources to add this facility. But surely if one of 
the C Compiler suppliers did supply a small core then this would be 
a bit of a marketing advantage?
Can someone explain if/why there is a problem of doing this?

Hi Graham,

> I have wondered for a while why the various C
compilers available do 
> not provide a simple multitasking environment. I gather you have to 
> go to 3rd party sources to add this facility. But surely if one of 
> the C Compiler suppliers did supply a small core then this would be 
> a bit of a marketing advantage?
> Can someone explain if/why there is a problem of doing this?

I can explain our current take on this, and then you can make up your
own mind.

Firstly, our company is a development tools company.  We make it
possible for customers to use our software to get their projects out the
door.  We focus on that core very well, providing compilation and
debugging tools.  Now, if we created an RTOS, that would detract from
our core offering and siphon off capital that could be put into
improving the base tools.  Not every customer wants an RTOS and
therefore we don't want our existing customers to pay for RTOS
development and support.

Also, even for those customers that *do* want an RTOS, their
requirements vary widely, and no one RTOS will fit the bill.  There is
no "standard API for an RTOS" but they all offer pretty much the same
feature set (OSEK is an obvious exception to this).  Customers (usually
Large Customers) wish to be free to change RTOSs or even have the RTOS
available on diverse processor families because they've standardised
in-house on that RTOS to keep re-tooling costs down, hence you're a
VxWorks shop or (as was) a pSOS shop.

For the MSP430, which has a small amount of RAM, large RTOSs are not
viable.  We ported uCOS-II to the MSP430 and it's very, very big even in
a cut-down form.  Much better suited to the task is Salvo from Pumpikin,
Inc. who are active in this forum.  We are currently making arrangements
with Pumpkin anyway, and already support the four major MSP430
compilers.  And they offer a free version, too, so you can take a look
at Salvo to see if it floats your boat.

As such, it's probably better for us, as a company, to foster
relationships ("synergise", what a word...) with other companies whose
focus is providing an RTOS, or even a portable RTOS as Salvo is, for the
compilers that we offer.  That's what we do with SoftBaugh, for
instance, where we support their boards with our software--we don't go
out and make an eval board when there's one already on the market.

However, all of the above does not preclude us offering a homebrew RTOS
in the future.

-- Paul.

At 08:51 AM 6/24/2003 +0000, grahamgollings wrote:
>I have wondered for a while why the various C
compilers available do
>not provide a simple multitasking environment. I gather you have to
>go to 3rd party sources to add this facility. But surely if one of
>the C Compiler suppliers did supply a small core then this would be
>a bit of a marketing advantage?
>Can someone explain if/why there is a problem of doing this?
>...

Check out uexec in our User Contribution section of our website. I wrote 
the ancestor version of it as my master's thesis, with a subsumption 
architecture based API! As a matter of fact, I started ImageCraft because 
there was no low cost HC11 compiler available. Anyway, uexec is really just 
a very simple preemptive task switcher. I wrote it for an article in 
Circuit Cellar. I know a number of people are using it, and modified it to 
run on all sort of CPUs. Some even added features like mailboxes, 
semaphores etc.  Strangely enough, no one (including me :-) ) has bothered 
to the AVR or the MSP430. Shouldn't be a reason why it can't be done
easily 
though.


// richard <http://www.imagecraft.com> 
<http://www.dragonsgate.net/mailman/listinfo> 

Dear Paul,Richard.

Thank you both for the explanations, I see you both differ somewhat 
in opinion, but eventually come to a similar conclusion. My own 
thoughts on this were inspired by another posting under the heading 
SOS small operating system around 15th June. I followed the then 
suggestions and briefly looked at salvo out of interest.

Richard, I have read you excellent Circuit Cellar article about 
uexec, and you wrote better than I could why a multitasking system 
makes sense. I also like the other information in the User 
Contribution section and will certainly revisit the site - nice work.

Dont jump on me guys, but I am probably a tiny percentage of this 
user group using Forth as a development system. As you know 
multitasking schemes are provided as standard and the following 
trivial example represents 10 minutes of my time (+20 writing this). 
It is pretty much self explanatory. The word TASK: allocates 15bytes 
of stack to each task ( this can be reduced )
The code represents 3x tasks ( Task1 + Task2 + the interative Forth 
task). I put a scope onto LED2 and TASK2 takes about 22 usec to run. 
The switching time between tasks is 4 usecs. ( at 8mh/z clock ). 
Notice TASK1 running DO1 only runs once, it can be run 1x again by 
typing TASK1 AWAKEN on the keyboard, it is a trivial job to attach 
this to an interupt pin or timer. TASK2 runs all the time, and can be 
started and stopped by using AWAKEN and REST from the keyboard.

All quite easy really. This is a simple cooperative multitasker 
needing about 180bytes of code space + ram space, the program below 
using 275bytes code + 80bytes of ram (15+15+50). Not that it does 
much!

I am completing another job using 8x tasks on a 430F123, 4 tasks are 
run from interupt pins and the rest are round robin.

I personally feel that a compact, easy to understand multitasker 
would serve C programmers well, and once used it is difficult to 
imagine how you managed without it. I imagine this would give your 
debuggers a fit, but thats another story.

Kind regards Graham.

\ ------------------------------
\ My Trivial example. Variable INK2 and Toggle-LED2 are updated at a 
\hell of a rate and INK1 and Toggle-LED1 runs once. Interactive Forth 
\is running and available to debug the code.


5 5 5 TASK: TASK1 \ data,return,and user stack sizes
5 5 5 TASK: TASK2 \ data,return,and user stack sizes

\ Ports-init, LED1 & LED2 definitions removed to shorten text.

: TOGGLE-LED1 ( - )   LED1 CHECK IF   LED1 OFF  \ 34 bytes
                                 ELSE LED1 ON  
                                 THEN  ;

: TOGGLE-LED2 ( - )   LED2 CHECK IF   LED2 OFF \ 34 bytes
                                 ELSE LED2 ON  
                                 THEN  ;

variable INK1
variable INK2

: DO1 ( - )  \ 32 bytes
                BEGIN    toggle-led1  
                         1 INK1 +! 
                         STOP    
                AGAIN ;
: DO2 ( - )  \ 32 bytes
                BEGIN    toggle-led2  
                         1 INK2 +!
                         PAUSE      
                AGAIN ;

: RUN-TASK1  TASK1 ACTIVATE     DO1 STOP ; \ 16 bytes
: RUN-TASK2  TASK2 ACTIVATE     DO2 STOP ; \ 16 bytes

\ Main sets up the tasker and then drops through to interactive Forth.
: MAIN \ 28 bytes
   Ports-init
   TASK1 LINK
   TASK2 LINK
   RUN-TASK1
   RUN-TASK2
;

\ ----------------
\ Other words available to, or called from the above code
Activate = 34 bytes
Pause = 2 bytes
link = 22 bytes
stop = 18 bytes
awaken = 22 bytes
rest = 26 bytes
task: = 0 bytes

--- In msp430@msp4..., "grahamgollings" <lmsbv@m...> wrote:
> But surely if one of 
> the C Compiler suppliers did supply a small core then this would be 
> a bit of a marketing advantage?

Funny you should ask this, Graham.

As part of our "modular" approach to the design of the Salvo RTOS,
we've created a very basic-functionality version (Salvo tiny -- see
http://www.pumpkininc.com/content/doc/forms/salvoversions.pdf)
specifically for the individual compiler vendors. It's built from
exactly the same core code as our other distributions (SE, LE and
Pro). 

Since Salvo tiny has supported for unlimited tasks, task delays and
binary semaphore events, it (IMO)
fulfills the notion of a basic multitasker with a lot of utility. And
of course it has Salvo's very small ROM and RAM footprints (much, much
smaller than uC/OS-II, for example).

Every application built with Salvo tiny is immediately portable
without source-code changes to any of the larger Salvo versions.

We've been discussing Salvo tiny with various compiler vendors whom we
work with. My hope is that some of them will choose to package Salvo
tiny with their toolsets for precisely what you describe -- a
marketing advantage.

--Andrew   aek ... at ... pumpkininc ... dot ... com

--- In msp430@msp4..., "grahamgollings" <lmsbv@m...> wrote:
> Dear Paul,Richard.
> 
> Thank you both for the explanations, I see you both differ somewhat 
> in opinion, but eventually come to a similar conclusion. 

Yes, I am surprised that more people don't use multitasking. I suspect
part of it is bad experiences with RTOSes that would be quite bloated
if ported to 8- and 16-bit MCUs. Plus, most RTOSes are very hard to
debug with, as they can be resource hogs and they "get in the way".

> As you know 
> multitasking schemes are provided as standard and the following 
> trivial example represents 10 minutes of my time (+20 writing this).
  
and 

> All quite easy really. This is a simple
cooperative multitasker 
> needing about 180bytes of code space + ram space, the program below 
> using 275bytes code + 80bytes of ram (15+15+50). Not that it does 
> much!

Well, I know very little about Forth, but I decided to see how Salvo
would compare. It's not quite apples to apples, but it is
illustrative. I did a very simple Salvo Lite application that simply
runs three tasks. Took under 10 minutes to write, build and test in
AQ430:

#include <msp430x14x.h>
#include "salvo.h"

void TaskA (void)
{
	for (;;) {
		P1OUT ^= 0x01;
		OS_Yield();
	}
}

void TaskB (void)
{
	for (;;) {
		P1OUT ^= 0x02;
		OS_Yield();
	}
}

void TaskC (void)
{
	for (;;) {
		P1OUT ^= 0x04;
		OS_Yield();
	}
}

void main ()
{
	P1OUT = 0x00;
	P1DIR |= 0xFF;
	
	OSInit();
	
	OSCreateTask(TaskA, OSTCBP(1), 5);
	OSCreateTask(TaskB, OSTCBP(2), 5);
	OSCreateTask(TaskC, OSTCBP(3), 5);
	
	for (;;)
		OSSched();
}

Results: 530 bytes of Flash (94 for main.c, rest for Salvo), 39 bytes
of RAM (total, including the stack -- 27 bytes for the Salvo
structures and 12 for the stack, obtained by filling stack memory with
a pattern and observing how much was then used). 

N.B. A Salvo Pro application would be somewhat smaller, both RAM- and
Flash-wise.

So, as with the Forth case, here's a really simple application in only
20 lines of C that's multitasking with three tasks.

> I personally feel that a compact, easy to
understand multitasker 
> would serve C programmers well, and once used it is difficult to 
> imagine how you managed without it. I imagine this would give your 
> debuggers a fit, but thats another story.

Amen. And Salvo isn't particular hard on debuggers, either.

--Andrew  aek ... at ... pumpkininc ... dot ... com

Andrew,

Thanks for your two interesting posts. We are not too far apart on 
the ram/rom requirement. I forgot to include the interactive Forth 
code which brings the total Flash requirement to about 400 bytes.

Thanks for the code example, like mine it is easy to understand. If 
I can make a suggestion. I did look at your website a few weeks ago 
and was a bit overwhelmed, and gave up after a short while. Why 
don't you add a button CODE SAMPLES on the home page and give a few 
simple examples like you did here. That is all I was looking 
initialy for and if they were there that might have given me the 
interest to study the site in more detail.  

I am using Forth because it produces reliable code with the ability 
to be interactively tested, so no debugger required, it also has a 
multitasking tools built in as standard.

I feel sad for the C compiler users who have to struggle with 
monolithic code, generated by a C compiler/assembler/optimiser in 
the classic edit-compile-run-debug-edit loop. Which is not 
particularly productive. The lack of even a simple C standard 
multitasker is comparable to modern kitchen without a microwave 
oven. (Shields up Mr Spock) - maybe I will get some flack....

I notice that there is a ominous silence from the C suppliers to our 
posts, I wonder if they are listening? Anyway, I wish you the best 
in your quest.

I am new to the 430 and know doubt you will see me posting some dumb 
questions here!

GrahamG.

	I do some Forth programming now and again, and while I am a strong
proponent 
of Forth, I find that it's actually easier to write C on most small 
microcontrollers.  

	The issue is one of code space and storage.  Parts like the MSP430F123 have 
256 bytes of RAM.  There's not much room for Forth words once you allocate
a 
stack and a few bytes of data for the interpeter.  In some systems, it's 
possible to compile words straight to FLASH, but that's fatiguing to the 
FLASH, and many microcontrollers only support programming blocks or sectors 
of FLASH.  Forth on a larger system, something with a 1K or more of RAM 
becomes much more viable. 

	I've played with a tethered 8051 system, and it was as unstable as
anything 
else I've used.  Half the time it wouldn't sync (almost as bad as
trying to 
use C-Spy :) ), and it while it was claimed it could do real-time, this 
wasn't my experience.    The other issue is that once you write a couple of

words on the target machine, if you're NOT using a tethered system, it can
be 
a pain to decompile them and get them back to the PC.

	I've been writing C a *long* time, and generally get it right in a few 
iterations.  In fact, my bigger problem is not the churn-and-burn (although 
sometimes that hits), but it's the customer changing specs.  And regardless

whether you're using Forth or C, you've still got to sit down and
rewrite 
code.  It's not time spent on the target, it's time spent on the
editor.

	The last issue is cost.  Most of the public domain Forths for micros are 
crap.  They're not ANSI, they're poorly maintained.  Good Forths, like
from 
Forth Systems, are expensive.  I priced a tethered system from them, and as I 
recall, it was around $1900.  While I do Forth programming, and have written 
an interpeter for the 8051, I don't consider myself a Forth wizard (in
fact, 
I'm better at writing an interpeter than I am writing production Forth
code).  
I can't afford the investment as an individual to buy a nice package, and
the 
company can't afford to either.  

	Indeed, it may make us (me...  I'm the only programmer) more productive. 
But 
do you know how hard it is to replace a Forth programmer than a C programmer?  
If I get hit by a truck, we can replace me.  If I do it all in Forth, it's 
going to be a lot more time consuming to find, evaluate and bring up to speed 
a Forth person.  I think Forth is a great language if you're already a
Forth 
shop, but if you're a seasoned C company (and likely this applies to other 
high-level languages, although I don't know *too* many people using Pascal
on 
a MSP430), it's not in your best interest to switch.

	Forth can be a great language if you're delivering a product to a company 
(like a barcode reader to Fedex).  If your contract requires you to deliver 
source code, that puts a new twist on it.

	Forth is a sub-culture.  It's one I'd like to be more part of, but
the 
real-world dynamics of most companies, particularly the personnel replacement 
issue, makes Forth a non-viable target language.  Other non-mainstream 
languages suffer the same fate, however, so don't get upset and say
I'm 
singling out Forth for this distinction.

	Incidently, when I worked at Hayes, I fought very hard (read: tilted at 
windmills) to replace the 8051 controller with a Forth engine.  I can't 
remember if it was one of Jeffs or Chucks, but it used 5 4-bit dynamic RAMs 
as memory store, and parallel decoded 4 words.  Something like effective 100 
MIPs throughput at 20 megahertz, IIRC.  I whipped out a complete AT command 
parser in about 4 days.  I showed the code, I showed the cost saving, I 
showed how it out-performed our max'ed out 8051 designed, particularly when

we went into V.34 modes.  No go.  Forth was too obscure for them.  People 
like the cost and performance numbers, but the reliance on Forth and the lack 
of availalble Forth programmers turned them off.

	--John

On Wednesday 25 June 2003 17:57 pm, grahamgollings
wrote:
>  Andrew,
>
>  Thanks for your two interesting posts. We are not too far apart on
>  the ram/rom requirement. I forgot to include the interactive Forth
>  code which brings the total Flash requirement to about 400 bytes.
>
>  Thanks for the code example, like mine it is easy to understand. If
>  I can make a suggestion. I did look at your website a few weeks ago
>  and was a bit overwhelmed, and gave up after a short while. Why
>  don't you add a button CODE SAMPLES on the home page and give a few
>  simple examples like you did here. That is all I was looking
>  initialy for and if they were there that might have given me the
>  interest to study the site in more detail. 
>
>  I am using Forth because it produces reliable code with the ability
>  to be interactively tested, so no debugger required, it also has a
>  multitasking tools built in as standard.
>
>  I feel sad for the C compiler users who have to struggle with
>  monolithic code, generated by a C compiler/assembler/optimiser in
>  the classic edit-compile-run-debug-edit loop. Which is not
>  particularly productive. The lack of even a simple C standard
>  multitasker is comparable to modern kitchen without a microwave
>  oven. (Shields up Mr Spock) - maybe I will get some flack....
>
>  I notice that there is a ominous silence from the C suppliers to our
>  posts, I wonder if they are listening? Anyway, I wish you the best
>  in your quest.
>
>  I am new to the 430 and know doubt you will see me posting some dumb
>  questions here!
>
>  GrahamG.
>
>
>
>
> Yahoo! Groups Sponsor
>
>
>
>
>
>
>  .
>
>
>
>  

At 09:57 PM 6/25/2003 +0000, grahamgollings wrote:
>...I notice that there is a ominous silence from
the C suppliers to our
>posts, I wonder if they are listening? Anyway, I wish you the best
>in your quest.
>...

I am sure there is a lot of back room haggling going on :-) Andrew wants to 
eat and feed his children, just like all of us. So the trick is a financial 
arrangement that makes sense to all parties involved.

That or I will go ahead and port uExec to the MSP430 and AVR...


// richard <http://www.imagecraft.com> 
<http://www.dragonsgate.net/mailman/listinfo> 

At 06:18 PM 6/25/2003 -0400, J.C. Wren wrote:
>....  Forth was too obscure for them.  People
>like the cost and performance numbers, but the reliance on Forth and the
lack
>of availalble Forth programmers turned them off.
>...

 From time to time, I thought of, boy wouldn't it be neat if I come out 
with a <xyz> (Lisp, Forth, Smalltalk, etc.) for the small micros. Then I 
have to splash cold water on my head to remind myself that there are 
children to be fed :-)


// richard <http://www.imagecraft.com> 
<http://www.dragonsgate.net/mailman/listinfo>