<diondokter[m]>
My guess is you've got `dyn Smbus` in that struct instead of `&dyn Smbus`
<diondokter[m]>
dyn Smbus is indeed !Sized
<diondokter[m]>
If you don't want to deal with the reference and this always runs on Linux you could also box it: `Box<dyn Smbus>`
<BenPh[m]>
I found this issue on github about the `embedded-time` crate. Can anything be done to upstream that work, assuming it's a desired goal of the author/project owner?
<JamesMunns[m]>
maybe yank now, release later? I'm not as aware of the failure mode tho
<diondokter[m]>
Yeah, I think yank now. At least that won't break many people after a simple cargo update
<JamesMunns[m]>
do you have a proposed set of crates to yank? Just cmrt, or also macros or any other deps? will this break any of our crates that depend on that new version?
<diondokter[m]>
Just cmrt
<JamesMunns[m]>
(we can always unyank, but better to have a concrete plan that makes sense if jumping quick is a bad idea)
<diondokter[m]>
0.7.3 works fine for everyone. 0.7.4 only adds some features
<JamesMunns[m]>
(also, we have cmrt HIL somewhere?)
<diondokter[m]>
No HIL afaik. There are lots of tests and UI tests
<JamesMunns[m]>
Who has the stm32 sitting under their desk we are using? :p
<diondokter[m]>
* UI tests though
<diondokter[m]>
Oh apparently we do :P
<adamgreig[m]>
No objection to yanking now or doing the release now. The CI is newam. thejpster spotted this a couple of days ago which is why I opened the PR
<adamgreig[m]>
If I wasn't at a conference all week I'd have done the release myself but alas
<JamesMunns[m]>
newam might want to talk to dirbaio to see if the way CI is setup is secure, GHA is a big ol security hole, which is why embassy has teleprobe and such.
<JamesMunns[m]>
(there is a download artifacts step, which seems positive, but yeah it's big footgun)
<JamesMunns[m]>
Also it seems broken atm since newam has three devices attached
<diondokter[m]>
Teleprobe is pretty nice for things like this
<M9names[m]>
omar_u8 is still in the room, they haven't posted here in a while though. i think they're more active in esp-rs
ddao is now known as dao
dao has quit [Quit: Client closed]
AtleoS has quit [Ping timeout: 264 seconds]
dinkelhacker has joined #rust-embedded
<dinkelhacker>
Hey! I'm trying to link a (rust) staticlib into my no_std project and am getting an error because rust_begin_undwind is now defined twice. Anyone got an idea how to solve this issue?
<JamesMunns[m]>
Usually you need to have all the rust in one project/staticlib, specifically to avoid this. Are you including multiple rust staticlibs into the same project?
<JamesMunns[m]>
also, `begin_unwind` should only show up if you have unwind, which is very unusual for no_std. do you need to set `panic = "abort"` in your cargo toml(s)?
<JamesMunns[m]>
(but the same issue will occur if you have two rust staticlibs linked together and they both provide a panic handler)
<dinkelhacker>
So I'm working on a hobby rust kernel and wanted to bundle all userspace tasks in a staticlib so they include all code they will ever need and I don't have to think about how to for example make the core lib to the userspace tasks available once memory protection is turned on.
<dinkelhacker>
But now that you mention it will I get the same issue if the kernel and the userspace application has the core lib included?
<dinkelhacker>
I have set "panic-strategy": "abort" in my target.json file.
<dinkelhacker>
So the only reason why I wanted to do that is to ensure that the userspace app comes with its own code and nothing is shared with the kernel.
badyjoke[m] has joined #rust-embedded
<badyjoke[m]>
Hi ! I'm having a weird issue with SPI. For context I use a ATSAM3X8 (Arduino Due) and I wrote my own HAL only for SPI. I'm reading data from a gyroscope but every byte I read is in double. I already played with baudrate/clock but it didn't change the behaviour. I also inspected with a probe and I have the expected result from the... (full message at
<ryan-summers[m]>
badyjoke[m]: > <@badyjoke:matrix.org> Hi ! I'm having a weird issue with SPI. For context I use a ATSAM3X8 (Arduino Due) and I wrote my own HAL only for SPI. I'm reading data from a gyroscope but every byte I read is in double. I already played with baudrate/clock but it didn't change the behaviour. I also inspected with a probe... (full message at
<badyjoke[m]>
ryan-summers[m]: Yes I shift with some dummy data
<ryan-summers[m]>
It's not about shifting with dummy data, its about discarding specific read data
<ryan-summers[m]>
I.e. you would read 2 bytes from spi, but only look at the second one
<badyjoke[m]>
I think, I get it. In the receive function when I read the RD register I get a u16 and then cast it as u8, to keep only the lower part of the register. Is this wrong ?
<ryan-summers[m]>
... That really depends on the SPI peripheral. Often you can configure the word size to be either 16 bit or 8-bit. If you're using it with 16-bit words, that would likely be sufficient, but this all depends on the exact wire format of the chip you're using
<badyjoke[m]>
I configured the SPI to 8-bit word size
<ryan-summers[m]>
Then likely it is only using 8-bits of the 16-bit RX register. You'll likely need to do two reads of the register to receive both words of your SPI transfers
<badyjoke[m]>
Thanks, I will look into that !
SArpnt[m] has quit [Quit: Idle timeout reached: 172800s]
newam[m] has joined #rust-embedded
<newam[m]>
<JamesMunns[m]> "newam might want to talk to..." <- It's on a physically isolated computer on an isolated network, it _should_ be fine, but yeah.
<newam[m]>
I'll look into those failures later today, on my way to work.
<JamesMunns[m]>
newam since you're around, can you do the yank we discussed above?
<newam[m]>
Just cmrt 0.7.4? Everyone agrees, happy to yank, what's the reason though?
<JamesMunns[m]>
newam yes, specifically cmrt 0.7.4, there was agreement from adamgreig, diondokter is more aware of the issue, I think there's an open PR for the fix but it needs review and release
<diondokter[m]>
Yep indeed
<diondokter[m]>
Once it is fixed we should still yank 0.7.4. It won't break anything. So we might as well do the yank now
<diondokter[m]>
Save other people some debugging time
<newam[m]>
Huh, I don't have yanking permissions unfortunately, not sure why though.
<diondokter[m]>
Oh weird
<newam[m]>
Yeah even for a release I did on embedded-alloc it doesn't show the yank button.
<JamesMunns[m]>
Can you try cargo yank cortex-m-rt@0.7.4 on the command line?
<JamesMunns[m]>
your permissions come via the team, not your individual account
<JamesMunns[m]>
newam ^
jannic[m] has joined #rust-embedded
<jannic[m]>
Before releasing 0.7.5, please have a look at https://github.com/rust-embedded/cortex-m/pull/535, I think there's a missing link_section attribute for the HardFault handler if trampolines are enabled.
<JamesMunns[m]>
jannic[m]: Cross-linked to the other one
<newam[m]>
JamesMunns[m]: Ah good, that worked!
<newam[m]>
Interesting quirk of the WebUI I guess. Thanks for the pointer!
<JamesMunns[m]>
newam[m]: > <@newam:matrix.org> Ah good, that worked!
<JamesMunns[m]>
> Interesting quirk of the WebUI I guess. Thanks for the pointer!
<JamesMunns[m]>
Thank you!
<diondokter[m]>
Cool!
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
diondokter: One thing I noticed with sequential-storage: after changing the type of the key from an u8 to a struct, new data could not be stored/recalled anymore. Only doing a erase of the flash solved the issue. But I'm not sure if this is something that could be fixed without breaking for storage format e.g. by adding some metadata of the key.
<diondokter[m]>
sourcebox[m]: Storing metadata would introduce more overhead, so not sure if that's something that would always be beneficial.
<diondokter[m]>
It is documented that you should not change the key type.
<diondokter[m]>
In theory you can evolve the key since it is dynamically sized, but your deserialization has to be able to deal with the old format and return the same length as the old key did
<sourcebox[m]>
I don't want to change the format of the key anymore but just mention that the issue exists. Sometimes firmware evolves and changes are unavoidable.
<sourcebox[m]>
Wouldn't just store the length of the key in bytes solve it?
<sourcebox[m]>
Shouldn't be much overhead.
<diondokter[m]>
Yep, I get that! But I don't think the library can really help more than it currently does.
<diondokter[m]>
I guess an example would help to show one way of evolving a key.
<diondokter[m]>
Note though that if your key is an enum, that simply adding a field is completely fine.
<diondokter[m]>
sourcebox[m]: Kinda? But how many bytes? 1 or 2?
<diondokter[m]>
But also, the header is now 8 bytes. Just adding one extra byte would cause the header to be 16 bytes including padding on STM hardware.
<diondokter[m]>
And also, users can already do this themselves with a custom key type
<sourcebox[m]>
Are you doing any integrity checks on the key?
<diondokter[m]>
Key+value has a 32-bit crc
<diondokter[m]>
* has a combined 32-bit crc
<sourcebox[m]>
If I change the key format, then the CRC should fail, doesn't it?
<diondokter[m]>
Hmmmm no. The crc just checks bytes. No format
<diondokter[m]>
If you're able to deserialize the existing bytes of the key and return the same key length as it was serialized with everything is fine.
<diondokter[m]>
When you store a new item with the new format, that gets its own crc value
<sourcebox[m]>
I'm just trying to understand why a new item cannot be stored then.
<diondokter[m]>
sourcebox[m]: Not sure. What error are you getting?
<sourcebox[m]>
No idea, it's a while ago I did this.
<sourcebox[m]>
After a full erase, everything worked.
<sourcebox[m]>
I know it's not a satisfying answer, but I was just not in the mood to further investigate it because of other things had to be done and I already need to rewrite the flash driver to get in working with esp-hal.
<diondokter[m]>
Haha np
<sourcebox[m]>
Getting a mature and general-purpose flash driver is a topic on its own. I know that for ESP32 there's some code around the bootloader that can deal with chips from several manufacturers to determine the special commands for dual/quad mode. Page count can also be read from the device at runtime.
<JamesMunns[m]>
Does anyone have the hackmd link we usually use for meetings handy?
<JamesMunns[m]>
btw Ben Ph - if you haven't seen `embassy-time`: https://docs.rs/embassy-time/latest/embassy_time/, it has also gotten somewhat popular, it has a somewhat more specific scope (wall clock time, ability to use for async sleeps as well as immediate time), and a more opinionated impl (use of a variable number of timers in a timer wheel, provides `embassy-time-driver` to allow for HAL or custom "backend" impls)
<JamesMunns[m]>
as with most of the embassy stuff, IMO it works best on async, but also has blocking/non-async support as a first class feature.
<sourcebox[m]>
I think what Ben Ph wants (as well as me) is something more "official" from the WG because that would encourage more people to use it in the same way as embedded-hal.
<BenPh[m]>
I'll check it out, but embassy is a subset of embedded, and there is nothing inherently async about what I have in mind
<JamesMunns[m]>
not saying you have to use it, nor is it official, but if you haven't seen it, it is fairly widely used today and is actively maintained.
<JamesMunns[m]>
historically, timers and time in general have the problem that there are actually like 5 different things people want to use timers for, and different cost/overhead amounts people are (or think they are) willing to pay.
<JamesMunns[m]>
embedded-hal also tends to be pretty unopinionated wrt concurrency and interrupts, and most timers require some kind of interrupt for normal usage.
<JamesMunns[m]>
sourcebox[m]: yep, I think that's reasonable! Just noting that we *have* discussed this a lot, and never got enough consensus in the past to make any approach "official". I'm not on the HAL team, so mostly just sharing history here!
<sourcebox[m]>
We had this discussion about all the time stuff long ago and it did not really lead to a solution that everybody would agree on.
<BenPh[m]>
What I'd like to see, is something akin to traits and structs that zero-cost encapsulate the getting of tick-counts, and the extrapolation of said counts to duration/instant primitives.
<JamesMunns[m]>
gotcha! I think that aligns well to embedded-time!
<JamesMunns[m]>
I just didn't think we ever hit consensus of "embedded-time works enough for everyone that we should make it official", but maybe I'm forgetting how some of that discussion went!
<BenPh[m]>
similar to the `InputPin` trait. all it is is a canonical cross-platform interface to get a read on whether or not a pin is high or not. it's up to implementors to determine how it's actually done.
<BenPh[m]>
...the value of the `InputPin` trait is that you don't need to be platform-aware when using something. so long as it implements `InputPin`, you're all good.
<sourcebox[m]>
With time it's way more complicated than with pins.
<BenPh[m]>
JamesMunns[m]: A big part of why I want to feature gate it behind a revision sem-ver bump. Minimal interference, and allows some instability on this specific thing before we start hunkering down and making it _official_ official by taking away the feature gate.
<JamesMunns[m]>
BenPh[m]: for what it's worth, we've ALSO moved more in favor of "make it an external crate, make it popular there", and not "behind unstable feature flags", as those tend to get stuck there forever.
<BenPh[m]>
like, put it behind experimental-time feature, or something
<sourcebox[m]>
E.g. you have to decide between u32 and u64 because it has to be the same type in the driver and the user code.
<BenPh[m]>
sourcebox[m]: I fully intend for it to be unsigned-work agnostic.
<JamesMunns[m]>
oh, the other challenge is:
<JamesMunns[m]>
* how do you share the timer, e.g. allow two drivers to use the timer concurrently
<BenPh[m]>
...up to the implementor to determine which work-size is used.
<sourcebox[m]>
But the implementor of the HAL and the driver can be different.
<JamesMunns[m]>
anyway, we can definitely discuss this during the meeting! Any additional details or context in your comment in the discussion topic will be useful for the people joining shortly
<BenPh[m]>
s/work/word/
<sourcebox[m]>
So you have a HAL providing u64 and a driver requiring u32.
<sourcebox[m]>
* So you e.g. have a
<BenPh[m]>
sourcebox[m]: people would be free to run their own impl of the trait. just as they are free to do their own impl of `InputPin` for an esp32 gpio pin.
<BenPh[m]>
where's the meeting?
<JamesMunns[m]>
Slightly early heads up, but:
<JamesMunns[m]>
I'll order the items we discuss (prio to embedded-wg team topics), but feel free to add whatever! We'll get started in 5m or so
<JamesMunns[m]>
JamesMunns[m]: err, here, rather :)
<BenPh[m]>
cool, I'll get my headphones ready
<JamesMunns[m]>
(it's just chat)
<BenPh[m]>
oh really?
<BenPh[m]>
okay.
<JamesMunns[m]>
beverage and good tunes of your choice are definitely encouraged
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Thanks James Munns ! Are we abandoning HackMD for good or just for today?
<JamesMunns[m]>
bartmassey[m]: Just today at least, I don't have the link and probably wouldn't have the permissions, so not setting any precedence
<JamesMunns[m]>
if you do have the link and there's anything carry over from last week, please do me a favor and share or add it to the discussion page!
<BenPh[m]>
So wrt the u32/64 issue, the intent is to ensure that there are no constraints other than those that make sense. if the platform reads the clock as a u64, then the implementor would be wise to set the output type as u64, and likewise if it's u32, u16, etc.
<JamesMunns[m]>
As a note, there were some regressions reported by diondokter and thejpster with cortex-m-rt v0.7.4, which was yanked today by newam (thank you all!)
<JamesMunns[m]>
there are a few PRs that are probably relevant:
<JamesMunns[m]>
If anyone can TL;DR the regressions, or the two PRs, that'd be appreciated!
<diondokter[m]>
Basically, the macros crate was updated but not released and the updated cmrt crate still depended on the old macros version. This caused the hardfault handler to give an unsound exception frame argument.
<diondokter[m]>
If you use the exception frame, the cpu would hardfault again, which locks up the cpu
<JamesMunns[m]>
Gotcha! I think everything is then covered by those 2/3 PRs?
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
o/
<JamesMunns[m]>
If so, then we can just hold out for cortex-m members to review and merge, and we should be able to release some time this week. I know some folks are traveling (namely Adam and Daniel), which is why we went for "yank now, release later".
<jannic[m]>
And the missing link_section will cause a linker error for non-trivial examples if the trampoline is enabled.
<JamesMunns[m]>
Anything else to be said on this, or just wait for review and release, but otherwise all good?
<jannic[m]>
I experimented a bit with it (wouldn't call it an exhaustive test). That's how I found the missing link_section. Didn't see any other issue.
<JamesMunns[m]>
It looks like we do have some qemu and hardware tests, if theres any way we can add some additional tests for this in the future, that'd probably be appreciated!
<BenPh[m]>
Basically: As there currently exists a canonical cross-platform interface to InputPins through said trait, I feel there is a vacume in the embedded ecosystem with respect to reading the count of an oscilator.
<JamesMunns[m]>
(also do we have any HAL team members in the room? Maybe mabez eldruin ryankurte or dirbaio?)
<dirbaio[m]>
o/
<JamesMunns[m]>
(to note, there was also some discussion of this right before the meeting started, if anyone wants to scroll back)
<BenPh[m]>
embedded-time's `Clock` interface does an excelent job at filling this void, but it has some key issues
<BenPh[m]>
- it is stale/abandoned: the repo had its last commit about 3 years ago, and if you look at PRs/Issues, it's much the same
<BenPh[m]>
- It places restrictions on reverse dependencies: it's use of const generics, and other decisions, means that it restricts some options to those that wish to use it.
<BenPh[m]>
A fundamental element of embeded development is the ability to get a read of an oscilator counter. whether it be an RTC, a HF clock that stops on sleep, etc.
<BenPh[m]>
I would like to put to the team that for rust to be a first class citizen of embedded development, the ability to canonically express a monotonically increasing oscilation counter is a pre-requisite.
<BenPh[m]>
* oscilation counter in a platform agnostic manner is a
<BenPh[m]>
The questions I would like to put to the team:
<BenPh[m]>
- how do people feel about extra dependencies: I would like to use `typenum` to represent compile-time values in a much more powerful way
<BenPh[m]>
- what are peoples perspectives on what embassy-time is missing?
<BenPh[m]>
- What are some key points needed in order for it to be deeped an essential requirement to implement to deep a platform "supported" in much the same way that it is required for a platform to support the `InputPin` trait for their gpio input pins?
<BenPh[m]>
s/deeped/deemed/
<JamesMunns[m]>
Gunna tag dirbaio for feedback on what has stopped us from formalizing anything more complex than the `Delay` trait so far, and what would be the next steps towards getting something like this in embedded-hal
<dirbaio[m]>
yeah
<JamesMunns[m]>
(or any other HAL team members)
<JamesMunns[m]>
I think there is certainly INTEREST in having something, just not agreement on WHAT).
<JamesMunns[m]>
s/)//
<bartmassey[m]>
TBH, I'm not excited about typenum in a world where Rust is moving rapidly toward good support for const generics. I don't know if stable const generics are good enough for what is needed currently though?
<JamesMunns[m]>
bartmassey[m]: yeah, typenum IS more powerful, but also is IMO fairly annoying to deal with
<BenPh[m]>
bartmassey[m]: I constantly run into problems with const generics. In my experience, every time I've run into trouble with getting around the limitations of const generics, and waiting on certain aspects of it to be stabalised, it's just a matter of bringing in typenum, and the problem is solved.
<BenPh[m]>
that's just my experience. I'm also going to be starting a conversation with the rust internals forum about supporting numbers at the type-level.
<bartmassey[m]>
Ben Ph: Yeah, I totally get that. But `typenum` is hard to teach and work with. Like I say, it's a question of whether stable const generics are good enough yet, and if not whether we're willing to wait (or even help) to make them better.
<JamesMunns[m]>
that being said: I think there are a lot of bigger picture discussions about "what are the next steps", before we get too far into impl details.
<BenPh[m]>
bartmassey[m]: For that reason, the use of typenum will be limited to very simple things at the user level. under the hood, it might be a bit tough, but to the end user, it will be just a matter of using `U...` instead of just `...`.
<BenPh[m]>
The advantage will be much easier ways of implementing. I tried implementing a `Clock` trait using fugit, but it was a &*()ing nightmare because of the way const generics are super limited.
<sourcebox[m]>
I remember that I made this PoC crate 2 years ago, dirbaio confirmed that it actually did very similar things to embassy-time, but overall the concept is not usable in general because it's oppinionated.
<BenPh[m]>
I tried making changes to the Clock trait in a fork using fugit*
<NickStevens[m]>
Sounds like a good first step might need an RFC generated so that people can compare/contrast options?
<NickStevens[m]>
It seems unlikely there'll be consensus in a 60 minute meeting.
<BenPh[m]>
essentially, I want to take the same minimilist approach as the InputPin and other traits in embedded-hal, and just put something out there that says to all the hal-implementors: If you implement this for your platform, it will be used wherever people use embedded-hal"
<dirbaio[m]>
also, there's more hard questions:
<dirbaio[m]>
- does the trait model some "clock" that only counts up, or does it model a "timer" that the driver can restart at will?
<BenPh[m]>
dirbaio[m]: I actually did a fugit fork migrating const-generics to typenum. only reason why a PR isn't up yet is because of github issues.
<sourcebox[m]>
There are not only 2 players in the game: HAL and end user, but also 3rd party drivers.
<JamesMunns[m]>
I think that's reasonable, but also likely would require Ben Ph or others to bring fugit or embedded-time (or a fork of that) up to date, and then bring forward an RFC to discuss adding the trait to embedded-hal
<dirbaio[m]>
typenum is incredibly annyoing to use, I wouldn't want to adopt something using typenum in embedded-hal
<JamesMunns[m]>
So, in the sake of time, I might propose the following:
<dirbaio[m]>
leaving so many things "up to the implementor" has an impact though
<BenPh[m]>
dirbaio[m]: I find the opposite. Every time I want to use const-generics in a way thit is at all useful, but non-trivial, there's issues around its limitations.
<JamesMunns[m]>
* get your fork of embedded-time/fugit up to the state you are happy with
<JamesMunns[m]>
* Write an issue or RFC showcasing your proposed additions to embedded-hal, wrt HAL/Driver/App aspects, discussing what things you do and do not address
<JamesMunns[m]>
* We can get feedback on that RFC specifically, and the HAL team can provide feedback
<BenPh[m]>
...but this is why the RFC process exists. to beat out these conflicting perspectives.
<JamesMunns[m]>
IMO it would be very useful to search for older discussions on timers, I know there were a lot in the 0.2 -> 1.0 transition, as well as in wg/e-hal issue trackers
<JamesMunns[m]>
If anyone has those handy and can forward them to Ben Ph, I think that would be useful!
<dirbaio[m]>
- Decide How to represent time durations (probably something like number of ticks in a given NUM/DENOM fraction)
<dirbaio[m]>
- Define traits using these time durations (clock, countdown, delay, etc)
<JamesMunns[m]>
BenPh[m]: dirbaio correct me if I'm wrong, but we are avoiding "e-hal feature flags" for experimental features, correct?
<dirbaio[m]>
yes, it turned out to be a mistake
<JamesMunns[m]>
The preferred route is "do it out of tree" (in your own crate), then upstream when ready?
<dirbaio[m]>
it's best to experiment in a separate crate
<dirbaio[m]>
then we can merge into embedded-hal
<dirbaio[m]>
* into embedded-hal when it's "done"
<dirbaio[m]>
or keep it as a separate crate but merge it into the embedded-hal repo
<dirbaio[m]>
multiple crates puts less "pressure" into getting everything right since the start
<BenPh[m]>
that creates a checken-egg problem though, no? I'm going to struggle to convince people like those in esp-rs to take the efforts seriously if it's out-of-crate, and it's not going to get in-crate if people like those in esp-rs won't take the efforts seriously.
<JamesMunns[m]>
There's nothing particularly "blessed" in embedded-hal - it's just a common repo. So we get all the "don't break semver" and little benefit for getting everything in e-hal until it's fully baked.
<dirbaio[m]>
since if we add something to embedded-hal 1.x it has to stay that way forever until 2.0 which we want to never have
<dirbaio[m]>
BenPh[m]: if it's a separate crate but if it's equally "official", I don't see what's the problem?
<dirbaio[m]>
it'd be the same as embedded-can or embedded-io
<BenPh[m]>
ohhhhh, okay then.
<BenPh[m]>
in that case, how would you feel about migrating embedded-time, or a clone of some sort, into the embedded-hal ecosystem similarly to embedded-can, assuming that the project owner is happy with that
<JamesMunns[m]>
BenPh[m]: I definitely think the next step is you getting embedded-time up to date, e.g. you get access to the repo, or make an embedded-time2 fork
<JamesMunns[m]>
Repos generally don't get merged to rust-embedded until the HAL teams are ready to maintain them.
<BenPh[m]>
what does the team think of making fugit a dependency?
<JamesMunns[m]>
(rust-embedded-community is also an option)
<BenPh[m]>
I advocate for it based purely on my observation that esp-rs is using it for their time-representation stuff
<JamesMunns[m]>
BenPh[m]: probably this is in the same general topic as the rest: it would be good to see it up to date, and then follow up in an RFC, or discuss in following meetings
<JamesMunns[m]>
I'll probably tag out of this topic, we can come back to this at the end if there is time. Thanks for sharing this Ben Ph!
<sourcebox[m]>
Yep, the usb-device crate currently has a serious flaw that's fixed in master. So what's missing to put out a new release?
<JamesMunns[m]>
If it's just "push the button", I can do that (maybe? or the other r-e-c maintainers), though ryan-summers is probably the most active maintainer there AFAIK
<dirbaio[m]>
every usb-device release is followed by months of chasing down HALs to update it lols
<dirbaio[m]>
* every usb-device release is followed by months of chasing down HAL crates and class impl crates to update it lols
<sourcebox[m]>
That's true, maybe more things should be put in before the next release. That's why I'm asking.
<sourcebox[m]>
But the current state is unusable for anyone with larger descriptors.
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
dirbaio[m]: so a backported patch release for the problem at hand to not create that problem?
<dirbaio[m]>
so HALs instantly work with new usb-device versions without needing an update, as long as usb-device-trait stays unchanged
<dirbaio[m]>
(this is what embassy-usb does. yesterday I released embassy-usb v2.0 and it was instantly usable with all HALs and all classes.)
<JamesMunns[m]>
vollbrecht[m]: (probably the deeper problems are the technical ones dirbaio is mentioning, but also that usb-device has a minimal set of maintainers to drive release forwards)
<dirbaio[m]>
(but this is perhaps offtopic, sorry for hijacking the discussion)
<dirbaio[m]>
* (this is what embassy-usb does. yesterday I released embassy-usb v0.2 and it was instantly usable with all HALs and all classes.)
<sourcebox[m]>
I'm already putting some effort in getting 2 class drivers transferred to the community.
<JamesMunns[m]>
I'd probably suggest chasing the existing maintainers (again, probably Ryan), and get sourcebox (and anyone else active) added as a maintainer
<JamesMunns[m]>
rust-embedded-community is much more relaxed wrt maintainance and such, if you can get a 👍️ from existing maintainers to be added, then we can figure out how to get you the permissions you need to drive it forward
<JamesMunns[m]>
(I think dirbaio's suggestions are good, on a technical level, but there has to be someone active behind the wheel to make it happen)
<JamesMunns[m]>
As eldruin is the person that has managed the migration of most repos to r-e-c, I'd defer to them on expertise?
<sourcebox[m]>
I thought that he noted down what to do.
<sourcebox[m]>
It's the last sentence in his comment that has to be checked.
<JamesMunns[m]>
I pinged out to them, if they are happy I can hit merge, or if you can chime in with a y/n of whether that last sentence is accurate or not?
<JamesMunns[m]>
I think that's about time for today (and I gotta run), thank you all for attending, and I hope you all have a good week!
AdamHott[m] has joined #rust-embedded
<AdamHott[m]>
Thanks all!
<bartmassey[m]>
Thanks for running the meeting!
<cbjamo[m]>
Alexandros Liarokapis: My 64GB version of that sandisk card works. What's your hardware setup?
<cbjamo[m]>
Also would you re-run the test with the small update I just made to pr #30? Defmt will work right now and the logs will be more useful.
sirhcel[m] has joined #rust-embedded
<sirhcel[m]>
I'm trying to build a c api around some rust code and want to have something like an "opaque proxy struct" for a rust struct i'd like to have allocated by the caller like context for storing the state during a longish operation. Like for example the crypto context used by mbedtls, which can be created on the stack by the caller, initialized, passed to the processing functions and freed at the end.
<sirhcel[m]>
I got cbindgen so far to generate either a c-compatible struct or an opaque without a size. Is there a way for generating a "sized proxy"?
<JamesMunns[m]>
I think cbindgen has something for that if the fields aren't pub, or if it's not repr c? You probably want to treat it as a maybeuninit tho if it's anything you don't trust C to zero init
<JamesMunns[m]>
Ah, making it sized
<JamesMunns[m]>
I'd have to go look later if I've done that before. Responded before I saw your last message
<sirhcel[m]>
Maybeuninit is a goot point. Will put this on the todo list.
<jannic[m]>
`cfg-static`, `device`, `unsafety` and `warnings` are missing.
<AlexandervanSaas>
<cbjamo[m]> "Alexandros Liarokapis: My 64GB..." <- Pi Pico on a breadboard. The SD card module is powered from the VBUS from a second pico that I use as debug probe.
<M762spr[m]>
I guess I could also match on the result, but would like to keep the ? because I feel like it is a more concise way to do it
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
One downside with your current version is that it throws away information. The spi transaction might fail an provide some useful debugging info in the error, but you are throwing that away and just returning "IOError"
<GrantM11235[m]>
s/an/and/
<M762spr[m]>
yeah that is a bit of a tradeoff and I understand that's the reasoning around wrapping it in the alternate way, it just got too bulky to manage the generics for functions that weren't using every different kind of error so I decided to simplify things to just throw an "any spi error" or "any gpio error"
<M762spr[m]>
I am probably looking at error handling wrong as a whole but this way seems to work for me, it just also seems a bit off
<M762spr[m]>
I haven't come across a lot of good info on how to properly do it. seems like STD rust has some better ways and most embedded examples just use unwrap
<adamgreig[m]>
Thank you for running the meeting James Munns ❤️
<adamgreig[m]>
I'm finally back at my hotel and the first talk tomorrow is in 7h40m lol
<GrantM11235[m]>
I think the "proper" way to do it is with generics in the enum, but I agree that it can be a hassle sometimes
<NickStevens[m]>
adamgreig[m]: Sounds like a successful conference then! 😄
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<M762spr[m]>
makes sense
<GrantM11235[m]>
As for functions that don't use spi at all, you could create another error enum that doesn't have the spi variant
<GrantM11235[m]>
But I'm not sure if that would make thing simpler (less generics in that particular error type) or more complicated (now you have multiple error types)
<M762spr[m]>
I could probably also do that (with generics), I actually had it set up that way initially but I only needed pin errors for one reset function, then it just because noise to be putting the pin generics in every function return type and I felt like it was harming code readability
<M762spr[m]>
right. ok well thanks for the input. I think I will stick with what I have for now since it is all going on very specific hardware and I will pretty much be the only one working on the code, so "something is wrong with the spi" is good enough to start a more in depth diagnosis. Hopefully there never actually will be anything wrong... it would almost certainly be some sort of hardware issue at that point haha
<GrantM11235[m]>
I wouldn't rule out just unwraping everyting. It's the simplest option, and it still gives you all the error information in the panic message
<M762spr[m]>
honestly that's a very good point considering my use case above
<GrantM11235[m]>
Especially if you are just going to unwrap the error eventually anyway
<M762spr[m]>
although a big point of doing this driver from scratch in the first place was to learn how to write a "proper" driver so I shouldn't take too many shortcuts
<M762spr[m]>
and boy have I learned a lot 😅 it's for a dw1000 and quite the trial by fire!