Help with real time system performance estimate

With exception to TCP, the answer to all your questions is "it depends". For TCP, the answer is "probably not".

If UDP isn't the way to go, then one of the newer real-time Ethernet protocols is. If your application owns the whole network (i.e., if the whole thing is in a box that you supply, and only processors that you supply are in the box), then you could also just send messages out on your own Ethernet port, and essentially roll your own protocol.

If the timing requirement is firm, then you need a hard real time system. I've heard good things about the real-time Linux extensions, so you may be able to make it work. If the app is small, however, you're probably better off with a smaller OS, like FreeRTOS or Micro-C/OS-II.

Without knowing all the details, it's hard to say what sort of processor you need. A Cortex M3 may well be good enough, but the Cortex M3 does not have an MMU, which I think is necessary to run Linux. You could use micro-Linux, but I'm not sure that's real-time. I suspect that the biggest thing in the software will be the Ethernet stack.

--

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

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

One option the OP may wish to look at to see if it's suitable for their requirements is RTEMS; no MMU is required.

RTEMS can be found at

A BSP will need to be written unless the board is already supported so it may not be suitable for them if they don't want to go down the writing a BSP road.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

An MMU isn't strictly necessary to run Linux, but by running Linux without one you forgo some of the features and benefits normally associated with Unix/Linux.

Do you mean uCLinux?

--
Grant Edwards               grant.b.edwards        Yow! Will it improve my
                                  at               CASH FLOW?
                              gmail.com

Yes.

--

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

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

I should have mentioned: Linux is a Really Big OS compared to a lot of embedded tasks. If all you're doing is monitoring some little digital inputs and echoing their state onto a network, then it may well be massive overkill. Using it would be akin to using a $40000 CNC mill to whack blocks off of a metal bar, when a $5 hacksaw would have gotten the job done quicker, and perfectly adequately.

I don't _know_ this to be the case here -- but the OP did not mention anything that would make Linux a 'must use'.

--

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

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html

Stupident. No slightest clue, huh?

Before casting smart words which only make you look dumber, you'd better get something to work. Take a PIC and implement their MAC-level networking over Ethernet.

VLV

Very definitely. The minimum (practical) memory size for Linux is probably 8MB or so RAM with 2-4MB of flash. 32MB+ of RAM is proabably a lot more common.

I didn't mean to imply that I thought the OP should (or wanted) to run Linux, just that it is possible to run Linux w/o an MMU.

--
Grant Edwards               grant.b.edwards        Yow! I have a very good
                                  at               DENTAL PLAN.  Thank you.
                              gmail.com

Let's look at your requirements in a bit more detail...

"Detect changes" can be as simple as: if (current_state != previous_state) { previous_state = current_state; signal_changed(); }

Do the signal states need to be "encode(d) and transmit(ted)" each time the inputs are *sampled*? Or, only when a change has been detected?

How often are they sampled? How often do you expect to see changes? Presumably, your solution must be capable of detecting changes AT EVERY sample point (i.e., a sampling frequency / 2 input signal rate). If so, then you have to be prepared to send a message at each sample time (?)

What sort of effort is required to "encode them"? Just a predictable message format? E.g., "Signal #4 has changed to the X state". Or, something more involved like "Signal #7 now indicates 56 degrees"?

[i.e., are you just using the "transmitters and network" to extend your field wiring?]

What sort of distances are involved? (presumably within the limits of whatever network technology you embrace)

Does each signal change have to be routed to a particular "receiver"? Or, do all signal changes get broadcast to all receivers??

In other words, can your code be as crude as: while (FOREVER) { update_sensor_states(); for (sensor = 0; sensor < NUMBER_SENSORS; sensor++) { if (new_state[sensor] = old_state[sensor]) { old_state[sensor] = new_state[sensor]; transmit(sensor, new_state[sensor]); } } }

Ethernet can support this sort of latency. Whether or not

*you* can do it in that timeframe is the issue. Look at your requirements: "digital input changing state [to] the corresponding digital outputs being activated" is "a few ms". "A few" is three :> (a, couple, few, many)

So, you have to be sampling your inputs better than ~300ms else your 3ms budget is lost before you get started. Let's say 1KHz (alternatively, the inputs could trigger interrupts so there is no polling interval). Worst case, an input could have changed some epsilon after your most recent sample. So, you won't "see" it for another 1ms-epsilon.

Once you see it, you now have 2ms to get that information to the "digital output(s)".

So, you can eliminate the delay between the input polling and the subsequent "input processing" (outlined above) by putting the processing *in* the polling loop. The above code takes close to zero time to run -- with the exception of the transmit() call.

Skipping ahead to the receive side, you have something waiting on incoming messages, decoding them and then "processing" them (whatever that entails). Eventually, it writes magic values into output latches and the data has arrived!

If the input task sits *in* the "wait for message" code, then you can eliminate the latency between the message being received at the receiver and "presented" to the application layer (this is analogous to putting the "input changed" code in the input sampling loop).

If decoding the message is simple (because a simple encoding format was intentionally chosen), *and* "processing" is little more than "input change X --> output Y to be set/cleared/toggled", then we can reduce the problem to the cost of "transmit()" plus "receive()".

[i.e., write this on a single processor assuming inputs and outputs are on the same device. let transmit() be something like "sensor_state[sensor] = state" -- with receive() being the mirror image -- and look at how fast you can make it.]

There are big differences between TCP and UDP. In your case, the most significant differences are the amount of code required and the time to execute that code. UDP can be "a page" of code vs. "a chapter" for TCP!

The more subtle issue, however, is that UDP doesn't "guarantee" delivery. And, if you are only sending messages when an input *changes* state, then the possibility of a dropped message being unnoticed (by the receiver) is a concern.

[i.e., if you were sending a message every time you sampled the inputs, then the receiver could *expect* a message every (e.g.) 1 ms and, if a messsage failed to appear, it would *know* that the message was dropped, someplace]

So, you would either have to guarantee (from the design of your system) that messages *can't* be dropped *or* provide a mechanism whereby you -- the xmtr -- can *know* that the message was received BY ALL INTENDED PARTIES.

Will you "own" the network? Or will you have to share it with other devices/applications (i.e. *traffic*)? If the latter is the case, you will find it very difficult to use UDP without some add-on protocol for this acknowledgment.

Well, what guarantees does Linux make on the services it provides?

I can imagine an implementation (i.e., giving me the freedom to make the "unspecified" requirements work entirely in my favor) where this would be possible. I can also imagine a set of requirements that would make implementation *impossible*! :> Only you have the detailed knowledge to decide if *you* requirements and

*your* implementation will be possible!

The

receive

inputs

needs

or

kind

an

Thanks for your advice. In addition to the real time stuff I need a web server (for configuration, to view system status, diagnostics and log files, to upload software updates etc.). The ethernet segment will not be used for other foreign or unknown applications, but it does span the building (i.e. it's not "in a box"), and there may be a PC or two on it which need to use standard spoftware. I think this means (a) that I have to use standard protocols such as UDP (or one of the real-time protocols you mention, assuming that these can co-exist with TCP/IP) and (b) I need standard Linux, possibly with a real time extension such as RTAI. Sounds like I therefore need a processor with MMU - maybe the Cortex A8?

Rowan

--------------------------------------- Posted through

If you need Linux, then you want to pick a processor - such as the Cortex A8. The Cortex M3 is a microcontroller - it is aimed at more compact systems that typically run all their code from its internal flash. While it is certainly /possible/ to attach lots of external memory to an M3 device, and to run code from there (including ucLinux), it would be slow and inefficient. A processor such as the A8, which is designed to run with external memory (for example, it has a good cache), will do a much better job.

You should also try to determine your real-time requirements. "Real-time" is often used as a buzz-word, when what is really meant is "fast", "low-latency", "reliable", "doesn't need reboots or other attention", etc. The term "real time" means that some events have deadlines which must occur within specific timing requirements.

Linux is not a hard real time system - it cannot give you those sorts of guarantees. There are real-time extensions, as you mention, but those are almost certainly not appropriate. When you have a task that really is hard real time, it should probably run on an auxiliary system rather than on the same processor as a large general-purpose OS - it makes it /much/ easier to be sure your system fits the requirements.

But I don't think you want hard real time here. You want "soft" real time - you want a system that is low-latency, and where unexpected delays are extremely rare. But you already need to cope with unexpected delays - they are inevitable when you have an Ethernet network (even if you avoid TCP/IP), and they are certainly inevitable if you include "standard spoftware" (a fine word, "spoftware" - I hope it wasn't just a typo!) and standard PC's in the mix.

Modern Linux kernels are perfectly suitable for such tasks - just make sure the kernel is configured as pre-emptive, that you pick appropriate priorities for your tasks, and that you are careful with things that can cause unpredictable delays such as disk access.

You can get deterministic behavior with Ethercat, which is specifically designed to send lots of I/O signals quickly and deterministically over a standard Ethernet cable. However you cannot combine it with other protocols on the same network cable. It depends very much on the specific requirements of the OP whether it fits the bill or not.