Reply by Steve at fivetrees●March 14, 20062006-03-14
"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
Reply by Tim Wescott●March 14, 20062006-03-14
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/
Reply by Steve at fivetrees●March 14, 20062006-03-14
"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
Reply by Not Really Me●March 13, 20062006-03-13
"Nemisis_2001" <kelvinjamieson@btinternet.com> wrote in message
news:1142026578.520276.63980@u72g2000cwu.googlegroups.com...
> Hi folks,
>
> 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. The PC104 will be
> installed in a remote location with proprietary ethernet or serial
> protocols revovering data from the PC104. I expect within 2 years we
> will be forced down the Modbus TCP/IP and OPC route for ethernet
> communications. There will be no user interface (except for debugging)
> and the only soft realtime requirements are related to the management
> and efficiency of the serial interfaces.We expect a volume of 400
> units/year and will be developing in accordance with SIL2 (IEC 61508).
> My team currently has a skillset in similair applications on QNX 4.
>
> We are currently considering which OS to use and are currently on a
> shortlist (not exclusive) of:
>
> Win CE 5.0
> QNX 6
> VxWorks
> RTLinux
>
> The evaluation is based on the following criteria (ranked in order of
> priority):
> 1) Availability (>95% over 20 years)
> 2) Available skillset (Transferrable skills or Contractors in the UK)
> 3) License cost (per unit)
> 4) Training (Classroom based in the UK)
> 5) Portability (To other PC104 manufacturers)
> 6) Additional IT infrastructure for development environment.(Windows
> company network)
> 7) BSP availability
> 8) Up front toolkit/license cost
> 9) Features
> 10) OS Vendor Support
>
> We are very pleased with QNX 4 over the years but we have struggled
> with 2,3,5,6,10 and it is has no BSP for our expected target.
> Any advice or pointers to other resources would be appreciated.
>
MicroC/OS-II. Widely used, low cost.
The API is well defined in a commercially published book - MicroC/OS-II,
The Real-Time Kernel, Second Edition, Jean J. Labrosse, CMP Books, ISBN
1-57820-103-9.
Source code comes in with the book.
Commercial license is low cost, under US$3K.
Used as course text in many universities.
Hundreds of ports to many platforms freely available from Micrium web site.
Has tcp/ip, gui, embedded filesyetem and modbus modules available.
Has been validated (by us) for use in safety-critical applications including
DO-178B Level-A.
--
Scott
Validated Software Corp.
Reply by Richard●March 13, 20062006-03-13
> We are currently considering which OS to use and are currently on a
> shortlist (not exclusive) of:
>
> Win CE 5.0
> QNX 6
> VxWorks
> RTLinux
I would suggest taking a look at www.on-time.com. Their OS is very easy to
use and well supported. The major drawback is it is protected mode x86
only, but if you are looking for COTS PC/104 then this may be the best
choise processor anyway as there are lots of vendors. The x86 target also
has a benfit as you can use Borland and MS compilers.
> 1) Availability (>95% over 20 years)
Availability? Up time? A 95% requirement seems very low.
> 2) Available skillset (Transferrable skills or Contractors in the UK)
The demo's that come with the download show you how to do most things you
could want. The x86 tools are familiar to most.
> 3) License cost (per unit)
No run time license.
> 4) Training (Classroom based in the UK)
Not available, but probably not necessary. I would be happy to provide some
training if you really feel this is necessary :-)
> 5) Portability (To other PC104 manufacturers)
Definately.
> 6) Additional IT infrastructure for development environment.(Windows
> company network)
On 11 Mar 2006 12:00:01 -0800, "Nemisis_2001"
<kelvinjamieson@btinternet.com> wrote:
>On one side of the coin the PC104 will serve as a serial communications
>master collecting analouge and digital information from serial slave
>device controllers and storing in a database. The performance
>requirements in this area are quite lose - all data recovered within 1
>second.
Are these serial devices on a single serial line or are multiple lines
used for communication ?
If multiple lines are used, the number of free interrupts can be a
problem if ordinary UARTs are used. If some multiplexor card is used,
it is a good idea if the card is supported by the selected operation
system, otherwise you would have to write the driver yourself.
>In addition to this (due to bespoke modems installed betwwen control
>room and PC104) we need to keep the interbyte timeouts down to less
>than an average of 16/300ths of a bit over 300 bytes.
This would require a chip with a sufficiently large TX-FIFO in order
to keep the transmitter saturated at all times.
Paul
Reply by Dave●March 11, 20062006-03-11
On Sat, 11 Mar 2006 12:00:01 -0800, Nemisis_2001 wrote:
> Appreciate all of the responses so I will address them all at once.
>
> I will certainly add eCos and RTEMS to the evaluation list. Redboot was
> always in the running for a bootloader.
>
> For real time Win CE appears to be a better choice than XP Embedded and
> even the Microsoft website agrees.
Please post after your evaluation with your choice and rationale. It
might help someone else later on.
~Dave~
Reply by Nemisis_2001●March 11, 20062006-03-11
Appreciate all of the responses so I will address them all at once.
I will certainly add eCos and RTEMS to the evaluation list. Redboot was
always in the running for a bootloader.
For real time Win CE appears to be a better choice than XP Embedded and
even the Microsoft website agrees.
On one side of the coin the PC104 will serve as a serial communications
master collecting analouge and digital information from serial slave
device controllers and storing in a database. The performance
requirements in this area are quite lose - all data recovered within 1
second.
On the other side the PC104 will act as a communications slave whereby
information will be (asynchronously) read by a control room serial
communciations master. In addition the this some control commands may
be issued by the control room which need to be forwarded to the serial
device controllers.
In terms of performance we are looking at a guaranteed response time of
28-32ms in response to a message from the control room and the
forwarding of control commands to device controllers within 100ms of
recieving.
In addition to this (due to bespoke modems installed betwwen control
room and PC104) we need to keep the interbyte timeouts down to less
than an average of 16/300ths of a bit over 300 bytes.
The only other real time requirements are the management of the
hardware watchdog (probably configured in the seconds range).
We have historically found that when CPU load increases the OS provided
serial interrupt handling always seems to suffer.
Best regards
Reply by Ian Bell●March 11, 20062006-03-11
Nemisis_2001 wrote:
> Hi folks,
>
> 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. The PC104 will be
> installed in a remote location with proprietary ethernet or serial
> protocols revovering data from the PC104. I expect within 2 years we
> will be forced down the Modbus TCP/IP and OPC route for ethernet
> communications. There will be no user interface (except for debugging)
> and the only soft realtime requirements are related to the management
> and efficiency of the serial interfaces.
So what are the real time requirements?
Ian
Reply by Dave●March 11, 20062006-03-11
On Fri, 10 Mar 2006 13:36:18 -0800, Nemisis_2001 wrote:
> We are currently considering which OS to use and are currently on a
> shortlist (not exclusive) of:
>
> Win CE 5.0
> QNX 6
> VxWorks
> RTLinux
>
> The evaluation is based on the following criteria (ranked in order of
> priority):
> 1) Availability (>95% over 20 years)
> 2) Available skillset (Transferrable skills or Contractors in the UK)
> 3) License cost (per unit)
> 4) Training (Classroom based in the UK)
> 5) Portability (To other PC104 manufacturers)
> 6) Additional IT infrastructure for development environment.(Windows
> company network)
> 7) BSP availability
> 8) Up front toolkit/license cost
> 9) Features
> 10) OS Vendor Support
>
> We are very pleased with QNX 4 over the years but we have struggled
> with 2,3,5,6,10 and it is has no BSP for our expected target.
> Any advice or pointers to other resources would be appreciated.
How about RTEMS (www.rtems.com)? Viper is Intel Xscale which is ARM 5.
RTEMS supports ARM V7 and above so that might be an issue. RTEMS supports
many other processor families, has BSPs, and is supported on Windows and
*nix environments. The source code is free and there are no licensing
costs. Training and support are available (not for free)--there is a
class scheduled for Munich in mid-July. I would hope it has high
availability--it is used on the Avenger Forward Air Defense System.
~Dave~