<re_irc>
<justacec> Ok, I have added that in and resolved the deps with the "atomic" crate and the core
<re_irc>
<firefrommoonlight> Shouldn't you do a single atomic fetch add there?
<re_irc>
<justacec> But, now I am getting more errors.
<re_irc>
<justacec> Here is an example (not sure where to even start with this...):
<re_irc>
= note: rust-lld: error: section .defmt.prim.{"package":"defmt","tag":"defmt_prim","data":"Unwrap of a None option value","disambiguator":"4025694437884228893"} virtual address range overlaps with .text
<re_irc>
>>> .defmt.prim.{"package":"defmt","tag":"defmt_prim","data":"Unwrap of a None option value","disambiguator":"4025694437884228893"} range is [0x8000138, 0x8000138]
<re_irc>
>>> .text range is [0x8000138, 0x8001DFB]
<re_irc>
<henrik_alser> firefrommoonlight: I guess, just quick copy paste from the knurling app template
<re_irc>
<justacec> I looked in the app-template for the example, but github search said the phrase "timestamp" does not exist in the knurling-rs/app-template.
Guest228 has joined #rust-embedded
<re_irc>
<henrik_alser> Ahh maybe it was an older version
<re_irc>
<henrik_alser> Just saw your error message was asking for it
<re_irc>
<henrik_alser> So thought that might be it
<re_irc>
<justacec> Yea. It does seem to address that one error, but now I am still getting the virtual address range overlap errors
<re_irc>
<justacec> I have never seen those.
<re_irc>
<henrik_alser> Hmm, neither have i
<re_irc>
<justacec> Ok. got it. I needed to add:
<re_irc>
"-C", "link-arg=-Tdefmt.x",
<re_irc>
to the cargo config file
<re_irc>
<justacec> Now I can get on with removing the builtin AT command set from the LoRa-E5 to make room for the blinky app.
<re_irc>
<David Cabanis> chocchoccccpa.\admin
<re_irc>
<yruama_lairba> justacec: do you use a compilation caching system ? i had issue related to that, so i finally disabled it
Guest228 has quit [Ping timeout: 256 seconds]
<re_irc>
<korken89> Hey diondokter if you're around, I've started converting device driver to a proc-macro. Would you have any feedback on this syntax?
<re_irc>
<korken89> Hey diondokter if you're around, I've started converting device driver to a proc-macro. Would you have any feedback on this syntax?
<re_irc>
<korken89> I shamelessly stole all your features :D
<re_irc>
<diondokter> More of an attribute style
<re_irc>
<korken89> Yeah
<re_irc>
<korken89> I like that rustfmt also still works
<re_irc>
<diondokter> Right
<re_irc>
<diondokter> Yeah, that crate really deserves some more love, but I'm just so busy LP
<re_irc>
<diondokter> * :P
<re_irc>
<korken89> Same here, but I have found a good need for starting to fix it :)
<re_irc>
<korken89> I'll try to make the syntax and codegen separate as well (as we do in RTIC, but one crate), so it should be sort of easy to work with it
<re_irc>
If you're serious and if you want, then I could add you to the repo so you can just commit to it. It would be silly to have two different projects for this.
<re_irc>
<diondokter> Right, well, I'm very open to PR's!
<re_irc>
<korken89> If you feel like it's fine, I'm up for it
<re_irc>
<korken89> I don't want to come and bulldoze your project as well :)
<re_irc>
<diondokter> Haha no problem
<re_irc>
<diondokter> You should have an invite now
<re_irc>
<korken89> Thanks!
<re_irc>
on reset?
<re_irc>
"__c_m_sh_syscall()"
<re_irc>
<marmrt> What's going on with the MCU I'm working on getting trapped in
<re_irc>
<marmrt> Works fine when debugging, but power cycling does not work
Guest271 has joined #rust-embedded
<re_irc>
<adamgreig> marmrt: are you using semihosting, I guess? possibly without a debugger attached?
<re_irc>
<adamgreig> the easy answer is probably "consider using RTT instead of semihosting" , which doesn't generally suffer from this issue
<re_irc>
<marmrt> Yes, I am using semihosting
<re_irc>
<marmrt> So the mcu is waiting for a debugger that isn
<re_irc>
<marmrt> * isn't connected and therefore nothing happens?
<re_irc>
<adamgreig> yea
<re_irc>
<henrik_alser> marmrt: Do yourself a favour and check out probe run with rtt instead!
<re_irc>
<marmrt> I have used probe run, it is neat. this project sadly is the one before I discovered probe run :/
<re_irc>
<henrik_alser> marmrt: ahh, should be a quick upgrade though!
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
<henrik_alser> (Much easier than dealing with semihosting i’d bet :))
<re_irc>
<marmrt> Sounds like a good solution, thanks for the help
<re_irc>
<henrik_alser> Good luck!
crabbedhaloablut has joined #rust-embedded
<re_irc>
<henrik_alser> We’re here of you need us :)
<re_irc>
<henrik_alser> * if you need help
starblue has quit [Ping timeout: 240 seconds]
<re_irc>
<marmrt> I'm back! :D
<re_irc>
So I'm flashing and debugging the mcu remotely via ssh which has worked fine so far. openocd on the remote laptop, port forwarding and gdb just works just like it would if I was doing everything locally.
<re_irc>
So I'm trying to fix this by installing probe-run on the remote laptop but the installation fails
<re_irc>
probe-run cannot find a debugger, this makes sense, the debugger is connected to a different laptop.
<re_irc>
<marmrt> but probe-run throws "Error: no probe was found."
<re_irc>
<dirbaio> hmm I don't think that probe is supported by probe-rs
<re_irc>
<marmrt> welp.
<re_irc>
<dirbaio> it supports ftdi stuff but only for jtag, not swd?
<re_irc>
<dirbaio> not sure
<re_irc>
<dirbaio> ask in #probe-rs:matrix.org (https://matrix.to/#/#probe-rs:matrix.org)
<re_irc>
<Noah> huiiii I had an olimex for the longest time :D Donated it to the students lab :D
<re_irc>
<Noah> (never used it)
<re_irc>
<Noah> marmrt: olimex is not supported :)
<re_irc>
<marmrt> Damn, I suppose finding an stlink probe is gonna be my solution.
<re_irc>
<marmrt> Thanks, all. This was an adventure, I'm gonna put it aside for now
<re_irc>
<Noah> I mean you can write a driver for the olimex, we would be very happy, but nobody has asked for it in 2 years. You can kinda gauge the popularity from that ;)
<re_irc>
<dirbaio> iirc someone else did ask about them
<re_irc>
<Noah> marmrt: do you use an stm32?
<re_irc>
<Noah> dirbaio: fak
<re_irc>
<dirbaio> so N=2 now I guess :D
<re_irc>
<marmrt> Im a bit surprised by that, to me the Olimex is The Capital D Debugger
<re_irc>
<Noah> dirbaio: DOUBLE THE REQUESTS!
<re_irc>
<dirbaio> requests up 100% in Q1 2022 🚀
<re_irc>
<Noah> marmrt: well it might have been back in the day :) nobody, at least in the hobbyist scene, uses JTAG anymore :)
<re_irc>
<Noah> all SWD
<re_irc>
<dirbaio> marmrt: perhasp you have a stm32 bluepill/blackpill or a raspi pico lying around? you can make these into probes by flashing a firmware
<re_irc>
<marmrt> Noah: No, it's an atsame, but I'm pretty sure I was successful on the board I have on my desk
<re_irc>
<adamgreig> the olimex ones are a normal FTDI probe and there's plenty of them out there, so it would be nice to support but.. kind of a faff and swd is so much more popular :/
<re_irc>
<Noah> marmrt: then for sure do not get an st-link!!
<re_irc>
<Noah> like, it works, but atsamd is kinda dumb and stlink is kinda dumb and both by different companies, so yeah :/
<re_irc>
<Noah> adamgreig: yeah I fully agree :)
<re_irc>
<dirbaio> there's already ftdi jtag support though, isn't it?
<re_irc>
<dirbaio> I was using it with the esp32c3
<re_irc>
<dirbaio> or is this another ftdi?
<re_irc>
<dirbaio> I'm confused
<re_irc>
<adamgreig> there's risc-v ftdi jtag support
<re_irc>
<adamgreig> does it work for cortex-m ftdi jtag?
<re_irc>
<adamgreig> i don't think we have cortex-m jtag support in general
<re_irc>
<dirbaio> yeah but at least list-probes should see that
<re_irc>
<dirbaio> * it
<re_irc>
<dirbaio> and fail later when you actually try to use it with arm (?)
<re_irc>
<adamgreig> maybe only with the ftdi feature which is non-default?
<re_irc>
<dirbaio> ahh that's probably it
<re_irc>
<dirbaio> probe-run doesn't enable it yup
<re_irc>
<Noah> adamgreig: nup :)
<re_irc>
<Noah> dirbaio: yeah, thats because it's a pain to build :/
<re_irc>
<Noah> need to get a FTDI probe so I can rewrite libftdi
<re_irc>
<dirbaio> it'd be nice to put builds in releases, for x86, armv7, aarch64 for example
<re_irc>
<dirbaio> with everything statically linked
<re_irc>
<dirbaio> so you just download it and it works
<re_irc>
<dirbaio> if end users no longer have to build it themselves, it matters a bit less that it's a pain to build
<re_irc>
<dirbaio> libftdi RiiR would be neat, but there's still the pain of libusb which is not going away:D
<re_irc>
<Noah> yeah
<re_irc>
<dirbaio> * away :D
<re_irc>
<Noah> dirbaio: well yeah, but libusb seems fairly easy on all platforms (not counting windows, because everything is a real pain there, but libftdi is a level more)
<re_irc>
<dirbaio> ubuntu has the multiple-versions footgun
<re_irc>
<dirbaio> and I also had fun with it trying to crosscompile with it for rpi
<re_irc>
<Noah> XD
<re_irc>
<Noah> binary builds would be nice :)
<re_irc>
<Noah> including nightlies :)
<re_irc>
<adamgreig> a rust libftdi using rusb would be great
<re_irc>
<adamgreig> i'd still like to do something about sharing probe-rs's cmsis-dap driver with my fpga/spi flash stuff, but better yet to allow it to also use ftdi chips
<re_irc>
<dirbaio> oh boi jschievink is at it again
<re_irc>
<adamgreig> room meeting time again, agenda's up at https://hackmd.io/g-iCjGvxSX6qjqCIVzlVuQ, please add anything you'd like to announce or discuss and we'll start in 5min
<re_irc>
<adamgreig> ok, let's start! I don't have any announcements, does anyone else?
<re_irc>
<adamgreig> well, shout later if you think of anything! not a huge amount else on the agenda, so...
<re_irc>
<adamgreig> once that's in we can consider some releases, cortex-m-semihosting/panic-semihosting first, probably cortex-m-rt fairly soon too
<re_irc>
<adamgreig> cortex-m wants to wait for 0.8 and we'll probably want some other changes first but could do an alpha
<re_irc>
<adamgreig> not sure if cortex-m-rt should bump to 0.8 or stay as 0.7 though... since the svd2rust PACs all depend on it, it's quite a slow thing to change, and this isn't technically a breaking change, so...
<re_irc>
<adamgreig> do you want to add the self-hosted runner in that PR or separately?
<re_irc>
<adamgreig> I think we can sort out the token, or if you're interested, you could join the cortex-m team and thus have access to the repo to sort it out anyway
<re_irc>
<newam> adamgreig: The PR is ready, either way works for me, it's probably easier if I join the repo so I can see the runner status page.
<re_irc>
<adamgreig> so we get ever closer towards 1.0
<re_irc>
<adamgreig> and, the MSRV guarantee for 1.0 was updated to clarify that we will probably bump it in a future 1.1 release after 1.0 is out, not least because we'll want to add async traits
<re_irc>
<eldruin> the question for e-h now would be if the i2c will also be restructured like spi, which would make sense, but we would need to see how it looks
<re_irc>
<dirbaio> it's some weird bug with higher-ranked trait bounds
<re_irc>
<dirbaio> it works with "-Z chalk" (the new very-WIP but much smarter trait engine) so I'm quite sure it's a bug in the old engine
<re_irc>
<eldruin> I see
<re_irc>
<dirbaio> I'm not sure if it's blocking, the workaround in that PR works fine
<re_irc>
<dirbaio> it's just very ugly
<re_irc>
<eldruin> It might be worth reporting it to the rust lang team so that it can be properly tracked or we can be referred to the underlying issue
<re_irc>
<eldruin> I see, I haven't cached up on that PR over the last few days
<re_irc>
<dirbaio> agreed, will do
<re_irc>
<eldruin> I will read it some other time, we can discuss other (or this topic, I just have nothing else to say ATM) topics now
<re_irc>
<adamgreig> I don't have anything else on the agenda 😅
<re_irc>
<therealprof> So cortex-m is just pending on newam finishing the CI? Or shall we do that indepedently?
<re_irc>
<adamgreig> may as well wait and get it all in the same PR I guess
<re_irc>
<newam> therealprof: It will fail at the moment if merged since it has the self-hosted runner in a CI action.
<re_irc>
<adamgreig> (I don't mind, though)
<re_irc>
<therealprof> Up to you.
<re_irc>
<newam> I would like to do it in the same PR ideally :)
<re_irc>
<adamgreig> ( thejpster has already approved it)
<re_irc>
<adamgreig> ok, let's end the meeting early there, then, thanks all!
<re_irc>
<allexoll> hey, anyone has a Github action repository that uses "cross"? I'm looking for an example, I though I had seen one passing but i cannot remember which repo it was...
<re_irc>
<James Munns> I will continue to troll about "(practically) no one actually cares about MSRV" :D
<re_irc>
<adamgreig> Yea, I don't think it's a huge deal
<re_irc>
<adamgreig> But the cortex m master branch is already tracking 0.8 due to other breaking changes, and I don't want to backport this to 0.7
<re_irc>
<dirbaio> I only care about MSRV when PRing something and getting "nooo can't use $FEATURE because MSRV is $ANCIENT_RUSTC" :D
<re_irc>
<dirbaio> never as a user
<re_irc>
<newam> dirbaio: I maintain some rust packages for NixOS, is it nice to support the current-1 while linux distros update to the latest rust version.
<re_irc>
That doesn't matter for embedded though 😄
<re_irc>
<disasm> As a person who uses $ANCIENT_RUSTC I can say that MSRV doesn't matter as long as I have Cargo.lock in a project
<re_irc>
<newam> disasm: I am curious, what is the purpose of using $ANCIENT_RUSTC ?
<re_irc>
<disasm> newam: To have a stable stable compiler :) Also useful when you want to gate your PRs with clippy and other things and you don't want to see a broken build just because rustc was updated today.
<re_irc>
<dirbaio> for that, why not pin a particular stable and still update it often?
<re_irc>
<dirbaio> like, you don't have to let it become $ANCIENT over time
<re_irc>
<disasm> Updating it often usually requires a significant effort to fix all the builds
<re_irc>
<disasm> ICEs, new clippy warnings, miscompiles, you name it
<re_irc>
<newam> is that just new clippy lints? For compiling itself I have had a very good experiences with forwards compatibility
<re_irc>
<Ryan Butler> newam: This - I don't have the issues I used to have
<re_irc>
<dirbaio> new clippy lints is an argument _in favor_ of updating :D
<re_irc>
<dirbaio> and if you do it often it's not that much work
<re_irc>
<disasm> dirbaio: Unless you have a lot of code ;)
<re_irc>
<dirbaio> :'(
<re_irc>
<newam> "Bump actions/checkout from 2 to 3", wew that's going to be a lot of repos to update dependabot.
<re_irc>
<xiretza> disasm: enough code that bumping the compiler version and fixing any new errors that pop up every six weeks is too much work?
<re_irc>
<disasm> xiretza: Well, I definitely spend less than six weeks to update to a newer version, but that would be an interesting problem
<re_irc>
<disasm> Also rustc introduced a panic inside "uninitialized" API one day, almost impossible to workaround in some cases
<re_irc>
<disasm> I really like rustc updates, but sometimes I wish someone updated all the code and fixed all the bugs while I'm sleeping
<re_irc>
<dirbaio> "mem::uninitialized" is insta UB in almost all cases
<re_irc>
<dirbaio> better get rid of that hehe
<re_irc>
<disasm> dirbaio: I spent one month to update a dependency that was using "mem::uninitialized", easy