Julia for microcontrollers (like Micropython)

Dear Julia community members,

I wish to develop a fork of Julia that can run on low memory low ram microcontrollers .

Similar to Micropython (python for microcontrollers)

Micropython website

I’m working on low cost wifi module ESP8266 with micropython.

I’m working on developing RTOS for Internet of things.

Kindly shed some light on my path to reach my goal…


Welcome! I’m not sure how to help you, but I suspect you will have better luck with others if you follow some of these suggestions with your question.

The project you describe sounds like a big one, and when you just ask “what path should I take?” I’m guessing it’s a bit too vague, and very few people will have any sense of how to help you. Maybe tell us what you’ve done already, and what problems you’ve encountered that you need help solving.


This is a great idea! I’ve been hoping one of the chip manufacturers would pick up on how great Julia is and integrate it themselves. I saw that the university of Malta is working on an LLVM for the 16 bit MSP430, so you might get some information there.
This does sound like a monumental task, and I can’t wait to see you succeed!

In theory something like Micropython could be replicated for Julia, (while it would be even more work for e.g. that MCU; I wasn’t even sure MicroPython supported any non-ARM ones). ARM (or x86) MCU would be the best bet.

Since you can call Python with PyCall.jl, or should I say, call Julia from Pyhon using PyJulia package (that’s based on PyCall.jl), it might be helpful to look into if PyJulia would work with MicroPython. It likely doesn’t because MicroPython is baremetal non-standard variant. Julia however requires an OS (currently at least) and a filesystem. I’m not sure you have any filesystem [access] with MicroPython. MicroPython also has changed garbage collection from regular Python. That it supports real-time use is interesting (and I recall based on fixed amount of memory and knowing the exact hardware/size). Getting the same GC guarantees with Julia should be possible, but I wouldn’t rely on it happening just by change.

Julia would not work directly on ESP8266 given that it uses “L106 32-bit RISC microprocessor core based on the Tensilica Xtensa”; and neither for any 16-bit despite it working on an LLVM:

E.g. even with 8/16-bit AVR having LLVM support (and working with Rust language, or getting there), that CPU, or any non-32-bit (or 64-bit), such as MSP430, will not work with Julia (see my thread in it; ans answers on how difficult and unlikely adding 26-bit support is; long term I see 8- and 16-bit CPUs as dead anyway, and would concentrate on ARM).

Only possibly workaround might be Julia2C (see other microcontroller thread where I wrote about that).


Just FYI, Espressif released a work in progress LLVM version for Xtensa last week. I don’t think it is ready for prime time quite yet, but the ESP32 is a 32-bit architecture, and while this development was likely aimed at Rust, seems as though Julia could piggy-back as well some day?


1 Like

This still runs into the problem of requiring a Julia runtime + large shared libraries to get a fully-functional system, but at least with a working LLVM backend we could do something like CUDAnative and launch “kernels” on the ESP32 as an accelerator of sorts. I’d be open to contributing to something like that once my free time becomes less finite :smile:


Forgive my ignorance, but what I personally would favor is a sort of Julia API for programming microcontrollers such as the ESP32, etc. I wouldn’t care so much if it’s actually C running the chip as long as I don’t need to learn C and just use Julia.

I feel like it would be much less work to write a Julia API/wrapper for microcontroller programming than it would be to write a “microJulia” that runs on MCUs. But again I point you to my ignorance here.


ESP32/Xtensa is not supported by Julia language, and likely never will. It’s not theoretically impossible however, it seems: GitHub - espressif/llvm-project: Fork of LLVM with Xtensa specific patches. To be upstreamed.

You can of course interface with any microcontroller somehow with Julia, but the best bet to get Julia code running on one would be on ARM and nothing else really viable. Long-term I don’t even see the point of any non-ARM for any embedded system, Julia or not. Is ESP32 better or cheaper for anything?

The ESP32 is fast, it is cheap and provides WiFi and Bluetooth out of the box but the analog inputs are terrible. I have been using it frequently.

The new Pi Pico doesn’t run Linux, but possibly Julia could be made to work on that Unix/microcontroller (or similar):

“Dual-core Arm Cortex-M0+ @ 133MHz” is not a lot, and 264KB RAM certainly limiting, and (at least currently):

The Fuzix port only uses one of the Pico’s cores


Again, I would suggest a Julia API to write and compile Lua or C++ or Assembly code to program any particular MCU, not try to have the MCU run Julia. This is given my all too many hobbies and the likelihood of picking up a lower-level language is slim despite the desire. So it would be nice to just learn an API in a language I already know and use (i.e. Julia) to do more exciting things (i.e. program MCUs).

Maybe not the best solution, but I can’t be the only one that doesn’t know C/C++ but would enjoy programming MCUs.

1 Like

What’s the path of least resistance, though? Learning C++ or MicroPython, or getting Julia to work on a very tiny microcontroller?

1 Like

It probably depends on your background. If you know Julia, Python is similar and shouldn’t take too long to pick up. MicroPython is mostly just Python minus a few less-used features.

C++ is less daunting than its reputation. Julia is likely not practical on ESP32, etc., until the ability to compile a sysimage with only what is needed.

What do you mean with tiny? As in size of RAM (or physical size?), then not even MicroPython or C will work. Julia works on something like Raspberry Pi.

Julia is not the least-resistence path to (tiny) microcontrollers, will probably take some more years to get to work. I really like the idea of Julia working on them, but MicroPython is now a good choice and e.g. C is for most microcontrollers. For some very low-RAM, you need Forth or assembly, and nothing else will work.

The smallest computer (i.e. a “microcontroller”), in the world is ARM-based (has no pins), and I do not see Julia exclusive to more mainstream small microcontrollers (assuming for now they are ARM-based):

Totally depends on what you want to do. Communicating with the microcontroller from Julia + using Arduino IDE works wonders: I don’t want all the logic to reside on the microcontroller, so I know enough C++ to get it to do simple things, and the rest I program on Julia and it runs on a laptop that communicates with the microcontroller. But that might not be possible in your case if you want it to be autonomous…


The controllers @znmeb seems to be interested in is the category that supports MicroPython and C but not a whole Julia installation. MicroPython Products Category on Adafruit Industries

A previous thread on this topic.

I really like the idea from that thread of using GPUCompiler to emit small “kernels” that run on the microcontroller. It is still a lot of work, but it sure seems better than limiting to microconctrollers that can fit the whole runtime.

I am currently working on a microcontroller kernel compiler Julia package, but only in my spare time unfortunately…

1 Like

Forth would work for my use case - the microcontroller is an STM32 and the application is audio. There are several hardware options, among them Raspberry Pi Pico, Teensy and Electro-Smith Daisy. They all have different versions of the STM32 and different flash and RAM sizes. And they all have C/C++ audio / DSP libraries.

A host (most likely a BeagleBone Black or an NVIDIA Jetson) plus microcontroller is also a viable option. Julia will definitely run on both of them and the Jetson GPU works with Julia’s CUDA library. I haven’t tested Julia on the BeagleBone Black yet but I don’t see why it wouldn’t work; it’s got Linux running on it.