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
<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]>
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.
<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]>
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)
<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
<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
<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]>
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.
<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]>
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.