search

rust-embedded / not-yet-awesome-embedded-rust

A collection of items that are not yet awesome in Embedded Rust
Creative Commons Attribution Share Alike 4.0 International
117 stars 11 forks source link

readme

Not Yet Awesome Embedded Rust

Awesome

This is a collection of things that are not yet awesome in Embedded Rust. We need your help to capture all of the things that are not yet awesome, and to start making them awesome!

This project is developed and maintained by the Resources team.

Are you interested in:

Check out our Contributing Guide for how to get started.

And don't forget to check our Awesome Embedded Rust list! The thing you are looking for may already exist!

Table of Contents

The List

Sharing Data With Interrupts

Background

Currently, it is not convenient to share non-atomic or non-Sync data with an interrupt using safe Rust. Because interrupt handlers are functions that take no arguments, all data consumed by interrupts must either be global or module scoped Atomics (e.g. AtomicBool), local static variables, or global or module scoped static variables.

Global variables are not great in Rust, because:

Frameworks like cortex-m-rtic achieve this in a zero cost fashion by using a Domain Specific Language to automatically provide safe access to shared resources between tasks and interrupts, however these tools can not be used by applications not using RTIC, or by libraries such as HAL or BSP crates.

Useful Links

Success Criteria

Ideally, we would be able to support all of the following use cases:

  1. Sharing a variable between the main thread and only one interrupt handler
  2. Sharing a variable between the main thread and one or more interrupt handlers
  3. Moving a variable from the main thread to one interrupt handler

We should be able to serve the three use cases listed above, while:

Serialization/Deserialization in no_std

Background

For embedded systems that send or receive data to other devices, or who read/write data to a medium such as an SD card or other Flash memory, it is useful to have automatic serialization and deserialization support to turn structured data into a binary format.

While tools like serde are widely used in Rust (and already support no_std), few of the the backends (like serde_json) are supported in a no_std environment.

Success Criteria

We should be able to serialize and deserialize data in an automatic way, either using a frontend like serde, or with a simple and convenient serialize and deserialize method. To use these, we should not need heap allocations, and it should be possible to detect when serialization and deserialization have failed.

Additionally, all common datatypes used in embedded Rust should be supported, as well as a (preferrably automatic) way to add support for custom data types. Common data types include:

We should also have support for different ways of serializing data, primarily:

Work in progress

Support crates for USB Host and USB Device Support

Background

The USB standard has a fair bit of commonality between USB Devices (like Mice, Printers, and Webcams) and USB Hosts (like Laptops and Raspberry Pis), but each specific microcontroller has a slightly different implementation of the USB Controller at the bottom of the stack. It would make bringing up a USB stack on a new chip much easier if there was a #[no_std] crate which defined some common traits, enumerations and structures at the bottom, and then provided support for various device classes above that.

Success Criteria

I'd like to be able to implement USB Host and USB Device support on the Texas Instruments Tiva-C line and the STM32F4 line by only implementing a thin shim around each device's USB OTG Controller registers. The USB Host should be able to handle a USB Keyboard and the USB Device should enumerate as a Communications Class Device (two of the most common use-cases).

Work in progress

Display and GUI support

Background

So far there seem to be no libraries to do anything with displays or gui's. However in C some libraries have already been written. Rust could interface with these libraries if bindings were made.

Useful links

Success Criteria

Bindings to C libraries or a Rust library that is meant for Displays and/or GUIs.

Work in progress

Support for no_std esp32-cam

Background

There is a large amount of accessible libraries and projects involving the esp32-cam in c++, and a few projects for rust using esp-idf-std (listed below), however there are no no_std crates with this support. A repository of information, including pin defintions, can be found (here)[https://github.com/raphaelbs/esp32-cam-ai-thinker/blob/master/docs/esp32cam-pin-notes.md].

Success Criteria

A library with bindings to the esp32-cam camera, accessible in a no_std environment.

Work in progress

Not Yet Awesome Item Template

Here's an example for something that is not yet awesome:

It's Hard to Foo without a Bar

Background

IETF RFC -1 states that you should be able to Foo with either a Bar, Bib, Bim, or Bap. However in all of these rust crates, you're required to have a Bar!

Success Criteria

I'd like to be able to Foo using only a Bib, Bim, or Bap.

Work in progress

License

The Not Yet Awesome Embedded Rust list (this project) is distributed under the terms of the Creative Commons CC-BY-SA v4.0 license.

Copies of the license used by this project may also be found here: CC-BY-SA v4.0 Hosted.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you shall be licensed as above, without any additional terms or conditions.

Code of Conduct

Contribution to this crate is organized under the terms of the Rust Code of Conduct, the maintainers of this crate, the Resources team, promises to intervene to uphold that code of conduct.