# Bring Julia code to embedded hardware (ARM)

**URL:** <https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979>\
**Category:** Maker\
**Created:** [January 23, 2019, 12:57pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979 "2019-01-23T12:57:50Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [July 25, 2020, 4:54pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/41 "2020-07-25T16:54:24Z")

</div>

The following talk might be interesting for you:  
[https://live.juliacon.org/talk/38UTLX](https://live.juliacon.org/talk/38UTLX)

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.

An example how to create a verified compiler/ toolchain you can find here for a C/C++ toolkit: [https://www.ti.com/lit/wp/spny004/spny004.pdf](https://www.ti.com/lit/wp/spny004/spny004.pdf)

This might not be required for small drones. Not so sure about the legal requirements for automated cars.

---

<div class="post-metadata">

**Author:** ![Allan\_Baker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/allan_baker/32/42645_2.png) [@Allan\_Baker](https://discourse.julialang.org/u/Allan_Baker)\
**Post date:** [July 25, 2020, 11:42pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/42 "2020-07-25T23:42:03Z")

</div>

Thanks!

---

<div class="post-metadata">

**Author:** ![amckay1](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/amckay1/32/8280_2.png) [@amckay1](https://discourse.julialang.org/u/amckay1)\
**Post date:** [July 26, 2020, 1:38am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/43 "2020-07-26T01:38:35Z")

</div>

I’m not as familiar with the verification tools aspect, but in terms of reliability for critical applications, you might be interested in this post from last year by Stefan Karpinski where he advocates for Julia as being safer than some statically typed languages such as C: [Julia with respect to reliability, sustainability, critical application, dynamic/static typing, big data, HPC? - #40 by StefanKarpinski](https://discourse.julialang.org/t/julia-with-respect-to-reliability-sustainability-critical-application-dynamic-static-typing-big-data-hpc/23135/40)

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [July 28, 2020, 11:29am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/44 "2020-07-28T11:29:56Z")

</div>

> [@cawhitley](#):
>
> AVR and ARM devices, most of which are too small to run Linux, as most of them had limited RAM and no memory management.

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](https://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:

> [@Julia with respect to reliability, sustainability, critical application, dynamic/static typing, big data, HPC?](https://discourse.julialang.org/t/julia-with-respect-to-reliability-sustainability-critical-application-dynamic-static-typing-big-data-hpc/23135/40):
>
> Julia does use a stop-the-world mark-and-sweet garbage collector. However, Julia’s support for and widespread use of immutable data and APIs for mutation of preallocated memory ( `f!` name convention for mutating functions) makes it fairly easy to write zero- or low-allocation code. This means that pressure on the garbage collector is much lower than many other garbage collected languages where memory pressure tends to be quite intense since the design of such languages usually makes it hard to avoid allocating objects.
> 
> That said, Julia is probably not the right choice for writing real-time systems.  
> […]  
> That said, I do think there is some reliability advantage to static type checking in safe static languages, but I also think that the cost in productivity and expressiveness is quite high.  
> […]  
> Bottom line: Julia is a good language for reliable programming. It is much safer than unsafe static languages like C, C++ and Fortran. It is also safer than most dynamic languages, which are duck-typed, whereas Julia can and does have explicit type annotations on function arguments. Finally, testing is the most important aspect of making any language reliable, and Julia has extensive tooling support for testing and a widespread culture of testing.

---

<div class="post-metadata">

**Author:** ![cawhitley](https://avatars.discourse-cdn.com/v4/letter/c/8797f3/32.png) [@cawhitley](https://discourse.julialang.org/u/cawhitley)\
**Post date:** [July 28, 2020, 12:47pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/45 "2020-07-28T12:47:22Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [July 28, 2020, 2:37pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/46 "2020-07-28T14:37:24Z")

</div>

What do you mean by:

> [@cawhitley](#):
>
> willingness to restrict language constructs in smaller platforms if necessary

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):

> [@How to use a julia compiled object from within a C program](https://discourse.julialang.org/t/how-to-use-a-julia-compiled-object-from-within-a-c-program/8475):
>
> Hi all ! I need to develop an interface to use an existing Julia project from within a C porgram. As I am VERY newbie in Julia, I started creating a VERY simple Julia script to better understand the operation mode. The steps I need to achieve are (I guess) : Write a simple julia script Create an object (using output-o compilation option) Create a shared object (by gcc -share) Create a .h header to use this library from C Use the Julia library from C But I am experiencing problems with the …

---

<div class="post-metadata">

**Author:** ![cawhitley](https://avatars.discourse-cdn.com/v4/letter/c/8797f3/32.png) [@cawhitley](https://discourse.julialang.org/u/cawhitley)\
**Post date:** [July 28, 2020, 2:57pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/47 "2020-07-28T14:57:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [July 28, 2020, 4:40pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/48 "2020-07-28T16:40:05Z")

</div>

> [@Palli](#):
>
> Julia does support ARM, but not ARM Cortex-M

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):

> <https://github.com/JuliaLang/julia/blob/a23a4ff08da5b6d95e9a35eee96e3260a452c02b/src/processor_arm.cpp#L50>

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.

---

<div class="post-metadata">

**Author:** ![yuyichao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yuyichao/32/20_2.png) [@yuyichao](https://discourse.julialang.org/u/yuyichao)\
**Post date:** [July 28, 2020, 6:05pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/49 "2020-07-28T18:05:27Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![asprionj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/asprionj/32/6856_2.png) [@asprionj](https://discourse.julialang.org/u/asprionj)\
**Post date:** [March 29, 2021, 2:28pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/50 "2021-03-29T14:28:05Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![Amin\_Yahyaabadi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/amin_yahyaabadi/32/9826_2.png) [@Amin\_Yahyaabadi](https://discourse.julialang.org/u/Amin_Yahyaabadi)\
**Post date:** [March 29, 2021, 11:37pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/51 "2021-03-29T23:37:49Z")

</div>

No, unfortunately, the organization got stale.

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.

---

<div class="post-metadata">

**Author:** ![asprionj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/asprionj/32/6856_2.png) [@asprionj](https://discourse.julialang.org/u/asprionj)\
**Post date:** [March 30, 2021, 9:52am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/52 "2021-03-30T09:52:02Z")

</div>

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](https://docs.julialang.org/en/v1/base/base/#Base.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](https://docs.julialang.org/en/v1/base/base/#Base.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?

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [March 30, 2021, 10:50am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/53 "2021-03-30T10:50:49Z")

</div>

> 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.

sounds more pessimistic that it actually is. ARM has 11 open bugs: [Issues · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/labels/arm)

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).

Before 1.4.0 release: [Support tier shuffle: Win32, ARMv7 -= 1, AArch64 += 1 (#667) · JuliaLang/www.julialang.org@55ff318 · GitHub](https://github.com/JuliaLang/www.julialang.org/commit/55ff318eec7e09e269a3229508e6621f14f9d004)

> 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.

Better is to avoid allocations entirely as is possible, see: [Robot Locomotion - JuliaHub](https://juliacomputing.com/case-studies/mit-robotics/)

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [March 30, 2021, 11:15am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/54 "2021-03-30T11:15:25Z")

</div>

> [@asprionj](#):
>
> Any comments on my question related to official 32-bit ARM binaries?

Julia doesn’t build for `armv7l` in the official building setup, that’s why there is no official build. Help to fix it would be appreciated. Recent example of user tracking down a bug for this platform: [Can't build Julia v1.6.0-beta1 for Arm32bit · Issue #39293 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/39293)

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [March 30, 2021, 11:22am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/55 "2021-03-30T11:22:15Z")

</div>

That closed issue ends with “now builds and passes my initial tests”, so Julia 1.6 (and 1.7) does build?

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [March 30, 2021, 11:31am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/56 "2021-03-30T11:31:17Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![sairus7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sairus7/32/10816_2.png) [@sairus7](https://discourse.julialang.org/u/sairus7)\
**Post date:** [March 30, 2021, 11:46am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/57 "2021-03-30T11:46:34Z")

</div>

There are unofficial builds for armv71:

> [@Have a try Julia v1.5.1 for arm32bit](https://discourse.julialang.org/t/have-a-try-julia-v1-5-1-for-arm32bit/45558/11):
>
> If you try it for RPI Zero, you need install dependencies via apt-get install… sudo apt-get update && \ sudo apt-get install -y build-essential libatomic1 python gfortran perl wget m4 cmake pkg-config \ libopenblas-dev \ liblapack-dev \ libgmp3-dev \ libmpfr-dev See [https://github.com/Julia-Embedded/jlcross#raspberry-pi-zero](https://github.com/Julia-Embedded/jlcross#raspberry-pi-zero) and [https://github.com/Julia-Embedded/jlcross/blob/master/rpizero/Dockerfile-v1.5.3#L27-L31](https://github.com/Julia-Embedded/jlcross/blob/master/rpizero/Dockerfile-v1.5.3#L27-L31) If you set USE\_xxx\_=0 and building procedure is passed,…

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 2, 2021, 12:34pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/58 "2021-04-02T12:34:47Z")

</div>

> [@asprionj](#):
>
> In getting from a dynamic to a static variant of some code, Julia can help a lot

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.

> [@asprionj](#):
>
> Now that sounds quite pessimistic… why so?

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.

---

<div class="post-metadata">

**Author:** ![jmkuhn](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jmkuhn/32/2090_2.png) [@jmkuhn](https://discourse.julialang.org/u/jmkuhn)\
**Post date:** [April 5, 2021, 9:17pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/59 "2021-04-05T21:17:12Z")

</div>

Julia v1.5.4 does compile from source. I expect v1.6.1 to compile with the backport of [https://github.com/JuliaLang/julia/pull/40176](https://github.com/JuliaLang/julia/pull/40176) already merged. Issue [armv7l - No loaded BLAS libraries were built with LP64 support · Issue #40199 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/40199) prevents building current master. I will continue to test and report issues.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [April 5, 2021, 9:51pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/60 "2021-04-05T21:51:06Z")

</div>

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.

[Previous page](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979.md?page=2)

[Next page](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979.md?page=4)