Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #27501 > unrolled thread

Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)?

Back to article view | Back to comp.arch.embedded

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? StateMachineCOM <statemachineguru@gmail.com> - 2018-01-05 09:47 -0800
    Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-05 11:51 -0800
      Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? StateMachineCOM <statemachineguru@gmail.com> - 2018-01-05 15:30 -0800
        Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-05 16:34 -0800
          Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2018-01-05 21:34 -0600
            Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-05 19:52 -0800
              Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2018-01-06 16:42 -0600
                Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-08 13:45 -0800
      Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-05 23:51 +0000
        Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Paul Rubin <no.email@nospam.invalid> - 2018-01-05 16:35 -0800
          Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-06 09:45 +0000
            Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? upsidedown@downunder.com - 2018-01-06 12:32 +0200
              Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-06 11:16 +0000
                Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? upsidedown@downunder.com - 2018-01-07 13:35 +0200
                  Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-07 13:55 +0000
              Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Les Cargill <lcargill99@comcast.com> - 2018-01-06 16:49 -0600
                Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)? Tom Gardner <spamjunk@blueyonder.co.uk> - 2018-01-07 01:39 +0000

#27501 — Re: When exactly do you choose to use a RTOS (instead of a non-OS approach)?

The question implies that a conventional RTOS and "superloop" (non-OS approach) are the only games in town. But the traditional shared-state concurrency and blocking based on RTOS is no longer the best known way of organizing embedded software. Neither are the various ad hoc tweaks to the venerable "superloop". To find out about the alternatives, I would recommend to google for the phrase "beyond the RTOS".

Miro Samek
state-machine.com

[toc] | [next] | [standalone]

#27502

StateMachineCOM <statemachineguru@gmail.com> writes:
> Neither are the various ad hoc tweaks to the venerable "superloop". To
> find out about the alternatives, I would recommend to google for the
> phrase "beyond the RTOS".

I looked at https://www.embeddedrelated.com/showarticle/951.php and the
linked slideshare presentation.  I'm not that much of an OOP guy so I
may have missed some of the jargon.  But it looks like you're advocating
a traditional message-passing approach to concurrency, with some scheme
for wrapping a separate event loop for each task.  You might like the
Erlang OTP system which does something like that, with preemptive
scheduling and no shared data between tasks.  It may be inadequate for
low latency hard-real-time systems but works very well when there's a
little bit more timing slack available (millisecond-level soft RT).

[toc] | [prev] | [next] | [standalone]

#27503

The approach I advocate is a very lightweight version of the Active Object (a.k.a Actor) design pattern (again, anybody interested should google for the "Active Object" or "Actor pattern"). It also turns out that the Actor pattern is a natural fit for state machines, or better yet, hierarchical state machines. 

So yes, this approach is conceptually related to Erlang insofar Erlang implements the actor pattern. But of course the Erlang language and the accompanying runtime are not applicable to deeply embedded systems such as ARM Cortex-M0 with 2KB of RAM.

However, this does not mean that the *concept* of active objects is necessarily heavyweight. To the contrary, event-driven systems are known to be lighter weight than traditional RTOS-based systems, because they don't require that much stack space (RAM). They are also naturally low-power.

Anyway, I think that most embedded developers are unaware of the event-driven active object pattern and its applicability in deeply embedded applications with hard real-time requirements.

[toc] | [prev] | [next] | [standalone]

#27505

StateMachineCOM <statemachineguru@gmail.com> writes:
> However, this does not mean that the *concept* of active objects is
> necessarily heavyweight. To the contrary, event-driven systems are
> known to be lighter weight than traditional RTOS-based systems,

Sure, they've been in Forth multitaskers for almost 50 years, as this
article describes:

http://www.complang.tuwien.ac.at/anton/euroforth/ef17/genproceedings/papers/haley-slides.pdf

There's some oft-repeated wisdom that as the application gets more
complicated, cooperative multasking runs into more and more problems
(tasks hanging or blocking crash the whole system etc) and preemption
becomes important.  So it's good to support both.

[toc] | [prev] | [next] | [standalone]

#27509

Paul Rubin wrote:
> StateMachineCOM <statemachineguru@gmail.com> writes:
>> However, this does not mean that the *concept* of active objects is
>> necessarily heavyweight. To the contrary, event-driven systems are
>> known to be lighter weight than traditional RTOS-based systems,
> 
> Sure, they've been in Forth multitaskers for almost 50 years, as this
> article describes:
> 
> http://www.complang.tuwien.ac.at/anton/euroforth/ef17/genproceedings/papers/haley-slides.pdf
> 
> There's some oft-repeated wisdom that as the application gets more
> complicated, cooperative multasking runs into more and more problems
> (tasks hanging or blocking crash the whole system etc) and preemption
> becomes important.  So it's good to support both.
> 

SO in order to have true determinism, one needs run-to-completion. This
forces the design to account for any indeterminate situations.

In some hard realtime domains, having the timer pop is a
*fault*. It indicates that the task has overrun its time
budget.  So preemption seems at times to try to make that
lemon into lemonade :)

Preemption is the "timesharing" thing; we may or may not need it
for embedded.

It depends on your appetite for indeterminacy; I say if
you're leaning on the timer tick to operate, you have multiple
latent bugs.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#27510

Les Cargill <lcargill99@comcast.com> writes:
> It depends on your appetite for indeterminacy; I say if
> you're leaning on the timer tick to operate, you have multiple
> latent bugs.

A complex enough program will have latent bugs no matter what.  If the
application critically depends on having no bugs, that dependence is a
bug in its own right.  A reliable system has to be able to recover from
faults including software bugs.  Erlang/OTP is set up so if something
goes wrong in an operation, the process handling it crashes and a
supervision process restarts it so things are in a known state again.
This is enough to recover from quite a lot of unexpected problems.  You
look at the crash log the next day, figure out what happened, and roll
out a fix.  You can even upgrade the software while it's still running.

[toc] | [prev] | [next] | [standalone]

#27520

Paul Rubin wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> It depends on your appetite for indeterminacy; I say if
>> you're leaning on the timer tick to operate, you have multiple
>> latent bugs.
> 
> A complex enough program will have latent bugs no matter what. 

Not... necessarily. If the complexity means it's never
truly finished, then yes.

> If the
> application critically depends on having no bugs, that dependence is a
> bug in its own right.

Well, I think we should all strive for that regardless. IMO, it doesn't
cost more to do things in a rigorous and careful way. I'd point you
to the writings of Bruce Powell-Douglas.

That, of course, is 180 degrees opposite of what many
think of as modern software practice.

> A reliable system has to be able to recover from
> faults including software bugs.  Erlang/OTP is set up so if something
> goes wrong in an operation, the process handling it crashes and a
> supervision process restarts it so things are in a known state again.

Yep.

> This is enough to recover from quite a lot of unexpected problems.  You
> look at the crash log the next day, figure out what happened, and roll
> out a fix.  You can even upgrade the software while it's still running.
> 

It's a heck of a nice system.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#27560

Les Cargill <lcargill99@comcast.com> writes:
> Not... necessarily. If the complexity means it's never
> truly finished, then yes.

I thought the saying was that software is never truly finished until the
last user is dead ;-).

> Well, I think we should all strive for that regardless. IMO, it doesn't
> cost more to do things in a rigorous and careful way. I'd point you
> to the writings of Bruce Powell-Douglas.

I've started to look at some, thanks.  He writes mostly about critical
real-time systems, a niche area which is of course of special interest
to c.a.e. (and to me).  I can accept that some of those programs must
have zero bugs, and accomplishing that requires special, ultra-rigorous
methods and tools.  But, I'd also say, that puts an upper limit on the
complexity of the things that the software can attempt to do.

Other types of software must deal more directly with the real world,
which requires accomodating the unbounded complexity of the real world,
which in turn puts more complexity into the software than a pure formal
approach can handle.  That may prevent the software from getting the
last epsilon of reliability, but that's ok, the real world isn't 100%
reliable either.

Joe Armstrong likes to say that any non-distributed system is inherently
unreliable, because the power cord is a single point of failure.  Most
of the programs that most of us write run on computers with a single
power cord, so they can also withstand software practices that wouldn't
suffice for critical realtime systems, but that can handle more types of
real-world requirements.

[toc] | [prev] | [next] | [standalone]

#27504

On 05/01/18 19:51, Paul Rubin wrote:
> StateMachineCOM <statemachineguru@gmail.com> writes:
>> Neither are the various ad hoc tweaks to the venerable "superloop". To
>> find out about the alternatives, I would recommend to google for the
>> phrase "beyond the RTOS".
>
> I looked at https://www.embeddedrelated.com/showarticle/951.php and the
> linked slideshare presentation.  I'm not that much of an OOP guy so I
> may have missed some of the jargon.  But it looks like you're advocating
> a traditional message-passing approach to concurrency, with some scheme
> for wrapping a separate event loop for each task.  You might like the
> Erlang OTP system which does something like that, with preemptive
> scheduling and no shared data between tasks.  It may be inadequate for
> low latency hard-real-time systems but works very well when there's a
> little bit more timing slack available (millisecond-level soft RT).

Or, with careful thought and decades of experience,
you can implement the RTOS in hardware.

See the multicore XMOS xCORE processors with xC
(a modern CSP/Occam), for embedded hard realtime
programs. "Hard" means the IDE/toolchain calculates
the min/max instruction times.

Processors with up to 32 cores and 4000MIPS, and
interrupt latencies of 10ns.

There is tightly integrated hardware plus software
support for i/o event processing and inter-core comms.
With that you don't need an RTOS :)

[toc] | [prev] | [next] | [standalone]

#27506

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> Processors with up to 32 cores and 4000MIPS, and interrupt latencies
> of 10ns.

Why stop there?  http://greenarraychipss.com 

[toc] | [prev] | [next] | [standalone]

#27515

On 06/01/18 00:35, Paul Rubin wrote:
> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>> Processors with up to 32 cores and 4000MIPS, and interrupt latencies
>> of 10ns.
>
> Why stop there?  http://greenarraychipss.com

1) I believe you can simply add more chips
in parallel, and the comms simply works, albeit
with increased latency

2) hardware is easy; the software is more difficult
and more important. XMOS has very good software
support (based on 40 years of theory and practical
implementations), plus excellent integration with
the hardware.

3) look at the investor lists for each company

IMNSHO, point 2 is the killer advantage/USP.

[toc] | [prev] | [next] | [standalone]

#27516

On Sat, 6 Jan 2018 09:45:31 +0000, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>On 06/01/18 00:35, Paul Rubin wrote:
>> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>>> Processors with up to 32 cores and 4000MIPS, and interrupt latencies
>>> of 10ns.
>>
>> Why stop there?  http://greenarraychipss.com
>
>1) I believe you can simply add more chips
>in parallel, and the comms simply works, albeit
>with increased latency
>
>2) hardware is easy; the software is more difficult
>and more important. XMOS has very good software
>support (based on 40 years of theory and practical
>implementations), plus excellent integration with
>the hardware.

The xCore style architecture is nice for multichannel DSP
applications, in which each channel is assigned a dedicated core and
the single sampling clock is routed to all cores, starting the
execution of all cores at each sample clock transition. 

The xCore could also be used to implement PLCs (Programmable Logic
Controller) with each execution loop executed in a dedicated core,
usually with different clocks for each loop. Quite a lot of problems
can be solved in a PLC type environment and the IEC 61131 programming
environment is quite handy. IEC 61131 has multiple kinds of
programming languages, e.g. ladder logic or ST (Structured Text, a
Modula/Pascal style programming language).

However, I do _not_ think that the xCore would be very handy for ad
hoc parallel processing, even with XMOS programming environment (which
is quite versatile).
 
>
>3) look at the investor lists for each company
>
>IMNSHO, point 2 is the killer advantage/USP.

[toc] | [prev] | [next] | [standalone]

#27517

On 06/01/18 10:32, upsidedown@downunder.com wrote:
> On Sat, 6 Jan 2018 09:45:31 +0000, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
>
>> On 06/01/18 00:35, Paul Rubin wrote:
>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>>>> Processors with up to 32 cores and 4000MIPS, and interrupt latencies
>>>> of 10ns.
>>>
>>> Why stop there?  http://greenarraychipss.com
>>
>> 1) I believe you can simply add more chips
>> in parallel, and the comms simply works, albeit
>> with increased latency
>>
>> 2) hardware is easy; the software is more difficult
>> and more important. XMOS has very good software
>> support (based on 40 years of theory and practical
>> implementations), plus excellent integration with
>> the hardware.
>
> The xCore style architecture is nice for multichannel DSP
> applications, in which each channel is assigned a dedicated core and
> the single sampling clock is routed to all cores, starting the
> execution of all cores at each sample clock transition.

It is great for *much* more than that, e.g. a general
purpose test instrument.

My "kick the tyres" test was a reciprocal frequency
counter with zero added hardware; software counted
the transitions in a 62.5Mb/s input data streams
   - two cores for the two primary inputs; absolute
     timing guarantees were required. I could squeeze it
     so that each input "cycle" was suspended for ~100ns
     before the next input event arrived
   - one core for front panel input
   - one core for front panel output
   - one controller core orchestrating all the other cores
   - many cores for a USB interface

Having guaranteed i/o timing in the presence of random
interaction with a user and a host computer is rather
nice :) The IDE gave those guarantees; I don't know of
any other processor that could do that.

Interrupts: get thee behind me Satan!

Overall I was /remarkably/ pleased at how simple
and predictable everything turned out to be. The
data sheets and programming tutorials are exemplary
in their conciseness and correctness. That's a benefit
of having the same team design the hardware and
software without being unduly constrained by the PDP11
and 1970 compiler technology :)


> The xCore could also be used to implement PLCs (Programmable Logic
> Controller) with each execution loop executed in a dedicated core,
> usually with different clocks for each loop. Quite a lot of problems
> can be solved in a PLC type environment and the IEC 61131 programming
> environment is quite handy. IEC 61131 has multiple kinds of
> programming languages, e.g. ladder logic or ST (Structured Text, a
> Modula/Pascal style programming language).

I don't know anything about PLCs, but I'm
suspicious about the clocking strategy you
mention.

Better, I would presume, to let each core
have a 100MHz clock and to stall until it
has something to do - i.e. an i/o event or
message event from another core.

Of course, such an i/o or message event
could well be a "software" clock.



> However, I do _not_ think that the xCore would be very handy for ad
> hoc parallel processing, even with XMOS programming environment (which
> is quite versatile).

There are two points there.

Firstly the xCORE processors are embedded devices
not general purpose devices. Anybody planning to
use them as general purpose compute engines will
be, um, disappointed :)

Having said that, ISTR some having one core being
an ARM processor (other 7 being xCORE), and the
IDE can generate code for ARMs. I have not
investigated any of that.

Secondly, xC is strongly based on Hoare's Communicating
Sequential Processes (CSP), as was Occam in the 80.
Several new languages (Go, Rust) also contain CSP
syntax and semantics, thus indicating that people still
think CSP is A Good Thing. In addition, it appears
that message passing is still the most reliable
general purpose way to structure large scale High
Performance Computing (HPC) programs.

That raises the question as to whether CSP (and "hence"
xC) is, on balance, better/worse than the alternatives.
That is not clear to me.

Mind you, I do like xC's "asynchronous" "interface"
extensions to CSP; they appear to be necessary on
limited core devices


>> 3) look at the investor lists for each company
>>
>> IMNSHO, point 2 is the killer advantage/USP.

[toc] | [prev] | [next] | [standalone]

#27542

On Sat, 6 Jan 2018 11:16:36 +0000, Tom Gardner
<spamjunk@blueyonder.co.uk> wrote:

>On 06/01/18 10:32, upsidedown@downunder.com wrote:
>> On Sat, 6 Jan 2018 09:45:31 +0000, Tom Gardner
>> <spamjunk@blueyonder.co.uk> wrote:
>>
>>> On 06/01/18 00:35, Paul Rubin wrote:
>>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>>>>> Processors with up to 32 cores and 4000MIPS, and interrupt latencies
>>>>> of 10ns.
>>>>
>>>> Why stop there?  http://greenarraychipss.com
>>>
>>> 1) I believe you can simply add more chips
>>> in parallel, and the comms simply works, albeit
>>> with increased latency
>>>
>>> 2) hardware is easy; the software is more difficult
>>> and more important. XMOS has very good software
>>> support (based on 40 years of theory and practical
>>> implementations), plus excellent integration with
>>> the hardware.
>>
>> The xCore style architecture is nice for multichannel DSP
>> applications, in which each channel is assigned a dedicated core and
>> the single sampling clock is routed to all cores, starting the
>> execution of all cores at each sample clock transition.
>
>It is great for *much* more than that, e.g. a general
>purpose test instrument.
>
>My "kick the tyres" test was a reciprocal frequency
>counter with zero added hardware; software counted
>the transitions in a 62.5Mb/s input data streams
>   - two cores for the two primary inputs; absolute
>     timing guarantees were required. I could squeeze it
>     so that each input "cycle" was suspended for ~100ns
>     before the next input event arrived
>   - one core for front panel input
>   - one core for front panel output
>   - one controller core orchestrating all the other cores
>   - many cores for a USB interface
>
>Having guaranteed i/o timing in the presence of random
>interaction with a user and a host computer is rather
>nice :) The IDE gave those guarantees; I don't know of
>any other processor that could do that.
>
>Interrupts: get thee behind me Satan!

What so bad bout interrupts ? These are nice in kicking around the
state machine. In the simplest case non-interrupt code is required
only at startup to set up the ISRs and then go to a low power
wait-for-interrupt loop. The processor spends most o the time i the
wait-for-interrupt instruction.

Things get a bit more complicated with multiple interrupt, when it
would be preferable to prioritized the interrupts in hardware, in
order to control the deadlines.

The nice thing abut xCore is that each "interrupt" starts immediately
in a dedicated core, so no deadline issues in properly designed
system.

>
>Overall I was /remarkably/ pleased at how simple
>and predictable everything turned out to be. The
>data sheets and programming tutorials are exemplary
>in their conciseness and correctness. That's a benefit
>of having the same team design the hardware and
>software without being unduly constrained by the PDP11
>and 1970 compiler technology :)
>
>
>> The xCore could also be used to implement PLCs (Programmable Logic
>> Controller) with each execution loop executed in a dedicated core,
>> usually with different clocks for each loop. Quite a lot of problems
>> can be solved in a PLC type environment and the IEC 61131 programming
>> environment is quite handy. IEC 61131 has multiple kinds of
>> programming languages, e.g. ladder logic or ST (Structured Text, a
>> Modula/Pascal style programming language).
>
>I don't know anything about PLCs, but I'm
>suspicious about the clocking strategy you
>mention.

In a PLC you have at least one loop, that is executed at regular
intervals, typically controlled by a timer. There are several steps
that is done in each iteration of the loop:

1. Wait for activation from a timer
2. Read (sample) all needed inputs
3. Execute the processing for all signals in this sample
4. Write processing results to output pins
5. Go to sleep waiting for the next timer activation.

Of course this sounds stupid, if you have only a few signals to
handle, but if the loop processes tens or hundreds signals in each
iteration, the overhead per signal of running the loop remains low.

When processing binary signals, the operation done on each signal can
be quite simple, such as some AND and OR functions. If interrupts or
separate threads would be used separately for each signal, the
overhead would be huge compared to the primitive actual work done. A
loop for binary signals would typically executed every 1 to 20 ms.

To implement flip-flops etc. some storage is needed between loop
iterations to remember the state from the previous loop iteration,
i.e. there can be as many state machines as there are internal or
external signals. 

For analog signals typically a 50 to 200 ms cycle time is often
sufficient. The reading (sampling) input would typically be reading
the ADC, sample processing e.g. running one sample into the PID
controller and output typically feeding a DAC. The PID needs some
storage across the loop iterations to maintain the PID internal state.

A loop updating a display could typically be executed every 500 ms.

When implementing multiple loops with some RTOS, the binary loop would
have the highest priority,  followed by the analog loop ad at the
bottom the non-time sensitive display loop. The human user would
hardly notice, if there is a 50 ms timing jitter, if the analog loop
kicks in during display update.

With xCore type systems, you can assign a dedicated core to each loop,
without worrying about priorities. In practice, you could have 2, 5,
20, 50 and 200 ms binary loops and 40, 200, 400 and 2000 s analog
loops. With xCore, you could still assign an own core for each loop.

>
>Better, I would presume, to let each core
>have a 100MHz clock and to stall until it
>has something to do - i.e. an i/o event or
>message event from another core.
>
>Of course, such an i/o or message event
>could well be a "software" clock.
>
>
>
>> However, I do _not_ think that the xCore would be very handy for ad
>> hoc parallel processing, even with XMOS programming environment (which
>> is quite versatile).
>
>There are two points there.
>
>Firstly the xCORE processors are embedded devices
>not general purpose devices. Anybody planning to
>use them as general purpose compute engines will
>be, um, disappointed :)
>
>Having said that, ISTR some having one core being
>an ARM processor (other 7 being xCORE), and the
>IDE can generate code for ARMs. I have not
>investigated any of that.
>
>Secondly, xC is strongly based on Hoare's Communicating
>Sequential Processes (CSP), as was Occam in the 80.
>Several new languages (Go, Rust) also contain CSP
>syntax and semantics, thus indicating that people still
>think CSP is A Good Thing. In addition, it appears
>that message passing is still the most reliable
>general purpose way to structure large scale High
>Performance Computing (HPC) programs.
>
>That raises the question as to whether CSP (and "hence"
>xC) is, on balance, better/worse than the alternatives.
>That is not clear to me.
>
>Mind you, I do like xC's "asynchronous" "interface"
>extensions to CSP; they appear to be necessary on
>limited core devices
>
>
>>> 3) look at the investor lists for each company
>>>
>>> IMNSHO, point 2 is the killer advantage/USP.
>

[toc] | [prev] | [next] | [standalone]

#27543

On 07/01/18 11:35, upsidedown@downunder.com wrote:
> On Sat, 6 Jan 2018 11:16:36 +0000, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
>
>> On 06/01/18 10:32, upsidedown@downunder.com wrote:
>>> On Sat, 6 Jan 2018 09:45:31 +0000, Tom Gardner
>>> <spamjunk@blueyonder.co.uk> wrote:
>>>
>>>> On 06/01/18 00:35, Paul Rubin wrote:
>>>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>>>>>> Processors with up to 32 cores and 4000MIPS, and interrupt latencies
>>>>>> of 10ns.
>>>>>
>>>>> Why stop there?  http://greenarraychipss.com
>>>>
>>>> 1) I believe you can simply add more chips
>>>> in parallel, and the comms simply works, albeit
>>>> with increased latency
>>>>
>>>> 2) hardware is easy; the software is more difficult
>>>> and more important. XMOS has very good software
>>>> support (based on 40 years of theory and practical
>>>> implementations), plus excellent integration with
>>>> the hardware.
>>>
>>> The xCore style architecture is nice for multichannel DSP
>>> applications, in which each channel is assigned a dedicated core and
>>> the single sampling clock is routed to all cores, starting the
>>> execution of all cores at each sample clock transition.
>>
>> It is great for *much* more than that, e.g. a general
>> purpose test instrument.
>>
>> My "kick the tyres" test was a reciprocal frequency
>> counter with zero added hardware; software counted
>> the transitions in a 62.5Mb/s input data streams
>>   - two cores for the two primary inputs; absolute
>>     timing guarantees were required. I could squeeze it
>>     so that each input "cycle" was suspended for ~100ns
>>     before the next input event arrived
>>   - one core for front panel input
>>   - one core for front panel output
>>   - one controller core orchestrating all the other cores
>>   - many cores for a USB interface
>>
>> Having guaranteed i/o timing in the presence of random
>> interaction with a user and a host computer is rather
>> nice :) The IDE gave those guarantees; I don't know of
>> any other processor that could do that.
>>
>> Interrupts: get thee behind me Satan!
>
> What so bad bout interrupts ? These are nice in kicking around the
> state machine. In the simplest case non-interrupt code is required
> only at startup to set up the ISRs and then go to a low power
> wait-for-interrupt loop. The processor spends most o the time i the
> wait-for-interrupt instruction.

As you note just below, they make it somewhat difficult
to guarantee latency and throughput, except in
"embarrassingly slow" applications.

I will admit to using wry overstatements to shock
youngsters out of the mistaken belief that interrupts
are the only mechanism. I doubt that's necessary in
your case :)


> Things get a bit more complicated with multiple interrupt, when it
> would be preferable to prioritized the interrupts in hardware, in
> order to control the deadlines.
>
> The nice thing abut xCore is that each "interrupt" starts immediately
> in a dedicated core, so no deadline issues in properly designed
> system.
>
>>
>> Overall I was /remarkably/ pleased at how simple
>> and predictable everything turned out to be. The
>> data sheets and programming tutorials are exemplary
>> in their conciseness and correctness. That's a benefit
>> of having the same team design the hardware and
>> software without being unduly constrained by the PDP11
>> and 1970 compiler technology :)
>>
>>
>>> The xCore could also be used to implement PLCs (Programmable Logic
>>> Controller) with each execution loop executed in a dedicated core,
>>> usually with different clocks for each loop. Quite a lot of problems
>>> can be solved in a PLC type environment and the IEC 61131 programming
>>> environment is quite handy. IEC 61131 has multiple kinds of
>>> programming languages, e.g. ladder logic or ST (Structured Text, a
>>> Modula/Pascal style programming language).
>>
>> I don't know anything about PLCs, but I'm
>> suspicious about the clocking strategy you
>> mention.
>
> In a PLC you have at least one loop, that is executed at regular
> intervals, typically controlled by a timer. There are several steps
> that is done in each iteration of the loop:
>
> 1. Wait for activation from a timer
> 2. Read (sample) all needed inputs
> 3. Execute the processing for all signals in this sample
> 4. Write processing results to output pins
> 5. Go to sleep waiting for the next timer activation.
>
> Of course this sounds stupid, if you have only a few signals to
> handle, but if the loop processes tens or hundreds signals in each
> iteration, the overhead per signal of running the loop remains low.
>
> When processing binary signals, the operation done on each signal can
> be quite simple, such as some AND and OR functions. If interrupts or
> separate threads would be used separately for each signal, the
> overhead would be huge compared to the primitive actual work done. A
> loop for binary signals would typically executed every 1 to 20 ms.
>
> To implement flip-flops etc. some storage is needed between loop
> iterations to remember the state from the previous loop iteration,
> i.e. there can be as many state machines as there are internal or
> external signals.
>
> For analog signals typically a 50 to 200 ms cycle time is often
> sufficient. The reading (sampling) input would typically be reading
> the ADC, sample processing e.g. running one sample into the PID
> controller and output typically feeding a DAC. The PID needs some
> storage across the loop iterations to maintain the PID internal state.
>
> A loop updating a display could typically be executed every 500 ms.
>
> When implementing multiple loops with some RTOS, the binary loop would
> have the highest priority,  followed by the analog loop ad at the
> bottom the non-time sensitive display loop. The human user would
> hardly notice, if there is a 50 ms timing jitter, if the analog loop
> kicks in during display update.

That all makes sense, and I would class that as an
"embarrassingly slow" application domain.


> With xCore type systems, you can assign a dedicated core to each loop,
> without worrying about priorities. In practice, you could have 2, 5,
> 20, 50 and 200 ms binary loops and 40, 200, 400 and 2000 s analog
> loops. With xCore, you could still assign an own core for each loop.

I don't think xCORE would offer any killer advantages
in such an implementation.

OTOH, xCORE could simultaneously communicate over
ethernet or USB, or control LCDs segments directly
(i.e. preserving zero DC bias), with _zero_ changes
to the latency and throughput.

That kind of consideration can make system design
less brittle in the face of evolving requirements.

Whether that is beneficial depends on circumstances,
of course.


>> Better, I would presume, to let each core
>> have a 100MHz clock and to stall until it
>> has something to do - i.e. an i/o event or
>> message event from another core.
>>
>> Of course, such an i/o or message event
>> could well be a "software" clock.
>>
>>
>>
>>> However, I do _not_ think that the xCore would be very handy for ad
>>> hoc parallel processing, even with XMOS programming environment (which
>>> is quite versatile).
>>
>> There are two points there.
>>
>> Firstly the xCORE processors are embedded devices
>> not general purpose devices. Anybody planning to
>> use them as general purpose compute engines will
>> be, um, disappointed :)
>>
>> Having said that, ISTR some having one core being
>> an ARM processor (other 7 being xCORE), and the
>> IDE can generate code for ARMs. I have not
>> investigated any of that.
>>
>> Secondly, xC is strongly based on Hoare's Communicating
>> Sequential Processes (CSP), as was Occam in the 80.
>> Several new languages (Go, Rust) also contain CSP
>> syntax and semantics, thus indicating that people still
>> think CSP is A Good Thing. In addition, it appears
>> that message passing is still the most reliable
>> general purpose way to structure large scale High
>> Performance Computing (HPC) programs.
>>
>> That raises the question as to whether CSP (and "hence"
>> xC) is, on balance, better/worse than the alternatives.
>> That is not clear to me.
>>
>> Mind you, I do like xC's "asynchronous" "interface"
>> extensions to CSP; they appear to be necessary on
>> limited core devices
>>
>>
>>>> 3) look at the investor lists for each company
>>>>
>>>> IMNSHO, point 2 is the killer advantage/USP.
>>
>

[toc] | [prev] | [next] | [standalone]

#27521

upsidedown@downunder.com wrote:
> On Sat, 6 Jan 2018 09:45:31 +0000, Tom Gardner
> <spamjunk@blueyonder.co.uk> wrote:
> 
>> On 06/01/18 00:35, Paul Rubin wrote:
>>> Tom Gardner <spamjunk@blueyonder.co.uk> writes:
>>>> Processors with up to 32 cores and 4000MIPS, and interrupt latencies
>>>> of 10ns.
>>>
>>> Why stop there?  http://greenarraychipss.com
>>
>> 1) I believe you can simply add more chips
>> in parallel, and the comms simply works, albeit
>> with increased latency
>>
>> 2) hardware is easy; the software is more difficult
>> and more important. XMOS has very good software
>> support (based on 40 years of theory and practical
>> implementations), plus excellent integration with
>> the hardware.
> 
> The xCore style architecture is nice for multichannel DSP
> applications, in which each channel is assigned a dedicated core and
> the single sampling clock is routed to all cores, starting the
> execution of all cores at each sample clock transition.
> 
> The xCore could also be used to implement PLCs (Programmable Logic
> Controller) with each execution loop executed in a dedicated core,
> usually with different clocks for each loop. Quite a lot of problems
> can be solved in a PLC type environment and the IEC 61131 programming
> environment is quite handy. IEC 61131 has multiple kinds of
> programming languages, e.g. ladder logic or ST (Structured Text, a
> Modula/Pascal style programming language).
> 

IMO, the systems software end of PLCs is a slow-moving train wreck.

They do what they do very well but nobody who uses them seems very fond
of what they are capable of. Ladder logic is excellent, but
rather limited.

And part of that is that SCADA protocols seem to be just bizarre and...
rent-seekey.

I know ( and have done some work for ) someone who is using RasPi and
Arduino-inspired custom hardware and it's a whale of a lot richer
software suite than traditional SCADA/PLC.

> However, I do _not_ think that the xCore would be very handy for ad
> hoc parallel processing, even with XMOS programming environment (which
> is quite versatile).
>   

It seems like total overkill for SCADA in general. I don't know if it 
means you can have GPP solutions that compete with ASICs ( I seriously
doubt it ) but the economics of ASICs have gone mad anyway :)

>>
>> 3) look at the investor lists for each company
>>
>> IMNSHO, point 2 is the killer advantage/USP.
> 

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#27532

On 06/01/18 22:49, Les Cargill wrote:
> upsidedown@downunder.com wrote:
>> However, I do _not_ think that the xCore would be very handy for ad hoc
>> parallel processing, even with XMOS programming environment (which is quite
>> versatile).
>>
>
> It seems like total overkill for SCADA in general.

Only in the sense that all fast processors, HLLs and
dev environments are overkill. Usually the determining
factors are cost and industrial inertia.

(When I returned to hardware/embedded after a gap
of 20 years, I was horrified at how little had
changed).


> I don't know if it means
> you can have GPP solutions that compete with ASICs ( I seriously doubt it )
> but the economics of ASICs have gone mad anyway :)

xCore has hard realtime "FPGA-like" i/o port structures, e.g.
  - per i/o port clocks down to a 4ns resolution (250MHz)
  - SERDES
  - timers for each i/o port
  - read inputs at a specific future clock cycle
  - capture time at which an input occurred
  - specify time at which the next output will occur
  - i/o "events" and messages latency of 10ns

The xC language and processor architecture also allow
hard realtime guarantees to be made by the IDE without
executing code. The IDE examines the (optimised) object
code emitted by the LLVM compiler, and calculates the
min/max timings from the call-flow graph.

IMNSHO they do eat into FPGA territory in ways that
other processors and languages simply cannot: /hard/
realtime /guarantees/, low latency, and multiprocessing.

They will not, of course, replace FPGAs. Nonetheless
in some cases they are a very viable alternative.
Given the impressive investments from many external
companies over the past decade, others agree :)

People that have a deep personal interest in FPGAs
will likely resist that, of course :)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web