<RockBoynton[m]>
Not sure if there is a better place to ask this before making a GH issue, but has anyone notice that sometimes a panic just hangs with defmt instead of showing the panic?
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
Are you using panic_probe? Did you enable the print-defmt feature flag?
<RockBoynton[m]>
yes and yes
<RockBoynton[m]>
it works when the panic is in some places, but not in others
<GrantM11235[m]>
When it doesn't work, is it a panic in your code or in a dependency?
<RockBoynton[m]>
panic in my code. Also of note, when this happens, it doesn't print out any log statements that happen before the panic
<JamesMunns[m]>
Are you logging a lot? And is defmt configured to drop on full or block on full?
<JamesMunns[m]>
Also are you on a chip that has fancy things like caches?
emerent has quit [Ping timeout: 276 seconds]
emerent has joined #rust-embedded
<RockBoynton[m]>
yes logging quite a bit
<RockBoynton[m]>
I didn't know there was a configuration for that, where?
<RockBoynton[m]>
yes instruction and data cache stm32h7
<RockBoynton[m]>
btw James Munns: I saw your talk on postcard and postcard-rpc recently and thought it was great, really want to use it in some projects coming up... might even try to implement the wire format in Haskell
Makarov has joined #rust-embedded
Makarov85 has joined #rust-embedded
Makarov has quit [Ping timeout: 256 seconds]
<JamesMunns[m]>
<RockBoynton[m]> "yes logging quite a bit..." <- I think defmt-rtt defaults to "drop when full", probe-run used to set "block when full" at runtime when it connected, I'd have to check what probe-rs run does today.
<JamesMunns[m]>
It would also probably be good to mention which ram section your defmt block is in, and what your caching settings are, in case there's some kind of issue due to coherence or something
<JamesMunns[m]>
<RockBoynton[m]> "btw James Munns: I saw your talk..." <- Neat!
<JamesMunns[m]>
> Starting with #2326 we enable blocking RTT for defmt channels. The CLI does not, but cargo-embed and the debugger has options to configure other channels
<JamesMunns[m]>
Does `probe-rs run` do this, or only cargo embed?
<JamesMunns[m]>
(I'll ask in the issue)
<M9names[m]>
it's the default (for rtt). anything that doesn't reconfigure it should get it.
<M9names[m]>
`probe-rs run` doesn't provide any way to specify a config (as noted in the quote)
<M9names[m]>
s/rtt/defmt/
<JamesMunns[m]>
ahhhh
<JamesMunns[m]>
The CLI does not (allow for setting other modes, and just uses the default)
<JamesMunns[m]>
Thank you :)
starblue1 has quit [Ping timeout: 248 seconds]
ben[m] has joined #rust-embedded
<ben[m]>
I am currently writing a driver for a UART device and have a couple of questions. Is there a "best practice" for handling the UART port? eg. for an SPI device driver it seems like I should be taking an `SpiDevice`. Currently I am taking anything that implements the embedded_hal_nb::serial `Read` and `Write` traits, as that's what the STM32F4xx-hal currently implements.
<ben[m]>
Having said that, I guess I should probably just have some sort of `feed_byte` function instead of owning the Rx - and handle reads in a interrupt callback - but if I'm writing a stand alone driver maybe it would be ideal if you could do both and have the option?
<ben[m]>
Is there a recommended way for handling uart timeouts? Currently I am using `nb::block!` but would want to timeout if nothing is read in X seconds. Is consuming a timer with a delay the way to go? Seems to be how `ExclusiveDevice` for SpiDevice does it.
starblue1 has joined #rust-embedded
<JamesMunns[m]>
tbh, the way most people deal with timeouts IMO is using async instead of nb, and using something like embassy-time's timeout, which uses select under the hood to race the two futures, allowing for cancellation of the UART transfer if it doesn't complete in time.
<JamesMunns[m]>
for writing drivers, it sort of depends. Most things work in one of two ways:
<JamesMunns[m]>
* You have the driver be "no i/o", e.g. you pass it in slices of `&[u8]`, and it buffers or parses or does whatever it needs to do, that way it doesn't matter if someone is using async, nb, or blocking I/O: the driver doesn't care as long as you give it slices.
<JamesMunns[m]>
* You have the driver own/mutably borrow the uart, and drive the I/O itself, but that requires choosing what strategy you use for async/nb/blocking
<JamesMunns[m]>
Usually uarts aren't shared like SPI/I2C - they are usually "point to point", there's no "multiple device bus" like SPI. Sometimes you have multiplexing, but that's sorta protocol specific, and something your driver would need to handle
<JamesMunns[m]>
Additionally, uarts are different than SPI/I2C (for "controller" or "master" roles), because you don't choose when to do the transfer. Most UART hardware doesn't have (much) buffering, which means you always need to be listening, or use interrupts to buffer data to make sure none is lost.
<JamesMunns[m]>
On your desktop, the OS buffers the UART for you, so when you `read`, you get the buffered data. But on bare metal, if you aren't "listening", then you'll miss data. This is why embassy has all the various buffered UART versions that handle this for you, so as long as you process the buffered data regularly to free up space, you never miss anything
<JamesMunns[m]>
Embassy drivers are also usually set up so you can pass them EITHER an owned or mutably borrowed peripheral, so you can choose whether you pass it by ref or by value when creating the driver. This makes it much easier to reconfigure or switch which driver is owning the peripheral
<JamesMunns[m]>
also fwiw, all of the embedded-hal serial stuff has moved to the embedded-io and embedded-io-async crates for 1.0. I don't know if your hal supports that, but if it does, that's probably a good idea too.
<JamesMunns[m]>
* (much) buffering (sometimes a few bytes if the hardware has a FIFO,, * , sometimes only a single byte if it doesn't), which means, * use interrupts or DMA to buffer
<ben[m]>
Thanks James Munns that all makes sense. I'm currently using RTIC for may main application - would it be worth using the embassy hal over the stm32f4xx-hal? I didn't really look at it as I didn't think I needed to use embassy for the application.
Mark[m] has joined #rust-embedded
<JamesMunns[m]>
I can't speak to "worth it", but the embassy hal works with RTIC, for sure
<Mark[m]>
You don't have to use embassy executor/runtime to use embassy HAL
<Mark[m]>
afaik
<JamesMunns[m]>
both for async and non-async interfaces. Embassy HAL drivers pretty consistently provide both, even to things like BufferedUarts.
thejpster[m] has joined #rust-embedded
<thejpster[m]>
ah dangnabbit. The rust compiler now refuses to accept my cfg(TODO) so my training material no longer builds.
<JamesMunns[m]>
:D yeah I ran into the same thing
<JamesMunns[m]>
You can add it as a config in a build-rs tho, if you want an easy fix.
d5[m] has joined #rust-embedded
<d5[m]>
Hi, where can I find example Code for the "sp32-2432s028" like to learn how to build "UI" on this device to see may: time / date and weather ....
<d5[m]>
s/UI/ GUI /
emerent_ has joined #rust-embedded
emerent has quit [Killed (mercury.libera.chat (Nickname regained by services))]
<JamesMunns[m]>
Is it possible your code panicked immediately on boot?
<JamesMunns[m]>
probe-rs takes some time to switch between "im programming the device" and "I've connected for debugging". If you panic between those two, sometimes probe-rs goes "huh? wtf?"
<kentborg[m]>
I don't think it panicked. I can see the red LED blink and the blue one responds to my pressing SW2. And gdb can talk to it.
<kentborg[m]>
How is the core supposed to become halted? probe-rs does that through the Segger card? It isn't supposed to have started??
danielb[m] has joined #rust-embedded
<danielb[m]>
What's the expected behaviour in case I drop/forget the future returned by the async SpiBus::transfer?
<danielb[m]>
does embedded-hal have any requirements here?
<JamesMunns[m]>
danielb[m]: off the top of my head: if you never polled it, it does nothing. If you have polled it, it should stop the transfer and de-assert the CS when it is dropped. If you forget it, probably "it depends on the impl". The CS will probably stay asserted, and if it's an embassy hal the DMA transfer could lead to data corruption
<JamesMunns[m]>
We should add requirements for what to do when dropped tho.
<JamesMunns[m]>
that being said, I could also see "the future busyloops until completion or a good stopping point" being reasonable, I would probably say the requirements should be:
<JamesMunns[m]>
"by the time the future's destructor has completed running, an unspecified amount of the transaction will have completed (unspecified and up to the HAL implementation, including halting a read/write/transfer midway, or busylooping to some point in the destructor; but it is recommended that the currently active transaction step is run to completion, if possible), but it is guaranteed that no CS pins will be asserted. It is not
<JamesMunns[m]>
recommended that futures are ever forgotten, as this may lead to unsafety in some HALs."
<JamesMunns[m]>
* the requirements on drop/cancellation should be:
<JamesMunns[m]>
CC dirbaio if you have other opinions.
<JamesMunns[m]>
danielb we can add this to the agenda today if you want to.
<danielb[m]>
🤷♂️ this is an active question for esp-hal but I'm usually braindead by the time of the meetings so I'm not sure I'll be able to provide anything meaningful to the convo
<JamesMunns[m]>
IMO: this answer should be the same for all e-h-async future methods. It's not just transactions, read/write impls to i2c/spi in general could be cancelled, and we should talk about what they do on cancellation.
<vollbrecht[m]>
Yeah we should talk about this. On that note i am wondering, if we more and more "clarify" e-hal 1.0 stuff, that actually would end up making it more strict, that would technically even be a breaking change right? 🙈
<vollbrecht[m]>
i mean we still should though there can be stuff out there that would may not adopt this "patch"
<JamesMunns[m]>
idk. good to ask. IMO "clarification" might be justified as say a 1.1.x release. If you rely on that clarified behavior, you can make sure you depend on e-hal 1.1.
<JamesMunns[m]>
but I can imagine counterarguments, so maybe let's just have the conversation :)
<vollbrecht[m]>
* should though, there
<JamesMunns[m]>
IMO the only firm change in my proposal would be "you must guarantee the transfers are stopped and the CS pins are de-asserted", which IMO if you don't do is probably a bug.
<danielb[m]>
there are possible implementations (like current esp-hal) that may just finish the transfer in the background.
<danielb[m]>
and the next operation blocks until the previous one is completed
<danielb[m]>
I have slight issues with this, because this requires data to be copied to an internal buffer, but I don't want to force a change in the HAL without at least some community-wide consensus.
<danielb[m]>
* community-wide consensus toward one approach.
<dirbaio[m]>
<JamesMunns[m]> "idk. good to ask. IMO "clarifica..." <- that makes no difference, your driver will still work if you plug it into a HAL that depends on 1.0.x
<JamesMunns[m]>
<danielb[m]> "I have slight issues with this..." <- Yep. Embassy doesn't do this, which is why it isn't safe in the face of forget.
<dirbaio[m]>
so "depend on 1.1.x" doesn't guarantee HALs have read and agreed to the new terms and conditions and privacy policy
<dirbaio[m]>
so i'd just consider it a "docs bugfix"
<dirbaio[m]>
<danielb[m]> "there are possible implementatio..." <- is this for SpiBus or SpiDevice?
<dirbaio[m]>
for SpiBus it could cause misbehavior in embedded-hal-bus
DominicFischer[m has joined #rust-embedded
<DominicFischer[m>
SpiBus
<DominicFischer[m>
Ahhh the CS pin
<dirbaio[m]>
even if embedded-hal-bus takes care of deasserting CS on drop
<vollbrecht[m]>
dirbaio[m]: the counter argument is, if there exist a implementation that is build without clarification and "behaves differently"
<DominicFischer[m>
It should call flush still no?
<JamesMunns[m]>
It's hard because drop isn't async
<DominicFischer[m>
Oh, I just noticed that e-hal-bus doesn't de-assert the CS pin when the future is cancelled
<dirbaio[m]>
the current impl doesn't deassert CS on drop yeah. that IS a bug that can be fixed
<dirbaio[m]>
but there's no way to call flush from drop
<dirbaio[m]>
ugh :D
<JamesMunns[m]>
Yeah, I think we need to leave "what gets done" as unspecified, and that it may be necessary to flush.
<dirbaio[m]>
the ExclusiveDevice impl could do a flush BEFORE asserting CS the next transaction
<dirbaio[m]>
so on drop it deasserts CS
<JamesMunns[m]>
dirbaio[m]: Mandated dirty bit :p
<dirbaio[m]>
and maybe the bus keeps clocking out shit
<dirbaio[m]>
but at least that shit won't be interpreted as data by the next transaction
<JamesMunns[m]>
Then glhf if you have a minimum setup time for the CS transition :D
<DominicFischer[m>
JamesMunns[m]: At least you can document possible behaviors and/or recommendations. Similar to what e-io says about cancellation.
<dirbaio[m]>
JamesMunns[m]: if you're dropping a transaction chances are you're doing invalid stuff anyway, cutting it short. 🤷
<DominicFischer[m>
<dirbaio[m]> "but there's no way to call flush..." <- Would it be sensible to call flush in Drop but only poll it once? At least this informs the hal that stopping is desired but the caller isn't willing to wait for it.
<dirbaio[m]>
"poll once" is almost always a bug in async
<JamesMunns[m]>
DominicFischer[m: idk, I probably wouldn't do this. If we require something like this, we should add an "emergency stop" trait method
<dirbaio[m]>
an impl could require two polls to actually "start doing the flusH"
<dirbaio[m]>
s/flusH/flush/
<JamesMunns[m]>
(that isn't async, and is "optional", e.g. `fn estop(&mut self) { }`)
<dirbaio[m]>
"how many polls until the thing starts getting done" is an implementation detail
<dirbaio[m]>
if you rely on that, you're gonna have a bad time
<JamesMunns[m]>
<DominicFischer[m> "At least you can document..." <- yeah. that being said, the only thing we can really strongly recommend is to *users* (e.g. try not to cancel, make sure you call flush + don't cancel that if you cancel a read/write/transfer/transaction).
<JamesMunns[m]>
THAT BEING SAID, if we make sure embassy-hals and esp-hal fix that, we probably fix 90%+ of the ecosystem of embedded-hal-async users.
<JamesMunns[m]>
there are other async impls, but I would bet "by volume" fixing those two will fix the experience for almost all "end users".
<DominicFischer[m>
"Try not to cancel" is a bit tough especially when you're dealing with several layers of abstraction. Like what if I'm using embassy-net-wiznet on top of e-hal. Is wiznet going to tell me not to cancel my network operation because that mean it'll cancel its SPI operations? Or do drivers like embassy-net-wiznet have to offload IO to another task so their operations don't get cancelled. It'd be nice if the small number of hals
<DominicFischer[m>
solved this problem rather than the many drivers, though I appreciate coming up with a sensible contract is hard.
<dirbaio[m]>
> Or do drivers like embassy-net-wiznet have to offload IO to another task so their operations don't get cancelled
<dirbaio[m]>
embassy-net-wiznet does exactly that, so this is a non-issue
<dirbaio[m]>
net ops never synchronously call into spi stuff
<dirbaio[m]>
this is for all embassy-net drivers
GntherJena[m] has joined #rust-embedded
<GntherJena[m]>
Hi! I worked for years with C on embedded systems. Now I started with Rust after trying RTIC ended up with embassy (great hal!). I find a lot of examples on github of various projects, but my current project is somehow killing me. The problem is "global state". In the project has various components and in the system there is a configuration handler (used to load/store config from/to flash), a communication protocol, an error
<GntherJena[m]>
handler, a logger, ... . So there is some amount of data which should be written be some and read by many components. I tried two approaches: Make small static datasets and make them threadsafe with Mutex - a lot of boilerplate code rises up and every access needs the handling of the mutex (implicit or explicit). The other approach is putting everything in one big struct and have one main task receiving hardware events. The
<GntherJena[m]>
problem here is passing the struct (or parts of it around through many layers is cumbersome. What is your approach? Do you have good examples?
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
<GntherJena[m]> "Hi! I worked for years with C on..." <- This is a bit of change from embedded C for sure. In general, the approach for rust is to move state around to external components that need them (principle of locality). For the few things that actually need to be globally accessible, indeed the best approach is to have a global Singleton object that's borrowed out when needed (i.e RTIC resource). You could look at
<IvanSanchez[m]>
<GntherJena[m]> "Hi! I worked for years with C on..." <- I've gone with the `lazy_static` + `Arc<Mutex<>>` approach, plus `lazy_static`+`Arc<Mutex<Vec<mpsc::SyncSender<>>>>` to pass state changes around. Not the cleanest architecture ever, but the overhead is acceptable for my use case.
<IvanSanchez[m]>
If you're interested in looking at some code (even if it's kinda dirty): https://gitlab.com/IvanSanchez/solanera . There's like 8(?) modules, each with their own bit of state and their own MPSC queue.
<AlexandrosLiarok>
<GntherJena[m]> "Hi! I worked for years with C on..." <- I wrote https://crates.io/crates/fieldset to help me with the state management. You derive fieldset for a set of mutually referenced struct types and it basically provides you with 1) an enum that corresponds / focuses to each struct field nd 2) A set of bounded-space iterable collections of this enum which you can treat as the original struct. So you write to some
<AlexandrosLiarok>
fields, the changes are appended to the collections and then you can iterate through them and propagate the changes to other subsystems.Most subsystems end up having a handle_param_change method but you can also pass the original full parameter struct for full syncs and retrievals.
<AlexandrosLiarok>
It is a bit unpolished yet but I use it successfully for my synthesizer project and there is a ton of things going on, internal preset loads/saves/imports/exports, internal & external controllers for the same parameters etc.
<GntherJena[m]>
<ryan-summers[m]> "This is a bit of change from..." <- quartiq/stabilizer and quartiq/booster are golden and might be the most comprehensive open source projects I found. It gave me a clue how to work with presistent configuration. Unfortunatly there are not that many moving parts - in my system I will have ~50 parameters of great variety. Anyway, big thumbs up on those projects.
<GntherJena[m]>
<IvanSanchez[m]> "I've gone with the `lazy_static`..." <- > <@IvanSanchez:matrix.org> I've gone with the `lazy_static` + `Arc<Mutex<>>` approach, plus `lazy_static`+`Arc<Mutex<Vec<mpsc::SyncSender<>>>>` to pass state changes around. Not the cleanest architecture ever, but the overhead is acceptable for my use case.
<GntherJena[m]>
> If you're interested in looking at some code (even if it's kinda dirty): https://gitlab.com/IvanSanchez/solanera . There's like 8(?) modules, each with their own bit of state and their own MPSC queue.
<GntherJena[m]>
It's a nice option to have `std` on ESP32. I work with STM32 and does not have `std`. I will have a look at it this evening. I miss a good source code search on gitlab.org (searching for code parts on all open source projects on gitlab.org). Github has a code search, although I'm missing some basic features there. I'm sure there would be some good projects on gitlab.org .
<vollbrecht[m]>
github is so slow these days. I just clone the repo and use ripgrep and have a much nicer overall experience with it :D
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
For PC software, I always go with the big struct. For embedded, it depends. My gut says for complicated global state, still go with the big struct, and split things out of it on a case-by-case basis. (For performance/concurrency etc reasons).
<firefrommoonligh>
I have a reasonably complicated rust embedded project (drone flight controller firmware). I went with the split state, with individual RTIC locks, and the access code is messy.
<firefrommoonligh>
<GntherJena[m]> "Hi! I worked for years with C on..." <- Either using RTIC, or macros to assist with Mutex unwrapping. You've indeed indentified the big choice: One big global state struct, or multiple smaller ones with their own locks.
<vollbrecht[m]>
* github is so slow these days. I just clone the repo and use ripgrep and have a much nicer overall experience with it :D Edit: ah i think i misunderstood you, if you want to query a specific thing against all the repos at the same time
<vollbrecht[m]>
* github is so slow these days. I just clone the repo and use `ripgrep` and have a much nicer overall experience with it :D
<vollbrecht[m]>
Edit: ah i think i misunderstood you, if you want to query a specific thing against all the repos at the same time cloning is not an option
<GntherJena[m]>
<AlexandrosLiarok> "I wrote https://crates.io/crates..."; <- Had a quick look at it and I'll need some time to wrap my head around. I like the functional approach, but I'll need some time to see, how an application will be implemented using fieldset.
<JamesMunns[m]>
Hello @room ! It's about that time, grab a beverage, and if you have any agenda items to add or announcements to share, nows the time!
<diondokter[m]>
Oh hey all! Joining in from Antwerp today 😁
<JamesMunns[m]>
Okay! Let's get started. Any announcements folks have?
<JamesMunns[m]>
maybe one from me, I think we've gotten most of the matrix rooms in rust-embedded universe under the same moderation bots, if anyone has a room that is not covered and would like to be, feel free to ping me or we can discuss after the meeting
<JamesMunns[m]>
(specifically embedded rust rooms that are vaguely affiliated, not personal rooms)
<bartmassey[m]>
I'll be running an intro embedded Rust workshop at GOSIM in Beijing in October, on MB2s. If anybody has any advice or wants to help with curriculum, or will be there and wants to help run the thing, that would be great.
<bartmassey[m]>
(I'll also be giving a talk on why embedded is the next big thing in Rust education. So there's that.)
<JamesMunns[m]>
But the general point is we don't have guidance for this, either for impls or users.
<danielb[m]>
I don't think "whether" is the question here, I think we should - behavioural consistency across HALs is never a bad thing if they implement the same interface
<JamesMunns[m]>
Additionally, if we DO add more constraints, whether adding/refining/clarifying these requirements is a breaking change, or how we handle this.
<diondokter[m]>
bartmassey[m]: Cool! I've been giving training with them today. Just make sure to give proper instructions for Windows. For some reason the debug probe shows up twice which makes probe-rs unsure which one to use. So you must instruct the user to add the debug serial to the config.toml where the runner is set up
<diondokter[m]>
s/debug/usb/
<bartmassey[m]>
diondokter[m]: Good to know, thanks!
<bartmassey[m]>
Do the traits need to be unsafe if forgetting is unsound?
<JamesMunns[m]>
Not sure if any of the HAL team members are here to discuss, I think this probably goes into a tracking issue in the e-hal repo, but wanted to give a chance to discuss now if there were opinions
<JamesMunns[m]>
bartmassey[m]: that is a very good and long question :)
<JamesMunns[m]>
The official answer is "yes", but embassy says "no"
<danielb[m]>
ergonomics also says no
<JamesMunns[m]>
don't necessarily want to litigate that point right now
<jannic[m]>
I think both are wise choices :-)
<JamesMunns[m]>
but it IS something we should recognize and discuss wrt our guidance.
<bartmassey[m]>
Check
<JamesMunns[m]>
any other things that should definitely be mentioned, or should be noted in the tracking issue? And any volunteers to make that issue if you have a moment now?
<bartmassey[m]>
Score one for linear types over affine types.
<JamesMunns[m]>
(I'm pretty sure the consensus is we SHOULD add guidance, like danielb said, probably more to discuss on the details, and what we do and don't require, but most folks seemed pretty on board with the big picture today)
<jannic[m]>
Regarding mem::forget I'd go a pragmatic route, even if it means sacrificing some consistency: Documentation shouldn't exactly endorse that unsoundness, but acknowledge that some implementations made that choice, and that users should therefore avoid forgetting futures.
<diondokter[m]>
Yeah this is something that we really do need more language support for.
<diondokter[m]>
So +1 from me for just adding guidance from me
<JamesMunns[m]>
Last call for e-h-async guidance notes? or tracking issue volunteers?
<bartmassey[m]>
Yeah. So I'd like to add deprecations to the previous edition of the Discovery books, and remove the scary warnings on the new edition.
<bartmassey[m]>
I haven't heard any complaints about the new edition. Does anyone mind?
<JamesMunns[m]>
bartmassey[m]: Gotcha! Any blockers you think to calling the mb2 the "current" and marking the older ones as "legacy"?
<JamesMunns[m]>
I haven't gotten caught up with the current material, do you think we could/should have that review/impl party before we do that? Or is that okay to do afterwards?
<bartmassey[m]>
Nope. The only issue is that we will not have current STM or MB1 editions of the book. But I think we decided that's OK.
<bartmassey[m]>
I'm good either way. The issue is that right now we're getting PRs against the previous addition, and I'm hand-merging them as appropriate.
<bartmassey[m]>
I'm kind of surprised that PRs came alive suddenly, but here we are…
<JamesMunns[m]>
One thing to note is that we do publish our books as part of the main rust bookshelf
<JamesMunns[m]>
we may want to PR the new book to that.
<bartmassey[m]>
PR the new book in and the old ones out, presumably.
<bartmassey[m]>
Yeah, update docs.r-e was the main plan.
<bartmassey[m]>
I still want to do a book sprint day, but the dates keep getting pushed back by things.
<bartmassey[m]>
Anyone have other thoughts and/or feelings, especially objections to moving forward?
<JamesMunns[m]>
Might be good to write up your todo list in an issue? But I don't have any blockers
<JamesMunns[m]>
especially if you're going to turn around and teach it in person, that's a pretty good test run :)
<bartmassey[m]>
Also, the changes are mostly not hugely substantive at this point: lots and lots of stuff, but not so much new material and not a dramatic amount of restructuring so far. So no surprises are really expected.
<bartmassey[m]>
The biggest surprise is probably that you can build all the example code by typing "cargo build" at top-level now. 😀
<bartmassey[m]>
K I'll move forward with this this week sometime. Lmk right away if something seems wonky and I'll fix it.
<jannic[m]>
And it's not like the old book is suddenly gone. It's just that the new one will be the one being promoted.
<JamesMunns[m]>
If you need support, feel free to shout!
<JamesMunns[m]>
Nick Stevens or Ryan Kurte are your go-tos for the rust-embedded.org page
<JamesMunns[m]>
Okay, thank you! Up next, I wanted to give a brief mention re: the survey
<JamesMunns[m]>
We closed the survey on Thursday, and ended up with 1346 responses. Thank you to everyone who took and shared it!
<JamesMunns[m]>
I have a PDF and some CSVs with all of the responses, now we need to figure out how to publish this data, and to review and maybe summarize a bunch of the "open response" questions
<bartmassey[m]>
Thanks huge for running it! That's a great return rate for something this niche: impressive.
<JamesMunns[m]>
If there are any volunteers, or thoughts on how we publish this, let me know!
<JamesMunns[m]>
I'm going to trickle some screenshots of charts - I'd share the PDF but I'd like to do a pass to ensure there is no personal info in any of the free responses
<diondokter[m]>
Do we know anyone in the Rust project/foundation who led their effort? Maybe they've got advice
<bartmassey[m]>
I think we should probably try to organize a work meeting to try to get a report together. With three or four of us we can probably do this in a few hours.
<JamesMunns[m]>
(okay I think that's all the charts)
<JamesMunns[m]>
bartmassey[m]: For reference, there are 132 pages of the PDF :D
<diondokter[m]>
Lots of interesting things here! Only 60% use probe-rs? More people use ATSAM than I expected. ESP going strong!
<JamesMunns[m]>
diondokter[m]: The survey team did mention they could generate word clouds from the free responses, but there are definitely some typos and inconsistencies.
<bartmassey[m]>
JamesMunns[m]: I'm imagining a 5-page executive summary as the report, with the sanitized giant PDF as an appendix?
<JamesMunns[m]>
bartmassey[m]: yep, could work!
<JamesMunns[m]>
for reference, the PDF free answers look like this:
<jannic[m]>
I guess you had a look at the free-form responses. How is your impression, is it mostly repeating the same things, or a lot of different answers?
<JamesMunns[m]>
:D
geky[m] has joined #rust-embedded
<geky[m]>
People with heaps :P
<geky[m]>
That looks parseable with a bit of grep/awk work
<JamesMunns[m]>
Yeah, the CSV is going to be much easier to work with. I think a couple of hours with some duct tape scripting is probably reasonable
<bartmassey[m]>
Unless there is something unexpected or remarkable in the free-form responses, I don't think they need to make it into the report at all…
<JamesMunns[m]>
I just maybe want to do the aggregation and cleanup. I think we're good to share even the raw results, as long as we check. I know one person put their email address in a free response form
<geky[m]>
If you want help with the scripting let me know, I like scripting
<bartmassey[m]>
Yeah, will definitely need to be sanitized, for privacy and for gross stuff.
<JamesMunns[m]>
So: we still have some agenda items, but:
<JamesMunns[m]>
If you are interested in this, and at least for the first pass, maybe limited to wg members, tho other analysis will be welcome once we publish the filtered raw data.
<JamesMunns[m]>
(I think that got discussed a meeting or two ago?)
<JamesMunns[m]>
But if there are cortex-m/risc-v/hal members around, it might be good to chime in there.
<JamesMunns[m]>
If we want to schedule a longer discussion on that for next week, +1 from me.
<diondokter[m]>
I thought the conclusion was that it was not needed, but also doesn't necessarily harm anything
<bartmassey[m]>
We discussed related stuff last meeting, but I think we need to get somebody to capture things in some definitive document. It's all quite confusing.
<jannic[m]>
The TL;DR seems to be: Nobody knows for sure if UnsafeCell (or MaybeUninit) is needed, but the gain of removing it is minimal, and so nobody feels like just removing them would be worth the risk.
<diondokter[m]>
Oh wait, no it added an extra instruction somewhere
<jannic[m]>
Yes, I found a case where a single load gets optimized away if we remove the UnsafeCell.
<jannic[m]>
Not sure if it is something that happens in practice.
<JamesMunns[m]>
k, I will add this to the agenda for next week, could y'all help me ping HAL team members?
<JamesMunns[m]>
If anyone has time to look, or permissions to merge (if it seems reasonable), it would likely be appreciated!
<diondokter[m]>
PR looked good to me when I checked it out a while ago
<RockBoynton[m]>
<jannic[m]> "> <@rockboynton:matrix.org..." <- I was hopeful about this cause the situation you describe is what I am seeing: If I set a particular `assert` to fail, then nothing from my app is logged and it just hangs, but if I make that `assert` pass, everything logs like normal. But some other assert failures are logged no problem
<JamesMunns[m]>
k, jannic the last 9 minutes are yours for triage notes :)
<RockBoynton[m]>
But alas, setting DEFMT_RTT_BUFFER_SIZE higher didn't do it
<Ralph[m]>
JamesMunns[m]: i _think_ the only (technical) thing which is missing is that somebody changes the required builds so that the PR can be merged. and i posted a proposal on how to simplify this for the future on the meeting discussion. it's entirely unrelated to the PR but i can add it there if the maintainers would like to have that and don't want to change the settings twice
<jannic[m]>
I think the first one can be closed with a nice answer.
<jannic[m]>
The second one is a reminder that we should think about project goals if we want to be in the next batch.
<jannic[m]>
The third one probably needs more discussion, nothing we can easily solve. But as there was no activity in 4 weeks I wanted to mention it so we don't forget about it.
<bartmassey[m]>
Is there some reason not to include a Cursor implementation in embedded-hal-io? It seems harmless offhand… In general I'm always a bit skeptical of solutions that involve an "extras" thing that a lot of people may use.
<jannic[m]>
bartmassey[m]: As I understand it, the hal crates are mainly about defining an interface, not about implementing features.
<bartmassey[m]>
Ah. Fair enough. A Cursor trait does seem a little silly.
<bartmassey[m]>
Anyway sadly moving to next meeting. Thanks all!
<jannic[m]>
If there was a single obvious implementation for a Cursor, it might still be worthwhile to add it, but I fear there are trade-offs (eg. how far back the cursor can move - and where he needed storage comes from)
<JamesMunns[m]>
And an action item for opening a tracking issue for the e-h-async discussion (i'll do that now)
<JamesMunns[m]>
Okay, I think that's it for this week, thank you all, and I hope you all have a good week!
<kentborg[m]>
I might be going about it in a silly way…
<kentborg[m]>
I'm looking at debouncing a GPIO pin, My idea is something like `.wait_for_low()` (someone pushed the butteon), then `.wait_for_high().with_timeout(debounce_time)`. And do it in a loop. If the second one returns because of the timeout, then the GPIO is stable, if not, then it is still bouncing.
<kentborg[m]>
So why a closure? Wanting to be general purpose I wanted a single hunk of code that could debounce anything, or debounce any GPIO. So call this function with one closure that knows how to `wait_for_low()` on the right pin, and a second closure that knows how to `wait_for_high()` on the right pin. This function then loops on these two closures until the second one returns because of a timeout.
<kentborg[m]>
And nightly maybe isn't what I need, but #![feature(async_closure)].
henrik_alser[m] has joined #rust-embedded
<henrik_alser[m]>
kentborg: Note that you wanna wait until the bouncing has settled _before_ you wait_for_high
<JamesMunns[m]>
<dirbaio[m]> "ooo survey results, nice" <- I just realized that I should have attached these all to a GH issue instead of spamming chat 🤦♂️
<RockBoynton[m]>
<JamesMunns[m]> "Screenshot 2024-09-24 at 20.26.0..." <- very curious about the folks planning to use Cortex-R, the open source tooling seems substantially less than Cortex-M. But my team would like to use it if it was feasible
<JamesMunns[m]>
RockBoynton[m]: It'll be placed in the section that defmts linker file specifies, probably just somewhere in RAM, not sure where. You could manually place it in another memory section to verify, but it might not be that.
<JamesMunns[m]>
<JamesMunns[m]> "Attached the images here, btw..." <- Also typed up tables, in lieu of alt text :p
andar1an[m]1 has joined #rust-embedded
<andar1an[m]1>
Is there any somewhat mature firmware for esp32 in Rust for NC? I found printhor, a buddy is trying to make a cnc at home and i went down a rabbit hole lol
hingwah has quit [Remote host closed the connection]
Jubilee[m] has joined #rust-embedded
<Jubilee[m]>
huhhh, why did it show me this in red...
<Jubilee[m]>
oh, room-wide notif.
<JamesMunns[m]>
ah yeah, we do a @\room once a week for the weekly meeting
<Jubilee[m]>
np, just the web client is really bad at letting me ACTUALLY FIND A NOTIFICATION
<JamesMunns[m]>
it's like on discord when you get a message sound, but there aren't any notifications :D
<Jubilee[m]>
which feels... kinda weird... for... a notification... supposed to be easy to find...?