<lanre[m]>
New to embedded rust and new to everything embedded that's not an arduino.
<lanre[m]>
* Sorry if i sound stupid, i am.
<lanre[m]>
New to embedded rust and new to everything embedded that's not an arduino.
<lanre[m]>
Should i get a nRF52840 DK or a STM dev board?
<lanre[m]>
* Sorry if i sound stupid, i am.
<lanre[m]>
New to embedded rust and new to everything embedded that's not an arduino.
<lanre[m]>
Should i get a nRF52840 DK or a STM32 dev board?
<JamesMunns[m]>
No need to be mean to yourself, we all started fresh at some point :)
<JamesMunns[m]>
Both STM32 and nRF52 make pretty good dev boards, I'd maybe recommend the nRF52: I find it a little less complicated than the STM32 sometimes, but either would be reasonable!
<SbastiendHerbais>
Anybody's got a good allocator to recommend? I have 32 MB of external SRAM that I'd like to use :D
<JamesMunns[m]>
If you'd like to use the standard library, you might want to check out the ESP32 devices. They've implemented the standard library. Most other boards don't, because they don't have an operating system (the ESP32 optionally can be based on FreeRTOS)
<JamesMunns[m]>
for the nrf52 though, you can check out embassy-nrf52, and the nrf-softdevice crate, those will give you access to BLE
<JamesMunns[m]>
SbastiendHerbais: One I've been meaning to check out is "talc", which I think is a little inspired by mimalloc? The typical go-to is `linked-list-allocator`, which is simple but not the best for performance, depending on your access patterns
<SbastiendHerbais>
Never heard of it before, it looks awesome, thanks!
<JamesMunns[m]>
Ah it's based on dlmalloc not mimalloc
<lanre[m]>
JamesMunns[m]: looks active and up to date, thanks. Do you recommend the full DK board, or should i work with the Seeed Studio XIAO nRF52840?
<lanre[m]>
i also don't want to fry anything expensive
<JamesMunns[m]>
I'd definitely recommend the DK, or another board that has a "debugger" on board, this will make learning and developing much easier. Both the microbit and the DK have this, but the XIAO doesn't.
<lanre[m]>
JamesMunns[m]: is this debugger a UART console (sorry i have no clue what that means)?
<JamesMunns[m]>
Yeah! So Cortex-M chips have what's called a "SWD" or "Single Wire Debug" port: if you've heard of "JTAG" before, it's like that.
<JamesMunns[m]>
This lets your PC reprogram, or peek into the memory of the microcontroller. In Rust, we usually use this for programming the chips, and then getting logs back, or even using GDB to do "single step" debugging, being able to run one line of code at a time and peek into the memory of the chip to see what it is doing.
<JamesMunns[m]>
This is really useful when your code crashes, which happens a lot when you are learning! If you don't have a debugger, it usually just stops running and you don't know why. With a debugger, you can get the exact reason why, and figure out where your code crashed.
<JamesMunns[m]>
(those boards ALSO usually have a UART console through the debugger, and a "virtual console" you can use for logs)
<JamesMunns[m]>
which means less external hardware to wire up :)
<JamesMunns[m]>
Having an SWD debugger (like the one that comes on the DK), lets you use tools like https://probe.rs/ which makes programming the chip really easy
<JamesMunns[m]>
and by the way, most STM32 boards like the Discovery or Nucleo boards will also have a debugger on board like this as well!
<lanre[m]>
so SWD is not the USB interface?
<JamesMunns[m]>
(but a lot of the cheaper dev boards, or boards from Adafruit or Sparkfun won't, unfortunately)
<JamesMunns[m]>
nope! It's a different interface. the DK has two USB ports on it:
<JamesMunns[m]>
one for the debugger, and one that is wired up to the nRF52
<lanre[m]>
okay i better start reading then, thank you so much!
<JamesMunns[m]>
Definitely feel free to ask questions here, there are lots of people that can help :)
<JamesMunns[m]>
not sure, I haven't actually used talc, I just looked at it and it seemed cool
<SbastiendHerbais>
I could just use a static mut that is linked into a new section for it, but it means i would need to modify probe-rs again
pbsds3 has quit [Ping timeout: 244 seconds]
Avery[m] has joined #rust-embedded
<Avery[m]>
So I am wanting to attempt to use CAN to a global logger for defmt. But I can already tell that I am probably going to run into ownership issues because I would also like to use the peripheral for messages other than just logging. How might I go about dealing with this?
<Darius>
put the messages on a queue?
<Darius>
then the thing reading from the queue is all that needs to own the CAN peripheral
pbsds3 has joined #rust-embedded
<Avery[m]>
That could be a solution if I run into issues, I've done it before in embassy (I'm using RTIC for this project) , but the peripheral already has a fifo built in. I'd end up having issues with a queue or a channel. I'm unsure how to get it from initialization to the defmt trait implementation
PedroFerreira[m] has quit [Quit: Idle timeout reached: 172800s]
<ryan-summers[m]>
Avery: I did this with USB for a project where the USB is also used for a serial terminal. Check out https://github.com/quartiq/booster/blob/main/src/logger.rs. I used an MPMC queue for the log entries and then passed in the USB periodically for processing the queued logs
<MathiasKoch[m]>
ryan-summers:
<MathiasKoch[m]>
What are my options for no-alloc solutions instead of `String` in `Path<String, ..>`? (miniconf)
<thejpster[m]>
Today I got timer interrupts working on a Cortex-R system and by jove it’s tricky doing it from scratch without cortex-m and cortex-m-rt to help.
<thejpster[m]>
I even got ThreadX running on top of my Rust code. It’s a ThreadX sandwich with Rust underneath it and Rust on top of it.
<thejpster[m]>
Also it’s completely unclear to me how to make a UART represent ownership with a PAC singleton. I ended up making the constructor unsafe.
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<SbastiendHerbais>
diondokter[m]: Bare metal for the win 😅
<thejpster[m]>
I honestly thought TheadX would have some kind of stack watermark check. But maybe that's optional and I didn't turn it on.
<thejpster[m]>
also I haven't configured a debugger that can inspect ThreadX task state. If I had that, this would have been obvious. Also I don't have defmt/rtt, so logging is really expensive.
<thejpster[m]>
If anyone knows how to do defmt/rtt from inside QEMU without using a UART, I'd love to see that. I have an idea involving semihosting and spawing defmt-print on a pty, but I haven't done it yet.
<dirbaio[m]>
what's missing is a high-level driver in embassy-stm32 (ie not raw register access)
<dirbaio[m]>
you don't need one to use LPTIM, you can always use the registers directly
<dirbaio[m]>
(but if you want to make one, PRs welcome, of course 🙃)
<SbastiendHerbais>
I'll try to make one, there are also pin assignment stuff missing iirc
<SbastiendHerbais>
Like pins for PWM outputs
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room, meeting time again! this week we're mainly focussing on discussing potential project goals that are relevant to embedded; the agenda discussion is https://github.com/rust-embedded/wg/discussions/778. please feel free to add anything else you want to discuss and if we have time left over we can get to them too. we'll start in a few mins!
<adamgreig[m]>
and do add any announcements you have too
jannic[m] has joined #rust-embedded
<jannic[m]>
I wondered if it would make sense if I joined the triage team. Should I add that question as an agenda item?
<adamgreig[m]>
sure :)
therealprof[m] has joined #rust-embedded
<therealprof[m]>
I think the triage team has kind of vanished. But we can certainly entertain giving people triage rights to shuffle stuff around a bit more efficiently.
<JamesMunns[m]>
Everyone gets busy sometimes. I'm supportive of empowering folks that are willing to help now :)
<adamgreig[m]>
ok, let's begin! does anyone have any announcements?
<adamgreig[m]>
none from me this week
jessebraham[m] has joined #rust-embedded
<jessebraham[m]>
therealprof[m]: Sorry, I had joined and then kind of disappeared for awhile. Happy to start performing my duties, but I'm not really sure what to do 😅
<jessebraham[m]>
Is there any sort of documentation for onboarding people? Would be a good first step if not
<JamesMunns[m]>
This is a good call, and we should maybe talk about that. I think "resolve issues you can", and "raise issues in the weekly meeting you can't" is a good start, but we definitely could use docs
<jessebraham[m]>
I just feel kind of weird jumping into projects I'm not familiar with or directly involved with and using my gut you know? Haha
<jessebraham[m]>
So being able to point people to rationale behind my decisions would be nice :)
<adamgreig[m]>
yea, having even some brief docs might help make it feel easier or more sensible
<adamgreig[m]>
cool, well let's start with project goals discussion and then talk about triage team members/docs?
<adamgreig[m]>
but the gist is, the goals are a target that is agreed upon between someone interested in pushing it forward and the team(s) that would have to approve it, without a promise that it'l get merged but with at least an acknowledgement that it's something everyone involved wants to see happen
<adamgreig[m]>
the goals for 2024H2 are already set, so we're talking about things to work on in 2025H1, for which discussions begin in october
<adamgreig[m]>
(of course if we pick something now and it gets done sooner, that's great too)
<adamgreig[m]>
the goals don't have to be huge, but since we're talking about fairly long term planning and work, they're probably all reasonably significant features/changes/stabilisations, I think?
<adamgreig[m]>
so perhaps the best place to start is to see if people do have some ideas on what things embedded developers would really like to see in rust next year
<JamesMunns[m]>
I think now might be good to enumerate any long term "suboptimal" items we've had, I tried to name mine :)
<adamgreig[m]>
I checked out the last time we made a big effort to enumerate this sort of thing in 2019, and a lot of the items are in fact done now 🎉
<adamgreig[m]>
ah indeed, where "project goals" are things we'd have to work on with rust-lang, and ecosystem goals are things that happen outside of the rust project?
<JamesMunns[m]>
e.g., what things do we need rust project team support for (compiler/stdlib features). As opposed to ecosystem goals, like "we should have a good USB host stack", etc.
<adamgreig[m]>
like perhaps the "tools for mut statics" and then for us specifically probably things like the new documentation efforts
<JamesMunns[m]>
oh, another long term one I'll add to my list, "ram funcs" stuff
<therealprof[m]>
JamesMunns[m]: I don't actually recall what exactly was missing there. I know it worked somewhat.
<jannic[m]>
JamesMunns[m]: Making sure that a function in RAM doesn't internally call something in flash? That would be great!
<therealprof[m]>
Was it just ergonomics?
<adamgreig[m]>
you can put a function in ram, but there's no way to ensure all the functions it calls are also put in ram
<adamgreig[m]>
including std/core functions and methods
<JamesMunns[m]>
Yeah, it was the fact that ram functions can call non-ram functions
<jannic[m]>
And intrinsics!
<JamesMunns[m]>
including if the optimizer turned some code into a memcpy
<JamesMunns[m]>
yeah
<JamesMunns[m]>
lol
<adamgreig[m]>
they have to get inlined, or you have to have manually annotated all the functions you call to put them in ram too (not possible for things in libraries/std)
<thejpster[m]>
Just a drive by comment to say that, having written a lot of Cortex-R code lately, there’s almost zero Cortex-R examples to go on.
<thejpster[m]>
Also, showing that a function is panic free.
<adamgreig[m]>
panic-free functions and in-ram functions seem spiritually a bit similar
<therealprof[m]>
Well, my motivation for ramfunc was to get rid of the flash read WS.
<thejpster[m]>
Also it sucks that you can’t stably recompile libcore with, say, M-Profile Vector Extensions. Or double precision FPU support.
<adamgreig[m]>
yea, there's lots of good reasons to need it
<adamgreig[m]>
runtime interrupts too
<adamgreig[m]>
thejpster: that's the `build-std` stabilisation, right?
<JamesMunns[m]>
thejpster[m]: Adam did mention "stabilize buildstd", I wonder if that's a path forward, esp with the long tail of riscv attributes?
<adamgreig[m]>
yea, it feels like it might help unlock a lot of the "my target is a bit niche/my requirements are a bit specialist/the default options aren't quite right for me" customisations embedded people want
<JamesMunns[m]>
We did have soft support for doing this at RustNL
<JamesMunns[m]>
I think the response was something like "put together a proposal and we can start stabilizing things"
<JamesMunns[m]>
so I think that could be a very good candidate.
<adamgreig[m]>
yep, I understand the cargo team didn't appreciate how desirable it was and didn't have anyone working on it, but would be happy to look at proposals to get it stabilised
<therealprof[m]>
Indeed.
<therealprof[m]>
Seems like an important building block that unlock some more interesting features.
<adamgreig[m]>
thejpster: for cortex-r, what sort of thing are you thinking of? more of a wg effort to improve docs/examples/libraries?
<JamesMunns[m]>
yeah, tbh, I wonder if that's really our prime candidate to focus on
<adamgreig[m]>
i fear without individuals who are specifically motivated to work on cortex-r it won't happen by itself, but i can definitely see the appeal for a lot of industrial embedded users
<JamesMunns[m]>
adamgreig[m]: thejpster if we can get any end users or silicon vendors you know of to chime in on this, it would likely be very interesting.
<adamgreig[m]>
the function-doesn't-panic annotation seems neat too and maybe the analysis/propagation that's needed is similar to ramfunc? the former seems like it might have a lot of use outside of embedded, while ramfunc is very very embedded-specific
<JamesMunns[m]>
I know the answer is usually "it's complicated" tho
<JamesMunns[m]>
adamgreig[m]: I wonder if dirbaio has opinions here from cargo-call-stack? Tho I think that has a lot of downstream-from-llvm issues
<adamgreig[m]>
yea... i can't think of anyone i know well who's using cortex-r atm, it feels like really its own world distinct from the cortex-m users
<adamgreig[m]>
better stack analysis would also be really nice for embedded but it's probably not as interesting as the other points
<JamesMunns[m]>
I meant in term of the metadata necessary to do that kind of analysis, but there may not actually be any dots there to connect :)
<JamesMunns[m]>
* kind of static analysis, but
<adamgreig[m]>
oh sure, just pondering if it would also be a nice thing to have
<therealprof[m]>
I'm sorry, something came up, gotta run.
<adamgreig[m]>
anything else on our embedded wishlist?
<adamgreig[m]>
it does feel a bit like we've got so much recently it's hard to know what else to want... or it's been so long we've forgotten, heh
<JamesMunns[m]>
I think maybe focusing on build-std, and any second order capabilities might be a good first effort.
<adamgreig[m]>
I guess the idea of what else is in scope has narrowed a bit. it would be cool if we could have New Linker Scripts That Don't Suck And Are Built In To Rust or something
<jannic[m]>
Sorry if I missed it, but have the questions regarding how to do volatile accesses properly been resolved? And relationship between mmio and the rust memory access rules?
<adamgreig[m]>
or zig's Yea Just Build C, Whatever
<JamesMunns[m]>
jannic[m]: ohhh that's a good one
<JamesMunns[m]>
JamesMunns[m]: Amanieu suggested shaking out a "specifically mmio and none of the other use cases of volatile" interface
<adamgreig[m]>
probably as a method on pointers iirc?
<adamgreig[m]>
like read_mmio instead of read_volatile
<adamgreig[m]>
arbitrary self types would be nice for that too 🥺
<JamesMunns[m]>
For anyone who wasn't at RustNL: volatile is surprisingly poorly specified how it interacts with a lot of stuff, instead of trying to formalize all of volatile, it might be easier to say "this is a method SPECIFICALLY not for 'normal RAM addrs', e.g. you can never use it on a regular static and stuff"
<JamesMunns[m]>
this makes it much easier to say "don't optimize, doesn't interact with anything outside the Rust model, no worries on provenance", etc.
<adamgreig[m]>
(and e.g. limited to word size, whereas you can use write_volatile on a like 50kB struct pointer and who knows what will happen)
<adamgreig[m]>
yea, that seems like a great one to prioritise too
<adamgreig[m]>
iirc we talked about just introducing those as methods that are implemented in assembly in the cortex-m crate today and then consider moving into core?
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
book report tl/dr; one more week. Done with the initial edit of the existing text, currently merging Henk and Adam's chapters and working on a script for easily re-numbering chapters. Then will set up publishing/CI and merge to main. See https://github.com/BartMassey-upstream/discovery-mb2:dev for the latest stuff.
<adamgreig[m]>
sweet, good work!
<JamesMunns[m]>
adamgreig[m]: maybe worth a standalone crate so riscv can join in on the fun?
<adamgreig[m]>
either that or implement them in the riscv(-pac?) crate too?
<bartmassey[m]>
Probably a traits crate and impls of the traits in the various µc crates?
<adamgreig[m]>
perhaps easier to just have the impls in the central crate in that case
<adamgreig[m]>
like portable-atomic
<bartmassey[m]>
May have arch-specific barriers and such, so either compile features or traits I guess.
<adamgreig[m]>
it's arch-specific asm, so we'll need compile features anyway
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
adamgreig[m]: yeah, could always just feature-gate the arch-specific stuff
<JamesMunns[m]>
adamgreig[m]: dunno if it makes sense but I wonder if there could be some path to stabilizing portable-atomic or critical-section
<dirbaio[m]>
i'm not sure if you can get the "can't be reordered wrt other atomics, but can be reordered wrt other memory accesses" properties with inline asm...?
<adamgreig[m]>
they're already stable, do you mean incorporate in std?
<JamesMunns[m]>
adamgreig[m]: yeah, maybe "upstream" and not "stabilize"
<adamgreig[m]>
dirbaio: you can add fences to ensure "can't be reordered" but not sure how it would interact with reordering with other memory accesses
<dirbaio[m]>
fences would prevent all reordering
<adamgreig[m]>
which i guess is in theory desirable.. maybe?
<dirbaio[m]>
you do want to allow reordering with regular memory accesses
<dirbaio[m]>
not allowing it would hurt perf
<adamgreig[m]>
to make sure people can continue writing a DMA descriptor just after transferring ownership to the DMA engine :P
<JamesMunns[m]>
Probably good to capture this in a new issue or something and bug Amanieu again in writing :)
<JamesMunns[m]>
we might have it in the minutes from RustNL, but it was a pretty quick and off the cuff conversation
AmanieudAntras[m has joined #rust-embedded
<AmanieudAntras[m>
It's not clear what is being asked for exactly...
<dirbaio[m]>
q is: if we were to replace atomics with asm, is there a way to keep the semantics of volatile of "can't be reordered with other volatile accesses, can be reordered with regular memory accesses"
<AmanieudAntras[m>
Asm is volatile by default unless you specifically use pure.
<dirbaio[m]>
by "is volatile" you mean it allows reodering with all regular memory accesses, but not with other asm blocks?
<dirbaio[m]>
seems it doesn't allow reordering by deault
<dirbaio[m]>
s/deault/default/
<dirbaio[m]>
but adding "nomem" would allow it?
<AmanieudAntras[m>
Yes, nomem + !pure means it is volatile but not ordered with other memory accesses.
<dirbaio[m]>
ah, awesome 👍️
<adamgreig[m]>
but can we put nomem on something that reads/writes a pointer in mmio?
<dirbaio[m]>
thanks for clarifying
<JamesMunns[m]>
adamgreig[m]: (specifically addresses that are outside the abstract machine)
<dirbaio[m]>
adamgreig[m]: yea, the whole point is mmio is not "memory" according to the abstract machine, it's just IO
<adamgreig[m]>
I guess if it won't touch any AM memory then maybe it won't make a difference, yea
<AmanieudAntras[m>
nomem can't access any memory that is accessed by normal Rust. MMIO is fine as long as you don't also use normal read/write operations on that same MMIO.
<adamgreig[m]>
seems like that could work nicely then
<jannic[m]>
Related: While https://doc.rust-lang.org/std/ptr/fn.write_volatile.html does only guarantee "not be elided or reordered by the compiler across other volatile operations", does the rust compiler actually do reorder volatile accesses with non-volatile ones? Just because it would be allowed to, it doesn't mean that it does actually take advantage of the possibility.
<dirbaio[m]>
it does
<JamesMunns[m]>
also, technically ordering between atomics and volatiles is completely undefined, IIRC?
<JamesMunns[m]>
(which is why we might want fences for this, for the "make sure your DMA RAM buffer is ready before you press 'go' via MMIO")
<adamgreig[m]>
if we add fences we're back to no re-ordering, so that should probably be more something the HAL has to get right
<adamgreig[m]>
anyway we are getting a bit off-topic 😅 shall we run through the other points in the last 8min or so?
<adamgreig[m]>
adamhott, you wanted to recruit volunteers?
<adamhott[m]>
Yeah, I'd like 1-2 to review a proposal WIP
<adamhott[m]>
for a Rust Foundation Project
<adamhott[m]>
It's short doc
<adamhott[m]>
Thanks adam
<adamgreig[m]>
cool, get in touch with adamhott directly if you can help!
<adamhott[m]>
yeah send me a DM if you can
<adamgreig[m]>
ok, triage team chat, I think it's pretty uncontroversial to approve jannic joining, but shall we quickly discuss setting up some docs around it?
<JamesMunns[m]>
First job for jessebraham and jannic, set down some docs, then start living it? :p
<adamgreig[m]>
<JamesMunns[m]> "This is a good call, and we..." <- I think this isn't a bad summary
<adamgreig[m]>
hah, yea
<adamgreig[m]>
we have an ops/ folder in the wg repo so that could be a good place for something to live?
<jessebraham[m]>
Sounds good!
<jannic[m]>
Yes, I agree.
<adamgreig[m]>
I see the goal as being trying to stop open issues/PRs getting forgotten about, so a mix of closing things that can be closed, and reminding people in the weekly meetings about them when they need working on, or otherwise letting them stew a bit when that's what's needed... but maybe have a ponder and we can discuss it further next week?
<adamgreig[m]>
if you get anything together then please do pr before that though
<jessebraham[m]>
Sure, I'll at least start thinking about it
<jannic[m]>
IMHO the most important task is to go through all the issues every now and then and make sure nothing gets forgotten. Everything else (like how to label tasks) is just tooling to make that task easier.
<jessebraham[m]>
Should be able to draft something up pretty quickly I think, though
<adamgreig[m]>
finally, Folkert de Vries do you want to mention your PSA?
<adamgreig[m]>
(@jannic, just filling out the teams repo update for you, do you have a zulip ID?)
<JamesMunns[m]>
adamgreig[m]: oh, I need to do a pass on this, and I think figure out how our @\all team works
FolkertdeVries[m has joined #rust-embedded
<FolkertdeVries[m>
yeah, so Tamme and I have been working on implementing error messages and some other changes for cmse that are required for stabilization
<adamgreig[m]>
(and is there an email address you're happy to be publicly associated?)
<FolkertdeVries[m>
I think that if/when this all gets merged, we can push for stabilization
<FolkertdeVries[m>
I've also been working on naked functions (see agenda for links), another feature where I think thing are just blocked on someone doing the work
<FolkertdeVries[m>
but very useful for (among other things) embedded
<jannic[m]>
I do have a zulip account but I don't even know how zulip accounts are identified :-)
<FolkertdeVries[m>
but given that I think nobody in rust's review rotation is particularly familiar with cmse, review from actual users would be useful
<adamgreig[m]>
jannic[m]: if you view your profile, the URL is like /#user/NNNNN where NNNN is your ID
<JamesMunns[m]>
I gotta run, thanks all!
<adamgreig[m]>
Folkert de Vries: I saw the recent push on naked functions too, nice work!
<FolkertdeVries[m>
a particular restriction that the current PRs impose is no generics in the signatures of cmse-entry and cmse-call functions
<adamgreig[m]>
that's it for the meeting though, thanks everyone!
<adamhott[m]>
Thanks all!
<jannic[m]>
<adamgreig[m]> "(and is there an email address..." <- Just use jan@gondor.com. While I hate spam, this is already on all of my git commits, so it's probably a lost cause :-)
<dirbaio[m]>
OTOH it can generate better code because it will actually assume mmio accesses can't alias with regular memory, which volatile doesn't seem to. see in the "cool_*" pair of functions how it moves the load of src out of the loop
<dirbaio[m]>
but I think it'll overall be a loss, since str r0, [r1, #4] is quite common when doing multiple writes to different registers of a peripheral...
<adamgreig[m]>
aah of course, it can't optimise that
<adamgreig[m]>
that's annoying and perhaps does suggest a std read_mmio would be better?
<dirbaio[m]>
yeah
<dirbaio[m]>
I wouldn't try to roll it in our own crate
<dirbaio[m]>
but of course there's the question of how does std implement it on top of llvm
<dirbaio[m]>
I don't think "mmio write" semantics exist in llvm :D
<dirbaio[m]>
it'd have to lower it to a volatile write
<lanre[m]>
I'm trying to work with a pn532 NFC board. I've found what seems to be the only crate to interface with this board over I2C, but using it requires me to downgrade to a embedded_hal version around 0.2.6 that requires the Write and Read traits for I2Cdev, which i've seen dropped but the functions thereof still being implemented in newer versions. Is the downgrade a good idea? (i'm new)
<thalesfragoso[m]>
<adamgreig[m]> "that's annoying and perhaps does..." <- Sorry I'm late to the party, but what is the problem with write_volatile again ?
<jannic[m]>
As I understand it, write_volatile is underspecified. It's unclear what should happen if `T` is larger than what the hardware can read/write in a single memory access. It's unclear how it should interact with regular memory accesses (pointer provenance etc.). "In particular, a race between a write_volatile and any other operation (reading or writing) on the same location is undefined behavior." may be too strict for some use cases.
<jannic[m]>
(The MMIO register may actually be used to provide synchronization, like the rp2040 spinlocks. So it's intended to access the register simultaneously from multiple cores.)
<jannic[m]>
While it may be possible to solve this issues by updating the specification of read_/write_volatile, it seems desirable to make it very clear that the interface is only meant for MMIO access and is not allowed to be used on "normal" memory locations covered by the rust memory model.
<JamesMunns[m]>
<jannic[m]> "As I understand it, write_volati..." <- > <@jannic:matrix.org> As I understand it, write_volatile is underspecified. It's unclear what should happen if `T` is larger than what the hardware can read/write in a single memory access. It's unclear how it should interact with regular memory accesses (... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/UNHTmCUxNHCCSvWcyiRmjMgE>)
jxsl has quit [Ping timeout: 260 seconds]
<thalesfragoso[m]>
Hmm. Regarding tearing and ordering, I think it has been like that forever everywhere and "well understood".
<thalesfragoso[m]>
Provenance I think they want to provide a concept for unbound provenance, which I think it's the case today with int -> ptr casts.
<thalesfragoso[m]>
But you bring a good point regarding IO used for synchronization.
<thalesfragoso[m]>
Does LLVM provide any guarantees w.r.t volatiles reads/writes when the target fits the underlying word ?
<JamesMunns[m]>
It promises that the reads and writes won't be elided, and that the reads and writes won't tear
<JamesMunns[m]>
that's it, AFAIK.
<JamesMunns[m]>
oh, and that volatile accesses won't ever be re-ordered relative to each other, but with no promises wrt normal access or atomic access
<thalesfragoso[m]>
Hmm, I'm not familiar with the "won't tear" part, but the rest seems quite standard.
<JamesMunns[m]>
It'll never chop up a 32-bit read into two 16-bit reads
<thalesfragoso[m]>
If it has that guarantee, then shouldn't it be enough ?
<Jonathan[m]>
I assume there's a limit to how large a read it won't tear
<JamesMunns[m]>
Enough for what?
<Jonathan[m]>
because of hardware
<JamesMunns[m]>
Yeah, sorry, it will only not-tear up to the native word width of the platform
<thalesfragoso[m]>
JamesMunns[m]: General MMIO usage.
<JamesMunns[m]>
(and for aligned access)
<JamesMunns[m]>
yeah, the point is that MMIO is a subset of the "fuzzy set of things volatile does/doesn't do"
<JamesMunns[m]>
the goal is to make the specific guarantees of MMIO usage clear, with a dedicated interface, to allow Rust to be more clear about what does and doesn't happen
<JamesMunns[m]>
like, today, volatile is the most-right thing we have for MMIO
<thalesfragoso[m]>
JamesMunns[m]: Can rustc even do that ? I mean, it can't promise more than LLVM
<thalesfragoso[m]>
JamesMunns[m]: Why would we need inline asm ?
<Jonathan[m]>
where would such a primitive live?
<Jonathan[m]>
* primitive live? (excuse me if I missed earlier related discussion)
<JamesMunns[m]>
the suggestion is to make a crate today that achieves this with inline asm, with the potential goal of rfc-ing it upstream to live in core::ptr or so
<Jonathan[m]>
do you envision something specific to MMIO being useful except on embedded, and how does that relate to it being in core in your opinion?
<JamesMunns[m]>
Jonathan[m]: desktops also use MMIO, including linux
<Jonathan[m]>
fair enough, just not a lot in userspace AFAIK, but I might be wrong about that
<JamesMunns[m]>
not as much in userspace, but Rust is also in the linux kernel
<JamesMunns[m]>
They write drivers like we do, more or less :)
<JamesMunns[m]>
thalesfragoso[m]: IIRC it was suggested we could pick reasonable asm attributes to model the things we are and are not promising, such as nomem, which means we promise we don't touch any memory in the abstract model
<Jonathan[m]>
no for sure, and that all makes a lot of sense, I think my comment comes more the fact that for higher level programs this will never be useful, but I guess that's true for read/write volatile in a way too so that's all good tbh. Thanks!!
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
Does rust-for-linux use the volatile stuff in core::ptr or do they have their own thing?
<JamesMunns[m]>
I don't know, I would assume they use one or both of inline asm or core::ptr::x_volatile
Ninetoone[m] has joined #rust-embedded
<Ninetoone[m]>
I'm pretty new in Rust Embedded. Yeah, I found some example for STM32F3 or F4, but actually I have bought this STM32H745i disco board. Actually I want to use the audio on it. Is there any project support this or is there any process or way can convert C driver or those BSP to support a Rust development?