ivmarkov[m] has quit [Quit: Idle timeout reached: 172800s]
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has joined #rust-embedded
<jannic[m]>
Are there even many discussions about the differences between HALs? To me it seems to be not too much, but too little. Not in the sense that we should argue about which team of developers does a better job, that's not the point. But a) to make the design decisions more obvious for newcomers and b) so we can learn from each other.
<Ralph[m]>
i'm not even greatly in favour of one over the other. but recently there's been a discussion about merging the `stm32*-hal`s (over in stm32-rs) and that did feel like partly religious discussions (i was just reading, not contributing).
<Ralph[m]>
if my comment could be interpreted in a negative way then i'm sorry, that was not my intention.
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
HumanG331 has joined #rust-embedded
Daniel[m] has joined #rust-embedded
<Daniel[m]>
HI there, anyone knows of a QUIC implementation for embedded preferably async to play nice with embassy?
Daniel[m] has quit [Client Quit]
Daniel[m] has joined #rust-embedded
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
danielb[m] has joined #rust-embedded
<danielb[m]>
a shot in the dark, but does defmt have a way to query the current log level?
wassasin[m] has joined #rust-embedded
<wassasin[m]>
You can query DEFMT_LOG
dngrs[m] has joined #rust-embedded
<dngrs[m]>
<danielb[m]> a shot in the dark, but does defmt have a way to query the current log level?
<dngrs[m]>
What's your goal?
<wassasin[m]>
DEFMT_LOG is the entrypoint for the macros to build the EnvFilter, so that is the source of truth for defmt itself as well
<danielb[m]>
wassasin[m]: but env filter code isn't exposed in the api and the format spec syntax is nontrivial
<wassasin[m]>
You want to check a predicate or something? I.e. "if this would be logged in this module with this level, then do X"
<danielb[m]>
yes, I'm looking for "are info logs enabled right here?"
<wassasin[m]>
I can imagine some hacky way to abuse side-effects in a log statement expression
<danielb[m]>
ok so the answer to my question is no I guess, thanks
<dngrs[m]>
danielb[m]: With what goal? Do you want an expensive expression only evaluated when it's logged or something?
<danielb[m]>
I'd like to avoid collecting bytes into a static buffer that then gets ignored
<dngrs[m]>
I think the optimizer should take care of that anyway
<wassasin[m]>
dngrs[m]: Depends on how the code is set up
<wassasin[m]>
Example: gathering persistent statistics and the like will be hard for the optimizer to eliminate
<dngrs[m]>
True
<wassasin[m]>
Sounds like an interesting addition to the defmt API anyway
<wassasin[m]>
Would still work to do a 'dummy' defmt::log! that as a side-effect sets a bool to true or something if you can have it as a runtime check
<wassasin[m]>
Personally I would make it a separate env variable to enable collecting the bytes or not
ska has joined #rust-embedded
jr-oss has quit [Ping timeout: 252 seconds]
jr-oss has joined #rust-embedded
eddie1o[m] has quit [Quit: Idle timeout reached: 172800s]
zeenix[m] has quit [Quit: Idle timeout reached: 172800s]
andar1an has joined #rust-embedded
ouilemur has quit [Quit: WeeChat 4.7.0]
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room, meeting time again! agenda is https://github.com/rust-embedded/wg/discussions/856 (thanks Ralph for setting it up), please add anything you'd like to announce or discuss and we'll start in a few minutes
<adamgreig[m]>
ok, let's start! first up about embedded-hal issue labels, sounds sensible to me, any objections to quickly adding some labels for each crate?
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
We could instead split the monorepo, I guess…
<adamgreig[m]>
don't glibly suggest such things 🤯
<bartmassey[m]>
😀😀😀
<jannic[m]>
Just in case you wonder, no tickets this week from me, I'm busy preparing for the WHY camp :-)
<jannic[m]>
So most likely I'll miss next week's meeting as well. In case someone goes to WHY as well: Let's meet there!
<adamgreig[m]>
ok, next up is the discussion about e-io/e-io-async 1.0
<adamgreig[m]>
looks like the main outstanding issues for e-io 1.0 is using core::error::Error and the name of the defmt feature/dependency version, then otherwise 1.0 sounds good, but it's a question ultimately for the libs team
<bartmassey[m]>
("WHY Camp" is un-Googleable. Link?)
<adamgreig[m]>
it's the first result when I google "why camp" though :P
<bartmassey[m]>
(I get a bunch of stuff about why kids should go to camp :P)
<bartmassey[m]>
I think with the PRs the e-io bump to 1.0 looks good. What objection should there be?
<adamgreig[m]>
no one's raised any yet :p
<bartmassey[m]>
Let's do it. 😀
<dirbaio[m]>
gave a quick look, they look good to me
<dirbaio[m]>
I can review+merge later
<dirbaio[m]>
it makes me sad it'll be inconsistent with e-hal... but it's for the better
<adamgreig[m]>
thanks!
<adamgreig[m]>
next up, we have two people joining teams, bartmassey to the arm team and zeenix to libs, both have a majority approval so I've merged them and opened https://github.com/rust-lang/team/pull/1927
<adamgreig[m]>
so, welcome 🎉
zeenix[m] has joined #rust-embedded
<zeenix[m]>
👑
* zeenix[m]
deletes the repo :P
<zeenix[m]>
on a serious note, thanks for your trust
<adamgreig[m]>
https://github.com/rust-lang/compiler-team/issues/896 has more details on what's going on in rust-lang; there's no immediate demotion of the older targets, but it's on a conveyor belt to such a decision in due course
<adamgreig[m]>
so there will be time later when they are actually on the chopping block to see if anyone actually becomes interested in keeping them tier 2
<bartmassey[m]>
Add me to the list and I'll vote for this. Or I can do it myself. I guess the question is do we want to support them all, or let the r targets drop to Tier 3 for now? I think thejpster would be stuck with them if we take them? What uses `armv7a-none-eabi`?
<bartmassey[m]>
Looks like we'd have to write some platform support pages for aarch64-unknown-none*? Not a huge deal, but some work.
<adamgreig[m]>
I think there's no interest in the big-endian targets at least
<bartmassey[m]>
For sure.
<adamgreig[m]>
aarch64-unknown-none is at least a modern target that people might reasonably want to use and in principle you can run on a modern rpi or somesuch, though i haven't personally..
<adamgreig[m]>
armv7r does at least run in an emulator but that's about it
<bartmassey[m]>
Yeah, I may be using it in a project, so I'd like to keep it.
<bartmassey[m]>
(aarch64-unknown-none)
<bartmassey[m]>
I guess aarch64-unknown-none-softfloat is a bit of a weirdo? Somebody got an easy example?
<bartmassey[m]>
Oh, nvm I'm using it right now 😀
<bartmassey[m]>
Kernel code.
<bartmassey[m]>
Always forget still nothing supports using the FPU in kernel, like it was 1980 or something.
<bartmassey[m]>
So yeah, the only priority for me is the two aarch64-unknown-none targets
<adamgreig[m]>
if you're up for putting together a target support doc with the arm team on it then I think that's all that needs to be done at this point
<adamgreig[m]>
I imagine it could look very similar to the existing thumb ones
<bartmassey[m]>
I'll add an issue marked 'good first issue' 'help wanted' and see if anyone bites. If not I'll get to it eventually.
<bartmassey[m]>
But add it where?
<bartmassey[m]>
Yes, my plan was to clone the closest existing one and lightly edit it.
<adamgreig[m]>
probably start with thumbv7em-none-eabi or something
<bartmassey[m]>
Seems reasonable.
<adamgreig[m]>
do bear in mind the decision on what targets to keep at tier 2 is for the rust-lang compiler team, it's just that without a target maintainer and platform docs those targets are almost definitely getting demoted to tier 3, whereas with them they could potentially/probably stay at tier 2
<adamgreig[m]>
I think at this point it just needs review, maybe changes, and merge, with further updates to come afterwards
<adamgreig[m]>
any other points people wanted to discuss or announce this week?
<bartmassey[m]>
I'm going to merge the new MB2 Disco Book content today. I think it's good enough that we can fix anything else in post.
therealprof[m] has joined #rust-embedded
<therealprof[m]>
bartmassey: Any progress on the book?
<therealprof[m]>
bartmassey[m]: I agree. Baby steps, no need to get everything right in one whoop.
<bartmassey[m]>
Yeah, just wanted to get it to someplace where we're happy to have people read it.
<bartmassey[m]>
I will eventually want to talk over some stuff about nrf52833-hal and microbit crates, but I think I should probably do that elsewhere…
<bartmassey[m]>
I am still considering whether we just want to move everything to embassy-nrf at some point.
<therealprof[m]>
bartmassey[m]: You do now?
<bartmassey[m]>
The DMA chapter coming up next kind of brings that all to a head.
andar1an has quit [Quit: andar1an]
<bartmassey[m]>
There's a lot of mess in DMA in the old crates.
<bartmassey[m]>
I can clean that up, and probably will, but… DMA in Embassy seems pretty friendly.
<bartmassey[m]>
Is there some reason HAL crates shouldn't re-export the Embedded HAL symbols/crates they're using? I don't know of any..
<therealprof[m]>
bartmassey[m]: Should be fine.
<therealprof[m]>
However somethings HAL support multiple E-H versions which makes that nasty.
<bartmassey[m]>
Yeah, we've got cfg for old E-H; I'm just planning to export some stuff in the modern version. Things like OutputPin disappeared in the transition, and it's annoying to have to explicitly add embedded-hal to every project just to get digital and delay
<dirbaio[m]>
<bartmassey[m]> Is there some reason HAL crates shouldn't re-export the Embedded HAL symbols/crates they're using? I don't know of any..
<dirbaio[m]>
embassy hals don't do this because they have inherent (non-trait) methods for all functionality. the idea is if the user is writing code for one chip, they don't have to use embedded-hal at all, the just use inherent methods and they show up nicely discoverable in rustdoc etc.
<bartmassey[m]>
Yeah, that's definitely a better way. I'm just trying to triage old crates, so I might get a bit lazy.
<dirbaio[m]>
i fhte hal only impls embedded-hal it's not very accessible. You go to rustdoc and see no methods, a bunch of trait impl gibberish and you have to learn you have to click on a particular one to go to the embedded-hal trait docs which lists the actual methods you can call.
<dirbaio[m]>
* if the hal only impls embedded-hal it's not very accessible. You go to rustdoc and see no methods, a bunch of trait impl gibberish and you have to learn you have to click on a particular one to go to the embedded-hal trait docs which lists the actual methods you can call.
<bartmassey[m]>
I guess I could at least put back the pre-1.0 inherent methods. It wouldn't be hard and would probably solve most of it.
<bartmassey[m]>
Yeah, no that's definitely fair. Someone should probably file a rustdoc issue to get it to be able to do the thing the OO language documentation does here.
ouilemur has joined #rust-embedded
ghostie[m] has quit [Quit: Idle timeout reached: 172800s]
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
Concur this is possibly fixable by rustdoc. Dirbaio's point has been valid for as long as I've been using rust: Trait-heavy APIs limit the utility of rust docs auto-genned part
<firefrommoonligh>
In the meanwhile, there are workarounds like explicit examples and descriptions in doc comments or elsewhere
<firefrommoonligh>
If it's a non-trait API, I can follow the constructors and public fields to figure out how to use the thing. If there's a trait, the trail stops, and I hope there are documented examples, or I will have to bother people with questions
<firefrommoonligh>
Ran into that with ESP-HAL recently