# 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:** 2

<div class="post-metadata">

**Author:** ![maleadt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maleadt/32/10097_2.png) [@maleadt](https://discourse.julialang.org/u/maleadt)\
**Post date:** [February 5, 2019, 7:15pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/21 "2019-02-05T19:15:52Z")

</div>

> [@tshort](#):
>
> That approach works well for type-stable code that doesn’t allocate and doesn’t call out to any C code.

I’ve been making some progress there too, eg. there’s now a compiled run-time library as a counterpart to some of the C functions: [https://github.com/JuliaGPU/CUDAnative.jl/blob/95fbf9356eaa6c3da3c3321ff35c3ffa5d41f77a/src/device/runtime\_intrinsics.jl](https://github.com/JuliaGPU/CUDAnative.jl/blob/95fbf9356eaa6c3da3c3321ff35c3ffa5d41f77a/src/device/runtime_intrinsics.jl)  
Currently supports boxing, allocations, and some exception handling. More to come, if and as soon as I have time to work on that.

> [@asprionj](#):
>
> And what approach would that be? Do they explain it somewhere? (In a form understandable by non-experts in Julia and LLVM…)

Basically, reconfiguring the existing compiler to emit GPU-compatible LLVM IR (mainly through regular dispatch, but Cassette would be great for this once it generates some better code) in combination with a custom back-end and run-time to compile and handle that IR.

Wrt. the lack of documentation on the CUDAnative internals, I’m considering creating a package that isolates and demonstrates the approach and submit that for a talk on the next JuliaCon.

---

<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:** [February 6, 2019, 4:50pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/22 "2019-02-06T16:50:03Z")

</div>

Having an isolated package for customised generation of LLVM IR would we great! What do you mean by:

> [@maleadt](#):
>
> Cassette would be great for this once it generates some better code

BTW, I guess that LLVM IR which is GPU-compatible can also be compiled for most embedded architectures…? Or do you add stuff to the IR which can _only_ be handled by GPU’s?

---

<div class="post-metadata">

**Author:** ![tshort](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tshort/32/43_2.png) [@tshort](https://discourse.julialang.org/u/tshort)\
**Post date:** [February 7, 2019, 1:38am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/23 "2019-02-07T01:38:30Z")

</div>

> [@asprionj](#):
>
> Having an isolated package for customised generation of LLVM IR would we great! What do you mean by:
> 
> > [@maleadt](#):
> >
> > Cassette would be great for this once it generates some better code

Currently, some code processed by Cassette results in extra stuff that doesn’t compile well to fast code. It’s getting closer, though: see [here](https://github.com/JuliaGPU/CUDAnative.jl/pull/334).

---

<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:** [May 31, 2019, 8:46am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/24 "2019-05-31T08:46:48Z")

</div>

Can’t we install Julia on a Linux distribution (e.g. Linaro) on ARM processor, and then run the code?  
That’s how a lot of embedded programming is done. This is the straightforward way.

The other way is to use an approach similar to MATLAB embedded coder does and converts code to C/C++, which is essentially similar to this:

> **[GitHub - JuliaHubOSS/llvm-cbe: resurrected LLVM "C Backend", with improvements](https://github.com/JuliaHubOSS/llvm-cbe)**
>
> resurrected LLVM "C Backend", with improvements. Contribute to JuliaHubOSS/llvm-cbe development by creating an account on GitHub.

---

<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:** [May 31, 2019, 8:59am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/25 "2019-05-31T08:59:34Z")

</div>

> [@Amin\_Yahyaabadi](#):
>
> Can’t we install Julia on a Linux distribution (e.g. Linaro) on ARM processor, and then run the code?  
> That’s how a lot of embedded programming is done. This is the straightforward way.

It’s nice when you can do that, but I think (some of the) discussion in this topic is about hardware which is not powerful enough for this solution.

---

<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:** [May 31, 2019, 10:19pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/26 "2019-05-31T22:19:52Z")

</div>

The straightforward way I already mentioned in my original post:

> [@asprionj](#):
>
> 1. Run Julia on the embedded hardware, AOT-compile all required methods when going in production.

As @Tamas_Papp correctly stated, I also detailed in the OP when this might be an option, and when it’s not:

> [@asprionj](#):
>
> If there’s a lot of flash and RAM, one could just use option 5. I guess that’s already possible today. However, on embedded devices, the entire OS (Yocto, Buildroot, Alpine, …) is usually stripped down to 2-4 MB, so one does not want to have some 100 MB software on it.

And, of course, if there even isn’t any Linux OS around, this route is not option. What’s the status, activity, roadmap of llvm-cbe? Could this be a viable option for bringing Julia to embedded devices?

I feel like this could be a an expedient way to go:

> [@maleadt](#):
>
> Basically, reconfiguring the existing compiler to emit GPU-compatible LLVM IR (mainly through regular dispatch, but Cassette would be great for this once it generates some better code) in combination with a custom back-end and run-time to compile and handle that IR.
> 
> Wrt. the lack of documentation on the CUDAnative internals, I’m considering creating a package that isolates and demonstrates the approach and submit that for a talk on the next JuliaCon.

Just replace GPU by anything else;

> reconfiguring the existing compiler to emit _[ANYTARGET]_-compatible LLVM IR

which should become easier by said clean, isolated “demo package”. @maleadt, do you plan to keep non-GPU-specific parts of this package separated to allow others to reuse them to reconfigure the compiler for their specific targets?

---

<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:** [August 23, 2019, 3:30am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/27 "2019-08-23T03:30:17Z")

</div>

I am not sure if you have noticed that the latest Julia 1.2 has Linux Binaries for 32bit ARM.

I was interested to try to build and try some simple programs using Julia, and make some examples for others to use as templates (I haven’t seen any really).  
I have an ARM Cortex A9 with Linux installed on it, and also an ARM Cortex M3 with FreeRTOS (installing Linux is also possible).

I want to experiment with

- building executable
- making lib/dll libraries.
- Also as you know, a lot of the drivers and libraries are written in C, so we also can try embedding Julia in an already written C code (like writing the main computational function in Julia).
- building on desktop (Windows, etc) for ARM.

I was wondering if anyone is interested to make a repository and try some examples for embedded programming. _Let me know if you want to be involved._

---

<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:** [August 23, 2019, 10:55am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/28 "2019-08-23T10:55:22Z")

</div>

I’m working on something that could help target embedded hardware (while not the main goal). While I could support all CPUs, is it a limitation to only support all 32-bit ones?

---

<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:** [August 23, 2019, 7:30pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/29 "2019-08-23T19:30:14Z")

</div>

No that’s not a limitation. But for embedded programming, most of the processors are 32 bit.

- all of the ARM Cortex-M processors ([ARM Cortex-M - Wikipedia](https://en.wikipedia.org/wiki/ARM_Cortex-M)) which are highly used in many embedded applications are 32 bit.
- a lot of ARM Cortex-A processors are 32 bit ([ARM Cortex-A - Wikipedia](https://en.wikipedia.org/wiki/ARM_Cortex-A)).
- all of the ARM Cortex-R processors ([ARM Cortex-R - Wikipedia](https://en.wikipedia.org/wiki/ARM_Cortex-R)) for mission-critical applications are 32 bit.

---

<div class="post-metadata">

**Author:** ![tshort](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tshort/32/43_2.png) [@tshort](https://discourse.julialang.org/u/tshort)\
**Post date:** [August 23, 2019, 7:41pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/30 "2019-08-23T19:41:24Z")

</div>

I’m interested in anything involving standalone compilation and cross compilation. My main immediate interest is WebAssembly (that’s a cross-compiled 32-bit platform, so there are lots of similarities).

---

<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:** [August 24, 2019, 2:27am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/31 "2019-08-24T02:27:32Z")

</div>

I created an organization for this purpose. Feel free to contact me so I give you access.

I have also created a master repository writing the goals and motivation.

> **[GitHub - Julia-Embedded/Julia-Embedded-Master: An organization for bringing...](https://github.com/Julia-Embedded/Julia-Embedded-Master)**
>
> An organization for bringing Julia to embedded processors - GitHub - Julia-Embedded/Julia-Embedded-Master: An organization for bringing Julia to embedded processors

First I think we should start with blinking LED 😃  
[https://github.com/Julia-Embedded/Blinking-LED](https://github.com/Julia-Embedded/Blinking-LED)

For that we need to write a function similar to [Arduino pinmode()](https://www.arduino.cc/reference/en/language/functions/digital-io/pinmode/) which we can define pins as input or output (GPIO).

---

<div class="post-metadata">

**Author:** ![imcinerney](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/imcinerney/32/9882_2.png) [@imcinerney](https://discourse.julialang.org/u/imcinerney)\
**Post date:** [August 24, 2019, 11:10pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/32 "2019-08-24T23:10:04Z")

</div>

I had actually already created a Julia embedded GitHub group a while ago here: [https://github.com/juliaembedded](https://github.com/juliaembedded). I was starting with just simulating embedded arithmetic, and was going to be building up a type system to model fixed-point and arbitrary floating-point arithmetic with rounding mode selection (including stochastic rounding). The goal is to allow an algorithm written in Julia to be simulated using the reduced precision that would be in embedded devices so designers could see the effect on performance.

The next project was going to be building an embedded compiler for Julia, that will take a Julia function and transform it to runtime-independent code that can be fed into the LLVM backend for the desired target (then the LLVM to C backend could be used to generate direct C code if desired). My main goal was to create static libraries that would contain the compiled Julia functions, and then those could be linked into existing C applications.

That does have its difficulties though, since you have to extract the memory allocations from the compiler, and ensure that they are either done with the provided embedded functions or all allocatons become static (which is actually the preferred way of handling memory in critical embedded systems). I haven’t had a chance to dig around in the generated code yet, but I think this should be doable in a similar way to how the GPU group accomplished this.

---

<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:** [August 25, 2019, 12:26am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/33 "2019-08-25T00:26:40Z")

</div>

This is awesome. We have the same goals! We should merge and work together. I sent you a PM regarding merging our groups.

I found this Rust embedded book. Rust is also uses LLVM, and so it is useful to inspire from it.  
[https://rust-embedded.github.io/book/](https://rust-embedded.github.io/book/)

---

<div class="post-metadata">

**Author:** ![klaff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/klaff/32/7637_2.png) [@klaff](https://discourse.julialang.org/u/klaff)\
**Post date:** [August 25, 2019, 9:10pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/34 "2019-08-25T21:10:22Z")

</div>

Are you aware of Juliaberry (Julia on Raspberry Pi)?

I played with it a little bit. I could get very fast gpio bit banging speed (about 100 ns per ccall to libpigpio, so it could generate a 5 MHz clock!) but with occasional interruptions by the OS I presume.

I was thinking of doing some embedded systems prototyping in which some control algorithm would be tested and results quickly plotted without having to move data to some other system, but I had trouble with compilation times being really excessive or not finishing at all because of insufficient memory.

I’m not actively messing with it now. If I tried again I would probably divide the problem - let the raspberry pi do the pseudo-real-time stuff in Julia, and let it serve data over Ethernet to a PC doing plotting and analysis, also in Julia.

---

<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:** [August 25, 2019, 9:47pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/35 "2019-08-25T21:47:10Z")

</div>

> [@imcinerney](#):
>
> The next project was going to be building an embedded compiler for Julia, that will take a Julia function and transform it to runtime-independent code that can be fed into the LLVM backend for the desired target (then the LLVM to C backend could be used to generate direct C code if desired). My main goal was to create static libraries that would contain the compiled Julia functions, and then those could be linked into existing C applications.

By _runtime-independent_ you mean architecture-independent? So removing all arch-specific stuff from the representation? This is exactly the idea behind the approach summarised in [this post](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/26). Just with the difference that there, the idea was to target some specific platform(s), instead of fully platform-agnostic code (which could then not utilise any of the platform’s features such as SIMD (?).

BTW, like the logo ([JuliaEmbedded · GitHub](https://github.com/juliaembedded)) and the idea of validating fixed-point versions of Julia code/functions.

---

<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:** [August 25, 2019, 10:57pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/36 "2019-08-25T22:57:11Z")

</div>

> [@Bring Julia code to embedded hardware (ARM)](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/34):
>
> Are you aware of Juliaberry (Julia on Raspberry Pi)? I played with it a little bit. I could get very fast gpio bit banging speed (about 100 ns per ccall to libpigpio, so it could generate a 5 MHz clock!) but with occasional interruptions by the OS I presume. I was thinking of doing some embedded systems prototyping in which some control algorithm would be tested and results quickly plotted without having to move data to some other system, but I had trouble with compilation times being really e…

That is definitely useful. I think the goal should be to do the simulations and build the program on desktop and only run it on the target processor. A lot of processors don’t have enough space, Ram, etc for running Julia and its compiler.

---

<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:** [August 26, 2019, 6:24am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/37 "2019-08-26T06:24:39Z")

</div>

For using drivers for ARM in Julia, I think we can start by writing Julia wrappers for [ARM CMSIS Driver](https://arm-software.github.io/CMSIS_5/Driver/html/index.html) which is part of [ARM CMSIS](https://developer.arm.com/tools-and-software/embedded/cmsis), and is supported by [many hardware](https://developer.arm.com/tools-and-software/embedded/cmsis/cmsis-packs).

It has API for many peripherals as stated in the documentation:

> The CMSIS-Driver specification is a software API that describes peripheral driver interfaces for middleware stacks and user applications. The CMSIS-Driver API is designed to be generic and independent of a specific RTOS making it reusable across a wide range of supported microcontroller devices.

> The following CMSIS-Driver API groups are defined:
> 
> - [CAN](https://arm-software.github.io/CMSIS_5/Driver/html/group __can__ interface__gr.html): Interface to CAN bus peripheral.
> - [Ethernet](https://arm-software.github.io/CMSIS_5/Driver/html/group __eth__ interface__gr.html): Interface to Ethernet MAC and PHY peripheral.
> - [I2C](https://arm-software.github.io/CMSIS_5/Driver/html/group __i2c__ interface__gr.html): Multi-master Serial Single-Ended Bus interface driver.
> - [MCI](https://arm-software.github.io/CMSIS_5/Driver/html/group __mci__ interface__gr.html): Memory Card Interface for SD/MMC memory.
> - [NAND](https://arm-software.github.io/CMSIS_5/Driver/html/group __nand__ interface__gr.html): NAND Flash Memory interface driver.
> - [Flash](https://arm-software.github.io/CMSIS_5/Driver/html/group __flash__ interface__gr.html): Flash Memory interface driver.
> - [SAI](https://arm-software.github.io/CMSIS_5/Driver/html/group __sai__ interface__gr.html): Serial audio interface driver (I2s, PCM, AC’97, TDM, MSB/LSB Justified).
> - [SPI](https://arm-software.github.io/CMSIS_5/Driver/html/group __spi__ interface__gr.html): Serial Peripheral Interface Bus driver.
> - [Storage](https://arm-software.github.io/CMSIS_5/Driver/html/group __storage__ interface__gr.html): Storage device interface driver.
> - [USART](https://arm-software.github.io/CMSIS_5/Driver/html/group __usart__ interface__gr.html): Universal Synchronous and Asynchronous Receiver/Transmitter interface driver.
> - [USB](https://arm-software.github.io/CMSIS_5/Driver/html/group __usb__ interface__gr.html): Interface driver for USB Host and USB Device communication.
> - [WiFi](https://arm-software.github.io/CMSIS_5/Driver/html/group __wifi__ interface__gr.html): Interface driver for wireless communication.

With a quick search that I did it is also possible to use it under Linux.

---

<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:** [May 13, 2020, 6:26pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/38 "2020-05-13T18:26:45Z")

</div>

Hello. I’m new to Julia, but not new to the embedded world. I have worked with many AVR and ARM devices, most of which are too small to run Linux, as most of them had limited RAM and no memory management.

I’m just wondering whether this discussion is still going on, since it appeared to halt in 2019. Are there any new developments from any of the folks who have mentioned potential directions for getting Julia onto small embedded platforms?

---

<div class="post-metadata">

**Author:** ![anon67531922](https://avatars.discourse-cdn.com/v4/letter/a/48db29/32.png) [@anon67531922](https://discourse.julialang.org/u/anon67531922)\
**Post date:** [May 15, 2020, 7:22am UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/39 "2020-05-15T07:22:36Z")

</div>

I have no idea about this subject, but it came up in the recent AMA. Maybe this helps answer your question:

[![](https://global.discourse-cdn.com/julialang/original/3X/8/f/8f4c9c52aec99b2306fc6bfcddc768cd8423b1c7.jpeg "Ask us anything: Jeff Bezanson and Stefan Karpinski") ](https://www.youtube.com/watch?v=vfxS6_Sx1Pk&t=4421)

(Link points to the spot where ARM is discussed briefly.)

---

<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, 2:20pm UTC](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979/40 "2020-07-25T14:20:14Z")

</div>

Second the request for more info. Also, I didn’t notice in the discussion talk of verification and validation. Do we need to now target a specific standard. Would you trust Julia to fly a plane or drive a car? Would it need to go into C so it could be checked by some of the verification tools? Where does this discussion live?

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

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