Embedded Rust on microcontrollers (Cortex M, Cortex A, Softcores etc.)

[coppice]

GC and caches/NUMA/multicore/etc all screw up hard realtime guarantees. Hence - back to my point(!) - there's little validity to this contention: .....

An example C# and java with its garbage collector were a goldmine for some epic hacks since the garbage collector was not real time.

Que? 

C isn't "real time" (to repeat your misuse of the term) either!

In C you still have the choice how you manage memory yourself. In Java, C#, Python, etc. you don't.

Most hard real time solutions do manage their memory, but do it statically. That is, they check the configuration requirements, allocate memory as appropriate, and stick with it until operation might be paused for a reconfiguration.

[tggzzz]

Most hard real time solutions do manage their memory, but do it statically. That is, they check the configuration requirements, allocate memory as appropriate, and stick with it until operation might be paused for a reconfiguration.

Agreed.

Even that isn't sufficient to be able to predict performance on a modern processor and computer.

Except in special circumstances it is impossible to predict the time taken to read (or worse write) an array element, because the time depends on the values that variables had arbitrarily far in the past. (And the sequence of instructions executed, of course)

People really ought to be disabused of the false idea that C performance is predictable and other languages aren't predictable.

[coppice]

People really ought to be disabused of the false idea that C performance is predictable and other languages aren't predictable.

Its amazing how clueless even quite senior engineers can be about the strengths and weaknesses of modern tools. Like taking code that runs in a loop, putting it on an ultra low power MCU, and being shocked that the current consumption is not anything like the minuscule figures the vendors have indicated.

[tggzzz]

People really ought to be disabused of the false idea that C performance is predictable and other languages aren't predictable.

Its amazing how clueless even quite senior engineers can be about the strengths and weaknesses of modern tools. Like taking code that runs in a loop, putting it on an ultra low power MCU, and being shocked that the current consumption is not anything like the minuscule figures the vendors have indicated.

There seem to be a few boundaries in thinking, possibly derived from how Things Are Taught.

Chemistry vs biology. That meant biochemistry had to be "invented" in the 60s/70s.

Analogue vs digitial vs RF electronics. OK, RF used to be completely distinct, but the rise of DSP/SDR and clock speeds has made the boundaries very porous. Digital vs analogue: too many people don't understand that (almost) all electronics are analogue, with some analogue circuits interpreting voltages as digital signals.

Software vs hardware vs electronics vs physics. To me they are a continuum, all interacting with one another (your example is software<->physics).

I see no easy-to-define boundary between (digital) hardware and software. But many people's experience is so insular and limited that they have difficulty comprehending the similarities and can't understand why there is no solid boundary.

[Kjelt]

I see no easy-to-define boundary between (digital) hardware and software. But many people's experience is so insular and limited that they have difficulty comprehending the similarities and can't understand why there is no solid boundary.

That has IMO less to do with people than with the college/university system artificially  seperating both.
But this goes for all studies all sciences, the artificial boundaries are so people can graduate in four years and have a limited scope. Everything from the universe to the sub molecule level are linked but comprehending everything is too big for a single human being to comprehend. Then you have to split it up in smaller parts and we get specialists.

But what I don't get is that if you have mastered one part you are not interested in the part next to it with what you interact. Personally I have a broad interest and also have all the hobbies, electronics, software, me hanics, mechatronics, pneumatics.

[coppice]

I see no easy-to-define boundary between (digital) hardware and software. But many people's experience is so insular and limited that they have difficulty comprehending the similarities and can't understand why there is no solid boundary.

People haven't really been hired for their ability to write software since the early 70s. Sure, there are lots of ads for software people, but when you get down to what they are really looking for its not the ability to write software. That's like the ability to write English. It a requirement so basic it barely registers in an interview. What people are really hired for at some level is application expertise. That might be business practices, or database design, or human interaction, or knowing enough about electronics to write the software to control some.

There used to be things called :software houses" that did really well in the early 70s as pure software plays, but crashed at the end of the 70s. They had to rapidly adapt to become some form of systems house, which was pretty hard to do, as there was a massive economic downturn at just the time they were restructuring.

[tggzzz]

I see no easy-to-define boundary between (digital) hardware and software. But many people's experience is so insular and limited that they have difficulty comprehending the similarities and can't understand why there is no solid boundary.

That has IMO less to do with people than with the college/university system artificially  seperating both.
But this goes for all studies all sciences, the artificial boundaries are so people can graduate in four years and have a limited scope. Everything from the universe to the sub molecule level are linked but comprehending everything is too big for a single human being to comprehend. Then you have to split it up in smaller parts and we get specialists.

Creating models is the way the complexity is contained. But you have to understand the source of the model and the model's boundaries. As someone once put it, "the best result of advanced mathematics is that you don't have to understand the detailed derivation".

But what I don't get is that if you have mastered one part you are not interested in the part next to it with what you interact. Personally I have a broad interest and also have all the hobbies, electronics, software, me hanics, mechatronics, pneumatics.

Just so.

That principle also applies in business....

In order to understand the value your product/service has to your customer, you have to understand how your product/service helps/hinders giving value to your customer's customers. Similarly, in order to have a good relationship with your supplier so they want to help you, you have to understand how they do/don't make their money.

[Siwastaja]

Realtime-ness in itself is a continuum. From most control and guarantees, to least,

1 Custom ASICs
2 FPGA's
3 The XMOS things
4 High end microcontrollers with application features (caches, external flash memories) disabled (minus point if RTOS is used)
5 Low end microcontrollers
6 High end microcontrollers with said application features enabled and used for all code (minus point if RTOS is used)
7 Application CPUs with general purpose OS tailored for real-time tasks
8 General purpose PC with general purpose OS not optimized for real-time tasks

1-3 can prove timing to one clock cycle, but with decreasing amount of resources (custom ASIC can do sub-ns stuff; FPGA is limited to maybe 500MHz tops clock and digital synchronous logic; XMOS is yet a step slower, and hard-limited by number of cores). 4-5 can be sometimes proved down to a clock cycle, but that is usually too much work; practically they are accurate down to "a few" cycles. Additionally, parallelism with many tasks which all are highly timing-critical becomes impossible. 6-8 become progressively more difficult to try to prove anything regarding timing.

A wise man learns to use the available tools; for example, while a high-end microcontroller with caches appear slower and more jittery if programmed lazily, it could be equipped with core-coupled instruction RAM which can be used for all timing-critical routines, leaving only user interfaces and such behind slower interfaces (and caches).

[Marco]

I'm pretty sure Kjelt was talking about GC not working real time in the sense of not immediately calling the destructor the moment an object goes out of scope BTW.

[tggzzz]

Realtime-ness in itself is a continuum. From most control and guarantees, to least,

1 Custom ASICs
2 FPGA's
3 The XMOS things
4 High end microcontrollers with application features (caches, external flash memories) disabled (minus point if RTOS is used)
5 Low end microcontrollers
6 High end microcontrollers with said application features enabled and used for all code (minus point if RTOS is used)
7 Application CPUs with general purpose OS tailored for real-time tasks
8 General purpose PC with general purpose OS not optimized for real-time tasks

1-3 can prove timing to one clock cycle, but with decreasing amount of resources (custom ASIC can do sub-ns stuff; FPGA is limited to maybe 500MHz tops clock and digital synchronous logic; XMOS is yet a step slower, and hard-limited by number of cores). 4-5 can be sometimes proved down to a clock cycle, but that is usually too much work; practically they are accurate down to "a few" cycles. Additionally, parallelism with many tasks which all are highly timing-critical becomes impossible. 6-8 become progressively more difficult to try to prove anything regarding timing.

A wise man learns to use the available tools; for example, while a high-end microcontroller with caches appear slower and more jittery if programmed lazily, it could be equipped with core-coupled instruction RAM which can be used for all timing-critical routines, leaving only user interfaces and such behind slower interfaces (and caches).

A sensible summary, especially "A wise man learns to use the available tools"

I'd nit-pick:

• point 1 Custom ASICs and discrete logic
• point 1-2 to sub-clock predictability, since they will be estimating gate and wire delays
• point 3-7 minus point if any algorithm which isn't O(1) used, e.g. a dictionary where performance degenerates when too full

The last of those is ignored by people that think programs written in C (and other languages of course!) have predictable performance.

[NorthGuy]

In FPGA you have full control of timing, so you can time events very precisely, such as 50-100 ps resolution.

In MCUs, if you have cycle accurate CPU, the best you can do is a clock cycle, say 10 ns on 100 MHz CPU. As CPUs get faster they tend to lose their cycle-accuracy, so you cannot get anywhere close to FPGAs.

However, many MCUs have means to time things more precisely, such as PWM modules which may produce sub-ns resolution regardless of the CPU clock.

All of these have nothing to do with languages however. In FPGA to get the highest resolution you have to use vendor-specific primitives (no matter if you use VHDL, Verilog, or whatever). To get precision on cycle-accurate MCU you must use assembler. To use timing features of MCU hardware modules, you write to MCU registers (or use vendor-specific librarians which do that for you).

[coppice]

Realtime-ness in itself is a continuum. From most control and guarantees, to least,

1 Custom ASICs
2 FPGA's
3 The XMOS things
4 High end microcontrollers with application features (caches, external flash memories) disabled (minus point if RTOS is used)
5 Low end microcontrollers
6 High end microcontrollers with said application features enabled and used for all code (minus point if RTOS is used)
7 Application CPUs with general purpose OS tailored for real-time tasks
8 General purpose PC with general purpose OS not optimized for real-time tasks

1-3 can prove timing to one clock cycle, but with decreasing amount of resources (custom ASIC can do sub-ns stuff; FPGA is limited to maybe 500MHz tops clock and digital synchronous logic; XMOS is yet a step slower, and hard-limited by number of cores). 4-5 can be sometimes proved down to a clock cycle, but that is usually too much work; practically they are accurate down to "a few" cycles. Additionally, parallelism with many tasks which all are highly timing-critical becomes impossible. 6-8 become progressively more difficult to try to prove anything regarding timing.

A wise man learns to use the available tools; for example, while a high-end microcontroller with caches appear slower and more jittery if programmed lazily, it could be equipped with core-coupled instruction RAM which can be used for all timing-critical routines, leaving only user interfaces and such behind slower interfaces (and caches).

Nothing confuses people like temporal issues. You seem to be confusing speed with real time. Hard real time is about meeting strict deadlines 100% of the time. Sometimes those deadlines are really short and only a few techniques can meet the goal. Sometimes those deadlines are quite long and a wide range of approaches can be shown to reliable. In almost every case you need to clock at the input and output interfaces, get the response to an input ready ahead of or exactly on the output deadline, and let the output clock feed it through at the right moment. If your deadlines are really critical the purity of the clocks at the input and output become your actual real time performance limit, not the solution you use in between.

[tggzzz]

To get precision on cycle-accurate MCU you must use assembler.

Not true.

The object code timing will be the same whether it is created directly by a human or indirectly via a compiler.

The algorithms, data structures, data values, and hardware will determine how repeatable/predictable the algorithm and instruction timings turn out to be. The language is irrelevant.

[NorthGuy]

To get precision on cycle-accurate MCU you must use assembler.

Not true.

Ok. Write a code which toggles one pin and then toggles the other pin exactly 4 cycles later without using assembler.

[coppice]

To get precision on cycle-accurate MCU you must use assembler.

Not true.

The object code timing will be the same whether it is created directly by a human or indirectly via a compiler.

The algorithms, data structures, data values, and hardware will determine how repeatable/predictable the algorithm and instruction timings turn out to be.

In a sense he was right. In a core so simple that the timing is predictable (which is getting rare) assembly language code will always do what you expect. For any high level language you need to check the version of every software tool you use, and ensure they never change during the life of the software. Any minor update might change the generated code.

[coppice]

To get precision on cycle-accurate MCU you must use assembler.

Not true.

Ok. Write a code which toggles one pin and then toggles the other pin exactly 4 cycles later without using assembler.

For things that basic the code produced by a compiler is so predictable that people frequently write C code for it. Looking up the cycles produced by simple C patterns is really no different from looking up the cycles each line of assembly language takes. As predictable cores fade away that will end.

[tggzzz]

To get precision on cycle-accurate MCU you must use assembler.

Not true.

Ok. Write a code which toggles one pin and then toggles the other pin exactly 4 cycles later without using assembler.

Please don't snip the reasons in order to make a strawman argument.

Or maybe you didn't understand the reasons?

[tggzzz]

To get precision on cycle-accurate MCU you must use assembler.

Not true.

The object code timing will be the same whether it is created directly by a human or indirectly via a compiler.

The algorithms, data structures, data values, and hardware will determine how repeatable/predictable the algorithm and instruction timings turn out to be.

In a sense he was right. In a core so simple that the timing is predictable (which is getting rare) assembly language code will always do what you expect. For any high level language you need to check the version of every software tool you use, and ensure they never change during the life of the software. Any minor update might change the generated code.

There's truth in that, but it isn't clear cut.

[tggzzz]

To get precision on cycle-accurate MCU you must use assembler.

Not true.

Ok. Write a code which toggles one pin and then toggles the other pin exactly 4 cycles later without using assembler.

Or perhaps I should enlighten people to one example of programming in a hard realtime environment. From the relevant programming guide, an example of generating a clock with a 40% duty cycle...

6.8 Performing I/O on specific clock edges

It is often necessary to perform an I/O operation on a port at a specific time with respect to its clock. The program below drives a pin high on the third clock period and low on the fifth:

Code: [Select]

void do_toggle ( out port  p) {
  int count ;
  p <: 0 @ count ;  // timestamped output
  while (1) {
    count += 3;
    p count <: 1; // timed output
    count += 2;
    p count <: 0; //  timed output
  }
}
The statement
  p <: 0 count;
performs a timestamped output, outputting the value 0 to the port p and reading into the variable count the value of the port counter when the output data is driven on the pins. The program then increments count by a value of 3 and performs a timed output statement
  p count <: 1;
This statement causes the port to wait until its counter equals the value count+3 (advancing three clock periods) and to then drive its pin high. The last two statements delay the next output by two clock periods.

[NorthGuy]

To get precision on cycle-accurate MCU you must use assembler.

Not true.

Ok. Write a code which toggles one pin and then toggles the other pin exactly 4 cycles later without using assembler.

Or perhaps I should enlighten people to one example of programming in a hard realtime environment. From the relevant programming guide, an example of generating a clock with a 40% duty cycle...

6.8 Performing I/O on specific clock edges

It is often necessary to perform an I/O operation on a port at a specific time with respect to its clock. The program below drives a pin high on the third clock period and low on the fifth:

Code: [Select]

void do_toggle ( out port  p) {
  int count ;
  p <: 0 @ count ;  // timestamped output
  while (1) {
    count += 3;
    p count <: 1; // timed output
    count += 2;
    p count <: 0; //  timed output
  }
}
The statement
  p <: 0 count;
performs a timestamped output, outputting the value 0 to the port p and reading into the variable count the value of the port counter when the output data is driven on the pins. The program then increments count by a value of 3 and performs a timed output statement
  p count <: 1;
This statement causes the port to wait until its counter equals the value count+3 (advancing three clock periods) and to then drive its pin high. The last two statements delay the next output by two clock periods.

What cycle-accurate MCU is this written for?

[tggzzz]

To get precision on cycle-accurate MCU you must use assembler.

Not true.

Ok. Write a code which toggles one pin and then toggles the other pin exactly 4 cycles later without using assembler.

Or perhaps I should enlighten people to one example of programming in a hard realtime environment. From the relevant programming guide, an example of generating a clock with a 40% duty cycle...

6.8 Performing I/O on specific clock edges

It is often necessary to perform an I/O operation on a port at a specific time with respect to its clock. The program below drives a pin high on the third clock period and low on the fifth:

Code: [Select]

void do_toggle ( out port  p) {
  int count ;
  p <: 0 @ count ;  // timestamped output
  while (1) {
    count += 3;
    p count <: 1; // timed output
    count += 2;
    p count <: 0; //  timed output
  }
}
The statement
  p <: 0 count;
performs a timestamped output, outputting the value 0 to the port p and reading into the variable count the value of the port counter when the output data is driven on the pins. The program then increments count by a value of 3 and performs a timed output statement
  p count <: 1;
This statement causes the port to wait until its counter equals the value count+3 (advancing three clock periods) and to then drive its pin high. The last two statements delay the next output by two clock periods.

What cycle-accurate MCU is this written for?

xCORE, of course.

The i/o ports' clock is settable independently of the processor clock. FPGA equivalent: clock tiles.

There are no library functions invoked by that code; each output instruction translates directly into two assembly instructions, one to set the timer in the relevant port, one to set the data value.

[Siwastaja]

You seem to be confusing speed with real time.

I'm not confusing anything. "Realtime-ness" was a fluffy term on purpose, it has no definite, correct meaning.

In real world realtime applications, both performance (speed) AND predictability are important, which is why I grouped first by predictability, but within the group of similar predictability, sorted by performance.

People often confuse their importance, for example thinking that extreme predictability is way more important than performance, or vice versa. Typical example would be thinking that a 8MHz AVR is somehow "better" than a 400MHz Cortex-M7 only because in the latter, branch prediction and ISR stacking tail-chaining, gives a few clock cycles of jitter. In reality however, meeting deadlines (worst case behavior) is usually more important than small amount of jitter, raw performance is in favor of this.

[coppice]

Typical example would be thinking that a 8MHz AVR is somehow "better" than a 400MHz Cortex-M7 only because in the latter, branch prediction and ISR stacking tail-chaining, gives a few clock cycles of jitter. In reality however, meeting deadlines (worst case behavior) is usually more important than small amount of jitter, raw performance is in favor of this.

Is this M7 on a chip with so much RAM it can run at 400MHz with the caches of? If not you'll get a lot more than a few cycles of jitter. The effects of branch predictors are minor compared to cache. Its a real killer for predictability in most modern devices.

[NorthGuy]

xCORE, of course.

The i/o ports' clock is settable independently of the processor clock. FPGA equivalent: clock tiles.

So, it's a programmable periphery like PIO in RP2040.

[Siwastaja]

Is this M7 on a chip with so much RAM it can run at 400MHz with the caches of? If not you'll get a lot more than a few cycles of jitter. The effects of branch predictors are minor compared to cache. Its a real killer for predictability in most modern devices.

Of course it depends on a project. I have never needed external flash or external RAM and thus caches on any of my STM32H7 projects, which have been quite complex in my own opinion. Quite frankly, I don't see the use case for the caches at all, but maybe there are some I don't see. Clearly caches are available for the same reason you have JPEG codec or two CAN peripherals available: some users might want it.

For example, H743/H750 has 64KB of core-coupled instruction RAM which does not need to go through bus arbitration, and 128KB of core-coupled data RAM, same thing. Anything even remotely timing critical tends to fit in some dozen KB, in my experience. Put interrupt vectors and all ISRs on the ITCM, it could not be easier.