Survey: 2019 wishlist #256
Comments
|
Category: Stabilization Request: Stabilize RFC 2282 - "Cargo profile dependencies" AKA Rationale:
|
|
Category: Bug fix Request: fix rust-lang/cargo#5730 - "Features of dependencies are enabled if they're enabled in build-dependencies; breaks no_std libs" Rationale: this makes some |
|
Category: Stabilization Request: Stabilize Rationale: this is required to make (*) |
|
Category: Stabilization Request: Stabilize Rationale: this is required to make (*) |
|
Category: "feature" Request: MIPS intrinsic for Rationale: Access to the system control coprocessor in MIPS provides access for features ranging from MMU control (for devices that have it) to enabling/disabling interrupts and handling interrupts. This currently requires either external assembly, which is not optimal, or |
|
Category: Stabilization Request: thumb intrinsics (#63) Rationale: many (all?) the intrinsics we want are in stdsimd (rust-lang/stdarch#518) and so available to nightly; it would be great to get them stabilised as well. The last RFC about this (#184) sort of stalled out. P.S. thanks @ZirconiumX for reminding me! |
|
Category: Std Request: Optimise memory routines in Rationale: At the moment the |
|
Category: Crate Request: High quality RTOS bindings Rationale: Being able to use Rust alongside an existing RTOS (FreeRTOS, ChibiOS, mbed-os, etc) would be really attractive for those already using the RTOS but wanting to start moving to Rust. Ideally in the end we'd have a Rust RTOS anyway (and RTFM provides a really compelling alternative already) but in the immediate future good bindings would be great. There's already work in this direction such as https://github.com/hashmismatch/freertos.rs and https://github.com/thenewwazoo/ChibiOS-rust. |
|
Category: Crate Rationale: Adding SD card support to your embedded project should be as easy as using the Arduino SD library - just depend on the crate and add a on-liner connecting the SD card library to your chip's SPI peripheral. This library should prioritize ease of use over performance (i.e. polling and byte-wise transfers rather than interrupt-driven DMA block transfers), but allow for higher-performance implementations to be plugged in if required, through a generic |
|
Category: Crate |
|
Category: Crate |
|
Category: Crate |
|
Category: Bug fix Rationale: In drivers that support several devices, it would simplify the code to be able to define generic associated constants for things like buffer sizes and use them to create fixed-size arrays for data transfer, for example. |
|
Category: Feature Request: std-aware Cargo / Xargo in Cargo Rationale:
This is planned work for the Cargo team so I mainly want to gauge interest and check how important is it for you to get this stabilized in 2019. Please vote with a 👍 if this would be great to have available in nightly, OR with a 🎉 if it's vital for you to have this working on stable. |
|
Category: Std Request: math support in core Rationale: there's nothing OS specific about math libraries. |
|
Category: Resources Request: Table/List of comparison/example between embedded_hal API vs Arduino API Rationale: This will help in teaching newcomer about embedded rust. Especially the one who doesn't have experience in firmware programming. Also, it makes it easier for someone to port some of Arduino libraries into rust drivers. |
|
Category: feature |
|
|
Category: stabilization |
|
Category: crate (Side note: I would probably be able to help writing this.) |
|
Category: feature Request: Add support for Cortex-R52 Rationale: One of the most advanced real-time embedded CPU out there. As the first |
|
Category: stabilization Request: stabilize Rationale: It would allow to use dynamic heap-allocated structures on stable |
|
Category: resources Request: are-we-no-std-yet style community push Rationale: push no_std amongst important libraries and a guide to helping library authors avoid std stuff they may not need, feature gate stuff they do |
|
Category: resources Request: Improve documentation needed to start experimenting with Rust on AVR, MSP430, RISC-V Rationale: The more people start to experiment with those platforms the better - more testing, more drivers, etc. Using Rust on cortex-m chips has been greatly simplified and streamlined during this year. Other mcu platforms are not yet there and have a more steep learning curve now. It would be great to have introductory documents for some available development boards (LaunchPads, Arduinos) explaining how to get started with Rust on those boards: how to prepare environment (Xargo/Cargo), maintained crates (HAL, drivers, etc), troubleshooting (e.g. where to post LLVM issues), and so on. |
|
Category: resources Request: Improve crates.io or create separate site for Rationale: It is still very hard to find suitable crates for |
|
Category: crate |
|
@eddyp in the linked repository, you can see that I have a |
|
@eddyp my target has no std lib (EDIT: and no atomics, so even proptest with nostd doesn't work), so I can not build my examples at all if cargo is trying to build quickcheck. https://travis-ci.org/rust-console/gba/builds/470340649 So, yes, i want almost all my tests to be built and run on a big beefy x86 machine with 50 cores and such. |
|
Category: stabilization Request: complete and stabilize the last bits of procedural macros (macros 1.2): crate level attributes and attributes on modules Rationale: Right now DSLs that require whole crate analysis to work and want to support the stable channel (e.g Real Time for The Masses v0.4) are forced to expose APIs like |
|
Category Feature Request: A way to get a pointer to and length of a function compiled within the program. Rationale: Within an embedded context, you might have a bit of code that you want to execute from some place other than the default memory storage. Sometimes you want to copy a function to a different piece of memory and then execute it there. It's already possible to have a pointer to a blob of bytes and then transmute it into a pointer to the function type in question, the only problem is that you can't currently talk about the compiled output of a function within rust, so you can't describe that you want to copy it into a particular part of memory. |
|
@Lokathor if the linker generated start function and end function symbols wouldn't that cover it? Maybe generate per function or per file with a flag that triggers these symbols to be generated? That would also assume inlining would not occur for those functions. |
|
Yeah, something like a function attribute and/or proc-macro where you tag a specific function as "transferable" would probably be enough. It doesn't need to be an ability available for every single function ever. |
|
@Lokathor would the presence of that flag imply no_mangle? |
|
Ahhhh.... maybe? That's actually a really tough one. I think it's not necessary, even if you might want it in some cases. Functions in Rust can already name other functions in Rust and the language handles it for you. // the fact that `ValType::func` gets mangled doesn't stop this from working right
let mapped_opt_val = opt_val.map(ValType::func);So if you've got a Rust program that doesn't care about outside code being able to find its symbols, then you won't need to apply the Just spitballing, but a "complete" program might look something like this: #![no_std]
#![feature(start)]
#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
loop {}
}
#[transferable_fn]
pub fn runs_from_ram(x: isize) -> isize {
x // pretend this does something interesting
}
#[start]
fn main(_argc: isize, _argv: *const *const u8) -> isize {
// This will point to the target location, transmuted to the correct fn type
let fptr: fn(u32) -> u32 = {
// Naturally users will need to be able to check the size of a
// compiled function somehow
if transfer_fn_size!(runs_from_ram) < 0xFF {
unsafe {
// This must panic if 0, should probably panic if unaligned,
// otherwise it does a memcopy to put the code in place
transfer_fn_here!(0x300_0000, runs_from_ram)
}
} else {
panic!("your func was too large!")
}
};
fptr(5);
} |
|
Category: crate/feature/resources Request: stabilize/document how to access to cpu specific instructions (e.g. nop, dsb, isb, wfi, msr, mrs, cpsie... for ARM, msync, isync, mtspr, mfspr, mbar... for Power) Rationale: On low level code such as RTOSes context switching, exception handling or HW programming there are often very specific assembly instructions which must occur in very specific sequences and with precise timings to correctly program or control hardware state. These can rely on barriers, special purpose register accesses or HW specific instructions to be issued and lacking a stable intrinsics APIs/ documentation makes this a problem for people considering to move to Rust because one is forced to face complex systems (build.rs or c/asm/rust combinations using make and calling rustc directly), and this is drawing focus away from the hard but very powerful new concepts rust brings to the table, decreasing the chance of switching to Rust. Since inline asm seems to be still far away, maybe the solution is some crate that provides precompiled .s code for the instructions similar to the HardFaultTrampoline snippet via macros (e.g. |
|
Category: feature/resources Request: Provide fine grained custom memory sections layout (similar to C Rationale: In embedded applications it is often specific memory ranges are used for specific purposes and not all memory has the same properties, for example noncacheable memory ranges, tightly coupled instruction or data memories, ECC SRAM memories, etc. It follows that it should be possible to define some specific custom memory sections via the linker script - With most embedded C/C++ tool chains it is possible to use compiler specific |
|
Why can't you use |
|
@eddyp It doesn't completely answer your question, but for Cortex-M there's the cortex-m crate, which provides precompiled instructions as you describe, and for link sections the quickstart shows an example of doing this here. It isn't quite complete since there's no rt support for initialisation in those sections yet, though. |
|
@ZirconiumX you can but is not desirable since in typical code I am thinking about you want to say "from this point on in the file onwards, all uninitialized data should be placed in .noncachablebss, until the end off the file or another choice for the section" or "all functions from this point should be placed in the tightly coupled instruction memory, until I explicitly revert to using flash". And it gets very tedious soon to add such attributes for each symbol when there are many symbols in a file that should be placed in that section, but definitely not all of them nor just a few. |
|
@adamgreig I was aware of the crate and the precompiled stuff, but from what I could see and understand from the sources, there were some problems with them:
Regarding sections, I am not only referring to data sections, but also .text; also see the answer above regarding what's missing from current I know it might mean that llvm must first add such support, but all C tool chains I've worked with have this #pragma mechanism: Green Hills, Windriver Diab, Cosmic, IAR, ARM/DS-5, Code Warrior. |
|
Category: Std Request: Provide a #[init] attribute to allow for an initialisation function Rationale: To ensure safe initialisation of the MCU, data and peripherals we might want to have a |
|
Category: crate Request: Supplement the Rationale: To share peripherals and other resources between interrupt/exception handlers and e.g. the main loop the user currently has to create a static |
|
Is that for multithreaded handlers? Because on a single core, I've been assured by some very serious people that you can just share a global between the main thread and the interrupt handler if it's always accessed in a volatile way. Speaking of which, on armv4t you must have an interrupt handler written with 32-bit arm state. Is that the same on later arm devices, and are you just programming the whole program in ARM state? I know it was asked about +thumb and -thumb above, but if there was a way to even write just the handler as ARM and the rest of the program as Thumb that'd be enough for most of the desired use case. |
|
Does writing android HALs with HIDL support fall under purview of rust embedded? |
|
For anyone here who added an item to the wishlist, please consider adding your item to the Not Yet Awesome Embedded Rust List to make the need for your wishlist item more visible! |
|
2019 finished. Maybe we can create a follow up issue for 2020. Nominating for next week's meeting. |
|
Closing as we're now well into 2020; if anything outstanding from this list is still relevant please add it to the not-yet-awesome embedded rust list, or create a new issue to track it. |
and others
Hello embedded Rustaceans!
We are collecting a "wishlist" of things you'd like to see done, fixed or
stabilized in 2019. We'll use this data to make a roadmap for 2019, i.e. to set
the goals of the WG for 2019.
You can request anything related to embedded Rust development: language
features, bug fixes, crates, docs, etc. The more requested something is the more
likely it is to make it into the roadmap; of course, other factors will be
considered as well: amount of work required; how beneficial would it be to the
community; does it require a rust-lang/rust RFC? how likely is that RFC to be
accepted?; who has to do the bulk of the work? the embedded community or a Rust
team?; etc.
To keep things tidy let's limit comments to one request per comment. Let's
also avoid "+1" and "I'd like to see that fixed too" comments; instead use a 👍
reaction to vote for a request.
To make our job easier please use the following format:
If you'd like to extend the rationale of an already submitted request just make
a new comment referencing the original request. We'll merge your comment into
the request comment. For example:
Summary of requests
Stabilization
profile-overridescore::mem::MaybeUninitconst fn-s that have trait bounds, e.g.const fn new() -> Mutex<T> where T: Send.Bug fixes
Features
#pragma unrolland-funroll-loops)Std
Crate
Resources
cc @rust-embedded/all please check this thread every now and then and update
the summary section
The text was updated successfully, but these errors were encountered: