rusefi.com

Since very early days of rusEFI I am curious about a toolchain for higher-level programming. I still do not have a great solution.

FSIO is an approach where we build our own language - that's really a lot of effort, FSIO would never be making developers more efficient, only limited scope. Not really an option.

https://rusefi.com/forum/viewtopic.php?f=5&t=741 did not go anywhere - an open source toolchain for model-based development does not seem to exist.

A funny option would be to embed a subset of java JVM - even a single-threaded or limited-threaded java runtime with garbage collection could be useful for the slower and richer areas of the codebase. No embeddable JVM I am aware of, it could be fun to make one from existing pieces but that's really a side gig.

Maybe Rust? Rust seems to depend on LLVM, ChibiOS claims clang support - so maybe Rust.

Another not great option would be to move high-level computation to a separate CPU running non-real-time linux and keep arm/chibios only for the quick stuff.

What else is around?

https://github.com/rusefi/funnyvm is the attempt to pile together a subset of a JVM in 5 minutes. So far it's a failed attempt - I do not speak Makefile enough

AndreyB wrote: ↑

Tue Apr 20, 2021 3:26 am

Maybe Rust? Rust seems to depend on LLVM, ChibiOS claims clang support - so maybe Rust.

As far as we're concerned, Rust is functionally the same as C++. Both compile to native code. No runtime for either. Not really much level than c++.

If your concern is ease of access, ease of learning, and ease of editing code on the ECU, Rust is not the place. The toolchain, build, and deploy process would look the same.

AndreyB wrote: ↑

Tue Apr 20, 2021 3:26 am

Since very early days of rusEFI I am curious about a toolchain for higher-level programming. I still do not have a great solution.

FSIO is an approach where we build our own language - that's really a lot of effort, FSIO would never be making developers more efficient, only limited scope. Not really an option.

https://rusefi.com/forum/viewtopic.php?f=5&t=741 did not go anywhere - an open source toolchain for model-based development does not seem to exist.

A funny option would be to embed a subset of java JVM - even a single-threaded or limited-threaded java runtime with garbage collection could be useful for the slower and richer areas of the codebase. No embeddable JVM I am aware of, it could be fun to make one from existing pieces but that's really a side gig.

Another not great option would be to move high-level computation to a separate CPU running non-real-time linux and keep arm/chibios only for the quick stuff.

I am still not yet sure what kind of problem you are trying to solve.

Can you please precisely define:

• making developers more efficient
• higher level programming
• slower and richer areas of the codebase

Have you heard of Lua? It's already used for embedded automotive applications on STM32: https://wiki.autosportlabs.com/RaceCapturePro_Lua_Scripting

Most OEMs have tools which allow then to specify high level stuff. They spec number of cyls, injector flow rates, etc. The tool then splices together the code they need to operate the engine. I recall Freescale has one that can be downloaded for free.

I will admit I can only see the need in terms of people making their own algorithms or strategies. Which leads me to think that the number of people that need it is very small and the number of those willing to put the work in to achieve it is even smaller.

The FSIO is a case where MATLAB or SciLab would work but that comes with big additional challenges of integrating any of it's auto generated code.

I feel a lot of what we are trying to cover here would be well served by an online or GUI based FSIO calculator. Something that we could use to interpret the input equation in more normal math notation and have it generate the FSIO compatible RPN output.

If we integrate into scratch, we could potentially attract many kids they would work for free.
https://scratch.mit.edu/

Scratch is a fairly decent graphical / easy to use programming environment. It might not be that far fetch of an idea to use as a higher level programming environment.

kb1gtt wrote: ↑

Tue Apr 20, 2021 9:10 pm

Scratch is a fairly decent graphical / easy to use programming environment. It might not be that far fetch of an idea to use as a higher level programming environment.

I think you are confusing "high level" and "simple". Simple languages can be high or low level, and high level languages can be simple or complex.

Scratch is a high level, simple language.

C#, Java, C++, and Rust are high level, complex languages.

Lua, JavaScript (ECMAScript) and Python are high level and somewhere in the middle, these days leaning complex.

mck1117 wrote: ↑

Tue Apr 20, 2021 6:55 am

Have you heard of Lua? It's already used for embedded automotive applications on STM32: https://wiki.autosportlabs.com/RaceCapturePro_Lua_Scripting

http://www.eluaproject.net/ that might be winner here! There is also https://github.com/linvinus/chibios_with_elua which would probably need to be ported to fresh ChibiOS

AndreyB wrote: ↑

Wed Apr 21, 2021 4:24 pm

mck1117 wrote: ↑

Tue Apr 20, 2021 6:55 am

Have you heard of Lua? It's already used for embedded automotive applications on STM32: https://wiki.autosportlabs.com/RaceCapturePro_Lua_Scripting

http://www.eluaproject.net/ that might be winner here! There is also https://github.com/linvinus/chibios_with_elua which would probably need to be ported to fresh ChibiOS

Racecapture's firmware is also open source https://github.com/autosportlabs/RaceCapture-Pro_firmware

OrchardPerformance wrote: ↑

Tue Apr 20, 2021 1:16 pm

I will admit I can only see the need in terms of people making their own algorithms or strategies. Which leads me to think that the number of people that need it is very small and the number of those willing to put the work in to achieve it is even smaller.

That sounds right. I use enginelab which was created to let most anyone easily set up whatever they want. I think its god's gift to the ecu market but 10 years later I'm not sure there are a dozen users. AEM uses it which is how they can create so many car specific setups.

Adaptric came out with a setup that used a labview knock-off that was pretty neat...very few understood and that caused the need for a massive amount of support time. They dropped it.

Motec M1 stuff is a C-lite, a few dealers use it to create custom applications that they then sell though motec while the vast majority of users buy pre-made apps.

...don't know