<michaeldesilva[m>
I've found an 'odd' quirk. If I compile the below code and get the binary at speeds > 420Mhz, the file-size is pretty "invalid". What I mean by this is that a normal binary is ~138kB, but an invalid one compiles down to 11kB (at the higher speed). Obviously the latter case isn't going to run.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HqZcxnWQOIXyQcUZqnpCnkfi>)
<michaeldesilva[m>
* if I attach my debugger I can see it stepping into `defmt::println!("main");` (I've added that now, not in the screenshot previously). However `defmt::info!()` calls are "skipped" by the "step-into" process.
<michaeldesilva[m>
Also there's no output at `nc localhost 8765` - which is odd?
<Ralph[m]>
<barafael[m]> "I took the drogue mpu6050 driver..." <- > <@barafael:matrix.org> I took the drogue mpu6050 driver by Bob McWhirter and un-drogueified it (minor changes). People seem to be still interested in this quite old hardware. I just ported it to eh1.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PoSDdYPwDxcOaurgAYCBOesY>)
<JamesMunns[m]>
typenum lets you do a lot of stuff like "the output of this function has a len that's the length of this input plus this input" and stuff you can't really express with normal generics
<JamesMunns[m]>
at the cost of a certain percentage of your sanity if there's ever a type error
<MathiasKoch[m]>
So i guess my `CryptoProvider::SignatureCurve` needs a trait bound.. something along the lines of `where SignatureSize<T>: ArrayLength<u8>`
<MathiasKoch[m]>
s/T/Self::SignatureCurve/
<MathiasKoch[m]>
But these generics are making me nuts!
<JamesMunns[m]>
Can you do `type SignatureCurve: PrimeCurve + ArrayLength<u8>;`, or make your own mini trait that is like `trait Glue: PrimeCurve + ArrayLength<u8> {}` or something?
<JamesMunns[m]>
(I'm just guessing, yeah, this level of generics is... not very pragmatic and I usually bail at this point 😅)
<MathiasKoch[m]>
Issue is, its not SignatureCurve that needs to implement ArrayLength, but some struct SignatureSize wrapping my SignatureCurve :/
<MathiasKoch[m]>
`pub type SignatureSize<C> = <FieldBytesSize<C> as Add>::Output;`
<MathiasKoch[m]>
the generics within the rustcrypto stuff is super hard to follow :p
<AdamHott[m]>
Does anyone know what happened to the Rust room on Matrix? It says the conversation moved, but when I click the link it says I'm not invited?
<AdamHott[m]>
ah I have to run to the flower shop, be back in a bit
<dirbaio[m]>
I got that too but was able to join the new one
<JamesMunns[m]>
you only config for -eabi but are building for -eabihf, a different target
<JamesMunns[m]>
so, you haven't told cargo to use that memory.x for eabihf targets.
<JamesMunns[m]>
<JamesMunns[m]> "> <@michael.desilva:matrix.org..." <- (and in general, discussing "performance" without specifically stating a metric, like cpu usage, memory usage, code size, latency, throughout, etc., is sort of like asking which one is "more good" :) )
<diondokter[m]>
Maybe? But then to be nicely usable in a driver form, the user would need to impl deref to my generated struct. It would all spiral out into weird things
<dirbaio[m]>
not ncessarily?
<dirbaio[m]>
the user could store the struct in their main driver struct
<dirbaio[m]>
and do self.regs.whatever().write(...)
<dirbaio[m]>
* driver struct in a `regs` feild
<dirbaio[m]>
* driver struct in a `regs` field
<diondokter[m]>
Hmmmm. It'd force that sorta style on the user.
<diondokter[m]>
Might be ok though...
<diondokter[m]>
I'll have a think about what I want
<dirbaio[m]>
I think it's nice that "registers" and "hand-written high-level driver functions" are in different "namespaces"
<diondokter[m]>
Sure! But the way it is now you could choose to do that
<diondokter[m]>
It's not forced
<dirbaio[m]>
yeah..
<dirbaio[m]>
I don't think it's doable without proc macros tho
<dirbaio[m]>
so if you want to allow choosing you'll have to use proc macros
<diondokter[m]>
In any case, thanks for thinking along! (And James too)
<dirbaio[m]>
tradeoffs tradeoffs 🫠
<dirbaio[m]>
i've done a few drivers with the self.regs style (with a hacked up chiptool) and it's worked nice enough
<spinfast[m]>
I wish chiptool maintainer would merge my PR ;)
<JamesMunns[m]>
<spinfast[m]> "I wish chiptool maintainer would..." <- Hey you're probably trying to be funny, but comments like these sorta suck to hear as a maintainer, just fyi.
Guest7282 has left #rust-embedded [Error from remote client]
<spinfast[m]>
Indeed, I spent a good solid week on that PR and writing a driver for an audio codec to support non-memory mapped regmap generation, which was based on a branch there already. So again, meant no disrespect or hurt feelings. Was my poor attempt at a nudge to have it looked at. My mistake
<spinfast[m]>
* My mistake, and believe me when I say I do fully understand the FOSS dilemma of reviews...
<dngrs[m]>
spinfast[m]: you could ping maintainer(s) in a PR comment, asking if they need anything or just currently don't have time to look at it etc. In general I'd suggest patience. Recently had a PR merged after 9 months or so :D
<spinfast[m]>
dirbaio is the sole maintainer which is probably the issue, as he's very very busy, understandably so
<dngrs[m]>
yeah we need to clone dirbaio a few times
<dirbaio[m]>
🫠
<spinfast[m]>
Sadly I don't have a cloning machine or I'd offer my assistance readily
Guest7282 has joined #rust-embedded
<barnabyw[m]>
I’ve merged years-old PRs on projects which I never even remember making before 😅 mostly crappy PHP which I wrote as a teenager, I’m astonished that anyone found it useful enough to need to contribute anything
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room, meeting time again! agenda is https://hackmd.io/7QZ8urR_SGupDw-24zbSoQ, please add anything you want to announce/discuss and we'll start in a few mins
andar1an[m] has joined #rust-embedded
<andar1an[m]>
Is it a video meeting?
<andar1an[m]>
Can I watch somewhere?
<AdamHott[m]>
it's just chat
<andar1an[m]>
Cool
<adamgreig[m]>
pretty light agenda this week too!
<adamgreig[m]>
couple of announcements; the rustNL embedded workshop I mentioned previously is confirmed for 9-10th may (just after RustNL), I'll set up a new matrix room for people who expressed interest as that's probably the best way to organise it a bit more... I'll post about it again here when that's up
<adamgreig[m]>
and svd 0.14.8 released with a few bug fixes
<adamgreig[m]>
any other announcements from anyone?
<andar1an[m]>
Is there any recommended rust embedded YouTube channels or videos?
Guest7282 has left #rust-embedded [Error from remote client]
<adamgreig[m]>
<adamgreig[m]> "couple of announcements; the..." <- I've made this room actually, so please shout or message me if you're interested in attending
posborne[m] has joined #rust-embedded
<posborne[m]>
In mid April, I will be gone for an extended period attempting a long-distance hike and will be putting myself on hibernation leading up to that.
<andar1an[m]>
Is workshop online? Or in NL?
<adamgreig[m]>
oh cool, where are you going?
<adamgreig[m]>
I don't think we ever quite managed to get access to the AWS account set up, might be worth sorting it first if possible?
<posborne[m]>
I'll be attemping to thru hike the Pacific Crest Trail.
<adamgreig[m]>
andar1an[m]: it's just after the RustNL conference, in person in Delft
<adamgreig[m]>
nice, enjoy!
<posborne[m]>
On the AWS account stuff, I think that may be more in the domain of Nick Stevens
<adamgreig[m]>
ah OK, should be fine then
<adamgreig[m]>
are you ok to open a pr to hibernate yourself? i.e. just moving your name to the hibernating list on the wg readme list
<adamgreig[m]>
well, worry about it in april anyway
<AdamHott[m]>
I've got to run, but I've got a probe headed my way and the stm32 to test probe-rs on figure out the tooling docs
<AdamHott[m]>
that was poor english, adios!
<posborne[m]>
Yeah, I can drop a PR for that leading up to that period. It could be good to get at least one more member onto the linux team and maybe consider adding contributors with write for specific repos that are less general like meta-rust-bin.
<adamgreig[m]>
perhaps worth opening an issue on the repo to see if you can get any volunteers?
<adamgreig[m]>
the remaining item on the agenda was about https://github.com/rust-embedded/embedded-hal/issues/576 for embedded-hal driver authors, but we probably need a few hal team members here to make it worth discussing
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
I generally agree with the comments in that thread: you should propagate the full error type in your own error enum
<GrantM11235[m]>
I didn't ping the hal team last week since I don't have permissions, then I forgot 😅
<dirbaio[m]>
sorry for the silence from me, I'm like torn 50/50 on it 🤣. clarified my position in the PR.
<GrantM11235[m]>
Thanks for the comment! Out of curiosity, what is on the other side of the 50/50 for you? Poisoning or just adding a warning to the docs? Or is it 50/25/25 🤣
<dirbaio[m]>
poisoning feels too complex, no
<dirbaio[m]>
the alternative is keeping current behavior and documenting it
Atlas667 has quit [Quit: Client closed]
<GrantM11235[m]>
My impression from the other maintainers is that they are 50/50 on merging #574 vs adding poisoning
<GrantM11235[m]>
(that is a very vague impression though, it might be wrong)
<dirbaio[m]>
indicating a preference for poisoning yes
<dirbaio[m]>
what I don't like about poisoning is you cna't do `RefCell<BUS>` anymore, it now has to be `RefCell<DeviceInner<BUS>` where `DeviceInner` has the bus and the poison flag
<dirbaio[m]>
so it's one extra step everyone now has to do when constructing SPI stuff
<dirbaio[m]>
* so it's one extra step everyone now has to do when constructing SPI stuff: wrap the bus with DeviceInner
<dirbaio[m]>
even if their GPIOs are infaliible, which most are
<dirbaio[m]>
at least the "require infallible gpio" only adds an extra step if you have fallible gpios
eldruin[m] has joined #rust-embedded
<eldruin[m]>
it's a tough one. I am also unsure what would be best
<spinfast[m]>
why would thread 1 be preempted, and be able to access the same spi bus while a mutex/critical section is held on it?
<spinfast[m]>
take lock, assert cs, do spi, deassert cs, release lock
<spinfast[m]>
where is the second context coming in and attempting to do spi stuff in there?
<dirbaio[m]>
if "deassert cs" fails
<GrantM11235[m]>
If "deassert cs" fails, it still releases the lock
<spinfast[m]>
I see, its because the error is reported and dealt with outside the lock
<spinfast[m]>
isn't the usual solution using a closure for this sort of thing?
<dirbaio[m]>
closures don't work with dyn or async
mabez[m] has joined #rust-embedded
<mabez[m]>
I just left my comment in the gh thread, but there is nothing stopping the existence of PoisenCriticalSectionBus existing in the future so imo that tips me in favour of the PR, which will cover 99% of all use cases anyway
thejpster[m] has joined #rust-embedded
* thejpster[m]
is here, just got in from the Safety Critical Systems Club Party
<spinfast[m]>
tokio has async mutexes and such no? maybe I missed that history, apologies if so
<spinfast[m]>
* such no? seemingly the same pattern would be possible? maybe I
<spinfast[m]>
* such no? seemingly the same pattern would be possible with embeeded async, does this not allow closures and such? maybe I
<dirbaio[m]>
if you want to do async things inside the closure, it'd have to be an async closure. You can sort of emulate that with a closure that returns a future, but that runs into borrow checker issues really fast
<dirbaio[m]>
it was already tried, an older SpiDevice used a closure
<dirbaio[m]>
* it was already tried, an older SpiDevice design used a closure
<dirbaio[m]>
we changed into the current `&mut [Operation]` because of these issues
<dirbaio[m]>
and there's also dyn. even ignoring async, it's also a big problem with using a closure here
<dirbaio[m]>
currently you can do `&mut dyn SpiDevice`, you couldn't with the closure design
<adamgreig[m]>
even then, you could panic on the deassert-cs just after the closure finishes couldn't you?
<adamgreig[m]>
unless the closure itself has to deassert cs
<dirbaio[m]>
that too, i'm not seeing how a closure would fix the issue :)
<spinfast[m]>
I mean externalizing the serialization over the device would let you deal with this, the closure in my head didn't assert the cs
<spinfast[m]>
but right, if the older closure did that then its no different
<dirbaio[m]>
are we talking about the same bug?
<dirbaio[m]>
😅
<spinfast[m]>
right now... you do bus.transaction() and CS is asserted and deasserted here outside of a mutex/critical section
<spinfast[m]>
that's inherently the issue isn't it?
<spinfast[m]>
* right now... you do bus.transaction() and CS is asserted and deasserted here inside the function, the caller doesn't get a chance to deal with the error inside the critical section it creates
<adamgreig[m]>
the assert/deassert happens inside the CS
<spinfast[m]>
sorry yes, corrected my statement
<adamgreig[m]>
but it might return an error, and then another thread might try to assert after that, but CS is still asserted from last time (because of the error deasserting it)
<adamgreig[m]>
yea
<adamgreig[m]>
we're not going back to a closure for spi, that ship has sailed
<dirbaio[m]>
the problem is not "the caller doesn't get a chance to deal with the error inside the critical section"
<dirbaio[m]>
even if the caller could
<dirbaio[m]>
it has to eventually return
<spinfast[m]>
what about externalizing the critical section
<dirbaio[m]>
and release the lock
<adamgreig[m]>
so the PR in question just requires that the pin be infallible so this can't happen
<dirbaio[m]>
therefore releasing it with the broken CS pin stuck in high
<spinfast[m]>
I mean arguably the caller should decide what to do though at the site of the call? otherwise your kicking the can down the road
<spinfast[m]>
next caller gets to deal with a potentially poisioned spi bus
<GrantM11235[m]>
spinfast[m]: The SpiDevice trait doesn't have any way to pass in the critical section
<dirbaio[m]>
to not do that, we need either panicking, poisoning or hanging forever,. I don't see much other solution
<spinfast[m]>
poisoning sounds ugly to deal with
<GrantM11235[m]>
There was a merge conflict, I think I fixed it
<spinfast[m]>
and the error really should have been dealt with by the original call that failed to deassert
<GrantM11235[m]>
mabez: Your approval got dismissed when I fixed the merge conflict
<adamgreig[m]>
(that's all for this meeting, thanks everyone!)
geky[m] has joined #rust-embedded
<geky[m]>
Just an outsider, but the way Mutexes are poisoned on thread exit may be interesting prior art
<adamgreig[m]>
spinfast: the "caller" that has to handle the error really is the CriticalSectionDevice
<adamgreig[m]>
the device drivers calling SpiDevice methods on it are just using the normal embedded-hal API and we're not changing that (and shouldn't need to)
<spinfast[m]>
right, but it internalizes the critical section
<adamgreig[m]>
so the thing that has the CS pin and sees the failures is the *Device from embedded-hal-bus, so the question is how should it handle the error
<spinfast[m]>
and the error isn't available until its too late potentially
<adamgreig[m]>
either by requiring the pin is infallible so there can't be an error, or it could poison the bus so the next device doesn't get to use it (but that has other downsides), or other options like panicking which we rejected
<adamgreig[m]>
we can't make changes to the embedded-hal API over this, so it's just what we do to the e-h-bus structs to handle it
<spinfast[m]>
* critical section/mutex lock
<adamgreig[m]>
so there's no way to get the ultimate device driver/caller an error inside a lock
<adamgreig[m]>
and even if we did, they'd still have to leave the lock and the bus would have to somehow not work for the next caller, which is a totally different device
<adamgreig[m]>
the driver just doesn't have any context to handle the error "CS pin failed to deassert"
<dirbaio[m]>
adamgreig[m]: and there shouldn't be, the generic driver is not equipped to handle it
<dirbaio[m]>
handling it will be hardware-specific
<dirbaio[m]>
like "i'm actually using an i2c gpio expander for CS that sometimes breaks and I can unbreak it by poking the "pls unbreak" register over spI"
<spinfast[m]>
dirbaio[m]: I'd argue if this is really fallible... like a gpio expander, then its going to be application specific what should happen next
<dirbaio[m]>
ther'es no way a generic driver can do that
<adamgreig[m]>
the problem really is more "how do you handle the CS pin having an error", whether it happens in/out the critical section is a distraction
<spinfast[m]>
* gpio expander for chip select, then
<adamgreig[m]>
the application can handle it by using a custom CS pin wrapper or a custom bus sharing struct
<dirbaio[m]>
because all the generic driver knows is "I got a SpiDevice", it doesn't know the end user is actually using it with such a weird i2c gpio expander
<adamgreig[m]>
so for most applications, we can say "use e-h-bus, but it requires infallible IO pins", or "use e-h-bus but be wary if you might have an IO failure" (the current status)
<dirbaio[m]>
yeah the right way to do this would probably be putting the "poke the unbreak register" inside the OutputPin impl
<adamgreig[m]>
and "if you need to handle CS pin errors, then you have to bring in something of your own, like an io pin wrapper or your own SpiDevice impl"
<adamgreig[m]>
lol yea, "simply unbreak it, duh"
<adamgreig[m]>
make it infallible :D
<dirbaio[m]>
yeah..
<dirbaio[m]>
so
<adamgreig[m]>
so having e-h-bus require infallible probably is the best compromise then?
<dirbaio[m]>
if CS actually fails, there's no recovery possible
<dirbaio[m]>
I mean, it could bubble up to the user then the user could then take hardware-specific corrective action
<adamgreig[m]>
and for users with fallible CS pins, they need to make an infallible wrapper which either 1) does whatever hardware-specific thing is required to fix it or 2) panics and shuts everything down, sort of thing?
<spinfast[m]>
i2c bus recovery isn't unheard of
<dirbaio[m]>
but by then the lock is already released, so this might've broken another driver's trasnfer
<dirbaio[m]>
s/trasnfer/transfer/
<adamgreig[m]>
the lock's still held inside the OutputPin set_low impl that's just found the error
<adamgreig[m]>
uh, set_high
<adamgreig[m]>
spinfast: yea, maybe the CS pin is on an I²C IO expander that needs to be reset or something like that
<adamgreig[m]>
probably quite annoying to write an OutputPin wrapper that's able to reset the I²C bus when it detects a failure though, hm
<adamgreig[m]>
well, maybe not too bad
<dirbaio[m]>
yea so you shold try really hard to avoid CS failures. for example if you're doing a "reset and retry" thing you do it inside set_high().
<dirbaio[m]>
and we should document that
<dirbaio[m]>
but
<dirbaio[m]>
should we take away the ability of the OutputPin from reporting errors up if something truly unrecoverable happens?
<dirbaio[m]>
(of course documenting that all bets are off at that point)
<dirbaio[m]>
because that's what we'd be doing by requiring infallible
<GrantM11235[m]>
If you actually have fallible chipselects, you should use your own poisoning impl
<GrantM11235[m]>
we aren't taking away anyones ability to do that
<dirbaio[m]>
we're taking away the ability to do it with e-h-bus
<spinfast[m]>
should probably implement your own bus wrapper at that point
<dirbaio[m]>
granted someone can do their own
<spinfast[m]>
not use the built in criticalsection/mutex ones
<dirbaio[m]>
but I mean
<GrantM11235[m]>
Which is what they should be doing anyways, because the current impls don't handle cs failure correctly
<dirbaio[m]>
of course if your GPIO is made of jelly and you expect it to regularly fail you should use an impl that does poisoning
<dirbaio[m]>
but if you don't expect that
<dirbaio[m]>
* expect that, it's still nice to be able to propagate the error up
<dirbaio[m]>
so you can log it and panic the same way as all the other SPI errors for example. instead of getting a panic
<GrantM11235[m]>
If it is just about changing how you panic, you can write your own UnwrappingAdapter
<dirbaio[m]>
no, it's about propagating all errors to the same place and handling it there
<dirbaio[m]>
even if I write my own UnwrappingAdapter, it's still annoying to have to put the error handling there for CS, and in the top level for everything else
<dirbaio[m]>
and the "lock is already released" is not always a problem, for example with RefCellDevice you can't share it across threads, so if you synchronously handle the error you know no other thread has concurrently tried to use the broken SPI
M9names[m] has joined #rust-embedded
<M9names[m]>
<andar1an[m]> "Is there any recommended rust..." <- Best to avoid asking questions during the weekly meeting, they will be ignored to help get through the agenda (it's hard enough when we stay on topic).
<M9names[m]>
has a list of all materials we know about. If you find more, please submit a pull request.
<dirbaio[m]>
if the behavior is documented, what's the issue?
<GrantM11235[m]>
Well for starters, no one reads the docs 🤣
<dirbaio[m]>
that's their problem lol
<spinfast[m]>
GrantM11235[m]: Guaranteed the docs for such a quirky scenario would be never read, never remembered, and only referenced after someone runs into it in a rare production bug scenario
<spinfast[m]>
* bug scenario spent countless hours hunting it down
<GrantM11235[m]>
Exactly. Even If you do read the docs, will you remember all the quirks when you are refactoring your code?
<dirbaio[m]>
this is not a slient misbehavior, the impl is literally returning the CS error to the user
<dirbaio[m]>
Rust forces the user to handle it somehow
<GrantM11235[m]>
dirbaio[m]: the impl is *maybe* returning the CS error
<spinfast[m]>
It does, but the unlucky dice roll here gets you an undefined spi bus setup without something changing
<spinfast[m]>
poisoning at least says the bus is unusable now
<spinfast[m]>
* unusable now, so that's somewhat nicer
<spinfast[m]>
* unusable now, so that's somewhat nicer, the nicest behavior would be the error can be dealt with before giving up the spi bus exclusive access
<GrantM11235[m]>
GrantM11235[m]: (that is one of the many quirks)
<dirbaio[m]>
plus this change doesn't guarantee correctness either
<dirbaio[m]>
what if it's SPI flush what fails?
<dirbaio[m]>
we deassert CS whlie the SPI is still clocking out bits
<dirbaio[m]>
then another driver might assert their CS, and the bits will go to the wrong chip
<dirbaio[m]>
do we also require infallible SPI?
<GrantM11235[m]>
Can we specify that even if the flush fails, the spi needs to stop clocking bits?
<dirbaio[m]>
if we're talking to the SPI peripheral via wet wire and that fails, how do you tell it to stop clocking bits?
Guest7282 has joined #rust-embedded
<dirbaio[m]>
you can't do that
<spinfast[m]>
we should all just use isospi
<spinfast[m]>
problems solved
<dirbaio[m]>
it's the same as specifying that even if set_high() fails it must still set the pin high 🙃
<GrantM11235[m]>
dirbaio[m]: If you know how much data it has to send, you can just block for that long in `flush`
<dirbaio[m]>
SpiDevice doesn't know the SPI frequency
<GrantM11235[m]>
flush is in SpiBus
<dirbaio[m]>
ah in the HAL
<GrantM11235[m]>
We could say that SpiBus impls should block on flush, even if there is an error, and that they are responsible for any errors if they don't
<dirbaio[m]>
then flush should be infallible, but it's not
<GrantM11235[m]>
flush can still be fallible
<dirbaio[m]>
you're saying "this function signature is fallible because it returns a Result, but it should actually never ever return an Err"
<GrantM11235[m]>
If it fails, that means it might not have sent all the bytes, but it still stopped
<dirbaio[m]>
in what situation can you still talk to your SPI peripheral to force-stop it, but cannot actually do the flush?
<GrantM11235[m]>
For example a buffering wrapper might need to do some writes in flush, so it needs to be able to return an error for those
<dirbaio[m]>
it
<dirbaio[m]>
* it's incredibly rare
<dirbaio[m]>
and I don't think this is worth complicating the SpiBus contract...
<dirbaio[m]>
* and I don't think this SpiDevice implementation technicality is worth complicating the SpiBus contract...
<dirbaio[m]>
and I don't agree you can always guaratnee flush either force-stops or waits.
<dirbaio[m]>
what if you're proxying the SpiBus calls over some kind of RPC, and the connection breaks?
<dirbaio[m]>
you say "just block for the amount of time the bytes could take to be sent", but how long is that? how many bytes? the sum of all the operations in the transactioN? that could be a long time
<dirbaio[m]>
maybe only the "SPI server" knows the baudrate and didn't tell you.
<dirbaio[m]>
I think it's reasonable for flush to be allowed to completely fail and do nothing.
<dirbaio[m]>
it's the same discussion as before
<dirbaio[m]>
it really shouldn't happen
<dirbaio[m]>
but when it does, it's nice to be able to return it as a plain rust error to handle it up the stack
<GrantM11235[m]>
dirbaio[m]: If you do that, I think you just need to accept responsibility for any possible breakages
<dirbaio[m]>
what's the point of a contract if impls are allowed to not comply with it and "accept responsibiltiy" for breakages?
<GrantM11235[m]>
Impls are always allowed to not comply, we're not cops
<GrantM11235[m]>
Like with the NoDelay stuff in e-h-bus
<dirbaio[m]>
then users shold be allowed to use a fallible CS too and "accept responsibility" of the bus being in a broken state if it actually fails
<GrantM11235[m]>
In this case, the analogy would be for the user to write their own UnwrappingAdapter that just logs the error and returns instead of panicing
<dirbaio[m]>
anyway
<dirbaio[m]>
my point is
<dirbaio[m]>
it's inconsistent to say "fallible CS is not allowed, but fallible flush is allowed"
<dirbaio[m]>
because both can fuck up the shared bus equally
<GrantM11235[m]>
That adapter would be a broken OutputPin impl, but they are allowed to do it if they want
<GrantM11235[m]>
I think that fallible-and-nonblocking flush is even more rare than fallible chipselect
<GrantM11235[m]>
So the proposed PR fixes most of the problem
<dirbaio[m]>
<GrantM11235[m]> "I'm not comfortable with..." <- i'm not comfortable with fixing most of the problem :)
<GrantM11235[m]>
The remainder of the problem can be "fixed" by specifying that fallible-and-nonblocking flush is bad, and you should feel bad for doing it
<dirbaio[m]>
I don't think that's something we shuld do
<dirbaio[m]>
s/shuld/should/
<dirbaio[m]>
no other fallible trait has such requirements
<dirbaio[m]>
and people don't read the docs
<dirbaio[m]>
IMO we shold go for either practicality (so, status quo) or correctness (poisoning or infallible, for both CS and SPI)
<GrantM11235[m]>
I don't think that the status quo is any more practical than the PR
<GrantM11235[m]>
Also, we don't need the entire SPI to be infallible, just that flush can't return early. I'm pretty sure that already covers the vast majority of spi impls
<spinfast[m]>
+1 for correctness guarantees from me
<spinfast[m]>
I’ve been that person debugging that ridiculous kind of issue for a week or more. Anything to save the next person the trouble
<holo[m]>
M9names[m]: ahh i have some program already flashed there and how to check my rp pi probe if its working?
<holo[m]>
i can not flash any of my picos for now so this i need to check first
<M9names[m]>
No I mean put a program on your probe using the uf2 bootloader
<holo[m]>
ahh never did that before
<M9names[m]>
So you should be able to check if your first Pico is dead by holding the boot button while plugging it in. It should show up as a flash drive
<holo[m]>
that sound easy.. checking
<holo[m]>
a i see new disk
<holo[m]>
🙂
<holo[m]>
and same probe-rs is showing as disk, where can i find such test uf2 file or how to create one?
<holo[m]>
i can mount all of my pico + probe but probe still dont want to flash picos
<holo[m]>
i have too usbasp v2 is there possiblity to flash pico with it to check if its working?
<barafael[m]>
<Ralph[m]> "> <@barafael:matrix.org> I..." <- that one doesn't do dmp (digital motion processor)
<spinfast[m]>
what kind of motion processing are you looking for? gravity vector?
<spinfast[m]>
s/gravity/orientation/
<barafael[m]>
data fusion of at least accelerometer and gyro. mpu6050-dmp does it
<barafael[m]>
that is, it uploads the custom proprietary firmware by the vendor to the integrated m0 core. That firmware is quite reliable and ok though
<spinfast[m]>
so kalman filter for a orientation then right, bosch has a few options, tdk seems to pushed that off into a library now rather than putting it on the sensor
<spinfast[m]>
* tdk seems have to pushed
<spinfast[m]>
e.g. icm42688-v "fusion library"
<spinfast[m]>
like thanks for making the mcu core do it now
<holo[m]>
<M9names[m]> "So you should be able to check..." <- Ok i figure out this. I reflashed both picos with this uf2 files and both are working again. I reflashed too pico probe with firmware from its documentation and still not working strange it can be mounted and basically looks ok except that its not seeing pico
<holo[m]>
s/pico/rp/
AdamHorden has quit [Quit: Adam Horden | adam.horden.me]
AdamHorden has joined #rust-embedded
cr1901 has quit [Quit: Leaving]
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
AHRS systems are a can of worms...
<firefrommoonligh>
(I've been using a ICM42688p; good sensor)