But I do not think that you can use Julia for any product that needs to be developed according to high security standards (e.g. DO-178C), because for these products you need formal verification not only of the code, but also of the compiler.
Julia does support ARM, but not ARM Cortex-M, i.e. those with no MMU (or only the 16-bit Thumb ISA), are not supported. Such assume non-Linux (or Linux variant Julia doesn’t support). In theory Julia could run baremetal, but I think it’s far away.
It might be possible to use an RTOS, like Arm OS (os.mbed.com), one that supports ARM Cortex-R. I’m just guessing here, it would have to be compatible enough with Linux/POSIX (or if not, Julia could support with some changes).
I do not foresee Julia ever supporting AVR or any 8-bit, or a future were using those are useful.
While ARM Cortex-R, does support real-time, and I believe Julia can too (given you’re careful to not trigger allocations, and using appropriate OS and hardware), note what Karpinski says:
Thanks, all for your responses. I was curious about where Julia-on-embedded might be headed (no rhyme intended!) I think its progression will depend on several factors, including, but not limited to, (1) real commercial need, (2) financial support for appropriate research, development, and testing, (3) willingness to restrict language constructs in smaller platforms if necessary, (4) level of effort required to use the desired parts of the language (from a source perspective), or to tie into specific compilation or build points, (5) whether the beauty and flavor of the language would be buried or lost by constraining it.
The garbage collector can and needs to be “constrained” for hard-real-time (but not all projects), and can already be done without changing the “language”. Mostly the user needs to be contained, not use all constructs of the language, like eval, that generates code at runtime (something you wouldn’t do in embedded, other languages for, do not have that). You can compile to assembly with PackageCompiler.jl, and even when using eval but then your code needs to have a compiler with it making the binary huge. There are ways to disable code you know will not be used, and PC could probably make smaller code by changing it 8not the Julia language), or some similar project. There are some older (outdated Intel’s Julia2C and I seem to remember another compiling Julia to C):
In essence, I was meaning that the user should be constrained from using things that would bloat the runtime size, cost, or danger, by modifying/parameterizing the compilation such that the user could not use certain constructs, such as “eval”. I am just beginning to read about Julia, so I am unfamiliar with its depths, thus I don’t know all of the potential pitfalls.
Or I’m assuming (still). I however see even e.g. ARM Cortex-M0 in the source code for Julia (but not sure what to read into that, if anything):
also ARM Cortex-Rs. When I said those to be supported, I really meant, they’re similar enough to ARM Cortex-A, some sort of middle ground between them and the M line, microcontrollers.
Anything that supports armv6 ISA that you can boot linux on is fine. In that you can (cross-)compile a version that works, though not necessarily tested thoroughly. Baremetal is not supported.
Is there any news here? @Amin_Yahyaabadi, @tshort, could you spend any time/effort on this since your thoughts/discussion in this topic back in August 2019?
The official support for 32-bit ARM still is Tier 3, will this remain the same in the future? Will there be an official 32-bit ARM binary for the next LTS version? There is one for 1.0.5; I managed to quickly do a minimal test (just install it and do some math in the REPL) on a Cortex-A7 and everything seemed to work just fine…
I don’t think Julia is capable of running on embedded devices unless the device has enough memory and you have enough time to spend precompiling your apps on that device. If you do all this, you can’t still use the app in real-time applications due to the garbage collector.
Now that sounds quite pessimistic… why so?
Sure, one needs enough memory to install and run Julia. Precompilation would only be necessary if something in the code changes (either when prototyping, or a “code upgrade” is compared to a full “software upgrade”). So having an embedded device that can self-compile changed logic or “scripts”, may be quite useful for some applications.
About real-time applications and GC: You can disable and re-enable the GC (GC.enable). So, you could disable it, run critical code, and then either re-enable it for non-time critical stuff, or manually trigger the collection (GC.gc) after every real-time loop instance.
Also, in very fast / time-critical embedded systems, one would anyway want to have almost everything statically allocated. In getting from a dynamic to a static variant of some code, Julia can help a lot (@code_...).
Any comments on my question related to official 32-bit ARM binaries?
Tier 3: Julia may or may not build. If it does, it is unlikely to pass tests. Binaries may be available in some cases. When they are, they should be considered experimental.
but all but two are for 64-bit ARM, which does actually have tier 1 support. It’s just that 32-bit ARM isn’t a priority (tier3 is to prevent ARM bugs blocking releases, while my understanding is older builds mostly work and I would expect for 1.6 too if not already out).
ARMv7 shifts from tier 2 to 3. We’ve had a number of issues on ARMv7,
which have made producing release binaries quite tricky due to build
failures and other issues.
About real-time applications and GC: You can disable and re-enable the GC
You can do that, but it’s not the best way. It will still allocate memory which is a no-no for hard-real-time, might be ok for soft-real-time.
There has been no official release after that, so Also, that issue was specific to Julia v1.6, but the official build on armv7l failed since Julia v1.4.2, so there might be other lingering issues.
Other people actively testing Julia master on these boards and reporting any issues would be very helpful. Since there is no CI for this platform, there is no easy way for the developers to catch regressions.
That may be, but Julia’s design does not encourage or require making all of your allocations static. Just where they matter. Memory management and being able to escape strict typing when necessary are key advantages of Julia.
The niche that Julia targets does not really coincide with the constraints of embedded devices (even though that is a moving target), especially with real time requirements, so I guess that most people just make a rational decision about not investing into this, and choose a different language or hardware.
The build reportedly isn’t successful on the official build machine though, that’s why there haven’t been official builds in a while for that platform.
Also, that issue was specific to Julia v1.6, but the official build on