<michaeldesilva[m>
* I managed to recover the device, by flashing the original Mbed bootloader back, then flashing my code on top. Also the datasheet for STM32H747XI page 18 describes the need for VOS0 in the "boosted" performance mode (also needs an LDO, which the GIGA R1 WiFI board has). So I don't think it is invalid; but it does seem this power config can get corrupted (may be due to the debugger?).
<michaeldesilva[m>
* I managed to recover the device, by flashing the original Mbed bootloader back, then flashing my code on top. Also the datasheet for STM32H747XI page 18 describes the need for VOS0 in the "boosted" performance mode (also needs an LDO, which the GIGA R1 WiFI board has).
<michaeldesilva[m>
If I power cycle after burning the mbed bootloader + flashing my code, it gets unstable again. This gives me a clue to try and refer the Mbed source to see how it sets the power stage.
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
notgull has quit [Ping timeout: 272 seconds]
Guest7282 has left #rust-embedded [Error from remote client]
bibble235[m] has quit [Quit: Idle timeout reached: 172800s]
<MatthieuDartiail>
<spinfast[m]> "I use yaml and chiptool to map..." <- Thanks. Do you know if there is a documentation of the yaml format ? I could not find anything online apart from looking at the files for different boards.
SimonJohansson[m has joined #rust-embedded
<SimonJohansson[m>
Hello! I've been trying to get rtic-scope working, but when I try to install cargo-rtic-scope I get a bunch of different dependency problems. Has anyone run into the same, and managed to get it working or do I have to fix the dependencies manually?
<thejpster[m]>
just a note to say I will missing the meeting today because I'm giving embedded training to a pacific coast client, and we don't start until my 5pm.
<thejpster[m]>
But you should note I nominated t-launching-pad as a team that renews or replaces its Council rep in March and not in September (we split the teams 50/50 to avoid every having an all-out change).
<firefrommoonligh>
Now you have sunk costs because you know too much. H7s only from now on. Gl
<dirbaio[m]>
then you get shortagened, chipaggedon'd
<firefrommoonligh>
That wouldn't happen
<dirbaio[m]>
it's "once in a lifetime" risk. and it has already happened therefore we're guaranteed no chipaggedon in the rest of our lives, right? riight?? is that how probability works? D
<vollbrecht[m]>
dirbaio[m]: i wonder how many bank lockers are now full with chips destine to rod away
<JamesMunns[m]>
vollbrecht[m]: hopefully in environment controlled storage and not a bank :D
<JamesMunns[m]>
that being said: lifetime buys used to be more common, but then we got Lean :D
<adamgreig[m]>
hi @room , meeting time again! agenda is https://hackmd.io/CfejK9IDTIaLGzULJZTuug, please add any announcements or things you'd like to discuss and we'll start in a few mins
<JamesMunns[m]>
bluesky (a twitter-like social network) is now open (no more invites needed), i'm attempting to katamari as many embedded and rust people as I can there: https://bsky.app
<JamesMunns[m]>
I think that's all I got. the last two are less important :D
<adamgreig[m]>
thanks!
<adamgreig[m]>
do you want to run a rust-embedded bsky account alongside the twitter one?
<adamgreig[m]>
dunno if there's any easy xposting setup
<JamesMunns[m]>
we could make an account but we'd want to tie it to rust-embedded.org
<JamesMunns[m]>
so it's not like I'm worried about squatting
<adamgreig[m]>
yea, makes sense
<adamgreig[m]>
ok, thanks for the other announcements! I've put discussing the cortex-m point on the agenda
<adamgreig[m]>
first up, vollbrecht did you want to discuss the embedded-svc stuff?
<vollbrecht[m]>
yeah can do that.
<vollbrecht[m]>
So for you all, that are not aware of it. esp-rs had has a crate called "embedded-svc". It provides traits for common "services" around networking / storage / ota.
<vollbrecht[m]>
We recently did go through, and slimed it done a bit and we currently would like to gather feedback from the wider community on it.
<vollbrecht[m]>
We are currently reflecting on the usefulness of the crate itself and how we may change it similar, to what was done in embedded-hal
<vollbrecht[m]>
currently the traits where mostly only implemented in the esp-rs ecosystem itself ( in the no_std esp-hal and the std based esp-idf-hal)
<vollbrecht[m]>
s/where/are/, s/no_std/no\_std/
ivmarkov[m] has joined #rust-embedded
<ivmarkov[m]>
To chime-in (as being the unfortunate author of these traits) it probably makes sense to whoever is interested in the topic to reads through the (long) set of opinions in the issue ^^^ offline. It also has some touch-points with embedded-nal-async (that is, my comment in there) which is highly related, I think.
<ivmarkov[m]>
* To chime-in (as being the unfortunate author of these traits) it probably makes sense to whoever is interested in the topic to reads through the (long) set of opinions in the issue ^^^ offline. It also has some touch-points with embedded-nal-async (that is, my comment in there) which is a highly related topic, I think.
<ivmarkov[m]>
* To chime-in (as being the unfortunate author of these traits) it probably makes sense to whoever is interested in the topic to read through the (long) set of opinions in the issue ^^^ offline. It also has some touch-points with embedded-nal-async (that is, my comment in there) which is a highly related topic, I think.
<adamgreig[m]>
yea, makes sense
<adamgreig[m]>
have you found it useful in esp land to have a set of traits in one place that you implement, overall?
<adamgreig[m]>
I guess for e-h we found that a focus on cross-platform drivers helped make sense of the actual audience for the traits which helped focus on whether they were useful
<vollbrecht[m]>
The dream to have for example an OTA abstraction that could work for the user the same on for example an rp2040 as on an esp is technically still there. Though because we only currently designed that ontop of the esp ecosystem it may was to centric around it.
<vollbrecht[m]>
But practically so far it did not live up to that. That's why we want to know from other people on other hal's what they think about the idea in general and what for example would never work.
<vollbrecht[m]>
* an OTA(over, * the air update) abstraction that
<adamgreig[m]>
it might also be worth opening an issue/discussion on some of the hal repos (embassy, rp-hal, etc)
<ivmarkov[m]>
Specifically for the networking traits (if we put the non-networking ones like OTA aside for a second) my target at least has always been platform independent code. As in the ability of the app core to migrate across baremetal (with async), ESP IDF (or other mini-OS having some sort of STD+async support) and "real" STD. Both from production standpoint, as well as for app-core testing standpoint. It is just that it is unclear
<ivmarkov[m]>
(for me) if the existing traits are at the right level of abstraction. E.g. rather than migrating/using another MQTT client on STD as compared to baremetal, you can continue using the baremetal MQTT client, on STD, as long as it coded against a networking transport layer, which itself is abstracted (i.e. embedded-nal-async).
<ivmarkov[m]>
* Specifically for the networking traits (if we put the non-networking ones like OTA aside for a second) my target at least has always been platform independent code. As in the ability of the app core to migrate across baremetal (with async), ESP IDF (or other mini-OS having some sort of STD+async support) and "real" STD. Both from production standpoint, as well as from app-core testing standpoint. It is just that it is unclear
<ivmarkov[m]>
(for me) if the existing traits are at the right level of abstraction. E.g. rather than migrating/using another MQTT client on STD as compared to baremetal, you can continue using the baremetal MQTT client, on STD, as long as it coded against a networking transport layer, which itself is abstracted (i.e. embedded-nal-async).
<ivmarkov[m]>
* Specifically for the networking traits (if we put the non-networking ones like OTA aside for a second) my target at least has always been platform independent code. As in the ability of the app core to migrate across baremetal (with async), ESP IDF (or other mini-OS having some sort of STD+async support) and "real" STD. Both from production standpoint, as well as from app-core testing standpoint. It is just that it is unclear
<ivmarkov[m]>
(for me) if the existing traits are at the right level of abstraction. E.g. rather than migrating/using another MQTT client on STD as compared to baremetal, you can continue using the baremetal MQTT client, on STD, as long as it is coded against a networking transport layer, which itself is abstracted (i.e. embedded-nal-async).
<ivmarkov[m]>
It is another topic whether platform-independent app code is in itself a target worth pursuing, but if we emphasize the running of the app code on a bigger iron - for testing/emulation purposes - perhaps it is.
<adamgreig[m]>
yea, being able to abstract out the underlying drivers so you can run the app logic hosted seems useful and valuable
<ivmarkov[m]>
My point precisely. It is just what to consider "drivers" in the networking case. You can consider MQTT client, WS client etc. drivers - or you can consider the lower level networking layer - TCP, IP etc. "drivers". And then you take the HTTP client of your choice with you everywhere, as it can run everywhere - as long as the IP/TCP/UDP layer is abstracted and the HTTP client is coded against that abstraction.
<ivmarkov[m]>
* My point precisely. It is just what to consider "drivers" in the networking case. You can consider MQTT client, WS client etc. drivers - or - you can consider the lower level networking layer - TCP, IP etc. "drivers". And then you take the HTTP client of your choice with you everywhere, as it can run everywhere - as long as the IP/TCP/UDP layer is abstracted and the HTTP client is coded against that abstraction.
<vollbrecht[m]>
Because all the question marks we potentially would go the route to retire the crate itself - or at least split it into micro crates.
<ivmarkov[m]>
Of course this is the layer 5 (app layer) vs layer 3/4 discussion. There is also stuff in there (namely, the Wifi trait) which is on layer 2. And the OTA trait. Which are a bit of a different use case. But I have the feeling we should maybe bring this offline. I would personally appreciate if anybody interested in the topic spends some time checking the issue, that's all.
<vollbrecht[m]>
Yeah i think its all said for the time ;)
<adamgreig[m]>
cool, thanks for talking about it!
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
(I added infallible chipselect to the agenda again, hopefully we will have time for it)
<adamgreig[m]>
sure, let's quickly look at it first, if anyone present has anything to say about it?
<adamgreig[m]>
it seems like the PR is basically ready for review/merge so just up to the hal team now
<GrantM11235[m]>
I'm not sure what else to say about it, but as always I am happy to answer any questions
<adamgreig[m]>
looks like we only have therealprof from hal team here today, so maybe ping the issue thread?
<spinfast[m]>
question w.r.t. async hal stuff, do any of the hal's today support poll loops on peripheral registers?
<spinfast[m]>
e.g. write bytes, wait for fifo space, write more, etc type of thing
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Checking, but I never had a big opinion on SPI sharing...
<spinfast[m]>
* of thing... in a non blocking way
<adamgreig[m]>
ok, last point then, the cortex-m issue around the static mut transform being unsafe on multi-core systems where the entry point and/or interrupt handlers might be executed by more than one core
<adamgreig[m]>
s/unsafe/unsound/
<adamgreig[m]>
I think it's clear they are unsound; originally I believe the entire cortex-m/cortex-m-rt ecosystem was explicitly "single core only", the svd2rust/cortex-m Peripherals singletons were the same
<adamgreig[m]>
the latter is somewhat resolved by the modern use of critical_section but the former points not, and these days multi-core mcus are of course very popular
<adamgreig[m]>
I feel like there's a feeling we should probably just remove the static mut transform from the entry/interrupt macros, but there's a handful of people still using it and finding it useful, so there's also been a suggestion it get moved to its own crate somehow
<adamgreig[m]>
in the meantime though, perhaps more explicit documentation in c-m/c-m-rt is required?
<therealprof[m]>
That's a tough one really.
<therealprof[m]>
Documentation is really the only useful approach really.
jannic[m] has joined #rust-embedded
<jannic[m]>
IMHO if we can't make them sound, we should remove them. They are nice to have, but not nice enough to justify an unsound API (even if documented as such).
<adamgreig[m]>
we can make them sound only by saying "you can only use these on single-core systems", which isn't totally unreasonable
<jannic[m]>
Then they should at least be behind some non-default feature.
<therealprof[m]>
The problem is that Rust specifics don't allow us to properly address this for multi-core systems.
<JamesMunns[m]>
therealprof[m]: Whatcha mean?
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
We could add a marker trait in single-core hals or pacs, I think…
<bartmassey[m]>
Do the generated pacs already say how many cores?
<GrantM11235[m]>
The other problem with the static mut transorm (imo) is that it is weird and unexpected. Making it conditional based on a feature or something would only make it weirder
<therealprof[m]>
JamesMunns[m]: Well, we have no indication of whether the system is a multi-core system. Plus we can't really dynamically generate boilerplate code which runs before main.
<therealprof[m]>
If I had to guess, then I'd say that single core MCUs by far outnumber multi-core MCUs. Removing something that is sound for the majority of MCUs only because some others exist which have special needs feels wrong to me.
<JamesMunns[m]>
I sorta disagree, the expectation in rust is that without unsafe it should be sound in all cases
<GrantM11235[m]>
I would suggest: 1) remove it, 2) let people experiment with solutions in their own crates, 3) (optional) officially adopt one of those solutions
<JamesMunns[m]>
I may have argued differently a few years ago, but I don't think multi core CPUs are going away
<therealprof[m]>
JamesMunns[m]: I agree but that's besides the point.
<JamesMunns[m]>
GrantM11235[m]: Seconded
blueluna[m] has quit [Quit: Idle timeout reached: 172800s]
<jannic[m]>
Usually in rust this would be something marked as unsafe with a proper safety comment telling the user "only use this on single-core machines". Then it's the callers responsibility to opt in by actively stating that the soundness conditions are fulfilled. But I have no idea how that could be applied to the static mut transform.
<JamesMunns[m]>
jannic[m]: I would then argue that *we just shouldn't provide it*, not "oh well leave it be"
<bartmassey[m]>
How massive will the crate breakage be if this is removed?
<adamgreig[m]>
well, we already have the "critical-section-single-core" feature which is only sound on single-core devices
<adamgreig[m]>
so there is precedent for a feature that you enable to opt-in to something that only works on single-core, and doesn't have "unsafe" in the name or involve calling "unsafe" code
<adamgreig[m]>
it's hard to say - almost all the breakage will be in firmware crates, which aren't generally published to crates.io or even necessarily to github
<JamesMunns[m]>
I feel a little better with the fact it's opt in, and at least verbose with "single core", but I get that's moving towards "just vibes"
<therealprof[m]>
Ideally we'd have some more control about code before main in Rust on no-std systems and a proper solution to place global variables (and protect them if necessary).
<JamesMunns[m]>
We do, in c-m-rt?
<adamgreig[m]>
we have complete control, yea
<JamesMunns[m]>
Which is where this macro comes from
<adamgreig[m]>
but I'm not sure that's enough to know "am i single core"
<jannic[m]>
BTW, I think on rp2040 it's only an issue with #[interrupt], as '#[entry]` wouldn't be called by the second core.
<therealprof[m]>
Sorry, but the macro is a weird hack.
<jannic[m]>
* BTW, I think on rp2040 it's only an issue with #[interrupt], as #\[entry\]\ wouldn't be called by the second core.
<jannic[m]>
s/#/`#/, s/,/`,/, s/'#/`#/
<adamgreig[m]>
huh?
<adamgreig[m]>
the static mut transform is the weird hack, I don't think the macro itself is otherwise troublesome
<therealprof[m]>
That's not what I think of when saying, Rust should provide proper control of programs on no-std.
<JamesMunns[m]>
I think that's maybe a different discussion
<JamesMunns[m]>
Like, that's an abi and lang discussion we don't control
<GrantM11235[m]>
therealprof[m]: Do you mean like something that would allow `fn main()` to Just Work on embedded?
<adamgreig[m]>
I feel like removing it outright is probably going to needlessly annoy/break people who are using it, so I'm sort of tempted to suggest feature gating it so at least those people can easily opt back in
<adamgreig[m]>
but otoh it is a weird feature and we should have better ways to handle statics these days
<adamgreig[m]>
I'm not sure how ergonomic providing it from a separate crate is. I guess the separate crate would just provide its own entry/interrupt macro?
<adamgreig[m]>
but the interrupt macro currently is re-exported from c-m-rt by PACs, so you can't easily substitute it
<therealprof[m]>
JamesMunns[m]: I think it's an discussion we should have.
<therealprof[m]>
GrantM11235[m]: Yes.
<firefrommoonligh>
<adamgreig[m]> "the static mut transform is..." <- It is kind of weird b/c it silently overrides other behavior
<firefrommoonligh>
But it's great if you are aware of it...
<jannic[m]>
As the meeting already is rather long, let me quickly add one small observation from FOSDEM before everyone runs away: While both rust and embedded were quite well represented, I did see barely any embedded-rust content. And after speaking with one of the rust dev room organizers, I'm sure it would have been welcome.
<adamgreig[m]>
oops yep, that's all for today, thanks everyone!
<GrantM11235[m]>
<adamgreig[m]> "looks like we only have therealp..." <- Is there a magic spell to ping the hal team on github?
<adamgreig[m]>
yea, @rust-embedded/hal I think? or hal-team
holo[m] has quit [Quit: Idle timeout reached: 172800s]
<GrantM11235[m]>
hmm, that doesn't look like it works
sirhcel[m] has joined #rust-embedded
<sirhcel[m]>
<jannic[m]> "As the meeting already is rather..." <- I've been at embedded open source summit this year an everybody was talking about rust there as well and a presentation showing a simple project on an esp32 was so well attended that people were standing all the talk long. I did not talk to the organizers back then but i felt that a talk with a cool showcase and a related workshop would have been pretty welcomed by the attendees
<sirhcel[m]>
there as well.
<sirhcel[m]>
What about giving one at the next ocasion? How are the plans for rustnl going?
<sirhcel[m]>
* rustnl going forward?
<sirhcel[m]>
I don't feel confident for giving deep dives yet. But ready for a beginner workshop. The learning materials are already out. A crate full of devboards, some time and here we go. ;-)
<dirbaio[m]>
re the SPI PR: I'm honestly not sure what's best. there's advantages to both that we already discussed a while ago...
<dirbaio[m]>
i'm not against it but neither in favor, if that makes sense? 😅
<dirbaio[m]>
* i'm not against it but not in favor either, if that makes sense? 😅
<GrantM11235[m]>
Even if we did allow fallible chipselects with poisoning or something, I don't think we would be able to make everyone happy. There are multiple ways to do it that allow more or less opportunity to recover, with more or less overhead
<GrantM11235[m]>
Or maybe infallible chipselect would make everyone happy. Perhaps no one is actually trying to recover from chipselect errors
ithinuel[m] has quit [Quit: Idle timeout reached: 172800s]
StephenD[m] has quit [Quit: Idle timeout reached: 172800s]
<Ecco>
I have a program that works well when built in release
<Ecco>
but fails in debug
<Ecco>
is there a way to bissect to find which function messes things up when built in debug?
badrb[m] has joined #rust-embedded
<badrb[m]>
Exploring OTA updates: I'm implementing a custom MQTT transport with embassy-boot but wonder if I'm overlooking better/mature solutions.
<badrb[m]>
The Linux world has some great open-source projects that "standardised" this problem (SWUpdate, RAUC, Mender, etc.). Any advice on streamlining OTA firmware deployments?
<badrb[m]>
* that "standardised" solutions this problem
<badrb[m]>
* MQTT transport + deployment management backend with embassy-boot, * that "standardised" solutions this problem
<badrb[m]>
* with embassy-boot + deployment management backend but wonder, * that "standardised" solutions this problem, * problem (hawkbit, SWUpdate, RAUC,
<badrb[m]>
* with embassy-boot + deployment management backend but wonder, * that "standardised" solutions this problem, * problem (hawkBit, SWUpdate, RAUC,