Intel x86 Compilation

[soham.m17@gmail.com]

Hello,
New to this forum. Awesome work.

I was wondering whether anyone has tried to build the source for an Intel x86 target, especially with embedded libc variants like newlib.

Thank you!

[AndreyB]

We have it included into any download https://github.com/rusefi/rusefi/wiki/Download

that's called https://github.com/rusefi/rusefi/wiki/Virtual-simulator

[AndreyB]

Search forum for "simulator" for instance https://rusefi.com/forum/viewtopic.php?f=5&t=1707

[soham.m17@gmail.com]

Thank you so much. Very good to know, although I was wondering whether the native code has been compiled in intel x86 and possibly linux or some other OS based on x86. But this is a good starting point.

[AndreyB]

I guess I do not follow What is the difference between simulator and what you are looking for?

x86 usually does not have HW times and SPI and UART, not sure how much closer can you get to reality with x86.

[soham.m17@gmail.com]

Hello,

Recent Single-board x86 machines has UART, SPI. They also have High-precision Event Timers. I was wondering if there was any port of the firmware for such machines.

https://up-board.org/upsquared/specifications/

[mck1117]

Hello,

Recent Single-board x86 machines has UART, SPI. They also have High-precision Event Timers. I was wondering if there was any port of the firmware for such machines.

https://up-board.org/upsquared/specifications/

What's the latency like from the CPU core to an IO pin?

I'd be curious about the result to a test like this:

Code: Select all

while (true) {
    bool value = readGpio(x);
    writeGpio(value);
 }

And then feed a 1khz square wave in to a gpio, and look at the delay on the output. On any microcontroller, that delay is going to be on the order of 1-3 clock cycles, aka <20ns for the stm32 we use.

[mck1117]

On a raspberry pi the GPIO latency is on the order of 50-60us. 3000 times more than the stm32.

[soham.m17@gmail.com]

So are there parts of the code which rely on such nanosecond latency issues?

I was also wondering if there was any code hierarchy to understand different interrelations of different parts of the code. So we could try to implement some of the things in x86 (that may not rely on the high precision clocks).

I have found this: https://rusefi.com/forum/viewtopic.php?f=5&t=10, but this just explains the control flow. An explanation of the code hierarchy could be great - if I could be pointed to some page like that.

[mck1117]

So are there parts of the code which rely on such nanosecond latency issues?

Not nanoseconds, but <1us jitter is important. That engine is coming around whether you're ready for it or not, and you better be ready to fire the ignition system at the right time. At 6000 RPM, one degree passes in 27 microseconds, so we need around an order of magnitude better predictability than that for it to be viable.

So we could try to implement some of the things in x86 (that may not rely on the high precision clocks).

But why? What value do you see added by running on an x86 processor?

[soham.m17@gmail.com]

But why? What value do you see added by running on an x86 processor?

yes, x86 might not be ideal for such low latency jobs. However, we might employ offloading some of these jobs to microcontrollers like Arduino or even ARM-based ones, like the stm32 by cross-compiling.
The advantages of x86 is that they are widely available, and they have comprehensive application support, and devices support, if needed. Most importantly, in automotive systems, virtualization is increasingly needed to isolate critical and secure components from others. Therefore, multicore x86 processors with strong hardware virtualization could give great benefits if an RTOS could be run alongside other general purpose operating system like Linux.

[AndreyB]

Therefore, multicore x86 processors with strong hardware virtualization could give great benefits if an RTOS could be run alongside other general purpose operating system like Linux.

Arm-R52 https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r52 is supposed to be the healthier option for this, one day in the distant future.

[soham.m17@gmail.com]

Therefore, multicore x86 processors with strong hardware virtualization could give great benefits if an RTOS could be run alongside other general purpose operating system like Linux.

Arm-R52 https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r52 is supposed to be the healthier option for this, one day in the distant future.

Yes, ARM is coming up with virtualization support. Now, it would be interesting to see whether they could drive up the same latency with the upcoming hardware virtualization. But I hope you get my point.

[mck1117]

However, we might employ offloading some of these jobs to microcontrollers like Arduino or even ARM-based ones, like the stm32 by cross-compiling.

If anything, I would actually forsee the rusEfi architecture going the other direction. Instead of moving higher-level "frontal lobe" functions to a more powerful processor, I'd move lower-level timing critical stuff to an FPGA. We're not strapped for compute time right now, and a significant fraction of the work we do now is trigger decode and output scheduling, especially on high-tooth-count trigger patterns (like the very popular 60-2).

The advantages of x86 is that they are widely available, and they have comprehensive application support, and devices support, if needed.

Those advantages apply to the general purpose computing world. Those do not apply to the realtime computing world. AFAIK the only major user of x86 architecture processors in safety critical realtime applications is aviation. For example, the Airbus A320 uses the Intel 286, and the 777 the Intel 486 (along with some AMD and Motorola 68k stuff).