demolemon[m] has quit [Quit: Idle timeout reached: 172800s]
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
<Ralph[m]>
<zeenix[m]> "https://toot.cat/@zeenix/1133065..."; <- interesting! out of interest: where do you host the code? there's no repo linked here, so how should people raise issues if they have questions/bugs/etc. or raise PRs to contribute?
juliand[m] has joined #rust-embedded
<juliand[m]>
<Ralph[m]> "interesting! out of interest..." <- https://github.com/jucr-io/firmware-controller I think this is it. Linking it on crates.io would make it easier to find, though
<nickez[m]>
Is it possible to deny warnings in CI builds when I have custom rust flags in the cargo config? It seems RUSTFLAGS=-Dwarning overrides my linker config
<nickez[m]>
* It seems `RUSTFLAGS=-Dwarning, * RUSTFLAGS=-Dwarning` overrides
<zeenix[m]>
<Ralph[m]> "turns out jannic already..." <- Yeah, that was an oversight, sorry. I wish cargo-publish would require repo URL in the Cargo.toml
Makarov has joined #rust-embedded
flippette[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
@room meeting time again! agenda link is ^, we'll start in a few minutes, please add anything you'd like to discuss to the link above
<adamgreig[m]>
ok, let's begin!
<adamgreig[m]>
only announcement from is me is svd2rust 0.33.5 was released just now 🎉
<adamgreig[m]>
any other announcements?
Henk[m] has joined #rust-embedded
<Henk[m]>
Yup, just another reminder: Next book sprint for the Discovery MB2 book will be on October 26, 17:00-21:00 CEST, 15:00-19:00 UTC, 8:00AM-12:00PM PST. Join if you're interested in helping to write the new discovery book! Give a thumbs up to [this comment](https://github.com/rust-embedded/wg/discussions/797#discussioncomment-10812164) to express your interest in joining.
<Henk[m]>
Henk[m]: We've got 5 people that are interested so far, so it's gonna be awesome!
<adamgreig[m]>
(lgtm btw, hopefully there's no surprise breakage :p)
<i509vcb[m]>
(I assume it would be possible to crater run just dependents of embedded-hal, but that sounds like a pain lol)
<dirbaio[m]>
tldr: it's technically breaking, but it only breaks dyn AddressMode which there's no way to usefully use, so it's almost guaranteed no one is using that
<adamgreig[m]>
doesn't seem like anyone on github has ever written that, at least
<dirbaio[m]>
thought i'd wait because iirc no one from the hal team other than me has lgtm'd therealprof ryankurte eldruin mabez
<dirbaio[m]>
if by the end of the meeting there's no objections i'll merge
<jannic[m]>
Without cargo semver-checks, nobody would have noticed the theoretical breaking nature of that change.
<dirbaio[m]>
(that's all, we can discuss async, no need to hold the meeting for this)
<dirbaio[m]>
* (that's all I wanted to say,, * , it's more like an announcement, we can
<adamgreig[m]>
looks like it's still waiting on the author to rebase to solve the clippy lint but otherwise ok?
<jannic[m]>
Not much to say about that. Request looks valid, but didn't get any reaction. I asked for the rebase less than a day ago, so no surprise that it didn't happen yet.
<adamgreig[m]>
the swap_remove_front/back methods seem kind of niche but presumably someone wanted them
<jannic[m]>
They exist in std as well.
<adamgreig[m]>
ah yep
<jannic[m]>
Then I'll write a short encouraging comment to the ticket and hope that the submitter will rebase it.
<adamgreig[m]>
sounds good, thanks! after that it's dirbaio / newam / reitermarkus to approve
<dirbaio[m]>
will review
<adamgreig[m]>
next up is https://github.com/rust-embedded/cortex-m/pull/560 by romancardenas, this looks great and we've been talking about it for a while but I haven't had a chance to review the pr itself yet, if any other cortex-m people wanna have a look please do
romancardenas[m] has joined #rust-embedded
<romancardenas[m]>
Now that the RISCV PR is about to be merged I wanted to port par of our efforts to cortex-m
<adamgreig[m]>
yea, perfect! it will be nice to have the two be better aligned
<adamgreig[m]>
fixing the CI is easy but the question is around how to handle having deps that break our MSRV
<adamgreig[m]>
as a general policy it's fine to bump the MSRV but in this case I can see the appeal of fixing the dep version instead, especially since cargo-binutils is a binary (so no one's depending on it and getting duplicate deps) and as mentioned it's packaged for things that at least presumably find it helpful to have a steady msrv
<jannic[m]>
At least for debian (the only distro I know much about...) a MSRV bump to 1.73 probably wouldn't hurt either. It was more like a general remark that sometimes MSRV bumps are really troublesome for distribution packagers.
<adamgreig[m]>
yea, fair. even if we bump the msrv now it will presumably happen again
<adamgreig[m]>
I can see the argument that if CI tests with --locked then we should also test without it occasionally, so a cron ci seems ok for that
<jannic[m]>
The scheduled CI build of master with latest allowed versions, and ideally on both stable and nightly, would also catch things like new clippy warnings.
<adamgreig[m]>
or alternatively test the msrv rust with --locked and also test stable rust without locked
<jannic[m]>
So I think it's a good idea anyway, independent from the MSRV policy.
<adamgreig[m]>
yea, true
<adamgreig[m]>
might be less noisy to have stable+beta but could start with nightly and see how it goes, it's at most one new issue a week lol
<adamgreig[m]>
what do you think about having the regular CI run msrv locked and stable not-locked?
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Nightly seems to be broken...
<jannic[m]>
I'd only include nightly if it's also part of the PR builds.
<therealprof[m]>
Bumping the MSRV sounds fine to me.
<adamgreig[m]>
yea, it's fine but we might as well get cargo.lock checked in and use it for this project I think
<adamgreig[m]>
ok, if you're happy to update that PR jannic then assuming burrbull agrees we can get it merged
<adamgreig[m]>
seems like a reasonable way forward and unblocks the other PRs too
<adamgreig[m]>
feel free to ping me when it's ready to approve
<adamgreig[m]>
anything else for this week from anyone?
<jannic[m]>
Update so we test msrv locked and stable not-locked? Can do.
<romancardenas[m]>
If no one has anything else to discuss, I wanted to ask if there is a common procedure to "rescue" unmaintained sensor drivers.
<romancardenas[m]>
I can fork it and update it, but it is already published in crates.io and it would be great if we could keep using it
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
usually, I see people rename it if they want to publish to crates.io (also with acknowledgement of the old project)
<adamgreig[m]>
in general if it's published on crates.io your only option is to try and get in touch with the original author and see if they'll let you take over the crates.io entry, even if it's from your own github fork
Makarov has quit [Quit: Client closed]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
<jannic[m]>
<adamgreig[m]> "ok, if you're happy to update..." <- Done. Not sure if it's the most elegant way to implement it on github actions, if there's a better way I'm open for suggestions.
<adamgreig[m]>
seems nice
<adamgreig[m]>
i'll give burrbull a chance to look and then yea let's get it merged, can add cron ci separately
<adamgreig[m]>
thanks!
<adamgreig[m]>
ok, I guess that's all for this meeting then, thanks everyone and see you next week!
<adamgreig[m]>
now to actually start the discussion issue for next week...
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
<Ralph[m]>
since we're past the meeting: do you have recommendations (in the best case based on personal experience) for microcontrollers which come with an ethernet connection (either directly on a dev. board or so that you can add a physical PHY (which one? any recommendations?) by just wiring it up)) for 100base-T and have Rust support? (note: WIFI is not an option)
<Ralph[m]>
* since we're past the meeting: do you have recommendations (in the best case based on personal experience) for microcontrollers which come with an ethernet connection (either directly on a dev. board or so that you can add a physical PHY (which one? any recommendations?) by just wiring it up)) for 100base-T and have Rust support? (note: WIFI is not an option)
<Ralph[m]>
EDIT: just to add: i don't need a lot of compute power (if i end up with the design where i need to do more compute i'll just take something with embedded linux on it, anyway). i saw that STM has a couple of STM32 F2,F4,F7,H7 dev. boards and i presume that these are more-or-less well supported by either the corresponding `stm32*xx-hal` or `embassy-stm32`?
<rmsyn[m]>
is SPI the fastest interface on STM32s?
<rmsyn[m]>
* on STM32s? edit: besides ethernet
<therealprof[m]>
rmsyn[m]: Uhm, not sure how to respond to that. Under which conditions?
<therealprof[m]>
SPI and Ethernet are universal but not really comparable.
<i509vcb[m]>
USB-HS with an external phy on some stm32s is probably slower
<rmsyn[m]>
like the STM32 is connected over ethernet, and you want to pass the data to another board/peripheral over some other interface
<i509vcb[m]>
Maybe the FMC could be faster in theory but thats quite some complication
<rmsyn[m]>
like SDIO is sometimes faster, do STM32s have SDIO faster than SPI?
<therealprof[m]>
Ok, for general purpose communication, probably (although still SPI and Ethernet are quite different).
<therealprof[m]>
rmsyn[m]: It's not just a matter of having fast peripherals but also how you have to feed them.
<i509vcb[m]>
I'm definitely sure you could saturate 10Mbps ethernet easily. 100Mbps ethernet you'd need DMA to get near the limits
<therealprof[m]>
It takes way more resources to assemble Ethernet frames than pumping data from RAM over an SPI peripheral.
<dirbaio[m]>
embassy-net can saturate 100mbps on tcp on stm32h7 :)
<therealprof[m]>
therealprof[m]: ... via DMA, that is.
<dirbaio[m]>
the eth peripheral on stm32 can ONLY be used with dma, they didn't even bother supporting cpu copy
<i509vcb[m]>
therealprof[m]: Do you need to assemble the frames with the SPI peripheral as well? I don't think the wiznet chips are going to be assembling L4 packets (your MCU runs a TCP stack or just uses UDP)
<i509vcb[m]>
To some extent those might only be doing L2
<therealprof[m]>
i509vcb[m]: The TCP/IP stack in Wiznet sucks big time and is very limited.
<dirbaio[m]>
the wiznet ones are the weird ones. they do have builtin tcp/ip
<dirbaio[m]>
but yeah it sucks heavily
<therealprof[m]>
You want to go raw, if you can.
<dirbaio[m]>
you can also use them in raw ethernet mode, that's what embassy-net-wiznet does
<dirbaio[m]>
so you get embassy-net / smoltcp on the mcu, like with all other eth chips
<dirbaio[m]>
even if you ignore their builtin tcp/ip stack they're still cost competitive 🤣
<dirbaio[m]>
cheaper than microchip's
<i509vcb[m]>
yeah the RP2040 EV boards are pretty cheap for the wiznet stuff
<therealprof[m]>
Which makes the point about the fastest peripheral rather moot...
<therealprof[m]>
On STM32 there're several fast peripherals, SPI, QSPI, MIPI-DSI, F(S)MC, Ethernet, USB... but which one is really the fastest depends on a lot of factors which are independent of the peripheral itself.
<Ralph[m]>
thanks everyone for your feedback!
omani[m] has joined #rust-embedded
<omani[m]>
I need an mpsc channel for my no_std lib. I asked here a while ago and `heapless` was a recommendation. it works. but I realize it is a queue, not a channel. so I get an Option back which forces me to loop. is there any kind of async channel that blocks until there is a message in the channel? or how can I turn this qeueu into an ordinary channel that blocks until a message is available so I dont have to spin the CPU?
<omani[m]>
* Option back (queue has Some, queue is empty None), which forces
Makarov has quit [Ping timeout: 256 seconds]
RockBoynton[m] has joined #rust-embedded
<RockBoynton[m]>
<omani[m]> "I need an mpsc channel for my no..." <- have you checked out https://crates.io/crates/bbq-rs? I haven't used it but heard James Munns talk about it on his and Amos' podcast and it seems like that might work for you?
<JamesMunns[m]>
RockBoynton[m]: bbqueue is a byte queue, it might be useful for sending specific types
<JamesMunns[m]>
* it might not be useful
<JamesMunns[m]>
<omani[m]> "I looked into thingbuf. but that..." <- Heapless has an mpmc queue you can use as mpsc
<JamesMunns[m]>
JamesMunns[m]: Also using embassy sync doesn't make you "depend on embassy", it's a standalone crate, it doesn't require or pull in the executor or anything.