embedded-hal
cppcoro
embedded-hal | cppcoro | |
---|---|---|
11 | 24 | |
1,815 | 3,252 | |
3.7% | - | |
8.6 | 0.0 | |
15 days ago | 5 months ago | |
Rust | C++ | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
embedded-hal
-
Announcing the new async-hal! Featuring embedded IO traits and new interrupt-based executor
What is the difference between this and https://github.com/rust-embedded/embedded-hal/tree/master/embedded-hal-async?
-
Introducing async-hal! A hardware abstraction layer for embedded devices with futures
Maybe worth mentioning if you (or someone else) hasn't seen it before, the embedded-wg is also working on an async version of the embedded-hal traits, embedded-hal-async.
-
Microsoft is rewriting core Windows libraries in Rust
In that case you want to keep most of the unsafe in the HAL crate, and expose an interface as safe as possible. To give you an idea, is it since 2018 that a "generic" DMA safe implementation is in discussion https://github.com/rust-embedded/embedded-hal/issues/37
-
Stop Comparing Rust to Old C++
Does something like embedded hal exist in the C/C++ world? ( https://github.com/rust-embedded/embedded-hal )
-
not entirely new to rust, but very new to rust+arduino,.... eli5 the differences between these projects?
worth mentioning also is embedded-hal but my understanding is this has absolutely nothing to do with arduino, so despite being embedded probably not what I want.
-
Google announce secure Rust-based OS for embedded system
The ecosystem is great and growing, It really benefits from a language-standard embedded HAL which makes writing cross-platform drivers a cinch - e.g., you can write a bit-banged MDIO driver and use it on anything that has a timer and a two IO pins, from a Zynq Ultrascale to an arduino. Sure, this is possible in C - but Rust really benefits from a less fragmented ecosystem here.
-
Want to volunteer for your projects
Have you thought about writing/contributing to embedded-hal compatible crates (a sensor module driver for example)? It's always good to contribute to an eco system.
-
STM32F4 Embedded Rust at the HAL: GPIO Button Controlled Blinking
đź“ť At the time of writing this post, it came to my attention that there is an additional HAL that targets STM32 device families (the stm32-hal). From what I figure, right now there seem to be two approaches for developing HALs. The first approach is trait driven so to speak where the embedded-hal is used as a foundation. The second approach is more application-driven and provides a high-level API that targets several families of a device. However, this exists only for the stm32 through the stm32-hal. Right now, the first approach is what I found to be more widespread as it covers different microcontrollers and what this post is based on.
-
Why doesn’t V8 fit on my microcontroller?
I can write a library for an OLED device that is driven by an platform agnostic I2C device that will run on any microcontroller that implements the necessary abstractions.
The `embedded-hal` (https://github.com/rust-embedded/embedded-hal) are these abstractions that allow this to happen
-
Hands-On: The RISC-V ESP32-C3 Will Be Your New ESP8266
Yes but there needs to be appropriate libraries available such as HAL. Well it doesn't have to but it makes my life as a beginner in both much easier. But its probably matter of time because i predict that this chip will be very popular in Rust embedded.
cppcoro
-
Struggle with C++ 20 Coroutines
PS: Take a look at cppcoro; this might help as well, especially generator<>, if you're looking to generate numbers, and stuff;
-
Does C++23 have a coroutine task promise type?
This is the only viable implementation.
-
Stop Comparing Rust to Old C++
Kind of sounds like whatever library you were using provided leaky abstractions. Something like cppcoro provides really good abstractions for coroutines, the user really doesn't need to understand why any of it works.
-
Sane coroutine imitation with macros; copyable, serializable, and with reflection
Is there a usecase for copying/serializing such coroutines? If not, I would use the normal C++20 coroutines (cppcoro?).
-
Is Tokio::sync::Mutex lock-free?
C++ has the popular CppCoro library. Async_mutex is its equivalent of Tokio::sync::Mutex, providing exclusive access to data shared between tasks.
- My experience with C++ 20 coroutines
-
My thoughts and dreams about a standard user-space I/O scheduler
Because the whole application is running under a single thread there is no need for atomic operations in synchronization primitives(which most of the time requires seq_cst memory order and CMPXCHG which is an expensive instruction in CPU). for example what async_mutex would look like if it knows it's running in a single-threaded scheduler (a non-atomic state variable and waiters queue).
-
[Discussion] What are some old C++ open source projects you wish were still active?
Maybe not old, but I wish cppcoro was still updated. It was such a nice start!
-
A high-level coroutine explanation
You can get generator<> from https://github.com/lewissbaker/cppcoro
-
C++ Coroutines Do Not Spark Joy
It is possible to compose them more easily than described in the article; Lewis Baker's cppcoro library for example provides a recursive_generator<> type[0] that allows this without using any macros. It's up to the library part of coroutines to make things easy, end users are not expected to write low-level coroutine code themselves.
I wonder about the allocation elision. Return value optimization became mandatory, and some compilers can already elide calls to new/delete and malloc()/free() in normal code, so perhaps it will be possible to guarantee allocation elision in the future in the most used cases.
[0]: https://github.com/lewissbaker/cppcoro#recursive_generatort
What are some alternatives?
quickjs-esp32 - QuickJS port for ESP32
libunifex - Unified Executors
microzig - Unified abstraction layer and HAL for several microcontrollers
drogon - Drogon: A C++14/17/20 based HTTP web application framework running on Linux/macOS/Unix/Windows
bl602-hal - Hardware Abstract Layer for BL602 RISC-V WiFi + BLE SoC in embedded Rust
Folly - An open-source C++ library developed and used at Facebook.
nesper - Program the ESP32 with Nim! Wrappers around ESP-IDF API's.
C-Coroutines - Coroutines for C.
esp8266-quickjs - An attempt on getting QuickJS working on ESP8266 hardware
Flow - Flow is a software framework focused on ease of use while maximizing performance in closed closed loop systems (e.g. robots). Flow is built on top of C++ 20 coroutines and utilizes modern C++ techniques.
embassy - Modern embedded framework, using Rust and async.
coproto - A protocol framework based on coroutines