<i509vcb[m]>
There is a "Motorola 3-wire" "Motorola 4-wire", "TI synchronous" and "National Microwire"
<i509vcb[m]>
* "Motorola 3-wire", "Motorola
<cr1901>
Which one is "the one everybody uses"?
<i509vcb[m]>
Pretty much datasheets are confusing
<cr1901>
(Also, I try to use the vendor names in MSP430, but due to SVD not being the original format of device descriptions, it's not always possible to construct a good name for all registers. I try my best given the circumstances.)
<i509vcb[m]>
yeah some of the SVD names are kind of bad
<i509vcb[m]>
Or having to come up with enum names that make sense to avoid duplicating the same enum 32 times
<cr1901>
most SVDs are not great (looking at you, LPC8xx)
<i509vcb[m]>
At least I am using chiptool for the peripherals so I can reuse parts as needed
norineko has quit [Remote host closed the connection]
norineko has joined #rust-embedded
jistr has quit [Quit: quit]
jistr has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
sroemer has joined #rust-embedded
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Client Quit]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Client Quit]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 246 seconds]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Remote host closed the connection]
Gilfoyl3 has joined #rust-embedded
starblue has joined #rust-embedded
Gilfoyl3 has quit [Quit: Gilfoyl3]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Remote host closed the connection]
Gilfoyl3 has joined #rust-embedded
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
dngrs[m] has joined #rust-embedded
<dngrs[m]>
why am I getting TRACE defmt logs even though I set DEFMT_LOG=debug?
Gilfoyl3 has quit [Quit: Gilfoyl3]
<dngrs[m]>
<dngrs[m]> "why am I getting TRACE defmt..." <- (this appears to only affect dependencies)
<dngrs[m]>
(also cargo +nightly seems to fix the issue?!)
Gilfoyl3 has joined #rust-embedded
pronvis has quit [Ping timeout: 252 seconds]
Gilfoyl3 has quit [Quit: Gilfoyl3]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Client Quit]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Remote host closed the connection]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Remote host closed the connection]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Quit: Gilfoyl3]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Remote host closed the connection]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Quit: Gilfoyl3]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Client Quit]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Client Quit]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Remote host closed the connection]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Remote host closed the connection]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Remote host closed the connection]
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Remote host closed the connection]
k86td has joined #rust-embedded
Gilfoyl3 has joined #rust-embedded
k86td has quit [Remote host closed the connection]
Gilfoyl3 has quit [Client Quit]
duderonomy has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
igiona[m] has joined #rust-embedded
<igiona[m]>
dngrs: have you done a cargo clean after changing DEFMT_LOG ?
<dngrs[m]>
igiona[m]: > <@igiona:matrix.org> dngrs: have you done a cargo clean after changing DEFMT_LOG ?
<igiona[m]>
Does anyone knows how the device flashing can be skipped when cargo run is performed?
<igiona[m]>
It's quite annoying to wait the flashing of the FW even when it did not change
<dngrs[m]>
I'm in bed now, will do some more testing later to be really sure stuff has been cleaned
<igiona[m]>
Does anyone knows how the device flashing can be skipped when cargo run is performed?
<igiona[m]>
It's quite annoying to wait the flashing of the FW even when it did not change
<igiona[m]>
s/knows/know/
<igiona[m]>
* Does anyone know how the device's flashing can be skipped when cargo run is performed?
<igiona[m]>
It's quite annoying to wait the flashing of the FW even when it did not change
M9names[m] has joined #rust-embedded
<M9names[m]>
probe-rs run --preverify (not available in the released version, you'll need to install from git)
<diondokter[m]>
M9names[m]: Oh sick!
tamme[m] has joined #rust-embedded
<tamme[m]>
<jannic[m]> "Is it somehow possible to select..." <- sorry I missed the meeting, yes you can filter by dependency, it even lets you select the version of the dependency, just open the "Dependency" filter and search for embedded-hal :) Also all drivers supporting 1.0 have a little checkmark in the description ✅️
<tamme[m]>
<adamgreig[m]> "oh, yea, we could definitely..." <- I could add a default filter for "only list e-h 1.0 crates" but then the list would look even smaller then now :D
<Ralph[m]>
btw: are there plans for anything similar to drive-rs for HALs? it'd be nice to easily get a list of supported MCUs
<tamme[m]>
Ralph[m]: so far only ideas and no plans :) But if somebody wants to pick it up I would love to help. It would mostly be about figuring out what you want to filter by (e.g. number of I2C interfaces) and figuring out how to use a HAL, e.g. `embassy-stm = { ..., features = ["X123"]}`
<tamme[m]>
I also talked with chrysn about having a list of BSPs, or rather a common format to describe a BSP and then have a list of those as well
koalillo has left #rust-embedded [#rust-embedded]
thejpster[m] has joined #rust-embedded
<thejpster[m]>
That’s not all it does.
<thejpster[m]>
POCI is going to be Peripheral Out Controller In. Or one half of the SPI Bus’s full duplex data path.
<scorpion2185[m]>
i can avoid to connect the cable
Makarov19 has joined #rust-embedded
Makarov55 has quit [Ping timeout: 256 seconds]
<dirbaio[m]>
does anyone know what could cause this?
<dirbaio[m]>
- Building in my workstation (Arch Linux), everything's fine
<dirbaio[m]>
- Building inside an Ubuntu 24.04 docker image, the firmware comes out a few kb bigger (and therefore doesn't fit in flash and the build fails)
<dirbaio[m]>
exact same code, exact same rust-toolchain.toml, etc etc
<dirbaio[m]>
i've tried rm -rf target ~/.rustup ~/.cargo, still reproduces
xnor has quit [Quit: WeeChat 3.4]
<dirbaio[m]>
it's extremely baffling
<dirbaio[m]>
and annoying, because it's causing ci to fail :D. The differences reproduce whether I run the ubuntu image in ci or locally
<dirbaio[m]>
and it's like ... random. you change something unrelated in the code or Cargo.toml and the issue goes away
<dirbaio[m]>
and i've also seen the opposite, CI coming up with smaller binaries than local
<dirbaio[m]>
wtf
<thejpster[m]>
Same host target and target target?
<dirbaio[m]>
yep
<dirbaio[m]>
* yep. host is all x64
<thejpster[m]>
Yeah but could be musl
<dirbaio[m]>
no, arch is glibc
<dirbaio[m]>
Fedora also gives different results as Ubuntu
<dirbaio[m]>
(haven't checked if Fedora and Arch match)
<thejpster[m]>
Not a cargo.lock difference?
<dirbaio[m]>
nope 🥲
<thejpster[m]>
Does cargo build -v look the same?
<thejpster[m]>
If so, what about ldd rustup which rustc
<thejpster[m]>
* If so, what about `ldd rustup which rustc
<thejpster[m]>
My thinking is to check if cargo is driving the compiler the same way
<thejpster[m]>
Then check the compiler
<thejpster[m]>
Also are you using lld or ld?
<thejpster[m]>
And did you leave RUSTFLAGS set by accident? I’ve seen that. But the verbose build will show that up.
<JamesMunns[m]>
Are you using gcc as a linker? Or stock lld?
<dirbaio[m]>
the final cortex-m binary is linked with lld
<dirbaio[m]>
* linked with rust-lld
<dirbaio[m]>
not sure about proc macros / build.rs
<JamesMunns[m]>
Ah, just saw how asked the same
<JamesMunns[m]>
s/how/JP/
<dirbaio[m]>
RUSTFLAGS=--print=link-args doesn't seem to apply to build scripts etc
<dirbaio[m]>
so I can't find a way to get the linker invocation for those :(
<dirbaio[m]>
I guess they'd be using the system linker
<dirbaio[m]>
the final link cmdline is identical
Makarov19 has quit [Quit: Client closed]
starblue has quit [Ping timeout: 265 seconds]
<dirbaio[m]>
nothing obvious comes out from looking at the binaries either! :(
<dirbaio[m]>
the ubuntu binary is slightly bigger ... everywhere. many many functions that are 10-50 bytes bigger.
<dirbaio[m]>
no single thing that got bigger
<dirbaio[m]>
well
<dirbaio[m]>
.text gets ~5kb bigger from this "death from a thousand cuts"
<dirbaio[m]>
and .data gets 5.5kb bigger from ... not sure what
<JamesMunns[m]>
Are they both clean envs? Maybe a parent folder .cargo/config-toml?
<dirbaio[m]>
well ubuntu is clean, arch is just my machine. but if it was some config.toml thing it'd show up in the cmdlines...
Koen[m] has joined #rust-embedded
<Koen[m]>
<dirbaio[m]> "the ubuntu binary is slightly..." <- Not that is matters much for finding what triggers the difference, but are the functions different in instructions, is it maybe just padding because of function alignment?
<dirbaio[m]>
I don't think so, the first function that diverges starts at the same addr
<dirbaio[m]>
tried on a clean archlinux docker, I get the same result as my main archlinux ...
k86td has joined #rust-embedded
<k86td>
hello, someone's online?
Gilfoyl3 has joined #rust-embedded
<dirbaio[m]>
it also repros with the embassy examples
<dirbaio[m]>
but much less dramatically
<dirbaio[m]>
I give up
Gilfoyl3 has quit [Client Quit]
apirkle has quit [Changing host]
apirkle has joined #rust-embedded
starblue has joined #rust-embedded
Gilfoyl3 has joined #rust-embedded
Gilfoyl3 has quit [Quit: Gilfoyl3]
Gilfoyl3 has joined #rust-embedded
hadez[m] has joined #rust-embedded
<hadez[m]>
I'm working with a ch32v203k8tx uC and am trying to find a way to handle sharing of the I2C bus between multiple devices. Does anyone have any suggestions between embedded-hal-bus and shared-bus or something else?