@anon92994695 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!
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.
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)!
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.
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.
My previous workplace use Julia in the student labs, to communicate with lab processes LabProcesses.jl
There’s also some connection-related stuff for beaglebone etc. LabConnections.jl
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’: Roadmap/README.md at master · JuliaMakers/Roadmap · GitHub
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?
I’ve created a wrapper for the hidapi library: GitHub - laborg/HidApi.jl: High level wrapper for hidapi
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.
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
c=read(p,1)[1]
push!(buf,c)
if c==cs
return join(buf)
end
end
end
end
"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]
end
p = SerialPort("COM16", 115200)
pyb(p,"myled = pyb.LED(1)\r")
function blink(p)
while true
pyb(p,"myled.on()\r")
pyb(p,"myled.off()\r")
end
end
blink(p)
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.
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.
