After Software, What's Next?

T

Timothy P Niemczyk

Let me know if you solve the marketing problem. We have a non-programable solid state solution to monitoring of inputs and outputs but marketing seems to stop forward progress. It is difficult to get industry to look beyond the the PLC market for a more secure solution.

> The number one problem I think is not technology, it is marketing.  There
> has been many great ideas that never get off of the ground.
 
> And most decry the procedural programming language stepping stone between mind and hardware. Assuming we
> don't veer off into massively parallel nanocomputers or chemical computing, I think the next step would be for our
> thinking machines to replicate a system from a description to produce an ASIC with logic built in or something on that
> order. Who will champion that? IP houses like ARM or the silicon giants.

I think the quantity of devices that are produced of a special ASIC type is much less than the quantity of ARM SoC devices.
Thus ARM solutions should be much cheaper.

My question is "What about hard realtime with ARM systems?"
For example, is it possible to assigning a given core exclusively for realtime tasks?

Where everything else will run on other cores.

If the realtime tasks have a bad "nice value" and you are able to measure or calculate a worst case cycle time of your realtime tasks, could we call it a realtime system?
 
> My question is "What about hard realtime with ARM systems?"
> For example, is it possible to assigning a given core exclusively for
> realtime tasks?

> Where everything else will run on other cores.

Probably not exactly what you are writing about, but an engineer I know has been spending time getting the inexpensive BeagleBone (ARM) to do linux-cnc (realtime) stuff. Here is a blog he started recently about this:
http://bb-lcnc.blogspot.com/
 
C

Charles Moeller

At long last, having solved the technical end, I am now working on the marketing problem:

I stumbled on a method that originated in Inventors Assistance League International, in which they suggest precise steps with which to perform a marketing campaign, not to the ultimate user, but to the manufacturer(s) or licensor(s). Such target (large) organizations would have the resources, once they are convinced of the item's/method's benefits, to carry the work forward.

The method leverages your ideas rather than having to do all the work yourself.

Can you describe the benefits of your "non-programmable SS solution"?

> Let me know if you solve the marketing problem. We have a non-programable solid state solution to monitoring of
> inputs and outputs but marketing seems to stop forward progress. It is difficult to get industry to look beyond
> the PLC market for a more secure solution.

>> The number one problem I think is not technology, it is marketing.  There
>> has been many great ideas that never get off of the ground.
 
C

Charles Moeller

pvbrowser:

ASIC requires massive chip volumes to be practical.

ARM is a set of “canned” solutions that already have a large volume, if you can find one that fits your application, but they use TM-types of operations and require large numbers of gates.

Hard realtime is not possible in a computing device.

In my opinion, a “real-time operating system” is a contradiction of terms, in that if an OS is relied upon to perform all, including time-critical process functions, then it is not a real-time system. This is based upon the observation that if one stops, in a real-time process, to look up or to fetch anything, or to perform any other function, one is truly out of real time. If the machine operation is linear-sequential, by my definition, it therefore can't be real time.

The only justification I can think of to call any OS an "RTOS" is that those particular systems may allow one to be as close as one may get to true real time <b>while using Boolean-sequential logic</b> (which, in truth, is not very close to true real time at all). That "everyone uses RTOSs" does not reverse the fact that they are very poor substitutes for true real-time operation. The universal factory automation that was eminent forty years ago has not yet happened, although the available computing power has since increased more than ten million-fold. It is still more cost-effective to manufacture most products semi-automatically. Because this is the actual case (just look around in industry) there must be something lacking in the current automation technology.

My definition: true real time is immediate response to the stimulus without having to perform any other function first. My parallel-concurrent PTQ system is, in that sense, true real time and produces a final hardware design from the process (being controlled) description.
 
C

Charles Moeller

Even a single core dedicated to "realtime" tasks can't really run in real time. It must run in machine op-cycles, where sampling, storing, fetching, comparing, etc. interrupts the "realtime" tasks. This TM-type computing in a von Neumann architecture, mediated by software is just not good enough for true realtime operation.

What is needed is a realtime portion of the system that is truly parallel-concurrent, with no instructions and no clock so it can concentrate its attention and dedicate its operation to stimulus-response in continuous, uninterrupted time and respond in immediate fashion. Thiis is how the supervisory or management portion of automated machine operation should be done.

>> My question is "What about hard realtime with ARM systems?"
>> For example, is it possible to assigning a given core exclusively for
>> realtime tasks?
>
>> Where everything else will run on other cores.
 
In response to Charles Moeller

According to my knowledge "realtime" means, that you can ensure a maximum time between a input and the according reaction.
Thus it is allowed that you need some instructions for fetching the input, do some calculations and output the result (same as every PLC does).

This can be achieved by a simple loop on dedicated hardware, where you can guarantee a maximum cycle time.
It could also be achived by interrupt driven I/O where you know the number of instructions needed for the ISR.

On a von Neumann machine you would have to know the maximum amount of time needed for scheduling and interrupt driven I/O. The userspace applications could not harm "realtime" because they can run on a lower priority as the realtime tasks.

When we talk about ARM / SoC (credit card sized) computers we will have a well defined set of hardware. We could run the emdedded hardware headless without booting up to the GUI, thus making the output more predictable. What we will have to take into account will be network I/O and USB traffic.

Eventually we are not able to calculate the according maximum response time, but we are able to do measurements. If we measure with heavy load and also watch the CPU usage, we will be able to ensure our maximum response and/or cycle time.

If we have multiple cores and we use a dedicated core for the realtime tasks i think get a solution which can provide even hard realtime.
(realtime does not necessarily mean fast but predictable according to a maximum response time)

This is not in conflict with the fact that you can get even faster reaction times on a ASIC.

But the CPU solution is much more flexible and much cheaper (provided the bandwith of your process is limited in bandwidth). You know according to Fourier you must have at least 2 samples within the period of the highest input frequency, this is sufficient
 
> According to my knowledge "realtime" means, that you can ensure a maximum time between a input and the according reaction.

real-time means delivering the correct data at the right time ( or deadline). How fast the reaction must be depends on the whole real-time system.

In a slow real-time process it can be minutes ... a fast real-time process e.g. needs a reaction time in the range of micro or milliseconds.

But in both cases we have a real-time system ...

Regards
Armin Steinhoff
 
C

Charles Moeller

pvbrowser:

Yes, “realtime” has been defined as something like “being ready before needed.”

Unfortunately, there are no guarantees for this at present in current technology, and no way to guarantee such a thing. The linear-sequential system will work only for as long as all events occur according to plan and there are no component failures or decision faults. The interrupts you mentioned are troublesome, because while being serviced, they suspend normal operation and cause distress to the idea of “realtime.”

The Nyquist–Shannon sampling theorem does not work for transients or spurious signals.

My PTQ system replaces linear-sequential algorithms with reactive circuits that are real-time and parallel-concurrent and which respond immediately rather than after fetch and decode, search and match, instruction, clock, interrupt, or executive loop times.
 
> Software is a consequence of using data processors or Turing-type machines (TMs) exclusively.

"SNIP"
AND, NOT, and STORE. That's three words. Imagine writing a newspaper article (or describing a dynamic process) using repetitions, variations, and combinations of only three root words. So few allowable words or operators (simplistic logic) forces structural complexity and is one of the reasons that software is troublesome. We can simplify the code by having more sophisticated primitive operators in the foundation logic, especially in the time-domain.

>Copyright 2011 by [email protected]
>
>Best regards,
>CharlieM

Yes it would get complex but remember DNA is mapped using only 4 "G C A T"
And the the whole English language uses only 26.
Down in the trenches digital electronics only uses two (1&0)
I guess it comes down to complexity, as compared to the average human understanding.
 
C

Charles Moeller

RussB,

Note that DNA is formulated with the 4 letters A, C, G, and T (abbreviations for the four different nucleotides). These nucleotides appear in specific groups of three to make a codon (word). The number of different codons, or words, possible is 4 x 4 x 4 = 64. Certain codons are strung in sequences to form the DNA strands. So the root words of DNA are 64 in number.

Twenty six letters make over a million words in the English language.

My dynamic logic can be expressed in combinations of eleven natural language words that together provide 60 different functions that can succinctly capture both static and dynamic behaviors of simple physical processes.

These functions, activated in parallel chains, mirror the process to be monitored and controlled. The functions can all be instantiated by interconnecting small numbers of NOR or NAND gates in a "sea of gates" FPGA. The fact that I can get all these different functions using one building block (2-input NOR gates) is due to the many different ways they may be interconnected.

(Recall that S. Cray built a supercomputer using only one type of NAND gate.)
 
Top