(post split in two because discourse won’t let me cc more than 10 people)
Off the top of my head I suggest two interfaces for many peripherals
I also think that we’ll probably need more than one set of traits to accommodate
the different async models that exist out there. Trying to fit all of them in
one set of traits will probably converge into a blocking API.
Wow, that’s some really neat stuff you are working on. I’m looking forward to
their public releases.
My first project has to do with a command-line tool to improve the build /
load / run workflow when interacting with most of the broadly available
embedded debuggers and bootloaders such as ST-Link, JLink, Arduino and Teensy
If I may ask: Is that an OpenOCD re-implementation or something that builds on
top of it?
My other project is a bit broader and has a bit further to go, but has to do
with the tooling and work needed to build and maintain HALs (including
peripheral drivers) within and across device families, with the goal being a
hierarchy of crates comparable to existing vendor-provided SDKs.
Is that something along the lines of PlatformIO or something different?
It depends on what’s their architecture. If it’s something that LLVM supports
then it’s doable in principle. I recall reading somewhere that you needed a
custom gcc toolchain to build code for them though, so no idea if LLVM supports
Thanks for sharing!
Nothing technically (we’re using Rust!!)
but key priorities for us are:
Stable Rust support
lang_items is a tough one, but you should be able to drop asm! if you move your
syscalls into external assembly files though that adds a dependency on an
external assembler and reduces performance due to less inlining.