# 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:** 1\
**Showing post:** 44

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

---

_[View the full topic](https://discourse.julialang.org/t/bring-julia-code-to-embedded-hardware-arm/19979)._