Linux Industrial I/O Crate

[fpagliughi]

Sorry, didn't know if this is the right place to ask this, but...

Has anyone been working on a Rust crate for accessing the Linux Industrial I/O subsystem (A/D's, D/A's, accelerometers, etc)?

If not, would there be any interest in one? I've been playing around with a Rust wrapper for libiio and getting basic functionality working would be pretty easy, but I'd likely advice and/or need help with library integration, API decisions, testing.
@posborne would you be up for helping?

[RandomInsano]

Good question! The embedded working group is interested in getting lower-level to the hardware than a C library provides. I live more in your world and there is an abstraction for us that pretends Linux is a micro-controller.

Likely the same folks frequent here so it's not a bad place to ask per sey, but I think a crate would not live within the WG's goal here. Now, if you wanted to create a crate separate from the project, propose an interface we could follow for A/D, D/A and other lower-level interfaces and then add that to linux-embedded-hal, I think that'd be swell. Lots and lots of work, but swell.

[posborne]

If not, would there be any interest in one? I've been playing around with a Rust wrapper for libiio and getting basic functionality working would be pretty easy, but I'd likely advice and/or need help with library integration, API decisions, testing.

Hi @fpagliughi, I think this type of support could very well fall under the umbrella of what the linux team might be willing to help maintain moving forward but probably not something we would pull in right away. I am familiar with the iio subsystem at a high level although haven't had opportunity to use it in practice for anything significant as of yet (the subsystem is fairly young as far as kernel stuff goes).

If it is something you need, I would encourage you to start working on crate(s) that safely capture the semantics of these kernel APIs and expose them to rust. As noted by @RandomInsano, looking at these APIs and proposing higher-level HAL traits may be worthwhile as well.

At some level, the iio subsystem and embedded-hal traits that exist conflict. The IIO subsystem in the kernel provides a framework for adding in-kernel support for sensors (accel, adc, gyro, light, potentiometer, etc.) connected via lower-level interfaces like SPI/I2C/etc. that form the lower-level traits for the HAL. To use the IIO kernel code we would want to be matching higher level abstractions. This is something we would probably want to work towards over time.

Quite awhile back some very rough cuts for what some of these types of traits is something I had snuck into the i2cdev crate to aid with examples but which was subsequently removed as it wasn't really the right place or the right time to get this right. E.g. https://github.com/rust-embedded/rust-i2cdev/pull/40/files#diff-e2b5f29521236a7c8a2e4092e0b6369dL27

[fpagliughi]

I was just thinking of something in line with some of the other existing Embedded Linux crates - a library that would allow a Linux application interact with IIO devices from user space - essentially a Rust version of "libiio" (or, simply a wrapper around it as a first pass).

The embedded HAL stuff looks really ambitious and intriguing, but it's well beyond what I would need for +90% of my embedded systems projects.

So, for now, I'll get started on the library and put it on my personal GitHub page, and beg for help as need be. Thanks.

[RandomInsano]

I’m well curious how your project goes so reply back here with a link when it’s been started!

I’m also curious how specialized it’ll be, so it may be a good thought exercise to see how your crate could map to the hardware abstraction layer.

[fpagliughi]

OK. It has started:
https://github.com/fpagliughi/rust-industrial-io

It may be a week before there's something that's actually usable and tested, but the initial structure is coming together.