Which RTOS?

"Nemisis_2001" <kelvinjamieson@btinternet.com> wrote in message 
news:1142026578.520276.63980@u72g2000cwu.googlegroups.com...
>
> I am about to emabark on a new development using a COTS PC104 single
> board computer (probably Arcom Viper) for use in an industrial control
> system. The PC104 will perform the role of an autonomous serial data
> acquisition hub with some basic control functions.

Just to play devil's advocate, you might also consider an OS-less approach. 
(This is my preferred approach wherever a standard file system is not a 
specific part of the requirement. The KISS principle...)

Except for:
> I expect within 2 years we
> will be forced down the Modbus TCP/IP and OPC route for ethernet
> communications.

TCP/IP might be a good reason to use an OS.

You might also consider OpenBSD... Not strictly an RTOS, but your realtime 
requirements are relatively mild.

Steve
http://www.fivetrees.com 

Steve at fivetrees wrote:

> "Nemisis_2001" <kelvinjamieson@btinternet.com> wrote in message 
> news:1142026578.520276.63980@u72g2000cwu.googlegroups.com...
> 
>>I am about to emabark on a new development using a COTS PC104 single
>>board computer (probably Arcom Viper) for use in an industrial control
>>system. The PC104 will perform the role of an autonomous serial data
>>acquisition hub with some basic control functions.
> 
> 
> Just to play devil's advocate, you might also consider an OS-less approach. 
> (This is my preferred approach wherever a standard file system is not a 
> specific part of the requirement. The KISS principle...)
> 
> Except for:
> 
>>I expect within 2 years we
>>will be forced down the Modbus TCP/IP and OPC route for ethernet
>>communications.
> 
> 
> TCP/IP might be a good reason to use an OS.
> 
> You might also consider OpenBSD... Not strictly an RTOS, but your realtime 
> requirements are relatively mild.
> 
> Steve
> http://www.fivetrees.com 
> 
> 
I've been happy to use RTOS's in many designs, none of which had file 
systems -- and I've used RTOS-less designs quite successfully as well. 
I tend to want to use a nice, preemptive RTOS anytime that I have 
different things happening at significantly different rates -- like 
complex user input at 10Hz that must happily coexist with motor control 
at 1kHz.

Going the "OS-less" route in such a case means guaranteeing that the 
slow stuff is chopped into bits of no more than 1ms execution time each. 
  This increases development time, puts more stringent requirements on 
the team members, and makes for a more fragile system.

It's always a trade off between the amount of overhead the OS 
contributes in time, money, complexity and fragility vs. the amount of 
all of the above that you save by using it.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Tim Wescott" <tim@seemywebsite.com> wrote in message 
news:CPudnSENQpyll4rZnZ2dnUVZ_vydnZ2d@web-ster.com...
> I've been happy to use RTOS's in many designs, none of which had file 
> systems -- and I've used RTOS-less designs quite successfully as well. I 
> tend to want to use a nice, preemptive RTOS anytime that I have different 
> things happening at significantly different rates -- like complex user 
> input at 10Hz that must happily coexist with motor control at 1kHz.
>
> Going the "OS-less" route in such a case means guaranteeing that the slow 
> stuff is chopped into bits of no more than 1ms execution time each. This 
> increases development time, puts more stringent requirements on the team 
> members, and makes for a more fragile system.

Yes, it *can* mean that. I guess it depends on one's background and mindset. 
For me, and working alone, I prefer OSless unless the OS provides something 
essential and heavy-duty *other* than scheduling. I'm very used to the 
constraints you outline - i.e. cooperative multitasking. But I agree it can 
get messy with teams who don't think homogenously.

> It's always a trade off between the amount of overhead the OS contributes 
> in time, money, complexity and fragility vs. the amount of all of the 
> above that you save by using it.

Agreed - mostly. Team discipline - or lack of it - can clobber both 
approaches. Given a good team, I'd still prefer OSless - simply because we 
have more control and there's less to go wrong. (Been bitten by 3rd-party 
code too often.)

Steve
http://www.fivetrees.com