nex8192 has left #rust-embedded [Error from remote client]
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
nex8192 has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
jessebraham[m] has joined #rust-embedded
<jessebraham[m]>
FYI we've now updated to the `1.0.0-rc.1` releases of all the `embedded-hal-*` traits in `esp-hal`, and have additionally implemented the `embedded-io{-async}` traits for our UART and USB Serial JTAG drivers. Haven't played with them a ton yet but initial testing was successful.
<jessebraham[m]>
I'm not sure what the timeline is for the next release, but we will likely publish new releases of our own in a couple weeks
<jessebraham[m]>
s/release/releases of these trait packages/
<ryan-summers[m]>
Is there a heapless hash-map that doesn't actually store the keys?
<JamesMunns[m]>
Like hashset?
<ryan-summers[m]>
I mean like, it hashes the key, then stores the hash as the key internally. My keys could be pretty large and I don't actually want to keep them around
<JamesMunns[m]>
Oh, generally the keys are stored to handle hash collisions
<ryan-summers[m]>
And probably fine with hash collisions
<JamesMunns[m]>
I dunno of any maps that don't store the full key off the top of my head
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
hash the key yourself, use the hash as the key in a regular hashmap
<cputoast[m]>
Has anyone gotten two STM32 SAIs to synchronize? I need two I2S streams with the same clocks. I've checked with CubeMX, which seems to indicate that its possible to synchronize one SAI to another, but I cant find that option in the stm32h7xx-hal.
fuse117[m] has joined #rust-embedded
<fuse117[m]>
what is this community's advised approach on using vendor provided C drivers? c2rust? i have re-written a few simple drivers from scratch as it seemed to be the path least resistance. i am looking at a few more complex drivers right now and wondering how best to manage them.
<dirbaio[m]>
rewrite in rust if you can, yes
<dirbaio[m]>
otherwise build and link the C code with the cc crate, and create Rust bindings by passing the headers through bindgen.
<fuse117[m]>
so bindgen over c2rust is more ideal?
<dirbaio[m]>
Actually converting all the C code through c2rust seems more risky to me, I'm not sure how accurate it is with large codebases...
<dirbaio[m]>
and you'll have a harder time if you want to modify it because the c2rust output is hideous
<dirbaio[m]>
(and you probably will need to modify it... it's a vendor C driver 🤣)
<jessebraham[m]>
I've never personally had any success with `c2rust`, wrapped a few C libraries using `bindgen` though
<jessebraham[m]>
As long as the library isn't super macro heavy on the public API usually works okay
<fuse117[m]>
the driver requires the user to provide platform i2c/spi read write functions. its not clear to me how to do that. can someone point to any examples
<dirbaio[m]>
they typically make you implement some C functions
<dirbaio[m]>
you can implement them from Rust with #[no_mangle} extern "C" fn spi_write(...)and make them call into your Rust HAL
<dirbaio[m]>
I don't know of any opensource examples of that tho, hopefully someone else has some
<adamgreig[m]>
hi @room, meeting time again! agenda is https://hackmd.io/jMvtahURTiCzMMlTf1KYhg, please add anything you'd like to discuss or announce and we'll kick off in a few mins
<diondokter[m]>
JamesMunns[m]: Oh sweet! Gonna queue it up!
<adamgreig[m]>
ok, let's go! a few announcements this time, embedded-hal 1.0.0-rc.1 is out, along with its companion crates!
<adamgreig[m]>
please try it out on your drivers/hals and report back, currently there's no technical changes planned except documentation and polish
<adamgreig[m]>
svd2rust 0.30 is out, with the new per-peripheral steal(), as well as big improvements to the generated docs
<adamgreig[m]>
and rust 1.72 is out thursay, though I think the only especially embedded-relevant is gaining a new tier 3 target for loongarch64-unknown-none
<adamgreig[m]>
any other announcements?
<thejpster[m]>
it also has a new tier3 target for SPARCv7, so you can run it on a Gaisler LEON3, which is available as a GPL3 soft core
<thejpster[m]>
fun for the FPGA x SPARC fans
<thejpster[m]>
* x SPARC x Rust fans
<adamgreig[m]>
oh, fun
<adamgreig[m]>
how's llvm for sparc?
<thejpster[m]>
worked perfectly on my testing - and it was already supported on SPARC Linux anyway. I basically didn't do anything.
<thejpster[m]>
but my first proper Rust PR and my first new target.
<adamgreig[m]>
I dunno how those get decided really
<adamgreig[m]>
anyway, nice work
<adamgreig[m]>
first on agenda is embedded-hal, I guess the main things now are feedback on the RC, the migration guide, and any other polish before release?
<adamgreig[m]>
I noticed the repo readme has a nice table of crates and other details but the one you get on crates.io/docs.rs is a bit different since it's a different file
<adamgreig[m]>
if nothing else we'll have to remove the notes about active development and alpha releases :P
<adamgreig[m]>
but also the 'design goals' talk about "Where possible must not be tied to a specific asynchronous model. The API should be usable in blocking mode, with the futures model, with an async/await model or with a callback model. (cf. the nb crate)"
<adamgreig[m]>
which I think probably needs removing :P
<adamgreig[m]>
it might be worth just reproducing the top-level readme table in each crate's own readme
<dirbaio[m]>
yeah, readmes could use some updating
<adamgreig[m]>
still, the end seems very much in sight at last :p
<adamgreig[m]>
romancardenas: do you wanna talk about the riscv thing?
<dirbaio[m]>
adamgreig[m]: except for the removed traits:D
<dirbaio[m]>
* removed traits :D
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
Sure, I'd like to know your opinion
<dirbaio[m]>
adamgreig[m]: except for the removed traits :D
starblue has joined #rust-embedded
<romancardenas[m]>
The idea is that we are implementing standard peripherals for RISC-V
<romancardenas[m]>
Buut... we have a few differences: base addresses are target-dependent and usually peripherals replicate a set of registers for every HART/core of the uC
<romancardenas[m]>
So... what do you think? I'd like to stick to one approach and start pushing new things to master
GeorgesP[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
Personally I see a lot of value in making it "just like cortex-m", to help people who are used to one and need to switch to the other.
<adamgreig[m]>
normally I'd agree, but I don't think the cortex-m ones are necessarily a great example
<dirbaio[m]>
the problem is the cortex-m approach has issues
<thejpster[m]>
and cortex
<thejpster[m]>
* fair point
<adamgreig[m]>
if anything, if you had a good time with a new approach in risc-v, I'd be tempted to copy it into cortex-m :P
<thejpster[m]>
ok, and if I say "well make it like the svd2rust generated API" ...?
<adamgreig[m]>
having a distinct PAC and HAL layer doesn't seem like a bad idea
<adamgreig[m]>
but whether that PAC is svd2rust generated or otherwise, dunno
<dirbaio[m]>
my opinion is that, in general, "make a repr(C) struct that mirrors the register layout" is a C-ism that we should get rid of
<thejpster[m]>
isn't the whole point to avoid pointer maths though?
<adamgreig[m]>
in particular, it seems unavoidable that it would lead to the dereferenceable soundness issue
<thejpster[m]>
or is the argument, the addresses are all in the datasheet so you might as well type them in rather than making a struct with the magic amount of padding?
<adamgreig[m]>
ideally you have something to generate the right code for you
<dirbaio[m]>
thejpster[m]: yep, this. you end up doing *more* math with repr(C) structs, calculating padding sizes etc
<adamgreig[m]>
so you get some sort of hardware description, like an SVD file or something you've written yourself, and your tool, like svd2rust or chiptool or whatever, can generate the rust that accesses those registers and fields
<dirbaio[m]>
the biggest issue with repr(C) structs is the "dereferencable" thing. The rustc implementation was changed to make it sound, but it's still unclear whether it is actually sound.
<dirbaio[m]>
vs the raw pointer approach is obviously sound
<cr1901>
Is the dereferencable soundness issue about that "technically most PACs are insta-UB because mut refs can't alias" thing?
<adamgreig[m]>
the idea is that the raw pointer thing should compile to the same optimal instructions as you'd expect from the repr(C) struct
<romancardenas[m]>
My vision is that svd2rust would detect the base address of the peripheral, implement all the traits such as Interrupt, Priority, etc. and use the "vanilla" riscv peripheral, regardless of the final approach we follow
<adamgreig[m]>
cr1901: nah, it's that "rust may insert a read to any &-ref anytime", but MMIO can react to reads
<cr1901>
ahhh
<adamgreig[m]>
romancardenas: unfortunately right now svd2rust doesn't support runtime changing of the base address really
<adamgreig[m]>
is it compile-time for you, or runtime?
<adamgreig[m]>
I appreciate it's target-dependent but maybe still known in advance?
<romancardenas[m]>
Compile time, usually PACs would just create a PLIC(base_address) to a valid base address
<thejpster[m]>
so I like to see new approaches to APIs and experimentation. I'm just not sure something as fundamental as the risc-v crate is the right place for that? But then again, maybe it's hard to write PACs and HALs without the basics in place.
<romancardenas[m]>
Yep, known in advance
<dirbaio[m]>
the raw pointer approach is quite proven, embassy-rp and embassy-stm32 use PAGs generated by chiptool which uses raw pointers instead of repr(C) structs. and it works fine
<dirbaio[m]>
it compiles 2x faster too
<adamgreig[m]>
yea, it's not clear yet how svd2rust can/will transition and it's a big change, but it does seem clear (to me) that the way forward should be raw pointers
<adamgreig[m]>
dirbaio[m]: not sure this is to do with raw pointers vs structs though, lol
<dirbaio[m]>
* <del>it compiles 2x faster too</del> no, that's due to svd2rust generating more proxy structs, not to repr(c) vs ptrs
<adamgreig[m]>
stm32ral compiles in no time at all and it's all repr(c) structs still
<dirbaio[m]>
yeah, just edited, sorry
<dirbaio[m]>
it's somewhat orthogonal
<adamgreig[m]>
romancardenas: any reason you don't want to bump msrv from 1.59 to 1.61?
<romancardenas[m]>
No, it's fine for me. But I'm relatively new and it feels awkward to start bumping everything 😅
burrbull[m] has joined #rust-embedded
<burrbull[m]>
no reason to not bump
<romancardenas[m]>
If the register block is somehow an issue, we could use riscv to build a mature raw pointer approach for peripherals
<romancardenas[m]>
And once we are all happy with it, port it to cortex-m, adapt svd2rust etc.
<romancardenas[m]>
What do you think?
<adamgreig[m]>
it seems nice. maybe you could start with a specific riscv-pac crate that just provides register access to the standard riscv peripherals, and then it doesn't need to be published as a riscv update or anything yet
<adamgreig[m]>
and could merge it later (or just depend on it from riscv and put the HAL-like code there)
<romancardenas[m]>
Good idea
<adamgreig[m]>
probably some questions about how you describe the peripherals though - for svd it obviously gets fed an svd file, which doesn't exist (yet) for cortex-m peripherals or riscv peripherals
<adamgreig[m]>
so maybe you just want a macro or something
<romancardenas[m]>
We can get back to these issues as they appear (they will 😂)
<romancardenas[m]>
Ok, so, we could do a riscv-peripheral crate (or riscv-pac) to develop peripherals with the raw pointer fashion and once it is mature we can merge it to riscv
<adamgreig[m]>
ideally we should replace all the openocd and gdb references with probe-rs, rtt, that sort of thing, I think
<thejpster[m]>
head's up - probe-run might go away in favour of just using probe-rs, because it's pretty much on-par now.
<thejpster[m]>
but I guess you'd point at probe-rs / cargo-flash / cargo-embed anyway.
<adamgreig[m]>
probably not even cargo-flash/cargo-embed, I guess
<burrbull[m]>
cargo-dfu. how to configure rust-analyzer
<dirbaio[m]>
I'd make the book tell the user to use a debug probe, not use bootloaders like DFU/UF2
<dirbaio[m]>
because without a probe you don't get good logging, especially about panics
<adamgreig[m]>
but you might not always have a debug probe, or a board that makes them easy to connect
<adamgreig[m]>
lotta mcu boards out there with bootloader only, sadly
<adamgreig[m]>
may as well signpost how to use that with rust, even if we strongly encourage using a debugger or getting a board with one
<adamgreig[m]>
given how cheap an stm32 nucleo or rpi+rpidebug combo or something is...
<dirbaio[m]>
the boards that the discovery book targets (f3discovery, microbit) do
<adamgreig[m]>
but like, all the adafruit boards with nice LEDs in fun form factors are bootloader-or-bust, or maybe you can solder wires to some solder pads for a debug probe
<dirbaio[m]>
and without one, the experience is so bad
<dirbaio[m]>
s/one/a probe/
<adamgreig[m]>
yea, but this is the book, not the discovery book
<dirbaio[m]>
I see this all the time in #embassy-rs:matrix.org
<dirbaio[m]>
people end up debugging their firmware "blind"
<adamgreig[m]>
anyway I don't disagree, it can say you should defo use a debug probe, but might as well point the way to how to use a dfu bootloader too
<dirbaio[m]>
removing chunks of code, making LEDs blink to try to guess where it's panicking
<dirbaio[m]>
until we tell them to get a debug probe
<dirbaio[m]>
"oooh you mean I can see the file+line of the panic??"
<dirbaio[m]>
and yes, it's criminal that there's so many hobby boards with no onboard probe and no easily accessible SWD pads
<burrbull[m]>
openocd section should also stay as alternative even if we recommend probe-rs
<diondokter[m]>
Agreed. All it takes is like a tag connect (free) or a small header (cheap)
<dirbaio[m]>
the book should scream "GET A DEBUG PROBE. DON'T EVEN TRY WITHOUT"
<adamgreig[m]>
dirbaio[m]: I guess it's ok if you're using micropython/circuitpython, not like a debug probe would help there
<dngrsspookyvisio>
from my POV there's lots of really good and cheap boards on aliexpress, the main issue I'd have with recommending that route is that you're pretty much guaranteed a counterfeit ST-Link v2 there. Not that those don't work, but officially endorsing them - hm
<dirbaio[m]>
yeah they're designed for *python 😬
<thejpster[m]>
burrbull: there are chips that have Rust support and only work with a custom openocd :/
<adamgreig[m]>
ah good point
<thejpster[m]>
so yeah, don't delete that section. it also says "hey, it's just like C binaries if you want it to be@
<adamgreig[m]>
so yea, we should keep the openocd stuff... just after the probe-rs suggestions
<thejpster[m]>
before we wrap up and you all run away, I just wanted to add "good work everyone" for managing to ship pre-compiled binaries in cortex-m for several years without upsetting anyone. Yes they were fairly trivial but also we put in the hard yards to cross-check everything in CI and prove we were shipping what we said we'd ship.
<adamgreig[m]>
oh man, I hadn't even thought about that through the whole controversy!
<dirbaio[m]>
yeah, same 🤯
<adamgreig[m]>
I guess the security implications are a bit different when it's running on the embedded device instead
<adamgreig[m]>
can't just steal some credentials out of ~/
<JamesMunns[m]>
are our binaries reproducable? :D
<adamgreig[m]>
yea! the CI rebuilt whatever was in git and would error if they didn't match
<dirbaio[m]>
also it was more "justified" because it was impossible to do it on stable otherwise
<dirbaio[m]>
vs just a perf optimization
<dirbaio[m]>
* vs just a build time optimization
<adamgreig[m]>
still I'm glad to have removed them
* cr1901
hasn't removed the msp430 binaries yet ._. ...
<adamgreig[m]>
jannic[m]: 👀 stm32-rs
<adamgreig[m]>
(that's all for the meeting, anyway, thanks everyone!)
<burrbull[m]>
waiting for announcement of stm32-rs release next week
<thejpster[m]>
oh, hmm, I guess my sparc changes will be in the next stable. I forgot about six weeks of beta!
<thejpster[m]>
good job I'm not in charge of anything
<thejpster[m]>
also, I managed to insert the platform into the wrong table and accidentally made it tier 2 :rofl:
<diondokter[m]>
thejpster[m]: Oh well if it's that easy, why not a nice new tier 1? :D
<diondokter[m]>
Think of all the extra CI you'll get!
crabbedhaloablut has quit []
vrakaslabs[m] has quit [Quit: Idle timeout reached: 172800s]