ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
kericsson has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
notgull has quit [Ping timeout: 248 seconds]
notgull has joined #rust-embedded
kenny has quit [Ping timeout: 245 seconds]
starblue has quit [Ping timeout: 250 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
pbsds has quit [Quit: The Lounge - https://thelounge.chat]
pbsds has joined #rust-embedded
dne has quit [Ping timeout: 255 seconds]
dne has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
kericsson has joined #rust-embedded
nex8192 has quit [Ping timeout: 250 seconds]
kericsson has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kericsson has joined #rust-embedded
corecode[m] has joined #rust-embedded
<corecode[m]> how do you set a memory location using gdb?
<corecode[m]> if gdb's lang is set to rust, i have no idea how to cast a raw location integer to a value so that i can set it
<corecode[m]> set *0xe0000000 = 65 doesn't work
<corecode[m]> ah, set *(0xe0000000 as *usize) = 65
nex8192 has joined #rust-embedded
nex8192 is now known as Guest5332
Guest5332 has quit [Quit: Gateway shutdown]
lynaghk[m] has joined #rust-embedded
<lynaghk[m]> I'm going to the KiCAD conference in Spain this weekend (https://kicon.kicad.org/) --- would love to chat with any Rust folks who might be attending, especially about ideas for a sort of fieldbus/PLC system I'm designing. There's also an extra place to sleep in my AirBNB, if anyone needs a place to crash! =D
Guest5332 has joined #rust-embedded
Guest5332 has quit [Changing host]
Guest5332 has joined #rust-embedded
Guest5332 is now known as nex8192
SEGFAULT[m] has joined #rust-embedded
<SEGFAULT[m]> Hey I have a really simple project, it just uses a STM32F4 as a clock gen for another board, I tried to recompile my firmware after about a month and cargo says it can't compile the MCO crate with a duplicate symbol __INTERUPTS anyone know why this is happening and how to fix it
IlPalazzo-ojiisa has joined #rust-embedded
sigmaris has quit [Server closed connection]
sigmaris has joined #rust-embedded
kenny has joined #rust-embedded
argjend_[m] has joined #rust-embedded
<argjend_[m]> Hey, how do i generate a .map file?
kericsson has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
kericsson has joined #rust-embedded
firefrommoonligh has joined #rust-embedded
<firefrommoonligh> Omg. I just learned sometimes checking in with the watchdog is called "petting". I called the HAL fn refresh. Need to update to pet. So much better. Worht the breaking change IMO
<firefrommoonligh> Wow who the fuck would call it that
marmrt[m] has joined #rust-embedded
<marmrt[m]> much nicer than kicking
K900 has joined #rust-embedded
<K900> Synopsys, IIRC?
<firefrommoonligh> I am not even a dog person
<firefrommoonligh> I just noticed H7xx hall calls it feed. That is also hilarious
eZioPan[m] has joined #rust-embedded
<eZioPan[m]> hi, has someone use QUADSPI access W25Q32JV with quad mode? I meet a really weird problem, that when I use quad command(eg. 94h), the flash chip just hold IO3 high, which make any communication cannot be done in quad mode. The flash chip works fine in single mode and dual mode, don’t know if it’s a hardware problem.
<eZioPan[m]> And the MCU I use is stm32f412ret6
<eZioPan[m]> * hold IO3 pin high, which
<eZioPan[m]> I try disconnect flash chip and rerun the code, from logical analyzer I can see IO3 properly driven by MCU, but if the flash chip is reconnected, then IO3 just always keep at high level.
<firefrommoonligh> You forgot to enable the periph clock. HTH!
fooker has quit [Ping timeout: 246 seconds]
dirbaio[m] has joined #rust-embedded
<dirbaio[m]> sometimes the flash chip itself has some "enable quad" bit in some control register that you have to set
<dirbaio[m]> and otherwise it uses the io2/io3 lines for something else like indicating busy/ready
<dirbaio[m]> yep this one has it too
fooker has joined #rust-embedded
<eZioPan[m]> <dirbaio[m]> "sometimes the flash chip..." <- yes, I check QE bit before I send quad command, the weirdest thing is that IO0 to IO2 work properly in quad mode, just IO3 keeps high.
<dirbaio[m]> hmm then I dunno :(
<eZioPan[m]> thanks, I might need to buy some other flash chip from other sellers, even from some different manufacturers(GD25 maybe?). I’m pretty new to QUADSPI peripheral, that I’m not sure which part has gone wrong(code, MCU or flash chip).
ello has quit [Server closed connection]
ello has joined #rust-embedded
adamgreig[m] has joined #rust-embedded
<adamgreig[m]> hi @room, meeting time again! agenda is https://hackmd.io/_PM-GykkQFmreosYZkRlOw, please add anything you'd like to announce or discuss, we'll start in a couple mins
<adamgreig[m]> <eZioPan[m]> "yes, I check QE bit before I..." <- could your PCB have the pin hardwired, since in single mode it's usually WP or HOLD or whatever?
<adamgreig[m]> ok, let's start! I don't have any announcements for this week, does anyone else?
<adamgreig[m]> thejpster: not sure if you're around, did you want to say anything about project rep elections?
jessebraham[m] has joined #rust-embedded
<jessebraham[m]> New esp-hal releases are out, includes implementations of the 1.0.0-rc.1 versions of the embedded-hal-* packages
<jessebraham[m]> Release notes here: https://github.com/esp-rs/esp-hal/releases/tag/v0.12.0
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]> diondokter put out a neat "are we embedded" post that might be a good reference for folks to share
<adamgreig[m]> got a link handy?
<adamgreig[m]> jessebraham[m]: nice! any issues with e-h rc1?
<jessebraham[m]> I haven't heard of anything yet, but I haven't played with it a ton myself to be honest
<jessebraham[m]> So far so good, though
<JamesMunns[m]> adamgreig[m]: Context, if he doesn't have a chance to comment: https://blog.rust-lang.org/2023/08/30/electing-new-project-directors.html
<jessebraham[m]> We've updated the `lis3dh-async` driver to use the new release as well, so I have at least tested that sensor and confirmed everything was working as expected
<adamgreig[m]> nice!
<dirbaio[m]> might be good to compile a list of hals/drivers that have updated to e-h rc1
<dirbaio[m]> to gauge how ready it is
<adamgreig[m]> where could we keep the list?
<adamgreig[m]> maybe in the 1.0 tracking issue?
jannic[m] has joined #rust-embedded
<jannic[m]> ithinuel updated rp2040-hal to e-h rc1. As far as I know, without any issues.
JonathanDickinso has joined #rust-embedded
<JonathanDickinso> I've been playing around with e-h rc1, no issues so far.
therealprof[m] has joined #rust-embedded
<therealprof[m]> Probably time to 🚢it...
<adamgreig[m]> not much on the agenda this week, but first up is the svdtools transfer to tools team, https://github.com/rust-embedded/wg/issues/695
<adamgreig[m]> therealprof: have you had a chance to look at that?
<therealprof[m]> I haven't.
<therealprof[m]> Doing right now.
<therealprof[m]> Ticked the box. As said last week, that transfer makes a ton of sense to me.
<adamgreig[m]> cool, I'll sort out that transfer soon then
<cr1901> adamgreig[m]: I think you'll forgive me for not paying attention to the meeting rn :P
thejpster[m] has joined #rust-embedded
<thejpster[m]> Sorry I was snowed under with … ✨ things ✨
<adamgreig[m]> next up, last time we discussed embedded-io's WriteAllError business and I think more or less concluded we should prohibit Ok(0) and just return an error, which I guess is awaiting a PR to implement it and potentially carry any further discussions
<dirbaio[m]> yea, conclusion was "PR welcome, will likely be accepted"
<dirbaio[m]> but PR has not happened
<adamgreig[m]> I don't think we had an issue or anything originally either, hm
<adamgreig[m]> anything else that anyone would like to discuss this week?
<adamgreig[m]> OK, if not then let's finish up early today, thanks everyone!
<adamgreig[m]> oh! I did want to briefly mention one other thing, sorry
<adamgreig[m]> there's some talk of various rust targets needing maintainers, and in particular the thumb* targets don't officially have one
<adamgreig[m]> perhaps Arm can officially maintain them as they currently do aarch64, but it's not clear if they will be, and at some point eventually, it seems likely they'll need a designated maintainer to keep tier 2 status
<adamgreig[m]> in which case, it might make sense for the cortex-m team to do so, if they don't object
<adamgreig[m]> some more detail in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Demote.20target.20.60sparc64-unknown-linux-gnu.60.20Tier.202.20-.3E.203
<adamgreig[m]> no idea yet if this will become necessary so we can discuss in more detail closer to the time, but thought I'd raise the prospect (if any other cortex-m team people are around :p)
<adamgreig[m]> 1.48 is.. three years old?
<dirbaio[m]> yeah 🥲
<jannic[m]> Debian oldstable? https://tracker.debian.org/pkg/rustc
<dirbaio[m]> why tho
<dirbaio[m]> seems a giant headache for little benefit
<dirbaio[m]> from their readme
<dirbaio[m]> > Rust can be installed using your package manager of choice or rustup.rs. The former way is considered more secure since it typically **doesn't involve trust in the CA system**
<dirbaio[m]> 🤔
<dirbaio[m]> where did you download your debian iso from? an https page! or a torrent link from an https page 😏
<adamgreig[m]> got it in the post of course 📮
<dirbaio[m]> noooo the post is also a centralized government-controlled system
<jannic[m]> Checked the gpg signature, of course!
danielb[m] has joined #rust-embedded
<danielb[m]> how can they trust any version of the compiler?
<JonathanDickinso> They could maintain a fork if they care this much
<jannic[m]> Seriously, if your potential enemy is a state actor, MITMing a TLS connection is probably a viable attack vector, because there are so many CAs that the state actor might control at least one of them. Whether it's realistic to defend against such an attacker by resorting to distribution packages is a different topic. Anyway - that's not really relevant. Even if you are using debian, you can use current stable and don't need to use an
<jannic[m]> even more ancient oldstable.
<JonathanDickinso> They are trusting CAs right there
<jannic[m]> They have a point though, that the changes to make embedded-io compatible with rust 1.48 are really small. How often do you run cargo doc on such a library, manually?
<adamgreig[m]> dirbaio: I summarised the writeallerror thing in https://github.com/rust-embedded/embedded-hal/issues/501, does it look about right? I feel like I missed the strength of the complaint against the current setup
diondokter[m] has joined #rust-embedded
<diondokter[m]> And of all things it's for bitcoin 🫠
<diondokter[m]> (thanks for sharing the link James Munns: !)
<adamgreig[m]> jannic: you might well run it on your own project that eventually depends on `embedded-io` many levels down, though
<adamgreig[m]> and then want to click through to that trait
<danielb[m]> it's just the top-level readme, isn't it?
<dirbaio[m]> it doesn't break all docs, just doesn't show the readme yeah
<dirbaio[m]> we actually bumped the e-h MSRV in the past specifically for #[doc = include_str!()] support
<jannic[m]> So let's at least be honest: If the PR is rejected, it's because of bitcoin, not for technical reasons :-)
<danielb[m]> bitcoin is a technical enough reason 😈
<dirbaio[m]> no
<dirbaio[m]> i'd still be against even if it was any random non-crypto crate
<JonathanDickinso> bitcoin is preventing us from having our dream rust jobs
<dirbaio[m]> it's extra effort that brings little value to embedded users
<jannic[m]> I'd have much more empathy with some request like "I need to provide security support for XYZ on debian oldstable, and the latest version of XYZ with the security bugfix uses embedded-io". But I'm biased.
<jannic[m]> (and the obvious solution would be to patch the debian package of embedded-io)
<adamgreig[m]> <dirbaio[m]> "it doesn't break all docs..." <- aah yea, of course, fair enough then
<dirbaio[m]> like, const generics landed in 1.51
<dirbaio[m]> and the embedded ecosystem relies heavily on those
<dirbaio[m]> i'd be surprised if anyone is doing serious embedded stuff on 1.48
<diondokter[m]> This is a nice overview of what everybody is at: https://lib.rs/stats#rustc
<diondokter[m]> Seems like 1.56 is the biggest cutoff point
<dirbaio[m]> makes sense, 1.56 added the 2021 edition
<dirbaio[m]> and the next biggest cutoff is 1.31 whcih added the 2018 edition
<dirbaio[m]> that graph is cool :D
<danielb[m]> data is beautiful
fooker has quit [Ping timeout: 246 seconds]
fooker has joined #rust-embedded
mfiumara[m] has joined #rust-embedded
<mfiumara[m]> Hey hope this is the correct channel for this question.. I'm trying to compile my app using defmt package. All's well untill I try to compile in using `DEFMT_LOG=info cargo build`, I get the following output:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/aVcVrzqAzdOrAbzGPfdXHzpR>)
<dirbaio[m]> do you have -Tdefmt.x in either build.rs or .cargo/config.toml?
<mfiumara[m]> Nope... Did I miss something in the docs?
<dirbaio[m]> add it, after -Tlink.x
<mfiumara[m]> I don't have any -Tlink.x in my build.rs
<mfiumara[m]> oh wait I do
<JonathanDickinso> it might be in your .cargo/config
<mfiumara[m]> Thanks I see I missed it in the docs here https://defmt.ferrous-systems.com/setup
fooker has quit [Ping timeout: 246 seconds]
crabbedhaloablut has quit []
fooker has joined #rust-embedded
nex8192 has left #rust-embedded [Error from remote client]
nex8192 has joined #rust-embedded
<mfiumara[m]> Can't seem to get defmt to print out anything over RTT... I must be misconfiguring something . When using `target-rtt` crate I get normal output over RTT, is there anything I'm missing?... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/bqNxBcMPiKTULFgMKXdBVnfd>)
<mfiumara[m]> Anyone faced similar issues?
<mfiumara[m]> the panic is unrelated to the logs btw
<danielb[m]> Do you have the DEFMT_LOG or whatever env var set?
<mfiumara[m]> I've compiled the code with DEFMT_LOG=trace cargo build
<mfiumara[m]> My `info!` macros are not doing anything it seems.
<mfiumara[m]> I have used target-rtt directly using `rprint` etc. and that seems to work fine.
<adamgreig[m]> How do you program it after building?
<JamesMunns[m]> What are you using to run your firmware? probe-run or the probe-rs CLI?
<mfiumara[m]> blackmagic probe
<JamesMunns[m]> Then what do you use to listen to the RTT that defmt prints out?
<adamgreig[m]> bmp supports RTT but I think not defmt
<JamesMunns[m]> You'll need to use something that can "decode" the defmt-encoded messages, so probe-run or the probe-rs-cli, it uses a non-text binary format (and the original ELF file) you need to decode
<JamesMunns[m]> yep, defmt spits out binary data over RTT, instead of plain text
<mfiumara[m]> oh wow oke
<mfiumara[m]> Well I can't use probe-rs due to the nature of the bmp
<mfiumara[m]> So then defmt is out of the question for me?
<adamgreig[m]> I think in principle you might be able to pipe the defmt data out of bmp and into the defmt decoder? Not sure
<JamesMunns[m]> I'm not sure if probe-rs supports BMP, but I think if you can pipe the RTT output into the defmt-print, it should work, something like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/UvuZGepcRmJQinXewJZjhHdo>)
<mfiumara[m]> It's just a serial device that spits out the rtt
<adamgreig[m]> probe-rs doesn't, bmp runs a gdb stub on-probe that you talk to over usb-uart but probe-rs doesn't have a way to talk to gdb
<adamgreig[m]> But yea, maybe you can just cat the uart and pipe it into defmt-print then...
<JamesMunns[m]> Ah yeah, that or like `< the-rtt-uart`
<mfiumara[m]> Alright thanks for the help I didn't realize the binary format
<mfiumara[m]> I should be able to figure something out here
<JamesMunns[m]> But yeah, defmt is very neat, but it manages to be very efficient by taking all the strings and stuff, and leaving them in the debug info of your compiled program, instead of putting them in on the device itself. so instead of formatting data and text together, over RTT it just sends something like "print string #123 and here's the data for it", and your PC does the formatting instead.
<JamesMunns[m]> Def check out the docs: https://defmt.ferrous-systems.com/introduction
<JamesMunns[m]> but that's why it needs a decoder, and the elf file you compiled, so it can use that to help decode.
<mfiumara[m]> Oke cool it's making more sense now. I'm actually debugging an external crate dependency that's using solely defmt logging.
<mfiumara[m]> The simple `cat /dev/xxx` pipe does not seem to work so will try some alternatives
<JamesMunns[m]> do you have xxd installed?
<JamesMunns[m]> oh, what OS are you on?
<JamesMunns[m]> I think by default on linux it line-buffers, so you have to use stty to make it not do that
<mfiumara[m]> It's a mac cat /dev/tty.usbmodem98B724953 | defmt-print -e target/thumbv8m.main-none-eabihf/debug/nrf91-at-client-rs
<JamesMunns[m]> k, gimme a sec
<JamesMunns[m]> I think I've done this on mac before
<JamesMunns[m]> no wait, that might do the speed setting, and not disable buffering, hmm
<mfiumara[m]> That seems to work :)
<JamesMunns[m]> oh!
<JamesMunns[m]> yay :D
<mfiumara[m]> awesome
<mfiumara[m]> Thanks a lot, and I should really be reading more documentation haha
<JamesMunns[m]> :)
<JamesMunns[m]> for reference, most people here tend to use DAP or JLink probes, and use either the probe-run tool or probe-rs(-cli) to flash and run, and those tools automatically flash, then open RTT, then pipe that all into the decoder (and hold onto the firmware they flashed for decoding)
<JamesMunns[m]> that's probably why folks were a little confused at first
<mfiumara[m]> Yes I know I have used JLink before with probe-rs
<JamesMunns[m]> ah, gotcha :D
<mfiumara[m]> It works really well
<mfiumara[m]> It'd be great if bmp would be supported as well but I feel like the gdb approach does not fully fit the probe-rs project
<mfiumara[m]> Found this issue on it (https://github.com/probe-rs/probe-rs/issues/599)
<mfiumara[m]> The decoder would probably have to be baked into the bmp firmware
<JamesMunns[m]> Yeah, the issue would also be you'd have to give the whole firmware to the device, which won't have enough RAM for it
<mfiumara[m]> Ah the whole .elf
<JamesMunns[m]> without the firmware, you can decode the messages, but they just say like "string #123", which you look up in the elf, yeah
<mfiumara[m]> Well there's a host build for bmp that could work
<mfiumara[m]> Then again just piping the rtt to defmt-print does the job
<mfiumara[m]> I'll add the one-liner to that issue in case anyone else finds it
<JamesMunns[m]> might be worth adding:
<JamesMunns[m]> "The reason for the tricky stty and piping stuff in the first half is to avoid `cat` line-buffering, which doesn't make sense with the binary data output by defmt over rtt"
<eZioPan[m]> <adamgreig[m]> "could your PCB have the pin..." <- thanks for reply. I bought the flash chip without pcb, then use a "programmer clip" to connect it to mcu. I guess there shouldn’t be any hardwired.
<eZioPan[m]> I even try desolder a flash chip from a prebuilt flash module, then connect it to mcu with the clip, but it still not working.