fabic_ has quit [Remote host closed the connection]
fabic has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
xnor has quit [Ping timeout: 252 seconds]
xnor has joined #rust-embedded
dkm has quit [Ping timeout: 252 seconds]
dkm has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic has quit [Remote host closed the connection]
vancz has quit [Ping timeout: 252 seconds]
vancz has joined #rust-embedded
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
fabic_ has quit [Ping timeout: 252 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fabic_ has joined #rust-embedded
unmanbearpig has quit [Ping timeout: 252 seconds]
<re_irc>
<@wsalmon:matrix.org> I have been using some existing embedded rust drivers and writing some of my own and I have found that the approche that seems most sensible to me has not been used by others, so i have created some helpful creates and writen about them in a blog post https://pointswaves.gitlab.io/blog/BitByteStructs-intro.html I'm interested to get some feed back. If others think this is sensible or at least heading in a...
<re_irc>
... sensible direction or if the community thinks there are some fundamental issues with it?
<re_irc>
<@wsalmon:matrix.org> yes, interesting. I had not seen that one before I will have to go check it out
<re_irc>
<@wsalmon:matrix.org> thanks for the link
<re_irc>
<@firefrommoonlight:matrix.org> DMA troubleshooting. Let's say the register address for a DMA read isn't the whole register, but starts at bit 8. Would you set the register pointer as `regs.flt0.rdatar as *const _ as u32 + 8,`, where `regs` is the pointer to the reg block` ?
<re_irc>
<@firefrommoonlight:matrix.org> (I can't get the DFSDM DMAEN bit to stay latched, or DMA to do anything)
<re_irc>
<@xiretza:xiretza.xyz> bit 8 or byte 8?
<re_irc>
<@firefrommoonlight:matrix.org> bit
<re_irc>
<@firefrommoonlight:matrix.org> The data register has multiple fields. For most periphs I've dealt with, there's a dedicated data register. Here there's only 24 bits possible, and they use the first 8 for something else
<re_irc>
<@xiretza:xiretza.xyz> wouldn't `[address] as *const _ as u32 + 8` be 8 _bytes_ from the start address?
<re_irc>
<@firefrommoonlight:matrix.org> Ha Probably
<re_irc>
<@firefrommoonlight:matrix.org> It's not fixing the problem, btw
<re_irc>
<@firefrommoonlight:matrix.org> How would you do it? (For all I know, this peripheral's DMA setup is expecting the periph address to be the whole register, but I noticed this and want to make sure.
<re_irc>
<@firefrommoonlight:matrix.org> (This is for entering in STM32's DMA `par` register)
<re_irc>
<@firefrommoonlight:matrix.org> So it knows where to write the data
fabic_ has quit [Ping timeout: 252 seconds]
<re_irc>
<@newam:matrix.org> Most of us here have probably seen someone asking for help with their build not linking due to multiple `cortex-m-rt` versions in the dependency tree.
<re_irc>
<@newam:matrix.org> I know I have helped quite a few people coming here for help with that exact issue.
<re_irc>
<@firefrommoonlight:matrix.org> I ended up reverting to `0.6.14`
<re_irc>
<@firefrommoonlight:matrix.org> Unfortunately, I still can't get `0.7.0` working; crashes after a few seconds
<re_irc>
<@firefrommoonlight:matrix.org> I just get `Operation Timed out` now
<re_irc>
<@firefrommoonlight:matrix.org> instead of the `multiple-versions-found` error before the stm32 pac upgrade
<re_irc>
<@firefrommoonlight:matrix.org> 0.6.14 works fine, so...
<re_irc>
<@firefrommoonlight:matrix.org> This class of error is one of the reasons I try to avoid dependencies when possible :/
<re_irc>
<@firefrommoonlight:matrix.org> Or end up on forks to update/sync dependencies, like I do with the ESB library
<re_irc>
<@newam:matrix.org> It is a massive bummer for newcomers that's for sure.
<re_irc>
<@newam:matrix.org> A clear error message would go a long way though. At the moment most people are not even sure how to diagnose the issue :/
<re_irc>
<@firefrommoonlight:matrix.org> Related: I submitted a PR to update the ESB lib to a newer nRF PAC. Paused/rejected due to the nRF-HALs using the old version. It's kind of a no-win
<re_irc>
<@firefrommoonlight:matrix.org> Unless package maintainers work together to stay current
<re_irc>
<@firefrommoonlight:matrix.org> I agree on a clear error being better
<re_irc>
<@firefrommoonlight:matrix.org> I'm not even sure why I can't use 0.7.0 now; no error at all!
<re_irc>
<@firefrommoonlight:matrix.org> Just crashes
<re_irc>
<@firefrommoonlight:matrix.org> Before at least it told me I had multiple versions floating around
<re_irc>
<@newam:matrix.org> More frequent updates would be lovely, and would definitely reduce occurrences of the issue; but anyone who has managed engineers will tell you getting them to agree is like herding cats, it ain't going to happen.
<re_irc>
<@firefrommoonlight:matrix.org> Agreed. I don't have a good solution
<re_irc>
<@firefrommoonlight:matrix.org> I think there was a discussion about why the PACs need a cortex-m dep at all, but they do for a reason I can't recall
<re_irc>
<@newam:matrix.org> firefrommoonlight:matrix.org: Can you add that to the issue (especially if it is reproducible)?
<re_irc>
<@newam:matrix.org> I have not seen this myself, but this is the kind of thing I want to resolve.
<re_irc>
<@newam:matrix.org> The newcomer experience to a new language is very important.
<re_irc>
<@thalesfragoso:matrix.org> They need cm-rt to define the interrupts/vector table
<re_irc>
<@firefrommoonlight:matrix.org> I don't know what to add other than Crashes with:
<re_irc>
<@firefrommoonlight:matrix.org> ```rust
<re_irc>
<@firefrommoonlight:matrix.org> Error: Operation timed out
<re_irc>
<@thalesfragoso:matrix.org> firefrommoonlight:matrix.org: Get CI to pass and I will merge the PR
<re_irc>
<@firefrommoonlight:matrix.org> sweet!
<re_irc>
<@firefrommoonlight:matrix.org> Btw, your lib is great, and I'm using it on a soon-to-be-released production product
<re_irc>
<@firefrommoonlight:matrix.org> the only reason I'm forking is the PAC thing
<re_irc>
<@thalesfragoso:matrix.org> Thanks, it's nice to have people using it to really test it, I only tried it a couple of times because I don't really have a use case for it right now
<re_irc>
<@firefrommoonlight:matrix.org> I'm using it to transmit temperature readings a short distance from a low power device
<re_irc>
<@firefrommoonlight:matrix.org> It's failing the CI on nRF51; not sure why yet
<re_irc>
<@firefrommoonlight:matrix.org> I think the PR also adds 53833 support, which is the MCU I'm using
<re_irc>
<@thalesfragoso:matrix.org> Probably some type/function got renamed or something
<re_irc>
<@firefrommoonlight:matrix.org> Thoughts on dropping 51 support cause it's old??
<re_irc>
<@firefrommoonlight:matrix.org> That's what I'm doing on the HAL branch!
<re_irc>
<@firefrommoonlight:matrix.org> In with the 53, out with the 51
<re_irc>
<@newam:matrix.org> Oooo I do like me some functional hacks. This replaces every appearance of `cortex-m-rt` in the dependency tree with a single version.
<re_irc>
<@thalesfragoso:matrix.org> firefrommoonlight:matrix.org: Doesn't seem like a good reason, given that the support is already there
<re_irc>
<@firefrommoonlight:matrix.org> Fair
<re_irc>
<@firefrommoonlight:matrix.org> Just throwing that out there
<re_irc>
<@firefrommoonlight:matrix.org> For future consideratino
<re_irc>
<@firefrommoonlight:matrix.org> Ie on my libs I've deliberately not added support for older MCUs, since the intent is for new projects
<re_irc>
<@firefrommoonlight:matrix.org> Ie you wouldn't use twice+ surpassed MCu on a new project, but would to support something existing
<re_irc>
<@firefrommoonlight:matrix.org> IMO
<re_irc>
<@firefrommoonlight:matrix.org> Fixed/pushed to PR
<re_irc>
<@adamgreig:matrix.org> huh, I was sure that should work :/
<re_irc>
<@adamgreig:matrix.org> I guess I have mostly used it to point at git repos...
<re_irc>
<@adamgreig:matrix.org> newam, could you add `cargo tree` output in your failing test case? i wonder if it's using c-m-rt <0.6.15 for the 0.16 version, so no `links` key
<re_irc>
<@adamgreig:matrix.org> it's a very frustrating error for sure
<re_irc>
<@adamgreig:matrix.org> hmm, your test case is especially weird due to duplicate INTERRUPTS, I wonder if one c-m-rt is not getting the rt feature set or something
<re_irc>
<@adamgreig:matrix.org> I guess if 0.6 is coming from defmt and it's not applying features, but 0.7 is coming from the PAC which adding rt, then the 0.6 will export interrupts, resulting in the duplicate
<re_irc>
<@adamgreig:matrix.org> but 0.6.15 and 0.7.0 should not get included together because of the conflicting `links` key
<re_irc>
<@adamgreig:matrix.org> perhaps cargo is finding a version resolution by skipping 0.6.15 though, I've seen that happen and it also sucks
<re_irc>
<@adamgreig:matrix.org> anyway a cargo-tree output would be helpful
<re_irc>
<@newam:matrix.org> I'll do that right now :)
<re_irc>
<@adamgreig:matrix.org> presumably this is something you've only noticed since c-m-rt 0.7 was released 2 months ago?
<re_irc>
<@newam:matrix.org> Yeah :/
<re_irc>
<@newam:matrix.org> The increase in people asking about it has increased a lot
<re_irc>
<@adamgreig:matrix.org> ah, yes, I think the problem here is: defmt allows 0.6.14, stm32wl allows >=0.6.15,<0.8, cargo picks 0.7 for stm32wl because it's newer and can't pick 0.6.15 for defmt because of the links key, but _can_ pick 0.6.14 for defmt, so links both
<re_irc>
<@adamgreig:matrix.org> instead of the better resolution of picking 0.6.15 for both
<re_irc>
<@newam:matrix.org> You are correct, 0.6.14
<re_irc>
<@adamgreig:matrix.org> as far as cargo's resolver is concerned, 0.6.14 and 0.7.0 should be fine in one build, because we only added the links key in 0.6.15
<re_irc>
<@adamgreig:matrix.org> maybe we should yank all the older c-m-rt versions
<re_irc>
<@adamgreig:matrix.org> frustrating
<re_irc>
<@adamgreig:matrix.org> in theory it shouldn't be a problem after 0.7 because we'll have always had the links key
<re_irc>
<@adamgreig:matrix.org> I guess what's very frustrating is there's a lot of pressure to get releases out, because everything is still developing and people want the new features and are frustrated at how slow things like cortex-m{,-rt}, stm32-rs, etc, release new versions
<re_irc>
<@adamgreig:matrix.org> but, every time we release a new version, there's loads of horrible breakage like this
<re_irc>
<@adamgreig:matrix.org> burrbull:matrix.org: yes, if your top-level project specifies `cortex-m-rt = "=0.6.15"` it should convince cargo to resolve correctly, I hope?
<re_irc>
<@newam:matrix.org> Yeah, this is more about the error message than my specific issue though.
<re_irc>
<@newam:matrix.org> I know how to resolve these problems; but it is a frequently asked question that a lot of people don't know how to resolve (or even diagnose in the first place)
<re_irc>
<@newam:matrix.org> burrbull:matrix.org: (For the record though this does work)
<re_irc>
<@burrbull:matrix.org> I still propose to backport fix to stm32 pacs 0.13
<re_irc>
<@newam:matrix.org> Added the cargo tree there, and specifics to reproduce.
<re_irc>
<@adamgreig:matrix.org> in a sense the answer is "use the links key, which we now do, and that causes cargo to resolve better and give better error messages", but the problem is the old versions, and "get other libraries to release updates using new c-m-rt"
<re_irc>
<@adamgreig:matrix.org> I'm up for seeing if yanking old c-m-rt does help cargo resolve better
<re_irc>
<@adamgreig:matrix.org> in theory this shouldn't happen with 0.7->0.8 due to having links from the start of the 0.7 history
<re_irc>
<@adamgreig:matrix.org> there's a general question of how to manage breaking changes in such core crates, too, don't know what we can do to improve there
<re_irc>
<@adamgreig:matrix.org> burrbull:matrix.org: you mean backport supporting c-m-rt 0.7? not exactly a "fix", right?
<re_irc>
<@adamgreig:matrix.org> I'm reluctant because I don't know how much it will really help: lots of HALs are on <0.13 anyway so won't benefit, and ideally people would upgrade to 0.14 which also uses new svd2rust, new InterruptNumber support, etc, which are all breaking changes so can't be backported to 0.13
<re_irc>
<@newam:matrix.org> adamgreig: I'll see if there's a way to query the dependents from the crates.io API and scan them.
<re_irc>
<@newam:matrix.org> This probably wont break anything, but it is worth checking.
<re_irc>
<@adamgreig:matrix.org> I can't imagine any of them are pinned to a specific 0.6 version
<re_irc>
<@adamgreig:matrix.org> it's possible to un-yank a version too, so we can do it for a week as a test and see who squeals
<re_irc>
<@newam:matrix.org> > Displaying 1-10 of 500 reverse dependencies of cortex-m-rt
<re_irc>
<@newam:matrix.org> That's impressive.
<re_irc>
<@adamgreig:matrix.org> 💀
<re_irc>
<@newam:matrix.org> adamgreig: Oh, that's news to me. Makes this a lot less dangerous.
<re_irc>
<@adamgreig:matrix.org> especially considering it's primarily used by application crates that won't be on crates.io
<re_irc>
<@newam:matrix.org> That's a good point.
<re_irc>
<@adamgreig:matrix.org> it doesn't _help_ that we have minimal automated testing in place for cortex-m and cortex-m-rt
<re_irc>
<@adamgreig:matrix.org> but that's very difficult and time consuming to set up, and not especially rewarding, so basically no one has done it
<re_irc>
<@newam:matrix.org> Do you mean on-target tests or just tests in general?
<re_irc>
<@adamgreig:matrix.org> on-target tests
<re_irc>
<@adamgreig:matrix.org> not sure what else would be all that useful
<re_irc>
<@adamgreig:matrix.org> like, you could check it builds binaries that contain a vector table, I guess, but we'd probably notice that sort of failure.. maybe
<re_irc>
<@adamgreig:matrix.org> (we do have CI run a bunch of builds and check none of it errors, we just don't really test that the resulting binary artifacts are correct)
<re_irc>
<@adamgreig:matrix.org> tests with all our supported linkers and targets and so on
<re_irc>
<@adamgreig:matrix.org> it's not awful, but it would be nice to somehow have tests on actual hardware
<re_irc>
<@adamgreig:matrix.org> cortex-m is worse, it has more code and less tests, and especially most of its code is basically a HAL, but much harder to test that without a target. maybe qemu could be useful for some level of testing.
<re_irc>
<@adamgreig:matrix.org> this is sort of off-topic for your actual issue though, sorry
<re_irc>
<@newam:matrix.org> That is janky and wont scale; but I can cook something up that would work if you want.
<re_irc>
<@adamgreig:matrix.org> how do you do the actual running of tests?
<re_irc>
<@newam:matrix.org> defmt test
<re_irc>
<@adamgreig:matrix.org> manually, or with a CI server that's triggered from github etc?
<re_irc>
<@newam:matrix.org> Oh, with a CI server.
<re_irc>
<@newam:matrix.org> I just have a few boards connected to my home server
<re_irc>
<@newam:matrix.org> the server scans PRs (I did not want to open more ports than necessary for webhooks), and if they are under my name they build automatically. For everyone else I have to authorize it to prevent running untrusted code.
<re_irc>
<@adamgreig:matrix.org> nice!
<re_irc>
<@adamgreig:matrix.org> newam:matrix.org: it looks like we already yanked most of 0.6, actually
<re_irc>
<@adamgreig:matrix.org> we'd only need to yank .11, .12, .13, and .14
<re_irc>
<@adamgreig:matrix.org> wanna give it a quick go and see if it helps?
<re_irc>
<@newam:matrix.org> Yeah, sure! I'm ready when you are
<re_irc>
<@adamgreig:matrix.org> hmm, seems like it worked!
<re_irc>
<@newam:matrix.org> Yeah, I am unable to reproduce that
<re_irc>
<@adamgreig:matrix.org> I eagerly await breakage reports from people who had 0.6.11 pinned for some reason lol
<re_irc>
<@dirbaio:matrix.org> wait what did you yank? cmrt `0.6.[11..=14]`?
<re_irc>
<@adamgreig:matrix.org> I'm very glad cargo decides the solution is to use 0.6.15 once, instead of trying 0.7 for stm32wl and then erroring out because it can't get a 0.6 for defmt
<re_irc>
<@adamgreig:matrix.org> dirbaio:matrix.org: yes, leaving only 0.6.15, which has the `links` field set
<re_irc>
<@newam:matrix.org> dirbaio:matrix.org: uh-oh, it has started.
<re_irc>
<@dirbaio:matrix.org> hmm
<re_irc>
<@adamgreig:matrix.org> (0.6.0 - 0.6.10 were already yanked)
<re_irc>
<@dirbaio:matrix.org> I think yanking doesn't fix it for people that already have 0.6.14 in their Cargo.lock and then they add something requiring cmrt0.7
<re_irc>
<@adamgreig:matrix.org> yes, if they have a lock file with the yanked versions it won't help until they 'cargo update' or delete the lock file
<re_irc>
<@dirbaio:matrix.org> Cargo will keep using 0.6.14 then give the mysterious errors
<re_irc>
<@adamgreig:matrix.org> but at least they might try 'cargo update' themselves, and it will fix it for any new projects too
<re_irc>
<@adamgreig:matrix.org> I don't think there's anything we can do for people with this bug waiting for them in a lockfile?
<re_irc>
<@dirbaio:matrix.org> how does cargo update fix it?
<re_irc>
<@dirbaio:matrix.org> if they have something requiring both 0.6 and 0.7, it'll be broken no matter what, right?
<re_irc>
<@newam:matrix.org> dirbaio:matrix.org: the issue is that cargo gives cryptic as heck error messages when multiple versions are linked.
<re_irc>
<@newam:matrix.org> it fixes that issue
<re_irc>
<@adamgreig:matrix.org> most things requiring 0.7 (specifically I mean stm32-rs PACs) require >=0.6.15,<0.8
<re_irc>
<@adamgreig:matrix.org> `cargo update` definitely takes it from broken to fix, I checked
<re_irc>
<@dirbaio:matrix.org> ahhh, nice!
<re_irc>
<@dirbaio:matrix.org> so
<re_irc>
<@dirbaio:matrix.org> it updates cmrt to 0.6.15, then "gives up" on using cmrt 0.7?
<re_irc>
<@adamgreig:matrix.org> yes
<re_irc>
<@adamgreig:matrix.org> because 0.6.15 satisfies both, and 0.7 isn't possible
<re_irc>
<@adamgreig:matrix.org> empirically that seems to be what happens and thank goodness for that
<re_irc>
<@adamgreig:matrix.org> but yes, if they want to use something that says 0.6 and another thing that's 0.7, that's just not possible and nothing we can do about it, they'll need to fix their dependencies
<re_irc>
<@newam:matrix.org> oh, that's more than I was expecting.
<re_irc>
<@newam:matrix.org> That's actually kind of amazing, that's a really annoying SAT solver problem.
<re_irc>
<@adamgreig:matrix.org> yea!
<re_irc>
<@adamgreig:matrix.org> cargo's resolver is really good
<re_irc>
<@adamgreig:matrix.org> the problem here is that it was too clever
<re_irc>
<@adamgreig:matrix.org> because it worked out that 0.7 and 0.6.14 should both be possible, so why not give stm32wl the newer 0.7
<re_irc>
<@dirbaio:matrix.org> yankety yank 🦀
<re_irc>
<@newam:matrix.org> Ahhh now it all makes sense. Very good choice on the yank then, this is a better resolution than I expected.
<re_irc>
<@adamgreig:matrix.org> same tbh
<re_irc>
<@adamgreig:matrix.org> I was half expecting this would just give us better errors, which would be annoying
<re_irc>
<@adamgreig:matrix.org> I guess now the pressure is off defmt to update to 0.7 though :P
<re_irc>
<@newam:matrix.org> Better errors are worth a lot, you cannot find anything when googling for linker errors as a result of cortex-m-rt shenanigans (which is also part of the reason I made that issue, give google and the like something to index)
<re_irc>
<@newam:matrix.org> I'm guessing the lack of search-ability is also why there have been people dropping by asking for help.
<re_irc>
<@newam:matrix.org> Yeah, `defmt-test` still needs 0.6 though
<re_irc>
<@adamgreig:matrix.org> yea, better errors would have been a decent outcome for sure, that was the motivation
<re_irc>
<@adamgreig:matrix.org> I'm just glad the end result is even better
<re_irc>
<@dirbaio:matrix.org> could defmt-test do the "0.6 or 0.7" trick? then the fix could be released as semver-minor
<re_irc>
<@adamgreig:matrix.org> of course, if the top-level application package wants to use "0.7" it still can't
<re_irc>
<@dirbaio:matrix.org> panic-probe 0.2.1 is already out removing the cmrt dep
<re_irc>
<@adamgreig:matrix.org> yes, I don't see why not? what does it need c-m-rt for?
<re_irc>
<@adamgreig:matrix.org> so long as all the APIs it uses from c-m-rt are identical in both versions it should be fine
<re_irc>
<@dirbaio:matrix.org> `use cortex_m_rt as _;`
<re_irc>
<@dirbaio:matrix.org> that's all lol
<re_irc>
<@adamgreig:matrix.org> I see
<re_irc>
<@adamgreig:matrix.org> ...why?
<re_irc>
<@dirbaio:matrix.org> 🤷
<re_irc>
<@dirbaio:matrix.org> probably to prevent broken binary due to the end user's crate not pulling in cmrt
<re_irc>
<@dirbaio:matrix.org> if you do a firmware with *only* tests
<re_irc>
<@adamgreig:matrix.org> well it sure seems like it could also specify >=0.6.15,<0.8 then
<re_irc>
<@dirbaio:matrix.org> no need for `#[entry]` etc
<re_irc>
<@dirbaio:matrix.org> but yeah it could even be removed imo
<re_irc>
<@dirbaio:matrix.org> less drama when cmrt0.8 comes out hehe
<re_irc>
<@adamgreig:matrix.org> yea lol
<re_irc>
<@dirbaio:matrix.org> could even PACs not depend on CMRT at all?
<re_irc>
<@adamgreig:matrix.org> they have to export the interrupt macro
<re_irc>
<@adamgreig:matrix.org> because of that name aliasing trick
<re_irc>
<@dirbaio:matrix.org> agh right the cursed macro namespacing hack
<re_irc>
<@adamgreig:matrix.org> yea. I believe that's all they use it for.
<re_irc>
<@dirbaio:matrix.org> they also set the `device` feature in cmrt
<re_irc>
<@adamgreig:matrix.org> alternatives welcome though it is much nicer than the old macro_rules interrupt registration I think
<re_irc>
<@dirbaio:matrix.org> so cmrt doesn't emit its own "default" interrupt vector
<re_irc>
<@adamgreig:matrix.org> true
<re_irc>
<@adamgreig:matrix.org> but tbh c-m-rt should do that by default and have it explicitly disabled
<re_irc>
<@adamgreig:matrix.org> it's so rare and weird to want the default vector
<re_irc>
<@dirbaio:matrix.org> if it was only that then I'd propose removing the dep
<re_irc>
<@dirbaio:matrix.org> exactly
<re_irc>
<@dirbaio:matrix.org> it'd be neater if cmrt didn't emit it unless explicitly asked
<re_irc>
<@adamgreig:matrix.org> in the latest stm32-rs release, I make rt a default feature, enabling cmrt device
<re_irc>
<@dirbaio:matrix.org> vs right now where the PAC has to ask it "don't emit it!
<re_irc>
<@adamgreig:matrix.org> yea... sort of a negative feature
<re_irc>
<@firefrommoonlight:matrix.org> Silly question - does anyone know why passing a `buf.as_ptr() as u32` as a DMA memory address for writing works when `buf` is a `static`, but not a `static mut` ?
<re_irc>
<@firefrommoonlight:matrix.org> Even if you don't mutate it. Is this something fences can help with?
<re_irc>
<@firefrommoonlight:matrix.org> (Writing from memory to periph)
<re_irc>
<@newam:matrix.org> what do you mean by does not work?
<re_irc>
<@newam:matrix.org> You can do `buf.as_mut_ptr() as u32` with a static mut
<re_irc>
<@firefrommoonlight:matrix.org> I'm not sure. It compiles, but DMA doesn't work for mem-to-periph the way I have it set up if it's a `static mut`
<re_irc>
<@firefrommoonlight:matrix.org> The DMA interrupt just never fires
<re_irc>
<@newam:matrix.org> oh interesting.
<re_irc>
<@firefrommoonlight:matrix.org> but switch to `static` and it works
<re_irc>
<@dirbaio:matrix.org> static puts it in .rodata (flash)
<re_irc>
<@dirbaio:matrix.org> static mut puts it in .data (ram)
<re_irc>
<@newam:matrix.org> ooo that's a good call ^
<re_irc>
<@dirbaio:matrix.org> maybe your .data is in some RAM that DMA can't access, DTCM or something
<re_irc>
<@dirbaio:matrix.org> check for the dma "error" flag
<re_irc>
<@firefrommoonlight:matrix.org> OH that sounds relevant!
<re_irc>
<@firefrommoonlight:matrix.org> Yep - the DMA transfer error is firing
<re_irc>
<@firefrommoonlight:matrix.org> Was trying to get the Transfer Complete one! Not taht!
<re_irc>
<@firefrommoonlight:matrix.org> Does this sound like something that could be addressed with flash config?
<re_irc>
<@dirbaio:matrix.org> what chip are you using, and what's your memory.x
<re_irc>
<@dirbaio:matrix.org> RAM is in DTCM, DMA can't access DTCM
<re_irc>
<@thalesfragoso:matrix.org> Use AXIS RAM, everyone can touch that
<re_irc>
<@firefrommoonlight:matrix.org> This might explain why I was having trouble reading to a buffer from input DMA earlier...
<re_irc>
<@firefrommoonlight:matrix.org> Which I thought was unrelated
<re_irc>
<@newam:matrix.org> Usually ST has a reference of what the DMA can access in the memory layout section of the RM.
<re_irc>
<@newam:matrix.org> For a big chip like that the DMA may be on a different mesh.
<re_irc>
<@firefrommoonlight:matrix.org> This is certainly more complicated than other STM32s I've used in this area
<re_irc>
<@dirbaio:matrix.org> H7 is a complex monster :P
<re_irc>
<@firefrommoonlight:matrix.org> Do you know how I'd modify that memory.x file to switch to AXIS for these?
<re_irc>
<@thalesfragoso:matrix.org> dirbaio:matrix.org: Wouldn't it have to check for interior immutability ?
<re_irc>
<@firefrommoonlight:matrix.org> Change the _stack_start` line ?
<re_irc>
<@thalesfragoso:matrix.org> firefrommoonlight:matrix.org: Just remove everything and only define FLASH and RAM, use the AXIS address and size there
<re_irc>
<@dirbaio:matrix.org> thalesfragoso:matrix.org: yeah, compiler checks for interior mutability then put it in .data or .rodata
<re_irc>
<@thalesfragoso:matrix.org> dirbaio:matrix.org: That sounds scary, I would maybe expect something like that, but maybe just on the LLVM side
<re_irc>
<@thalesfragoso:matrix.org> I.e., eliminate the variable completely instead of initializing it from .rodata to .data
<re_irc>
<@dirbaio:matrix.org> I think it's rustc
<re_irc>
<@adamgreig:matrix.org> thalesfragoso:matrix.org: const don't go in memory at all, they're copy-pasted everywhere you use them, static goes into rodata unless it contains an unsafecell in which case it also goes into data
<re_irc>
<@dirbaio:matrix.org> the check is "does it have an UnsafeCell internally?"
<re_irc>
<@adamgreig:matrix.org> ah sorry I see you were just talking about it
<re_irc>
<@dirbaio:matrix.org> I don't think llvm knows about unsafecell :P
<re_irc>
<@firefrommoonlight:matrix.org> Trying this... No success yet. Will keep diving!
<re_irc>
<@thalesfragoso:matrix.org> dirbaio:matrix.org: Well, it knows if something was written to or not
<re_irc>
<@dirbaio:matrix.org> `static`s with unsafecells go in .data even if you don't write to them
<re_irc>
<@dirbaio:matrix.org> like, rustc tells llvm to put them in .data
<re_irc>
<@dirbaio:matrix.org> then llvm might or might not optimize
<re_irc>
<@firefrommoonlight:matrix.org> OH WAIT IT"S WORKING NOW
<re_irc>
<@firefrommoonlight:matrix.org> thank you
<re_irc>
<@firefrommoonlight:matrix.org> Never would have figured that out
<re_irc>
<@firefrommoonlight:matrix.org> For context, it's reading from a PDM mic via DFSDM using DMA, then (for now passthrough) to internal DAC via DMA
<re_irc>
<@thalesfragoso:matrix.org> dirbaio:matrix.org: Yeah, it all makes sense, but I don't remember reading something about that
<re_irc>
<@firefrommoonlight:matrix.org> The intent is to then do some DSP isntead of passthrough
<re_irc>
<@thalesfragoso:matrix.org> But there's a simple way to find out, write to a static that doesn't have UnsafeCell
<re_irc>
<@thalesfragoso:matrix.org> And look at the binary
<re_irc>
<@thalesfragoso:matrix.org> Yeah, I get a segfault on playground at least
<re_irc>
<@sirhcel:matrix.org> I wanted to take a look at the discovery rewrite of the discover book this weekend but failed to build anything (book, examples) due to some dependency resolution foo which exceeds my understanding:
<re_irc>
<@dirbaio:matrix.org> nrf-hal git master is now 0.14
<re_irc>
<@sirhcel:matrix.org> I'm using rustc 1.55.0. And I'm pretty sure that i managed to build and flash the led roulette some weeks ago.
<re_irc>
<@hargonix:matrix.org> We are requiring the nrf hals directly from git since there were some features i patched in that were unreleased and it appears they have upgraded their version (i.e. made a release). So the solution would be to depend on the released version instead of the one published on git now basically.
<re_irc>
<@hargonix:matrix.org> Which in turn would require a PR to microbit since thats where the dependency is coming from
<re_irc>
<@windfisch42:matrix.org> heya! I am trying to implement the USB host side state machine in rust; this implies two nested state machines, one for the port itself and one for each device that may be attached to the port... I would absolutely love to use loops and if statements for this, i.e. generator- or async/await-like syntax. However currently, I don't see how I could store that in an object since generators and futures only...
<re_irc>
... give me opaque types that are `impl SomeTrait`, but I don't know their sizes yet.
<re_irc>
<@windfisch42:matrix.org> Do you guys have any suggestions or prior art on how to do such a thing? Using `Box<dyn Trait>` seems to be impossible either, since on embedded, I usually don't have an allocator around.
<re_irc>
<@dirbaio:matrix.org> you can do it without alloc, with `#![feature(type_alias_impl_trait)]`
<re_irc>
<@dirbaio:matrix.org> otherwise it's not possible
<re_irc>
<@hargonix:matrix.org> sirhcel:matrix.org: I'm gonna write a PR to fix it real quick
<re_irc>
<@windfisch42:matrix.org> how would I use `type_alias_impl_trait` to store a future or generator object in a struct (e.g. an RTIC resource)? How does the compiler know how much space to allocate at all?
<re_irc>
<@dirbaio:matrix.org> type_alias_impl_trait allows you to "give a name" to an `impl Future`
<re_irc>
<@sirhcel:matrix.org> Thank you very much hargonix! This is my first contact with dependency conflicts an I feel rather slow. :)
<re_irc>
<@dirbaio:matrix.org> so once the type has a name, you can store it just like any other type
<re_irc>
<@windfisch42:matrix.org> dirbaio: but to... which `impl Future`? I mean, there can be lots of them, some tiny, some really large
<re_irc>
<@windfisch42:matrix.org> in my imagination, this looks similar to the following:
<re_irc>
<@windfisch42:matrix.org> type Foo = impl MyTrait;
<re_irc>
<@windfisch42:matrix.org> foo: Foo
<re_irc>
<@hargonix:matrix.org> There is apparently already a PR for this to microbit: https://github.com/nrf-rs/microbit/pull/67 but its not working since something seems to be broken...so I guess you'll have to wait for this one sirhcel
<re_irc>
<@windfisch42:matrix.org> now I see problems when i initialize bla with `returns_something_small_implementing_MyTrait()` but when i initialize `bla2: MyStruct` with `returns_something_huge_implementing_MyTrait()`; how does rust handle this
<re_irc>
<@thalesfragoso:matrix.org> windfisch42:matrix.org: TAIT has something called defining use, you need multiple TAITs if you want to represent different types
<re_irc>
<@thalesfragoso:matrix.org> Otherwise you get a compiler error
<re_irc>
<@windfisch42:matrix.org> ohhhh. that is... very nice actually. hm.
<re_irc>
<@windfisch42:matrix.org> now I might need to "yield into" a generator somehow and I might be set, actually
<re_irc>
<@windfisch42:matrix.org> The workaround for "yielding into" a generator (or "resume arguments" other than `()`) might be to use a RefCell or Cell that both the caller of the generator and the generator have access to.
<re_irc>
<@windfisch42:matrix.org> do you think that could work?
<re_irc>
<@dirbaio:matrix.org> are you using the actual Rust generators?
<re_irc>
<@windfisch42:matrix.org> currently, I am not using anything yet, but I am thinking about using the "actual" generators
<re_irc>
<@dirbaio:matrix.org> fun!
<re_irc>
<@windfisch42:matrix.org> after all, I might find that I don't need resume arguments at all; after all, everything that is resumed probably can access certain hardware registers on its own. hm
<re_irc>
<@windfisch42:matrix.org> dirbaio: not sure how much of a sarcastic remark that was :P :D
<re_irc>
<@dirbaio:matrix.org> not very sarcastic :)
<re_irc>
<@dirbaio:matrix.org> it's legit fun
<re_irc>
<@braincode:matrix.org> adamgreig: Also a bit unrelated question about FPGAs: is the ICE40k8 suitable for USB stuff? I wonder if a Glasgow (ice40 based) can do what Luna does with an ECP5 (https://www.crowdsupply.com/great-scott-gadgets/luna)…. and now a bit more related: how’s the FPGA tooling in rust-embedded? Is there something similar to yosys/nmigen & co w/Rust?
<re_irc>
<@dirbaio:matrix.org> you'll maybe run into some "sarcastic fun" too because they're not stable
<re_irc>
<@dirbaio:matrix.org> haven't messed with generator myself, just async/awiat
<re_irc>
<@windfisch42:matrix.org> basically, I have one... let's call them "activity", that basically is
<re_irc>
<@windfisch42:matrix.org> yield; // wait for interrupt
<re_irc>
<@windfisch42:matrix.org> // port is down
<re_irc>
<@windfisch42:matrix.org> ahh good :). yea i hope this is gonna be fun, but i'm quite unsure :D
<re_irc>
<@dirbaio:matrix.org> with async/await you could write a "low level HAL" to "do stuff" with the usb hardawre
<re_irc>
<@windfisch42:matrix.org> I've seen similar code written in C and it's a huge switch-and-callback-hell
<re_irc>
<@dirbaio:matrix.org> for example "tx", "rx"
<re_irc>
<@windfisch42:matrix.org> yes... async/await look quite nice, but don't want to have a global executor, since this is only a driver for one peripheral
<re_irc>
<@dirbaio:matrix.org> then just call these from the top level
<re_irc>
<@windfisch42:matrix.org> i.e. to the top level / client code, I still want to look like a state machine object that gets called its `process()` method in the ISR
<re_irc>
<@windfisch42:matrix.org> with "call these", you mean "resume these"?
<re_irc>
<@dirbaio:matrix.org> hmm just .await (?)
<re_irc>
<@windfisch42:matrix.org> because the whole async call will not come back ever, this is an endless loop
<re_irc>
<@dirbaio:matrix.org> like, you won't be doing multiple rx/tx at the same time
<re_irc>
<@dirbaio:matrix.org> (disclaimer: I have no idea how USB works lol)
<re_irc>
<@windfisch42:matrix.org> i am not talking so much about rx/tx, but about the whole port handling statemachine
<re_irc>
<@windfisch42:matrix.org> basically, I need to return from my `process()` handler with every yield
<re_irc>
<@windfisch42:matrix.org> but i might just write async/await and then call resume on the futures, hm
<re_irc>
<@windfisch42:matrix.org> that might actually be a better way
<re_irc>
<@thalesfragoso:matrix.org> Yeah, you could make the user poll the future on the interrupt, if it's a single one that might not be that bad
<re_irc>
<@thalesfragoso:matrix.org> But the user still needs to take the future to the interrupt and pin it somehow
<re_irc>
<@thalesfragoso:matrix.org> The other option would be to use traits that are implement in the HAL and let the HAL deal with the interrupts
<re_irc>
<@dirbaio:matrix.org> "future must be polled from the irq" would be quite "nonstandard"
<re_irc>
<@windfisch42:matrix.org> i basically want to implement a HAL driver, yes
<re_irc>
<@thalesfragoso:matrix.org> Like embassy's HAL which have an owned interrupt that can be passed to drivers
<re_irc>
<@windfisch42:matrix.org> i want the user code to be unaware of anything future or async/await-related.
<re_irc>
<@windfisch42:matrix.org> (apart from being required to use a nightly toolchain, apparently)
<re_irc>
<@thalesfragoso:matrix.org> And then the HAL itself finds a way to wake the future on the interrupt
<re_irc>
<@windfisch42:matrix.org> the user code shall be able to write
<re_irc>
<@windfisch42:matrix.org> GLOBAL_RESOURCES.usb_handler.process(); // will do everything future related internally
<re_irc>
<@adamgreig:matrix.org> braincode:matrix.org: afaik the luna usb-fs stuff works fine on ice40, both up5k and hx8k, though I haven't used it personally
<re_irc>
<@windfisch42:matrix.org> yea i've read about embassy, that's an async/await executor like tokio, right? I don't want to have a global executor or anything
<re_irc>
<@thalesfragoso:matrix.org> windfisch42:matrix.org: Not sure if you could reliable pin a future with that API, since async fns and the like are !Unpin
<re_irc>
<@windfisch42:matrix.org> (or do I? can I "locally" use embassy only within my crate?)
<re_irc>
<@adamgreig:matrix.org> there are some new-hdls in rust, like kaze and rust-hdl, but I don't think any of them are as mature as nmigen yet
<re_irc>
<@adamgreig:matrix.org> there's nothing like yosys in rust, but it doesn't matter, you just use yosys
<re_irc>
<@dirbaio:matrix.org> windfisch42:matrix.org: an "executor" can be something as simple as `loop { fut.poll() }`
<re_irc>
<@adamgreig:matrix.org> there _are_ a bunch of things for using rust on embedded risc-v soft cores, which is quite popular, disasm would know more
<re_irc>
<@dirbaio:matrix.org> so you could "bring your own" executor with your crate so the user doesn't need one
<re_irc>
<@windfisch42:matrix.org> my codebase that i want to integrate the usb driver into uses RTIC
<re_irc>
<@dirbaio:matrix.org> if it's just one future you're polling you don't need embassy's
<re_irc>
<@dirbaio:matrix.org> what I meant by "nonstandard" is
<re_irc>
<@windfisch42:matrix.org> but basically polling a future sounds great... just ehh, how to deal with that pinning. I never got behind Pin yet
<re_irc>
<@dirbaio:matrix.org> the Future trait specifies types implementing Future must implement wakers "correctly"
<re_irc>
<@thalesfragoso:matrix.org> But you might need to ask the user for some &'static muts or something to pin the future safely
<re_irc>
<@dirbaio:matrix.org> so that executors can skip polling until there's a wake
<re_irc>
<@thalesfragoso:matrix.org> Since you don't want to deal with Box
<re_irc>
<@dirbaio:matrix.org> so if you don't implement wakers and instead tell the user "poll this future every USB interrupt"
<re_irc>
<@thalesfragoso:matrix.org> Heapless' Box could work too
<re_irc>
<@windfisch42:matrix.org> would a mut global variable be sufficient?
<re_irc>
<@dirbaio:matrix.org> then the user can try running that future with a "normal" executor like embassy or tokio, which will hang
<re_irc>
<@dirbaio:matrix.org> because you're not sending "wakes" to the executor
<re_irc>
<@dirbaio:matrix.org> which is not nice
<re_irc>
<@windfisch42:matrix.org> that's what the usb device driver for stm32 does: you basically create a global mut variable and use that from one ISR only
<re_irc>
<@thalesfragoso:matrix.org> Yeah, but if you expose the future to the user you will run into the problem dirbaio pointed
<re_irc>
<@dirbaio:matrix.org> so
<re_irc>
<@thalesfragoso:matrix.org> But you could ask for &'static mut of a wrapper type that has the future in a private field maybe
<re_irc>
<@dirbaio:matrix.org> Approach 1:
<re_irc>
<@dirbaio:matrix.org> - you implement a Future, then expose it to the user
<re_irc>
<@dirbaio:matrix.org> - you implement wakers correctly for the future (usually this means your driver crate has to *own* the interrupt, then wake on interrupt)
<re_irc>
<@dirbaio:matrix.org> - user runs that Future with whatever executor, it'll work with any
<re_irc>
<@dirbaio:matrix.org> - You implement a Future. You don't implement wakers for it. Since it's not fully compliant with the Future trait, you don't expose it.
<re_irc>
<@dirbaio:matrix.org> Approach 2:
<re_irc>
<@sirhcel:matrix.org> hargonix:matrix.org: Thank you for pointing me there! I tried to set up building this pr but apparently did not make it. My attempt was cloning _microbit_ and _nrf-hal_ in the same directory as the discovery book and to edit the dependency chain from led roulette all the way down to nrf52833-hal to use paths referring to my local checkouts. When the paths are wrong, I'm receiving error messages. But when they..
<re_irc>
... presumably correctly reference the crate directories, I'm getting the same error message as before. I'm puzzled. How would you setup your project for working with unreleased crates in such a case?
<re_irc>
<@hargonix:matrix.org> well as I already pointed out the PR does not work and will fail to build anyways right now so its rather pointless to attempt and locally build it atm.
<re_irc>
<@dirbaio:matrix.org> so in the 2nd case the user has no idea you're using async/await internally. And it's "OK" for you to "violate" the Future contract because you're only using it internally, so you can deal with its weirdness
<re_irc>
<@thalesfragoso:matrix.org> state would have to be pinned though, or with similar guarantees
<re_irc>
<@dirbaio:matrix.org> oh yeah, ugh
<re_irc>
<@dirbaio:matrix.org> Pin sucks
<re_irc>
<@dirbaio:matrix.org> RTIC should be able to pin your stuff, but I don't think it does
<re_irc>
<@windfisch42:matrix.org> hm gotta look into wakers.
<re_irc>
<@thalesfragoso:matrix.org> Just separate the future from the driver and ask for a &'static mut of it maybe
<re_irc>
<@dirbaio:matrix.org> `&'static mut` won't work nicely with RTIC
<re_irc>
<@windfisch42:matrix.org> but yea probably i'm gonna encapsulate it internally and deal with my weirdness.
<re_irc>
<@sirhcel:matrix.org> sirhcel:matrix.org: Alright, then I will sit tight and wait for this pr to land. I was still overzealous to see if i could do something for the code where i feel more comfortable than with the dependencies.
<re_irc>
<@dirbaio:matrix.org> it gives you `&mut` that only lasts while the current task (interrupt handler) runs
<re_irc>
<@thalesfragoso:matrix.org> dirbaio:matrix.org: I think you can still get them on init
<re_irc>
<@grantm11235:matrix.org> Is there much of an advantage to doing approach 2 compared to just writing a state machine by hand?
<re_irc>
<@thalesfragoso:matrix.org> grantm11235:matrix.org: On the HAL level, maybe not, but might be better on the driver level
<re_irc>
<@dirbaio:matrix.org> sirhcel:matrix.org: the error is probably because you're only replacing some deps with the path one. you can check with `cargo tree`.
<re_irc>
<@dirbaio:matrix.org> Usually to replace a dep with a local copy it's easier to do a `[patch.crates.io]`. That replaces the crate in the whole tree, not just your crate.
<re_irc>
<@thalesfragoso:matrix.org> dirbaio:matrix.org: Yep, also make sure the deps are compatible with the one you're patching
<re_irc>
<@thalesfragoso:matrix.org> Can't patch 0.14 with a 0.13
<re_irc>
<@sirhcel:matrix.org> Thank you for the pointers dirbaio and thalesfragoso! This sounds like i would have to go down the rabbit hole because `cargo tree` failed due to the dependency issue and if `patch.crates.io` does not work, this sounds pretty tedious to me. I will call it a day and check this out once the pr has landed.
<re_irc>
<@windfisch42:matrix.org> hm but i think rtic can give me a static object in an handler, right?
<re_irc>
<@windfisch42:matrix.org> ah no, right: I can have them in init as a function-local static with static lifetime, and then have a 'static &mut resource within rtic. somethig like this
<re_irc>
<@firefrommoonlight:matrix.org> You can do that sort of stuff to the side with RTIC
<re_irc>
<@firefrommoonlight:matrix.org> Ie it won't interfere
<re_irc>
<@firefrommoonlight:matrix.org> The code I have right now uses RTIC share handle things like periph structs, and manage interrupts, but use static mut for DMA buffers
<re_irc>
<@firefrommoonlight:matrix.org> No conflict
<re_irc>
<@thalesfragoso:matrix.org> firefrommoonlight:matrix.org: I think they meant safely
<re_irc>
<@thalesfragoso:matrix.org> But you can get them on init safely afaik