ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<re_irc> <yruama_lairba> ;( seems i have bugged chip, some sequence of commands behave weirdly
<re_irc> <yruama_lairba> confirmed, i identified the command causing werid behaviour
<re_irc> <GrantM11235> > insufficient DWARF info; compile your program with "debug = 2" to enable location info
<re_irc> why is probe-run giving me this warning even though I have "debug = 2" set?
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
<re_irc> <korken89> I've had it for ages, still works though
<re_irc> <justacec> Getting some strange errors in the linking stage of my build:
<re_irc> = note: rust-lld: error: undefined symbol: _defmt_timestamp
<re_irc> '''
<re_irc> >>> referenced by (/Users/justaceclutter/.cargo/registry/src/
<re_irc> <justacec> I have been googling for a while trying to figure it out. Has anybody here ever seen this?
<re_irc> <justacec> I should also highlight that the error goes away if I remove the "defmt" feature from the lora-e5-bsp in the Cargo.toml file.
<re_irc> <henrik_alser> justacec: have you defined a timestamp?
<re_irc> <justacec> I have also done a full clean and rebuild and still get the error
<re_irc> <henrik_alser> Something like
<re_irc> static COUNT: AtomicUsize = AtomicUsize::new(0);
<re_irc> defmt::timestamp!("{=usize}", {
<re_irc> // NOTE(no-CAS) `timestamps` runs with interrupts disabled
<re_irc> <justacec> No, I have not.
<re_irc> <justacec> Standby...
<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> #[device_driver]
<re_irc> /// The mode of the pin. 2 bits.
<re_irc> mod SR1000 {
<re_irc> <diondokter> Ah cool!
<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> mod SR1000 {
<re_irc> #[device_driver]
<re_irc> /// The mode of the pin. 2 bits.
<re_irc> <diondokter> That looks pretty good!
<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> <korken89> Parse -> AST -> Analysis -> Codegen
<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> <adamgreig> or cargo-embed, both with on your firmware
<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> <dirbaio> ubuntu?
<re_irc> <dirbaio> apt install libusb1.0-dev libudev-dev
<re_irc> <marmrt> indeed
<re_irc> <marmrt> "libusb-1.0-0-dev is already the newest version (2:1.0.20-1)."
<re_irc> <adamgreig> double check you're not installing it from inside a directory that has a .cargo/config telling cargo to use a thumb target, too
<re_irc> <dirbaio> doesn't "cargo install" ignore the .cargo/config target? wot
<re_irc> <marmrt> good catch, there is indeed a .cargo folder in my home directory
<re_irc> <dirbaio> there was some weird issue with libusb versions, there's a few packages
<re_irc> <dirbaio> libusb-dev, libusb1.0-dev, libusb1.0-0-dev
<re_irc> <marmrt> no config, though
<re_irc> <adamgreig> yea, there's also some nuisance with libusb versions that could well be it
<re_irc> <dirbaio> I think the last two are the same but libusb-dev isn't
<re_irc> <marmrt> .cargo/env is what I have, and also what I expect
<re_irc> <dirbaio> try removing libusb-dev
<re_irc> <dirbaio> having the wrong one can sabotage the build :S
Guest271 has quit [Quit: Client closed]
skunkjoe has joined #rust-embedded
<re_irc> <marmrt> Progress! I installed probe-run 0.3.0 instead of 0.3.1
<re_irc> However, I am not finding a probe
<re_irc> <marmrt> "lsusb`` lists "Bus 001 Device 020: ID 15ba:002a Olimex Ltd. ARM-USB-TINY-H JTAG interface```
<re_irc> <marmrt> * "lsusb" lists "Bus 001 Device 020: ID 15ba:002a Olimex Ltd. ARM-USB-TINY-H JTAG interface"
<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 (
<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> <adamgreig> one day, heh
<re_irc> <dirbaio> oh boi jschievink is at it again
<re_irc> <adamgreig> room meeting time again, agenda's up at, 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> cortex-m: the PR to move to the newly stabilised asm and global_asm macros is ready to merge, I think,
<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> and I think newam's PR for qemu testing is ready too? or did it still need some final updates?
<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> <therealprof> Ooh, a new member. πŸ˜‰
<re_irc> <adamgreig> if you're up for it, could you PR adding your name to ?
<re_irc> <newam> adamgreig: Will do!
<re_irc> <adamgreig> great, thanks :)
<re_irc> <adamgreig> other than that for cortex-m, in embedded-hal the new SPI traits have been merged πŸŽ‰
<re_irc> <adamgreig> ( for those following along)
<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> I would say yes
<re_irc> <dirbaio> it annoys me because the async equivalent will become unusable, just like SPI... (context (
<re_irc> <dirbaio> but it's just due to rust limitations that will be eventually resolved, so we should do what's best for the blocking traits now
<re_irc> <eldruin> yeah agreed. is this limitation known to the rust team?
<re_irc> <eldruin> can we track some open issues or something?
<re_irc> <dirbaio> one is linked in the next post, the other one I still haven't tracked down
<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> πŸ‘οΈ let's do that, then
<re_irc> <adamgreig> therealprof, if you get a moment to check over the asm PR I think it's otherwise good to go
<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
skunkjoe has quit [Ping timeout: 252 seconds]
skunkjoe has joined #rust-embedded
skunkjoe has quit [Ping timeout: 268 seconds]
richardeoin has quit [Ping timeout: 256 seconds]
sknebel has quit [Ping timeout: 256 seconds]
limpkin has quit [Ping timeout: 256 seconds]
limpkin_ has joined #rust-embedded
sknebel has joined #rust-embedded
richardeoin has joined #rust-embedded