<re_irc>
<@burrbull:matrix.org> : Interesting. I never thought this way, but this could also work with typestates. Something like:
<re_irc>
pub enum SdaPin1 {
<re_irc>
B8(PB8<Alternate<x>>),
<re_irc>
}
<re_irc>
...
<re_irc>
impl Instance for I2C1 {
<re_irc>
type Sda = SdaPin1;
<re_irc>
type Scl = SclPin1;
<re_irc>
}
<re_irc>
let i2c_baro = I2c::new(dp.I2C1, SdaPin1::B8(pb8.into_alternate()), , SclPin1::B9(pb9.into_alternate()), I2cConfig::default());
<re_irc>
This adds some verbosity in user code, but now I2c does not have "PINS" generic.
<re_irc>
<@burrbull:matrix.org> -,
<re_irc>
<@burrbull:matrix.org> Interesting. I never thought this way, but this could also work with typestates. Something like:
<re_irc>
pub enum SdaPin1 {
<re_irc>
B8(PB8<Alternate<x>>),
<re_irc>
...
<re_irc>
impl Instance for I2C1 {
<re_irc>
}
<re_irc>
type Sda = SdaPin1;
<re_irc>
type Scl = SclPin1;
<re_irc>
...
<re_irc>
}
<re_irc>
let i2c_baro = I2c::new(dp.I2C1, SdaPin1::B8(pb8.into_alternate()), SclPin1::B9(pb9.into_alternate()), I2cConfig::default());
<re_irc>
This adds some verbosity in user code, but now I2c does not have "PINS" generic.
<re_irc>
<@korken89:matrix.org> : I agree here, I'll find some time to open an issue for this. E.g. i use a logging framework where embedded units in the field talk to a central backend that decodes logs. It works great, bit the backend needs to support all versions of defmt that can come. The issue then becomes, if you can only support one, what happens at times when the wire format breaks? Either loose logging support for all units in the field or force...
<re_irc>
... to an old version, either way you have become locked. :(
<re_irc>
<@korken89:matrix.org> I agree here, I'll find some time to open an issue for this. E.g. i use a logging framework where embedded units in the field talk to a central backend that decodes logs. It works great, with the only requirement that the backend needs to support all versions of defmt that can come. The issue then becomes, if you can only support one, what happens at times when the wire format breaks? Either loose logging support for all...
<re_irc>
... units in the field or force to an old version, either way you have become locked. :(
<re_irc>
<@burrbull:matrix.org> * generic (at least i hope so).
rardiol has quit [Read error: Connection reset by peer]
dc740 has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> At this pt, the reason I probably won't impl something like this is ensuring correct pins for all variants
<re_irc>
<@firefrommoonlight:matrix.org> There are also considerations like pin output speed, hardware PUs etc that may still need to be configured separately
<re_irc>
<@firefrommoonlight:matrix.org> Doable, but don't feel like the tedium
<re_irc>
<@dngrs:matrix.org> : I tried their git version a few days ago and it didn't support the new defmt wire format. I'm not seeing any recent commits in their log (https://github.com/knurling-rs/probe-run/commits/main) indicating updated support - am I missing something?
<re_irc>
<@dngrs:matrix.org> : (tangent) oof, the issue you linked (specifically, your comment) makes a good point. It seems like a rock vs hard place situation :|
<re_irc>
<@datdenkikniet:matrix.org> Pretty sure no "probe-run" that supports wire format 4 exists atm
<re_irc>
<@datdenkikniet:matrix.org> Since the latest version has "defmt-decoder = "=0.3.5""
<re_irc>
<@datdenkikniet:matrix.org> Which is yanked, and older than "0.3.6" which actually supports version 4
<re_irc>
<@dngrs:matrix.org> aye. so this bites every crate that uses a semver dependency on defmt
<re_irc>
<@dngrs:matrix.org> (as in "defmt = "0.3"")
<re_irc>
<@admin:orangemurker.com> : There is a PR open to update the defmt-decoder version. At this moment you can clone the repo and build it by yourself to fix the issue before an official release gets published.
<re_irc>
<@dngrs:matrix.org> : aye! I've been mostly pinning defmt to older versions for the time being but at some point this becomes tedious
<re_irc>
<@dngrs:matrix.org> it gets complicated by me running a defmt fork sometimes…
<re_irc>
<@sousandrei:matrix.org> Anyone used the sx127x_lora crate before? I've got it to compile and run on a STM32L433 Board with a FeatherWing RFM9x LoRa radio, but I get version mismatch :c
<re_irc>
Something is funky on the SPI?
<re_irc>
<@sousandrei:matrix.org> -Something is funky on the SPI?
<re_irc>
<@sousandrei:matrix.org> the reading register part is always returning zero 🤔
<re_irc>
<@datdenkikniet:matrix.org> Never tried it, but I would also recommend that you ask in #public-lora-wan-rs:matrix.org (https://matrix.to/#/#public-lora-wan-rs:matrix.org)!
<re_irc>
<@sousandrei:matrix.org> that is a path forward! Thank you
rardiol_ has quit [Ping timeout: 268 seconds]
dc740 has quit [Remote host closed the connection]
<re_irc>
<@andrewgazelka:matrix.org> do you need to run the new one to generate the json file?
<re_irc>
<@dirbaio:matrix.org> yeah, on the "stm32-data" repo run "cargo run --release --bin stm32-data-gen"
<re_irc>
<@dirbaio:matrix.org> you get the jsons in "build/data/"
<re_irc>
<@andrewgazelka:matrix.org> cool :)
<re_irc>
<@andrewgazelka:matrix.org> yea half of this project was just so I can understand the XML files better
<re_irc>
<@dirbaio:matrix.org> (I linked to the old repo because that one committed the generated json files, but we had to stop doing that as the repo size balooned beyond hundreds of megabytes 😭)
<re_irc>
<@dirbaio:matrix.org> the XMLs are awful
<re_irc>
<@andrewgazelka:matrix.org> ^^^^^ facts
<re_irc>
<@andrewgazelka:matrix.org> XML in general