rust-embedded / awesome-embedded-rust Goto Github PK

Hello !
The blue pill support crate redirect to the stm32f103 hal.

I wrote a board support crate, betafpv-f3, for a drone flight controller. Currently, the board support crates section of this repo says Crates tailored for specific development boards..

Is there any interest in listing board crates for more specialized boards like this? I was thinking possibly an Other category could be used to group them separately from the existing boards, but I wanted to discuss it before making a PR.

The AS5048A driver crate appears to be empty? https://github.com/uwearzt/as5048a

Should this list include a section on things like probe-rs, flip-link, cargo-bloat, ... ?

Sipeed offers quite a few interesting very low cost RISC V boards, like the Sipeed Longan Nano.
The cpu - a GD32 - is officially supported by the RISC V Team, in this crate: https://github.com/riscv-rust/gd32vf103xx-hal

Adding Sipeed and a link to that Repo would be nice, so that people don't think there board isn't supported after they looked hear.

Found a few nRF52 related crates that are maybe worth mentioning: https://crates.io/search?q=Nrf52

Even though the new awesome-embedded-rust project just started, it's already getting a bit unwieldy to read and edit so I'd like to split it up in more manageable chunks so for starters I'd like to take the crate heavy sections (i.e. Device crates, HAL implementations, BSP crates and Drivers) and put them each into their own .md file, move the vendor entries from the subsections to where the individual crates are now and make them into direct links to their new location (where available, drivers should also be categorized at some point).

Once that is done I'd like to follow up with enriching the content quite a bit and also to bring back the wish list/idea pool which @japaric started in rust-embedded/wg/issues/39.

Thoughts or comments?

The readme links to the IRC channel still, should it?

This PR went in a bit overly quick and just after a rough review, I left a number of comments and nits which require addressing and possibly additional discussion hence this ticket.

In my research about Rust-RTOSs, I just saw this project here, which might be worth adding to the list:

https://github.com/AntoineSebert/dandelion

Just a suggestion. Let’s make this a arewe_yet website.

It would be a more “pragmatic rust” way of doing this. Generating markdown-based website from the readme won’t be hard and I am willing to do it. Forking another arewe_yet website that already has the ci setup would be good too.

Also the title is like that just for readability. I know snake case is better.

Dead link to https://github.com/japaric/msp430g2553

Sorry if this is the wrong place:
The Cortex-M Quickstart guide Docs.rs build 0.3.4 is failing with the following:
error[E0658]: The attribute 'panic_implementation' is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642) --> .cargo/registry/src/github.com-1ecc6299db9ec823/panic-semihosting-0.3.0/src/lib.rs:71:1 | 71 | #[panic_implementation] | ^^^^^^^^^^^^^^^^^^^^^^^ | = help: add #![feature(custom_attribute)] to the crate attributes to enable

Also, the last built version (0.3.1) references using Nightly, which is no longer required for the Cortex-M.

The list of no-std crates is currently empty!

We have collected a list of such crates in rust-embedded/wg#12 but the list hasn't been
updated in a long time. It now probably contains deprecated crates, crates that are no longer under
active development or crates that never achieved a "complete" (published and documented) state.

Help us review that old list and make a new list with the best parts of the old one. Also, it would
be great if the new list was split in categories to make it easier for readers to find what they are
looking for. The awesome Rust list may provide some inspiration for this
categorization task.

it seems that the IRQ library is archived on github so i don't think it should be in this list anymore.
https://github.com/jonas-schievink/irq

The full list of devices equivalent to the LM75, per the library's README, are:

This driver is also compatible with at least LM75A, LM75B, LM75C, AT30TS75A, DS1775, DS75, DS7505, G751, MAX7500/1/2/3/4, MAX6625, MCP9800/1/2/3, STDS75, TCN75, PCT2075.

It would be awesome if this list was included in this repo for easied Ctrl+F!

Related to #154 we can use markdown linter. There is some existing one out there :

• https://github.com/igorshubovych/markdownlint-cli
• https://github.com/markdownlint/markdownlint

The discovery book is an amazing resource, but it uses very specific hardware.
I want to make a similar book but for the micro:bit (and only needing the micro:bit), as it is a board specifically made for teaching, and I think has wider availability and is cheaper. I have also explicitly tried to use a different structure and style where it made sense, just to see if it would work better.
If you want to take a look at a very early state: https://github.com/droogmic/microrust, obviously contributions are welcome.
I'd appreciate some help with the licensing though, as I don't want to infringe on japaric's copyright.

The awesome-embedded-rust list has grown a lot over the last few years and it might be time to think about how we could reorganise the crates to help make it easier to navigate and find the crate you're looking for.

A few specific ideas we've had in the weekly meetings:

• New section for shared abstractions, which overlaps somewhat with the current "component abstraction crates" but should probably be more obviously highlighted, containing things like embedded-hal, embedded-dma, embedded-nal, embedded-time/fugit, embedded-graphics, ...
• Could compact some entries to reduce the page length, e.g. all HAL implementations for a specific chip on one line
• Sort and group drivers by type of device, e.g. a section for accelerometers, a section for CO2 sensors, etc
• Your idea here!

It would be awesome to see on the awsome list cryptographic libraries from these repos:

1. https://github.com/dalek-cryptography
2. https://github.com/RustCrypto

Some additional details here:
https://rustsec.org/advisories/RUSTSEC-2016-0005.html

Hi, I'm new to this space and this repo was mentioned to possibly find here. Is there support for BeagleBone Black? If so, do you have any samples to possibly get noobs started? Thanks for any info.

Referencing: rust-embedded/cortex-a#43

Now that Rust 2018 is almost upon us, embedded Rust crates can hope to start working on stable Rust. We should update the awesome-embedded-rust list to track which crates do or do not work on stable.

I imagine this being either a badge (but see #32) or a note or a new section.

Hopefully many crate authors will be update their listings themselves, but if not it is also hopefully not too much work to test arbitrary crates to find out. I think ideally our standard for inclusion should be "the project's public CI indicates it builds on stable".

Time and again questions of "but is it production ready yet?" come up (latest).

Would it be within scope to gather links to commercial projects that publicly state that they're doing embedded Rust? I'm aware (and probably it should be pointed out) that such statements only always cover just the set of components they are using, and in the way they are using them. Still, I think it'd help answer these questions, and be a useful resource for developers who want to explore embedded Rust in their companies. It may also be a convenient place to cross-reference http://showcase.rust-embedded.org/ (which is more focused on community projects you can study).

To not send the opposite message, such a section should only be opened if there is actually material for it (which could be gathered here).

The abandonment note on esp-rs in favor of building rustc on Espressif's LLVM and the related quickstart repo indicate that mrustc is not the way to go on ESP32 / ESP8266 / Xtensa cores any more.

I don't have the devices at hand or experience with that platform, but the current information in this repo seems to be outdated. @emosenkis or @rahul-thakoor, could you maybe have a look at that?

To help me maintain this list by merging the PRs that are submitted by the community.

https://robigalia.org/ returns a 404 page.

I came a cross this library yesterday, thought I might put it here as I didn't see it here:
https://github.com/drone-os
I'm not very good with embedded so I am not sure which projects should be listed in here.

As pointed out by @JohnDoneth, @kunerd crate HD44780 is doing custom bitbanging via sysfs instead of using the embedded-hal traits which means that this driver does not fulfil the criteria for a "driver crate" as mentioned on the page:

Platform agnostic crates to interface external components. These crates use the embedded-hal interface to support all the devices and systems that implement the embedded-hal traits.

We could move it down a section to the no_std crates.

@kunerd What do you think?

Right now, while we provide links to crates roughly structured into "implements embedded-hal" and "uses embedded-hal" (driver crates). For the crates we list, that's easily managed manually, and we only list awesome stuff and that determination can not be made automatically yet.

The utility of embedded-hal is part of the awesomeness we want to demonstrate, and that not only comes from all the awesome crates, but also from the average ones that do boring foot work. (Not every sensor crate will have a blog post or even documentation exceeding "here's the class, and these are the constructors", especially if sensor abstractions take off and then there's really nothing to document than "this struct is for that device, pass in its I2C contact point and it provides the general accelerometer traits").

For these crates, it would be nice (maybe even awesome) to have lists of "who implements traits of that crate" or "who uses traits of that crate" easily accessible. This won't be part of a-e-r, but I don't know what it will be part of yet, but I know I eventually want entries like this:

• embedded-graphics: 2D drawing library for any size display. Implementers, users.

Now how do we get there? (And this is where it starts to become a bit of a scatchpad, which I hope is OK because the top half should illustrate why it belongs here too).

Starting points are:

• We currently have this manually for one crate with the embedded-hal-impl & co keywords. (People forget that, and it doesn't scale).
• crates.io has dependencies, which is a good starting point -- to implement and use a crate's traits you have to depend on it (at least indirectly, if the direct dependency pub uses something).
• rustdoc has the data as it lists implementations of a crate. It doesn't list implementers across crates in the HTML version, but it lists what is implemented for a struct, and having the information in one direction is enough (the rest is indexing / database management).

I've peeked into the output of rustdoc [lot of args from strace -f -eexecve cargo doc] -Z unstable-options --output-format json --document-private-items --document-hidden-items (private and hidden items because my test crate is embedded-nal-minimal-coaptcpserver which implements coap-message, but doesn't have a public type that does so and only passes around the implementation through as an impl MinimalWritableMessage).

Gold for the "X implements Y" side was found in an item ["index"]["0:14"], which has ["kind"] = "impl" and an ["inner"] that is has the ["for"]["inner"]["id"] = "0:4" of an item of this crate (the non-public Message) and a ["trait"]["inner"]["id"] = "20:22" of the MinimalWritableMessage trait it implements.

(The other side will be a bit harder, as "uses any implementation of" can occur in lots of places, but maybe some XPath magic can help.)

The data I think makes sense to extract is in a first stage is only on the crate level:

• "minimal_coaptcpserver implements some trait of coap-message"
• "minimal_coaptcpserver uses (by accepting any implementation of) some trait of coap-handler"

The information is available in more detail, and could gradually be expanded to which trait is shared, and (ultimately) which item of minimal_coaptcpserver implements which trait and which item ("in which position" would be taking it too far) uses which trait. That ultimate stage is IMO best left to rustdoc only.

So, the data is there, and an extractor Can't Be That Hard^TM to write. But for where?

• Can rustdoc be enhanced to the point where docs.rs makes this accessible?

  This would be nice but a bit backwards, as the first step would be the "ultimate" extension step of above across crates. (The "Implementors" section is currently largely empty if all implementations are in different crates -- see https://docs.rs/embedded-hal/0.2.6/embedded_hal/digital/v2/trait.InputPin.html#implementors for an example).

• Can docs.rs provide it?

  They already provide the dependency graph, but barely look into the crates, so if they'd provide it as part of their API, I guess that data would need to come from somewhere.

• If neither, what can host it?

  And how is it updated, especially in light of conflicting versions? (What breaks while everyone is still providing embedded-hal 0.2 but 1.0 is released?).

  For the time being, this wouldn't need to run across all crates; picking the pivot crates (embedded-hal etc) and regularly getting a list of their reverse dependencies should do for our purposes. Still, this needs to run somewhere. (Hosting as in output files is easy then, for it's just a static list of links).

The MPU6050 can be accessed with the MPU930 crate in your list. Nevertheless I wrote my own driver specifically for the MPU6050. Should I create a pr nevertheless?

Contributions to the Embedded Rust Ecosystem should be published under the same license as Rust itself, embedded-hal and cortex-m-rtfm which is:

Licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Why? In a professional environment the license is of utmost importance. When you start a project and choose an ecosystem for embedded development you need to make sure that all code and drivers are released under compatible licenses. To ease this process I suggest that all code released under a divergent license should be labelled divergent special license.

At the same time the new divergent special license label will encourage code writers to join our common license policy. A common and coherent license policy constitutes the condition sine qua non for professional suitability. It supports our vision (To improve the productivity of embedded software development teams). Linux would not have been successful without its a common and coherent license policy.

In order to encourage a common license policy for Embedded Rust, I suggest that contributions are only fully accepted in this list, when they comply with the above licenses. Contributions published under divergent licenses can be listed, but should have a divergent special license label.

Over the last month or two I've been working on a blog series focused around designing and implementing a real-world embedded system (intro/all posts), primarily based on the experience I've gained programming CNC machines in the wild.

There are a lot of resources online based on the low-level details like peripheral crates and how to get code running, but I haven't seen much in the way of high-level architecture or how to make these sorts of embedded systems in a scalable way. That's what I'm trying to address with the aforementioned blog series.

However, the implementation itself is written using WASM instead of a real embedded device (everyone has a browser, not everyone has a STM32 dev board handy).

Is this sort of resource still relevant to the Awesome Embedded Rust list?

Im an arduino user, diving into the depper lever of embedded, and would be useful to have the most common radio module support, the nordic rf24l01.... I hope I've helped!

Suggested repo title Curated list of resources for Embedded and Low-level development in Rust programming language

Suggested tags awesome-list, awesome, rust, embedded, embedded-systems, libraries

(copied from the old list)

There's quite a few panic implementations now, so I think it'd be useful to list them here. I'm not sure where exactly they should be put though, because some of them are platform-independent while others aren't. Personally I think these belong in their own section.

List of crates:

• panic-halt: Halts the processor on panics
• panic-abort: Causes an abort on panics (nightly-only)
• panic-ramdump: Writes the panic message into the beginning of RAM and enters an infinite loop; the message can be extracted by attaching a debugger (Cortex-M only)
• panic-semihosting: Prints the panic message via semihosting to an attached debugger (Cortex-M only)
• panic-itm: Prints the panic through the chip's ITM to a debugger attached to the SWO pin (Cortex-M with ITM only)

Previously opened an issue about formatting and badge use on the awesome-rust list rust-unofficial/awesome-rust#419.

For awesome-embedded-rust, I propose continuing with the format we have now, which is the "simpler alternative" in the above link, except without any graphical badges (the graphical logo at the top looks fantastic, however). Removing the noise of misaligned badges, It's easier to read and especially to load. Bringing up now before the lists begin to grow, especially with the many crates to be added for no-std #2.

To all the crates that have been published to crates.io. The markdown to add is:

![crates.io](https://img.shields.io/crates/v/$CRATE.svg)

The result should look like this for $CRATE = l3gd20:

• L3GD20 - SPI - Gyroscope - Intro blog post -