<marmrt[m]>
The cargo test call is part of our CI process and has been working well so far, but is now broken probably due to a bump in MSRV
hampycalc[m] has joined #rust-embedded
<hampycalc[m]>
Hi everyone. I've had a decent amount of experience (albeit 5-6 years ago) developing an embedded product. Tools included C/C++ with STM32 using STM32CubeMX. I've started the development of a new product and experimenting with Rust, specifically using the stm32fxx-hal. My greatest block so far is the lack of useful documentation. The examples in the repo are out-of-date with the code, but even so, I'm fairly limited to browsing
<hampycalc[m]>
Rust blogs for information (which are often out-of-date with the current HAL version). I'm concerned that this is too great a risk to take on for this project. Currently, I'm trying to tie a USART to a DMA channel, and it's just difficult to figure out where all of the configuration mechanisms are... Anyway, if you have an opinion on this, please share
<hampycalc[m]>
moreso - if there is anyone who is in the professional field of embedded development and has moved from C/C++/STM32 to Rust/STM32, I'd be very interested in hearing your experience w.r.t skill ramp-up, usefulness of documentation, ongoing breaking changed, ease of configuration of peripherals/memory mechanism/interupts, etc
<therealprof[m]>
@hampycalc:matrix.org If you find examples which are out of date with the code, it might be worth opening an issue. Most (all?) HAL impls compile the examples as part of the CI so it's a bit curious why this would happen.
<AdamHott[m]>
I have a general embedded question. When I'm building my projects, do I need to bring in the source code from various crates and reference them as mod xyz_crate to bring them into the project to use? Or does Rust bring in the code if I reference the crates as dependencies in the cargo.toml file then in main.rs I reference them by "use xyz_crate"?
<JamesMunns[m]>
The second one! You should never have to copy in or "vendor" dependencies (unless you are doing something unusual on purpose)
K900 has joined #rust-embedded
<K900>
That's more of a general Rust question
<K900>
But generally vendoring dependencies is not recommended
FlixtheNewbie[m] has joined #rust-embedded
<FlixtheNewbie[m]>
I assume that the main reason people do that (in C++ for example) is because the experience with pulling an external dependency is horrible.
<AdamHott[m]>
Haha I'm so green to this!
<K900>
Any complicated enough C project eventually either adopts Nix/Bazel style meta build systems or writes their own, worse one by accident
<FlixtheNewbie[m]>
C is backward compatible, unlike C++. I think it's better to vendor things in C++.
<K900>
C isn
<K900>
* C isn't
<K900>
C likes to claim it is
<K900>
But it isn't
<FlixtheNewbie[m]>
The only compiled language I have written during the last 5 years is Rust: when there is some C code to compile (foobar-sys), it just compiles. Every time the dependency is C++, it breaks and I have to find a workaround: use a binary directly, download an older version of the compiler, etc. So I was talking about my personal experience mainly.
<FlixtheNewbie[m]>
Rust being backward compatible is actually such a gift
<Lumpio[m]>
Really the only reason to "vendor" stuff in Rust projects is to ensure some crate doesn't go missing in the future and your project becomes unbuildable - which is a bit less rare with crates.io but nothing is impossible. Even then I would still use cargo and rather take a backup of the source crates instead of copying and pasting the code in your project.
<Lumpio[m]>
s/less//
<AdamHott[m]>
I guess I'm trying to figure out why I'm getting unresolved imports?
<AdamHott[m]>
like in Cargo.toml I have a dependency -> sht31 = "0.2.1"
<AdamHott[m]>
then in main.rs I have -> use sht31::Sht31;
<K900>
I'm surprised the compiler didn't catch that honestly
<K900>
It does some "did you mean" suggestions
<AdamHott[m]>
I'm being silly is what it is
<FlixtheNewbie[m]>
That name SHT31 is not the recommended name in Rust tho :3
<AdamHott[m]>
I need to get more into the habit of reading the docs
<FlixtheNewbie[m]>
Sht31 would be the recommended one
<M9names[m]>
You can check the docs of any crates you've imported by using `cargo doc --open` inside of your crate
<AdamHott[m]>
9names: Do I go into the src directory to run that command?
<FlixtheNewbie[m]>
No
<FlixtheNewbie[m]>
The root is the directory with the Cargo.toml
<AdamHott[m]>
ah ok the root
<M9names[m]>
At the crate root usually, just like you would for build
<Shell>
(But you can do it in any directory under there too, if you happen to have a shell there for whatever reason.)
<AdamHott[m]>
ah I see what's going on now!
<AdamHott[m]>
thanks so much everyone!
<marmrt[m]>
<M9names[m]> "> <@marmrt:matrix.org> I'm..." <- Thanks for the pointer
<StephenD[m]>
<sourcebox[m]> "Will not be here anymore because..." <- I am still powerless lol
<StephenD[m]>
<sourcebox[m]> "dfu-util?" <- dfu-util shows the same device multiple times and thus won't let me do anything("Select a specific device using the serial #", except every serial # is the same)
<StephenD[m]>
cargo dfu is what I was using and it just fails with a LibUsb<Access> error
<StephenD[m]>
<cr1901> "stephen: Do you have Zadig..." <- I do; that's what I used to install libusb
IlPalazzo-ojiisa has joined #rust-embedded
spinfast[m] has joined #rust-embedded
<spinfast[m]>
can I have svdtools reuse a registerblock one ip is using for another? e.g. I want to patch instances 2,3,4 to reuse register block defined for instance 1
<spinfast[m]>
* one ip block instance is using
<jessebraham[m]>
Yes, if you look at the `README.md` in the repo there is a `_derive` keyword for this
<spinfast[m]>
thanks! I never would have thought to read _derive like that
MarkSzente[m] has joined #rust-embedded
<MarkSzente[m]>
Hi everyone. I am trying to make `embedded-hal-bus`'s `ExclusiveDevice` to conform to (async) `SpiDevice`. I know the trait is already implemented on the type, but I simply cannot get it to work. I use an ESP32 board with `esp32-hal 0.17.0`, targeting eHAL `=1.0.0-rc.2`, but keep getting the following error:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/kfjfCzPkZvfGqULVAXoQCvCL>)
<danielb[m]>
You might want to take a look at embassy-embedded-hal
<newam[m]>
There's the HackMD link Adam posted with the agenda
<JarrodHamilton[m>
Oh gotcha
<adamgreig[m]>
ok, let's get going!
<adamgreig[m]>
couple of announcements, embedded-hal v1.0.0-rc.3 is out, probably the last rc before the 1.0.0 release on 28th dec
<adamgreig[m]>
the change in rc.3 is that InputPin now requires `&mut self` instead of `&self`, for consistency and in case implementations need to mutate state to read pins
<adamgreig[m]>
we have a tracking issue open to collect people's end of year blog posts and thoughts on embedded rust, https://github.com/rust-embedded/wg/issues/720, if anyone is feeling inspired to write something in the next few weeks!
<AdamHott[m]>
If anyone wants to review it, I'll turn it into a more picturesque tutorial
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
one topic around releasing embedded-hal on github releases. I want to bring up that the current approach is not automated enough and messy. For example we didn't get releases for embedded-hal-async rc.3 on gh. But they are new releases on crates.io for it.
<vollbrecht[m]>
It would be ideal if the actual 1.0 release will be more smooth in that regard
<adamgreig[m]>
do you have anything that relies on the gh releases getting made? having it automated is nice but there aren't usually many releases and it's often a bunch of work to get the automation working right and tested, so
<adamgreig[m]>
or rather: if we discover the release isn't made on gh, it's easy to do it retrospectively, maybe easier than having to set up automation in the first place?
<therealprof[m]>
Not quite sure what the benefit of releases on GH is TBH...
<vollbrecht[m]>
well i have no problem with that. it don't have to be automated. maybe it should just happen is more what i am try to say
<vollbrecht[m]>
the benefit of it is that people get notifications for it and they are made aware on one more channel
<adamgreig[m]>
perhaps just a readme-release checklist for releasing to help make sure nothing's missed
<newam[m]>
This isn't a problem for me, but from experience GH releases can help in corporate environments where things like crates.io might be blocked (but not github).
<adamgreig[m]>
yea, makes sense, we definitely do want them there
<dirbaio[m]>
there's git tags for every crate
<adamgreig[m]>
yea, just a few clicks to turn them into gh releases
<adamgreig[m]>
admittedly gh makes this kinda annoying for multi-crate repos
<dirbaio[m]>
and there's a single github release for all crates
<dirbaio[m]>
as in, "the embedded-hal project" has released v1.0.0-rc.3, which consists of several crates
<dirbaio[m]>
I can see that being confusing though
<therealprof[m]>
newam[m]: If crates.io is blocked, how do you get access to the crate?
<newam[m]>
therealprof[m]: overriding everything to point to github
<thejpster[m]>
tags are good, gh releases only seen useful for release notes (which are in the change log) and artefacts (and there aren’t any for a library)
<vollbrecht[m]>
its confusing for example with embedded-io and stuff
<newam[m]>
therealprof[m]: Yeah... I quickly got out of that situation. Having tags works though, no problem there.
<adamgreig[m]>
oh, yea, so long as we have the overall 1.0.0-rc.3 release I think that's fine? having a separate release on github for each component crate doesn't seem like it would buy us anything
<adamgreig[m]>
except spam watchers with a ton of notifications :p
<therealprof[m]>
I agree, GH is nice for release notes but I think the more important aspect of releases in GH is artefacts usually which we don't have for crates.
<vollbrecht[m]>
I think we eitere should use github releases for every crate or for no crate. The current situation is just confusing.
<vollbrecht[m]>
* just confusing. In my opinion
<dirbaio[m]>
copypasting changelogs for every single crate etc is quite annoying
<dirbaio[m]>
if it was more automated then maybe
<dirbaio[m]>
but I haven't found any good tooling to automatically manage changelogs, git tags, github releases, crates.io releases for rust library monorepos :(
<dirbaio[m]>
Embassy has the same problem
<dirbaio[m]>
everything assumes either single crate
Ralph[m] has joined #rust-embedded
<Ralph[m]>
GH release notifications show up in the dashboard of people (not only watchers but also others which GH deems interested in embedded / rust where it decides to show these things from time to time). i'm also happy to see such notifications there.
<Ralph[m]>
and then there are of course those which explicitly subscribe for release notifications on GH.
<thejpster[m]>
cargo dist does this
<adamgreig[m]>
we do make releases, so that does trigger notifications
<adamgreig[m]>
just we don't currently make 8 new releases for each release
<thejpster[m]>
It even parses change logs
<dirbaio[m]>
or the project is a binary, not a library, so the only version that matters is the main binary crate's (cargo-dist falls into this category)
<thejpster[m]>
But I don’t know if it does libraries, or mono repos
<therealprof[m]>
Ralph[m]: > <@rursprung:matrix.org> GH release notifications show up in the dashboard of people (not only watchers but also others which GH deems interested in embedded / rust where it decides to show these things from time to time). i'm also happy to see such notifications there.
<therealprof[m]>
> and then there are of course those which explicitly subscribe for release notifications on GH.
<therealprof[m]>
I would have never thought people manually track GH releases for crates.
cr1901 has quit [Read error: Connection reset by peer]
<adamgreig[m]>
I can imagine people watching or starring crates they're interested in on github and then seeing the releases on their gh dashboard
cr1901 has joined #rust-embedded
<adamgreig[m]>
my dashboard is a total horrorshow so I never look at it, but I can imagine :P
<therealprof[m]>
That would be really annoying for me.
<therealprof[m]>
adamgreig[m]: Same.
pbsds has quit [Quit: Ping timeout (120 seconds)]
<AdamHott[m]>
Let's build an alternative to git and github for Rust?
<AdamHott[m]>
haha
<adamgreig[m]>
I'm not sure what the utility of having a github release for e-h-async and e-h-bus and alongside the main e-h would be, though
<adamgreig[m]>
since it's at the same time
pbsds has joined #rust-embedded
<therealprof[m]>
I very much prefer either `cargo outdated` or tools like dependabot to automatically tell me when there's something new.
dnm has quit [Read error: Connection reset by peer]
nohit has quit [Read error: Connection reset by peer]
seds has quit [Read error: Connection reset by peer]
dnm has joined #rust-embedded
nohit has joined #rust-embedded
seds has joined #rust-embedded
<therealprof[m]>
Starring hundreds of crates and then trying to remember which of the dozen projects used a particular crate sounds rather tedious. 😅
<adamgreig[m]>
ok, let's move on
<adamgreig[m]>
the other embedded-hal issue of note for 1.0 is about ToggleableOutputPin
<adamgreig[m]>
and in particular whether it's worth having as a trait, vs a method on StatefulOutputPin or such
Ecco has quit [Ping timeout: 245 seconds]
<adamgreig[m]>
or even having at all... it seems rare to imagine a driver needing to toggle without caring about the actual state. except like, an external watchdog chip driver maybe
<dirbaio[m]>
yeah, i'm not sure what to think
<dirbaio[m]>
upside is we can provide a default impl
<adamgreig[m]>
but it's also a bit late in the day to delete traits and it's probably not actively harmful or wrong, just not very useful
<dirbaio[m]>
downside is we drop support for pins that can be toggled but not read, which I'm not sure if it exists
Ecco has joined #rust-embedded
<adamgreig[m]>
I don't think I've ever seen one... but even if they exist, does anything need to use them?
<dirbaio[m]>
it's funny how announcing a release date and putting RC's out there attracts more eyes 🤣
<dirbaio[m]>
these things (also the `&self` thing) have been like that since forever, and only now 1 week before release people are finding them as issues
<Ralph[m]>
adamgreig[m]: i'd presume there are a variety of cases where you just need to pulse something (LED or a poor man's keep-alive signal on a line) where you really just have a `while true { toggle; sleep; }` loop?
<therealprof[m]>
I even remember the discussion about it in the old days... 😅
<adamgreig[m]>
in a driver, though?
<adamgreig[m]>
we can still have a toggle() method in StatefulOutputPin
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Yeah, I've only ever used it in application code, not in drivers
<Ralph[m]>
diondokter[m]: i know that most here have another opinion, but personally i also try to use e-h for application code: it gives you the option to easily port the application to other platforms without having to rewrite major parts of it.
<dirbaio[m]>
yeah there's a few uses from user code, not hal-independent though
<dirbaio[m]>
for HALs that don't provide inherent methods so you must use it through the e-h trait
<adamgreig[m]>
Ralph[m]: yea, that's fair!
<dirbaio[m]>
no hal-independent driver
<dirbaio[m]>
so idk
<therealprof[m]>
There might be usecases where reading the actual state might be annoying, e.g. a GPIO provided by an I2C port expander.
<adamgreig[m]>
it seems worth keeping toggle() then, just whether it's in its own trait or the statefuloutputpin
<therealprof[m]>
I totally agree that toggle on a stateful pin makes more sense than a separate trait.
<dirbaio[m]>
therealprof[m]: if the i2c port expander has a "toggle pin" command, impls can override the default impl to use that instead of "read, then write"
<dirbaio[m]>
so there's no perf downside
<dirbaio[m]>
the q is whether there's gpio expanders that can toggle, but can't read current output state
<therealprof[m]>
dirbaio[m]: Indeed. That's not what I was thinking of though, it's yet another use case.
<vollbrecht[m]>
how its implemented is a detail of the HAL in the end. we dont need a trait just a method defined somehwere
<vollbrecht[m]>
* need a standalone trait just
<therealprof[m]>
dirbaio[m]: Probably not. I don't recall seeing toggle very often but since they're often both in and output...
<dirbaio[m]>
yeah
<dirbaio[m]>
afaict that's the only "risk"
<dirbaio[m]>
i'm not very comfortable doing changes this close to the release (does it need an rc.4?)
<dirbaio[m]>
OTOH the risk for this is quite lower than the `&self -> &mut self` change from last week
<therealprof[m]>
I agree.
<adamgreig[m]>
the alternative is to just keep it as-is, it just means hals have to manually implement the extra trait
<diondokter[m]>
Removing the trait now is a breaking change. We won't want to do that in the future.
<diondokter[m]>
Adding it back later is not a breaking change
<therealprof[m]>
We could feature gate it, if people complain about breakage we could re-enable it, otherwise drop it in a later release.
<Ralph[m]>
dirbaio[m]: re: rc.4: i'm not sure how many would still update to it this close to the release - e.g. `stm32f4xx-hal` also didn't release a new release for rc.3 anymore (though i did contribute the update to it), thus there won't be any consumers based on it (or at least very few, as they'll have to switch to a git-dep)
<vollbrecht[m]>
on that note esp-hal and esp-idf-hal both not releasing rc3 + versions till 28.12 duo to MSRV 1.75 and xtensa dont have that currently
<dirbaio[m]>
Ralph: at least I do update embassy, and that did uncover some issues with the `&self` change (that we then deemed acceptable, but without the rc3 we wouldn't have found at all)
<jessebraham[m]>
vollbrecht[m]: We have no plans for `esp-hal` releases for quite a few weeks, regardless.
<adamgreig[m]>
diondokter[m]: > <@diondokter:matrix.org> Removing the trait now is a breaking change. We won't want to do that in the future.
<adamgreig[m]>
> Adding it back later is not a breaking change
<adamgreig[m]>
yea, that's true
<therealprof[m]>
Ralph[m]: Have you tried pinging @burrbull:matrix.org to create a release?
<dirbaio[m]>
there's the "compat" argument: having many atomized traits means it's easy for the HAL to "forget" implementing it
<adamgreig[m]>
can't imagine wanting to add it back, especially if we have toggle() on StatefulOutputPin
<dirbaio[m]>
for example I just checked, embassy-stm32, embassy-rp impl ToggleableOutputPin, embassy-nrf doesn't
<dirbaio[m]>
while if it waas part of StatefulOutputPin, I wouldn't have "forgotten"
<dirbaio[m]>
s/waas/was/
<Ralph[m]>
and i don't _need_ it (my crates aren't that important, it doesn't matter whether i update them now or in a month)
<Ralph[m]>
therealprof[m]: he explicitly wrote on the PR that he doesn't plan to do it this close to the release of e-h 1.0.
<dirbaio[m]>
ther'es no need for actual HAL releases, just updating it in git and checking nothing breaks is already helpful
<dirbaio[m]>
and effort spent updating is not "wasted" since 1.0 will also have those changes
<dirbaio[m]>
* "wasted" since the final 1.0 will
<jessebraham[m]>
dirbaio[m]: CI blows up because of the Xtensa toolchain
<dirbaio[m]>
😭
<Ralph[m]>
dirbaio[m]: it'd be great if there'd be some "this trait should be implemented" flag on traits (or even a general "all traits should be implemented" on a mod/crate level) and then crates would explicitly have to say "i opt out of implementing this set of traits") so that it's more obvious why certain traits are not implemented (lack of matching hardware vs. just haven't had time yet)
<dirbaio[m]>
like, at the language level?
<Ralph[m]>
dirbaio[m]: would be the nicest option. but maybe some macro-voodoo (i'm not too familiar with it) might do the trick as well?
<Ralph[m]>
it's just something which crossed my mind
<adamgreig[m]>
most crates that depend on e-h probably aren't implementing any traits though, so it would have to be like "if you implement this trait, you probably also want to implement this trait", but it would probably be implemented on some other struct...
<adamgreig[m]>
anyway, ToggleableOutputPin...
<dirbaio[m]>
i'm leaning towards doing the change
<adamgreig[m]>
maybe PR deleting and adding a default impl of toggle to statefuloutputpin and PR it and hal team vote?
<diondokter[m]>
I was against it at first, but I think I
<diondokter[m]>
* think I've been swayed
<adamgreig[m]>
it does seem like on balance a good change, so for me it's mainly a question of whether it's worth the disruption, but it seems like it will primarily impact HALs that can hopefully make the change quickly (just delete the entire existing impl, that's it)
<dirbaio[m]>
I can test Embassy, if i'm going to be the only one doing it then i'd rather not do rc4
<dirbaio[m]>
* can test updating Embassy, if
<dirbaio[m]>
(it can be tested with a [patch.crates.io} without a rc4 release)
<therealprof[m]>
I'd be for the removal.
jannic[m] has joined #rust-embedded
<jannic[m]>
I can test updating rp2040-hal.
<jannic[m]>
(But can also use [patch.crates.io])
<vollbrecht[m]>
on esp-idf-hal i also test it but just against riscv
<Ralph[m]>
adamgreig[m]: yeah, it'd probably have to be hidden behind a feature toggle ("i am a HAL impl"). i was thinking along the lines of `[[nodiscard]]` introduced in C++11 (a warning which rust emits by default :))
<Ralph[m]>
(also: sorry for off-topic!)
<dirbaio[m]>
So. remove ToggleableOutputPin, move toggle to a defaulted method in StatefulOutputPin?
<dirbaio[m]>
or just remove ToggleableOutputPin?
<dirbaio[m]>
can't think of any downside to having toggle in StatefulOutputPin
<adamgreig[m]>
doesn't hurt to have the default method and it seems like there's at least a couple of feasibly useful situations
<Ralph[m]>
adamgreig[m]: remove? not just move the method to the `impl` of `StatefulOutputPin`? i guess if e-h provides a default impl everyone who would do the same can remove it and only those (if any) which have special handling for it would have to keep it?
* dirbaio[m]
PRs
<adamgreig[m]>
yea, exactly, so you can just remove it unless you want to specialise the implementation
<adamgreig[m]>
ok, great, I think that's all for embedded-hal unless anyone has any other points?
<adamgreig[m]>
nomem: The asm! blocks does not read or write to any memory. This allows the compiler to cache the values of modified global variables in registers across the asm! block since it knows that they are not read or written to by the asm!."
<dirbaio[m]>
they shouldn't have nomem
<dirbaio[m]>
nomem is actually "reorder memory accesses past this instruction is allowed"
<dirbaio[m]>
if oyu're using it to synchronize stuff, you don't want reordering
<dirbaio[m]>
* nomem actually means "reordering memory accesses past this instruction is allowed"
<adamgreig[m]>
yea, the typical use is basically where you might otherwise put a sync::fence
<adamgreig[m]>
in fact generally the fence() would just spit out a dsb anyway...
<adamgreig[m]>
but obviously does prevent compiler re-ordering
<adamgreig[m]>
that will ideally want backporting to 0.7 too
<adamgreig[m]>
it can go with the bacported vectactive fix
<AdamHott[m]>
Hey all I gotta run, thanks everyone happy holidays!
<adamgreig[m]>
I think that's all for today anyway, does anyone have anything else they want to discuss in the last few mins?
<diondokter[m]>
Checking it in godbolt, I don't see any changes with the asm with and without nomem
<diondokter[m]>
Which is expected I guess for simple stuff
<adamgreig[m]>
the asm should only emit the dsb anyway, but with/without nomem can affect how optimisations apply to the rust code around the asm block
starblue has quit [Ping timeout: 264 seconds]
<adamgreig[m]>
oh, I forgot! one final important thing is the annual two weeks of not having weekly meetings
<diondokter[m]>
adamgreig[m]: I'm only seeing a difference when I remove the compiler fences around it
<adamgreig[m]>
though I'm sure there will be some chat on the 28th :P
<adamgreig[m]>
but nominally our next weekly meeting will be on the 9th Jan
<adamgreig[m]>
ok, that's all then, thanks everyone! see you in 3 weeks!
<thejpster[m]>
Please take a look at the Rust 2023 survey!
<JamesMunns[m]>
<dirbaio[m]> "upside is we can provide a..." <- Just a note that I don't think we should do that - I think it prevents anyone else from implementing that trait
<dirbaio[m]>
?? why?
<diondokter[m]>
This is a default function impl on the trait
<thejpster[m]>
Can now do recursive directory listings, and handle relative paths (like `cd B:../bar`, which was apparently a thing).
<thejpster[m]>
In which I attempt to eat my own dog food, and sort-of replicate the MS-DOS command prompt using embedded_sdmmc.
<thejpster[m]>
I continue to struggle with RawDirectory handles (don't you dare drop them!) and smart handles (but now you can't access two at once or do recursion, as they mutably borrow the filesystem context), but I prove you can make it work if you are careful.
<thejpster[m]>
and it's really no worse that C, when it's easy to forget the result of open("foo", 0o600) and leak a handle that way.
<thejpster[m]>
the only heap allocation in the example is for the tree-walk (a heapless Vec could work here), and for when reading files from disk (so I can convert from bytes to UTF-8 in one go - there's probably a way I could do a streaming conversion, or I could just throw raw bytes at stdout and pretend it's not my problem). Oh, and for the A:/FOO/BAR prompt, where again, a heapless Vec would work.
<elpiel[m]>
thejpster: what is a solution that you would accept for async support?
<thejpster[m]>
I don't know of any good solution to have a library that is both async and non-async.
<thejpster[m]>
Basically I'll take async support it if doesn't change any of my example code (or at least, not significantly). Because the goal is to be as easy to use as the Arduino SdFat library.
<thejpster[m]>
I think someone already forked it and made an async version anyway?
dngrsspookyvisio has joined #rust-embedded
<dngrsspookyvisio>
thejpster[m]: If I'm reading the embassy chat correctly that's unmaintained
<elpiel[m]>
thejpster[m]: Yes, at least the crates are in an embassy fork, for the rest of the fork
<elpiel[m]>
There's `deasync` and `maybe_async` but we need to handle the generic traits bounds somehow iirc
<elpiel[m]>
* There's `deasync` and `maybe_async` but we need to handle the generic traits bounds somehow iirc
<elpiel[m]>
* In reply to @thejpster:matrix.org
<elpiel[m]>
Yes, at least the traits* are in an embassy fork, for the rest of the fork
<elpiel[m]>
I think someone already forked it and made an async version anyway?
<mabez[m]>
Haven't tried it, but eventually I want to add an example in the embedded-fatfs repo, no time atm though
<elpiel[m]>
I did try to work with it once but somehow it had an issue with even initialising for my sd card.
<elpiel[m]>
It was a very tedious process but it works
<elpiel[m]>
I ended up copying the SD card impl from embedded-sdmmc with the embassy async API fork (with the capacity function changed to async as well).
<dngrsspookyvisio>
btw, am I understanding it right that quad spi speeds (or higher) of the sd card protocol are a license minefield?
<thejpster[m]>
which I think is new? I thought you could only get the simplified physical layer spec, which only described SPI mode operation.
<thejpster[m]>
but Linux must implement the SD Host controller stuff (e.g. for the Raspberry Pi, and about a bazillion other ARM Socs) so it's hardly a trade secret