Comments (4)
I've been testing giocdev the last few days and am really impressed with what @warthog618 has done, especially with him claiming to be a Rust newcomer when he started the project!
And though I hate throwing away good work (including my own), I'm leaning toward moving my own apps to gpiocdev.
I also found some additional Pro's:
- Supports async/await for all the major executors via tokio and async-io
- The API is close to libgpiod, and makes it more convenient to switch between Rust and C/C++ project (which I am forced to do by some customers)
- The author seems extremely responsive and committed to the project.
- Now I won't need to do a lot of free work to get v2 and async-io implemented :-)
from linux-embedded-hal.
If you have any doubts I was a Rust newbie you can always look at some of the earlier commits - they are sure to be pretty ugly.
The API probably feels like the C and C++ libgpiod v2 APIs as I had a hand in those as well (Bart did the work, I did some reviewing and updated the tools), so I probably pushed him in the direction of the Go API I wrote while developing the GPIO uAPI v2 itself (I needed something to drive it from userspace, didn't know Rust then, and updating libgpiod was way too much work - which is one of the reasons libgpiod v2 only just released. So Go did the job at the time.) Though the constraints of writing an extensible and backwardly compatible library interface in those languages adds a whole load of ugliness (maybe not warts, but definitely plenty of pimpls), so my apologies to anyone that has to use them. My Rust API followed the Go, more or less, though as Rust understands ownership the resulting API is clearer, IMHO.
On a related note, Linaro thought it was better to write a Rust binding for libgpiod v2 than go Rust native, so libgpiod v2 has a Rust binding included as well (I did some reviewing on that too). That makes little sense to me, as that binding has to deal with the aforementioned C library ugliness, and you gain a dependency on libgpiod itself, when it could just go direct to the ioctls, as gpiocdev does.
Anyway, enough history. Let me know if you find any issues with gpiocdev or need additional features, and I'll see what I can do. Same goes for the uAPI itself.
from linux-embedded-hal.
nice work @warthog618! and thank you @fpagliughi for digging into this ^_^
i'm oki with the idea of a swap (and async will be really nice to have!), if we really wanted to we could plug in both backends for the moment and feature gate a swap in case anyone is very attached to the prior version, but, e-h 1.x.y-alpha is still an adventure in breaking changes so it's probably not necessary.
perhaps it's worth a PR here to see how it looks? and if we are adopting this it would be good to add the e-h team to the repo as maintainers with a goal of one day adopting it here if you're open to this @warthog618? (or equally, moving it here and adopting @warthog618 :-P)
from linux-embedded-hal.
Not something I had considered and, not having much familiarity with rust-embedded team, not something I'm open to at the moment.
I'm not ruling it out, but I don't see it as a move that needs to be made urgently, so give it time.
Worst case if I get hit by a bus you can fork.
from linux-embedded-hal.
Related Issues (20)
- Add embedded-io implementation
- v0.4.0-alpha.4 release HOT 1
- Async-tokio DelayNs implementation inaccurate for delays shorter than a few ms
- impl embedded_hal::digital::Error for linux_embedded_hal::gpio_cdev::Error HOT 2
- v0.4.0 is missing embedded_hal_0_2::blocking::i2c traits?
- Async `SpiDevice`?
- Is this as simple as using `gpiozerio-rust` crate?
- Unable to get gpio-cdev feature working on v0.3.0 HOT 3
- Update dependencies to use nix >= 0.23 due to vulnerability HOT 3
- CAN trait implementation HOT 8
- Improvement of error matching necessary
- Update for [email protected]
- Enable i2c as a feature? HOT 6
- I2C transaction breaks I2c trait contract HOT 4
- serial-unix crate is unmaintained HOT 3
- SPI implementation doesn't follow embedded-hal requirements for CS HOT 10
- Pin set_direction errors right after export HOT 6
- SPI implementation panics if read and write buffers in a transfer are not the same length HOT 1
- SPI struct implements both SpiBus and SpiDevice HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from linux-embedded-hal.