Which RTOS?

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.

Reply to
Nemisis_2001
Loading thread data ...

I'd probably recommend a look at eCos:

formatting link
formatting link

Well, I've never seen it crash.

Cambridge is the eCos capital of the world. ;)

Free.

Cambridge again.

It should run on most PC-like platforms.

Absolutely no clue what that means.

Um, Yes.

Toolkit is free, unless you want to pay for one with support from soembody like eCosCentric.

No license cost.

Yes, eCos has features!

eCosCentric is probably the big one, but there are others who offer support as well.

--
Grant Edwards                   grante             Yow!  I want to kill
                                  at               everyone here with a cute
 Click to see the full signature
Reply to
Grant Edwards

"Nemisis_2001"

Why don't you add windows xp embedded to your list? While it is a stripped down version of windows xp (therefore non-RTOS), there are modules available that implement real time in it. With that items #2, 4, 5 (given that you keep on winxp compatible platform), 6 and 9 come are completely met.

Up front toolkit costs around $900, and license cost is around $90 per unit, which could be a limiting factor in many applications. I'm using it in a robotic application, and while I'm not using the RTOS module, it meets all my expectations.

Cheers

Padu

Reply to
Padu

How about RTEMS

formatting link
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~

Reply to
Dave

So what are the real time requirements?

Ian

Reply to
Ian Bell

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 to
Nemisis_2001

Please post after your evaluation with your choice and rationale. It might help someone else later on.

~Dave~

Reply to
Dave

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.

This would require a chip with a sufficiently large TX-FIFO in order to keep the transmitter saturated at all times.

Paul

Reply to
Paul Keinanen

I would suggest taking a look at

formatting link
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.

Availability? Up time? A 95% requirement seems very low.

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.

No run time license.

Not available, but probably not necessary. I would be happy to provide some training if you really feel this is necessary :-)

Definately.

Lots.

An industrial PC is basically a PC.

Low.

See the WEB link above.

In my experience this has been very good.

Regards, Richard.

formatting link

Reply to
Richard

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 to
Not Really Me

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:

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

formatting link

Reply to
Steve at fivetrees

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
 Click to see the full signature
Reply to
Tim Wescott

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.

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

formatting link

Reply to
Steve at fivetrees

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.