New Domain - what are people using Julia for in Hardware?

@ckneale has driven a new domain for Discourse covering all things hardware… the Maker domain. Thanks!!

With one of my hats, I am a hardware guy very new to Julia, and I am curious what people are using Julia for. For myself, I’m currently using Julia to improve the integrated circuit layout flows and verification processes at the small company I work for. I have historically done the bulk of these in Python, with Haskell used for the more computationally-intensive bits. I generally favor development speed first and ability to bring others in my group up to speed on the resulting tools second. Fine for Python, bad for Haskell (on the second). Julia seems to hold the promise of unifying the two areas.

Things I have done hardware-wise in the past and can see using Julia for in the future:

  • Domain-specific simulators (previously Haskell)
  • Bench automation software (previously Python)
  • IC subsystem generation (previously Python)
  • Simulator connectivity e.g. connecting LabView to VerilogAMS (previously Python & C)

Other ME/EE/Physics hardware types out there? What are you all using Julia for in your areas? (I have to say, this is one of the most helpful and civilized online crowds I’ve ever run across.) Happy New Year, all!


I mostly use Julia over USB serial in this world. Pretty much exclusively with Arduinos for now.

Nice. Is there already a USB driver in Julia somewhere, or are you wrapping some C? I noticed a VISA package in the PainterQubits group, but I assume that is wrapping NI’s (or someone else’s) VISA driver.

1 Like

I’ll put a blog post out on solving ODEs on eGPUs soon. Does that count?


Tricky question… Tricky tricky… My knee jerk reaction is that it does count. Especially if the discussion focuses on not going over bus lanes or something to do with the architecture. I’m sure someone who knows more about eGPU’s then me is more qualified to answer :). Either way you should write a blog on that - we could figure out where it belongs later(probably belongs in two locations anyways because its super cool)!

I just use a Julia library( so I cheaped out :). But it still has some considerations related to Julia and hardware! I’m planning a blog/miniproject to demo something a little simple at first (sharing, all code, CAD models, etc).

Then as time goes on posting some more “advanced” projects :). Most of these I’ve already done, just very haggardly, and not using Julia (which would have had advantages to say the least). A lot of makers just lack the ability to easily process their data. IE: writing 500 lines of java/C/C++, $$$ for software, or 10 lines of easy to read fast julia. It’s a match made in heaven for someone hacking away.

A fun project could be hooking up a USB software defined radio to Makie and looking at some radio waves or something! Oooh I have like 6,000 project ideas… If anyone wants some let me know.

1 Like

I’ve been experimenting with bench instruments control using the excellent VISA wrapper:

I have a small repo, partly mimicking IVI, where I started writing generic functions for various instruments. The goal is to have portable code and let Julia choose the correct method depending on the instrument that you have available. It’s a lot of manual work, but I think it’s quite easy to extend: just add a new method with the correct SCPI command for your equipment.
I find multiple dispatch a good tool for this job because it lets me use only one layer of abstraction, making it easy to understand the code. Object oriented approaches would need inheritance, more levels and more code to understand.


Sounds cool - I’ll have a look. I admit in our lab we are using PyVisa, and I don’t know if we’ll be switching from that anytime soon but perhaps this will give us a reason. :slight_smile:


Awesome work here! Not sure how I didn’t see this package!

My previous workplace use Julia in the student labs, to communicate with lab processes
There’s also some connection-related stuff for beaglebone etc.


Thanks! Again most awesome stuff here. Hey haven’t seen a beaglebone project for a while now!

I’m adding anything people post here to the following ‘roadmap’:
If anyone wants to have their project removed from the readme please let me know. I’m just using it as a map of what is pre-existing. Don’t worry I’m not going to be spamming anyone asking if they want their work contributed to a github Organization(atleast yet). I think I am going to do something different anyways, and just curate a list of useful things, and try to map utilities to projects. So no one has to do anything different and can be autonomous :).


Instruments.jl is so simple and yet so powerful. I don’t know why it was removed from the official registry. I talked to one of the developers and he said they aren’t actively developing it. From my point of view it’s very good as it is and it should be added again. However I don’t know the procedure. Is it a request that the only the developers can submit?


Let me draw some attention to your post! I want this sort of effort back in the registry and back in development!

A while back, we removed packages from the General registry that didn’t support Julia 1.0.

If you’d like to resurrect the package, the process is straightforward.

Step 1: have the current owner of the repository transfer the repository to a GitHub organization

Step 2: update the package to work on Julia 1.0.

Step 3: register the package


I can accept the package in the newly minted JuliaMakers organization( if there’s no other home for it.

1 Like

I’ve created a wrapper for the hidapi library:
It should be easy to use, as there are no prerequisites. The necessary binaries are provided via BinaryBuilder (had to create hidapi_jll fist, which took me a whole weekend).
After some additional testing I’d like to register it.

Feedback is welcome!


Playing tonight with wiggling gpio pins via a pyboard.

using SerialPorts
import Base.readuntil

CTRLA = '\x01'
CTRLD = '\x04'
# broken LibSerialPort can only send one byte at a time on Windows!
# so we use SerialPorts (which uses pySerial)
# SerialPorts has limited functionality, so we add readuntil

function readuntil(p::SerialPort, cs::Char)
    buf = Array{Char,1}(undef,0)
    while true
        if bytesavailable(p)>0
            if c==cs
                return join(buf)

"execute string s on pyboard attached to SerialPort p"
function pyb(p,s)
    s=replace(s,'\n'=>'\r') # pyboard likes returns not newlines
    write(p,CTRLA)  # enter raw mode
    readuntil(p,'>') # clear serial port / wait for pyboard
    write(p,s) # send string of commands
    write(p,CTRLD) # exit raw mode
    return readuntil(p,'>')[3:end-5]

p = SerialPort("COM16", 115200)
pyb(p,"myled = pyb.LED(1)\r")

function blink(p)
    while true


This manages to wiggle the GPIO pin at about 580 Hz (minimum of about 650 μs per update, average around 900 μs) , although it’s pretty jittery. It’s a very circuitous path from julia to python (SerialPorts wraps pySerial) on Windows through USB to micropython on an Arm M4F to the gpio pin.


There’s also :slight_smile: so no python

1 Like

I tried that one first but on Windows there’s a bug where it will only send one byte at a time, although I’m pulling one byte at a time on the receive side anyway.

It might be much better to write a CLI in micropython so that the pyboard isn’t having to interpret new python code every cycle.I think I’ll build a little dictionary dispatch thing with a few commands.

If it is okay with you, can I add the readuntil method to SerialPorts.jl?