As promised in the last blog post, I spent some time developing a derive macro that allows deriving how new types will be written to and read from an instrument. This blog post is about these changes, how they work, and how they still need to be improved.
It has been a few weeks since my last post. Since then I have focused on the async interface, a note on this at the end of this blog post, and on integrating a new instrument using instrumentRs v0.2.0. Here are my findings on writing a more complex driver.
In the last blogpost
we discussed design ideas for instrumentRs v0.2.0.
Here, I will mainly focus on
the mock interface for testing instruments drivers
developed using instrumenRs v0.2.0.
If you haven't already done so,
it is highly recommended that you read the last blogpost first
for context.
Over the years I have written many drivers to control scientific equipment. These were mostly in python using the wonderful instrumentkit. As my tech stack has mostly moved to Rust however, I have missed a consistent, simple-to-use way to write instrument drivers.
This post discusses a very rough idea on how such an improved driver kit might look like in Rust. In addition to inspiration from instrumentkit, a lot of inspiration is also taken from the fantastic device-driver tool.
The python ecosystem has changed a lot over the last year, especially with respect to tooling. The usage of Rust has opened new, very fast, and by now very popular tools that aid in linting (ruff) and package management (uv, rye). But what tools are there if you want to share your python applications with colleagues that do not use python?