a2800276 has quit [Remote host closed the connection]
DominicFischer[m has joined #rust-embedded
<DominicFischer[m>
<JamesMunns[m]> "because if so that is a very..." <- Why? Shouldn't a future do nothing unless polled?
<DominicFischer[m>
<danielb[m]> "like... "You decided to join the..." <- Looks like the interrupt bit is never cleared. So the next time the interrupt is enabled, it fires immediately. (Which is why int_ena shouldn't be used for checking if a future is ready)
<danielb[m]>
<DominicFischer[m> "Why? Shouldn't a future do..." <- futures do nothing unless polled, that's part of the problem I'm facing :) but I guess your question is about **constructing** a future?
<thejpster[m]>
Ferrocene 24.08 just dropped, with a commitment to do a new release every other upstream stable release.
<thejpster[m]>
(So, every 3 months).
<DominicFischer[m>
<danielb[m]> "futures do nothing unless polled..." <- Yes, imo the constructor should be empty
<TiagoManczak[m]>
Hello there. Infineon is proposing a change to generate test documentation the same way cargo doc generates source code documentation. This is necessary for certification purposes (e.g. Common Criteria, ASPICE, EMVco) and is currently a gap in the Rust ecosystem. Would appreciate to have some input from you. https://internals.rust-lang.org/t/generating-a-documentation-for-tests/21442
<thejpster[m]>
that sounds really neat
AtleoS has quit [Ping timeout: 248 seconds]
AtleoS has joined #rust-embedded
<diondokter[m]>
<TiagoManczak[m]> "Hello there. Infineon is..." <- Oh that would be nice to have! Why not?
<diondokter[m]>
s/?/!/
eddie1o[m] has joined #rust-embedded
<eddie1o[m]>
Hello lovely people!
<eddie1o[m]>
I'd like to ask for your opinion on serving static web files (html, css, js) from an ESP32 and I know, I know esp is not a server. Currently I use Axum to serve svelte build directory gzipped and converted to a rust file like on the screenshot below. It kind of woks, but often I get OOM Errors and the esp reboots. I tried to delay the response to prevent loading everything to memory at once but it's not the best solution. Do I need
<eddie1o[m]>
to chunk bigger files and stream them, or do you know a better way?
<ryan-summers[m]>
If the files are what I think they are (const flash-based contents), I don't understand how you could be getting OOM unless they get loaded into RAM elsewhere
<ryan-summers[m]>
But yeah, if you're not chunking them, that could be a problem. You should probably send fixed sized chunks over your network interface to avoid putting everything in RAM at once
<eddie1o[m]>
the constants mentioned in the match statement are like u8 arrays like: `pub const INDEX_HTML_GZ: &[u8] = &[
<eddie1o[m]>
31, 139, 8, ....]`
<ryan-summers[m]>
Yeah, so they sit in flash, and thus you can't run out of that kind of memory during runtime (the linker will yell at you instead). If you're hitting OOM, it's likely when you're copying said files over the network interface
<eddie1o[m]>
yes, when I send a GET request to the ESP, it loads the index.html, tries to load all the *.js files and in this exact moment the ESP restarts
davidmpye[m] has joined #rust-embedded
<davidmpye[m]>
Can you limit simultaneous requests?
<eddie1o[m]>
I've tried to do this via random delays on every request, but I think there should be more proper way
<thejpster[m]>
<ryan-summers[m]> "Yeah, so they sit in flash..." <- const doesn’t go in flash, static does. const is pasted as a const expression at every usage site. Not sure what the array literal is converted to - probably rodata (like a string literal) but I guess it depends on context.
<eddie1o[m]>
Do you think changing const to static would help?
<JamesMunns[m]>
it probably depends on how Axum is implemented, honestly
<JamesMunns[m]>
if it tries to load the whole files into memory at the same time, or allows too much concurrency, you can run out of memory.
<JamesMunns[m]>
or even if they load too many chunks in memory at once, you can OOM. This is one of the challenges of using a "desktop library" on a microcontroller - they are usually written assuming the OS will handle this for you (and that you have a lot of RAM)
<ryan-summers[m]>
Yeah this is also why lots of embedded systems avoid using dynamic memory allocation, since it becomes harder to reason about at a high level to guarantee functionality (at least in my experience)
<adamgreig[m]>
ok, let's begin! couple of quick announcements: as you may have heard, our survey is live! please take it / encourage others to take it, at https://www.surveyhero.com/c/uenp3ydt, and thanks James Munns for driving it!
<bartmassey[m]>
(Was last week too, but I forgot to mention.)
<bartmassey[m]>
I will be picking a date in October to try the Book Sprint idea again, if there are people interested: please thumbs up here if you are "vaguely planning to attend"
<adamgreig[m]>
I'll be on holiday until the 8th of october so can't do the first week
<bartmassey[m]>
Good to know, thanks. Later is probably better anyhow.
<bartmassey[m]>
I need to give enough lead time that folks can schedule it in. Was the timing I chose last time the right one?
<adamgreig[m]>
time of day was generally good for me
<bartmassey[m]>
We should talk about what to do about genericizing PWM again sometime: I understand why it's not part of the current embedded traits, but I wonder what could be done about it?
<adamgreig[m]>
the hard part is "how to express time/frequency in some way that: 1) has enough resolution 2) doesn't use too big numbers 3) doesn't have loads or any generics"
<adamgreig[m]>
we had an interesting proposal for a timer trait recently that I think got closer to consensus than previous attempts
<bartmassey[m]>
There's that, which is probably copable, but there's also all the weird quirks of PWM hardware: up-count vs up-down, inversions, frequency modulation, etc
<bartmassey[m]>
It's definitely a can of worms.
<bartmassey[m]>
Why are we avoiding generics again?
<adamgreig[m]>
well, for embedded-hal the general thing is to only define runtime changes and not setup/configuration
<adamgreig[m]>
which helps avoid some number of pwm problems
<adamgreig[m]>
using generics makes it hard for drivers to actually abstract over lots of hardware, and also ends up being awkward to use, we found
<bartmassey[m]>
Anyhow, don't want to derail the meeting. We should maybe make it a future meeting topic or set up a discussion or something though.
<adamgreig[m]>
no worries, agenda's pretty light today anyway!
<adamgreig[m]>
probably the most effective thing would be an rfc proposing a pwm trait, even if it's just a gist we can discuss before it's actually posted as an rfc
<adamgreig[m]>
well, the other agenda item was indeed very quick to resolve, thanks for triaging that rmsyn! I've closed the issue
<adamgreig[m]>
anything else anyone would like to discuss this week?
<adamgreig[m]>
it sounds like we are pretty happy with the change to embedded-io, even if it doesn't land like that in std?
<adamgreig[m]>
i'd be tempted to merge the e-io change now, and maybe wait a few days to publish a new release while we see what the reaction is from rust-lang?
<bartmassey[m]>
Dang. Let's talk about it on wg-embedded-static-mut
<JamesMunns[m]>
#wg-embedded-static-mut:matrix.org for an easy link
<adamgreig[m]>
hmm
<adamgreig[m]>
I think I was gonig to suggest we could close our issue
<adamgreig[m]>
I don't think it's a "bug in rustc" any more really, it's just that "references can't be to MMIO, rust has come around to this idea in the intervening years, hopefully we'll get something else sometime or otherwise more ergonomic raw pointers"
<bartmassey[m]>
Is hoping good enough? This will be immanently a huge problem for "fixing" existing embedded code: we should have a solution and a fixing guide in place ASAP I think?
<adamgreig[m]>
the behaviour isn't changed since before rust 1.0
<bartmassey[m]>
I just spent a bunch of time trying to figure out how to do split-phase DMA buffers and have so far mostly failed.
<bartmassey[m]>
The behavior will change in 2024, tho
<bartmassey[m]>
(Which may or may not come out in 2024 😀)
<adamgreig[m]>
the behaviour of references being dereferencable?
<adamgreig[m]>
or the temporary fix to not emit it?
<bartmassey[m]>
The compiler refusing to allow references to static mut because it might cause dereference problems. Is this not the plan?
<adamgreig[m]>
sorry, I think we're talking at cross purposes
<adamgreig[m]>
387 is about how if you have a & or &mut then the compiler may insert a read any time it likes, but if that & is to MMIO that read might have side effects like clearing some bits or whatever; Rust has basically said "well don't have & to MMIO, it's memory outside rust's AM and so doesn't really make sense"
<adamgreig[m]>
however we use & to MMIO for memory-mapped structs of peripheral registers in svd2rust by default
K900 has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
ultimately we should make svd2rust default to not do that, but it's complicated for back-compat reasons, but nothing about it is changing quickly afaik
<bartmassey[m]>
Yeah, the svd2rust thing is sort of separate, but I think maybe we should push for something better even for that case. I was going to type a long comment on that today that may or may not make sense.
<adamgreig[m]>
our open issue about it is from 2019 when it was considered maybe a bug in rust that the compiler might insert these reads
<adamgreig[m]>
but I think the conclusion today is that it's not a bug, the error is having & to MMIO
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
does that implicit "maybe read" also happen with raw pointers? I don't understand how this happens with `&` and `&mut` since those are basically fat pointers
<adamgreig[m]>
it does not happen with raw pointers
slinkee[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
it happens with & and &mut because rustc marks them with the "dereferencable" attribute to LLVM, which permits it to optimise by adding reads whenever it likes
<adamgreig[m]>
(and potentially rustc can also insert writes if it wants)
<adamgreig[m]>
the solution is to just use raw pointers for MMIO, which can be done without a huge loss of ergonomics or optimality - chiptool generates such a PAC for instance - but doesn't permit the same syntax that svd2rust uses by default
<adamgreig[m]>
* is to <del>just, * just</del>only use
<rmsyn[m]>
right, there are a number of places where I'm passing references to MMIO register objects. this would seem to require a lot more usage of unsafe wrapping raw pointer access
<adamgreig[m]>
there are other ways, like a zero-sized type that wraps the peripheral object and internally performs the raw register access
<adamgreig[m]>
in fact 😅 387 is an RFC proposing a new svd2rust syntax that uses ZSTs
<rmsyn[m]>
ok, still reading through that issue. a lot to consider that I had no prior knowledge of
<bartmassey[m]>
I don't think we should close this until folks here have had time to digest everything. Glad people are looking at it.
<adamgreig[m]>
it's been open since 2019, and it's a proposal to change svd2rust which is now really outdated, I don't think it's helpful to have it open especially
<adamgreig[m]>
we should have an issue to track "don't use refs for mmio", though I thought we did and can't find it, but I don't think it should be an old RFC
<jannic[m]>
Maybe open a bug on the svd2rust repo (if there isn't any), with a link to 387 so it's easily findable?
<adamgreig[m]>
yea, I feel like there must be one though, but I can't find it...
<adamgreig[m]>
I think the summary is "rust 2024 may well keep `static mut` instead of removing it, but keep the strong lint on taking `&'static mut` from them"
<bartmassey[m]>
Thanks all: have to go now!
<adamgreig[m]>
thanks!
<adamgreig[m]>
I think let's call it there for today anyway, thanks everyone!
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<JamesMunns[m]>
Btw just got an update, survey is at 980 responses