<re_irc>
<@dngrs:matrix.org> (from a crate that uses either `libm` or `micromath`)
<re_irc>
<@sajattack:matrix.org> nice
<re_irc>
<@sajattack:matrix.org> odd that such a workaround is needed, but thanks
<re_irc>
<@dngrs:matrix.org> I think you only need it when you're not directly linking to the functions yourself, at least it's like that with micromath
<re_irc>
<@sajattack:matrix.org> yeah
<re_irc>
<@sajattack:matrix.org> I ran into an issue with fontdue missing some float math it needed
<re_irc>
<@dngrs:matrix.org> after thinking about it some more I came to the conclusion that those libs are not primarily made for C linkage
<re_irc>
<@fragadaleta:matrix.org> i have a bunch of robots that need to communicate at ~ 5 messages/sec to stay in sync and currently thinking of xbee zigbee for that. Do you know any better alternative to a mesh network for that case?
PyroPeter has quit [Ping timeout: 250 seconds]
<Darius>
wifi? :)
PyroPeter has joined #rust-embedded
<Darius>
I used to have some XBee's as comms for my brew fridge controller and sprinkler but when they died I replaced them with ESP8266 or ESP32s
<re_irc>
<@fragadaleta:matrix.org> thing is that these robots will be in open environments and there should be no single point of failure
<re_irc>
<@fragadaleta:matrix.org> the assumption is that all robots keep a relatively constant range among each other aka they stay grouped
<Darius>
ahh right
<Darius>
well the XBee stuff was reasonably reliable for me
<Darius>
and the binary protocol (not the AT one) is very easy to parse
<re_irc>
<@fragadaleta:matrix.org> so i guess xbee is the best i can get in such a scenario?
<Darius>
honestly I am not sure, I m pretty sure you could find several Zigbee implementations
<Darius>
I used them because I got them for free for helping a friend with a project
<re_irc>
<@fragadaleta:matrix.org> ok well, thanks 🙂
<Darius>
eg nordic semi have a precanned stack I think
<re_irc>
<@fragadaleta:matrix.org> do you have a link?
<Darius>
I guess it also depends what level of "doneness" you require
<Darius>
XBee is nice as a "plug and play" thing
<re_irc>
<@fragadaleta:matrix.org> yeah i know that difference. In the ideal scenario of having no issues with zigbee, do you think I should expect same perf?
<Darius>
I think the performance is highly dependant on signal conditions so very hard to say
<re_irc>
<@fragadaleta:matrix.org> yeah you are very right.
<re_irc>
<@fragadaleta:matrix.org> which made me think about other solutions eventually
<Darius>
might be worth considering difference bands too
<re_irc>
<@fragadaleta:matrix.org> and is the Rust toolchain mature for zigbee/xbee?
<Darius>
you mean write code in rust to run on the Xbee MCU?
<Darius>
I dunno if anyone has attempted that..
<re_irc>
<@tk.cket:matrix.org> Hiya!
<re_irc>
<@tk.cket:matrix.org> on the set up page of the book and running into an issue
<re_irc>
<@tk.cket:matrix.org> $ # make sure you are in src/03-setup of the books source code
<re_irc>
<@tk.cket:matrix.org> $ # If you are working with micro:bit v2
<re_irc>
<@tk.cket:matrix.org> $ rustup target add thumbv7em-none-eabihf <- this works
<re_irc>
<@tk.cket:matrix.org> $ cargo embed --target thumbv7em-none-eabihf <- this doesn't
<re_irc>
<@tk.cket:matrix.org> error : "Error Failed to parse supplied configuration:
<re_irc>
<@tk.cket:matrix.org> expected an equals, found a newline at line 5 column 4 in Embed.toml TOML file
<re_irc>
<@dirbaio:matrix.org> don't uncomment the `v2` thing, it's just a comment telling you microbit v2 is nrf52833
<re_irc>
<@tk.cket:matrix.org> ohhhhh
<re_irc>
<@tk.cket:matrix.org> okay!
<re_irc>
<@tk.cket:matrix.org> awesome
<re_irc>
<@tk.cket:matrix.org> super that worked! thank dirbaio!
<re_irc>
<@tk.cket:matrix.org> thanks*
creich has quit [Quit: Leaving]
creich has joined #rust-embedded
<re_irc>
<@fragadaleta:matrix.org> irc_libera_darius:psion.agg.io: well starting with interacting with an xbee?
<re_irc>
<@fragadaleta:matrix.org> recv/send packets for instance
<Darius>
not a clue sorry
<Darius>
but it's really not a very difficult protocol
<re_irc>
<@k900:0upti.me> Generally an XBee device will be something external to your board
<re_irc>
<@k900:0upti.me> That you just talk to over I2C or whatever
<re_irc>
<@k900:0upti.me> There's no special language or compiler level support needed
<re_irc>
<@tk.cket:matrix.org> Hey Guys, another issue
<re_irc>
<@tk.cket:matrix.org> Let's debug!
<re_irc>
<@tk.cket:matrix.org> Since cargo-embed is blocking our current shell we can simply open a new one and cd back into our project directory. Once we are there we first have to open the binary in gdb like this:
<re_irc>
<@tk.cket:matrix.org> ```# For micro:bit v2
<re_irc>
<@tk.cket:matrix.org> I don't know which one this is in chapter 3
<re_irc>
<@tk.cket:matrix.org> NOTE Depending on which GDB you installed you will have to use a different command to launch it, check out chapter 3 if you forgot which one it was.
<re_irc>
<@tk.cket:matrix.org> but on my terminal gdb command can't be found
<re_irc>
<@tk.cket:matrix.org> I installed this ```$ # Arm GCC toolchain
<re_irc>
<@tk.cket:matrix.org> $ brew tap ArmMbed/homebrew-formulae
<re_irc>
<@tk.cket:matrix.org> pls help
<re_irc>
<@k900:0upti.me> You probably don't have a gdb
<re_irc>
<@k900:0upti.me> Try `brew install gdb`?
<re_irc>
<@k900:0upti.me> ...or something
<re_irc>
<@k900:0upti.me> I have no idea how OSX stuff works
<re_irc>
<@luojia65:matrix.org> Hello! I wrote a small project to deserialize linux Device Tree Binary blob in rust and serde, it's no_std compatible and can be used on motherboard firmware like RISC-V SBI implementations. Link: https://github.com/luojia65/serde_device_tree
<re_irc>
<@tk.cket:matrix.org> k900:0upti.me: hmm that works on some level. let's see if it takes me all the way
<re_irc>
<@tk.cket:matrix.org> Remote debugging using :1337
<re_irc>
<@tk.cket:matrix.org> 0x00000116 in nrf52833_pac::{{impl}}::fmt (self=0xd472e165, f=0x3c195ff7) at /home/nix/.cargo/registry/src/github.com-1ecc6299db9ec823/nrf52833-pac-0.9.0/src/lib.rs:157
<re_irc>
<@tk.cket:matrix.org> Remote debugging using :1337
<re_irc>
<@tk.cket:matrix.org> this is what shows
<re_irc>
<@tk.cket:matrix.org> tk.cket:matrix.org: this is what is supposed to show
<re_irc>
<@tk.cket:matrix.org> ERROR probe_rs_gdb_server::gdb_server_async > An error with the current connection has been encountered. It has been closed.
<re_irc>
<@tk.cket:matrix.org> "Finished flashing in 0.319s
<re_irc>
<@k900:0upti.me> Try reconnecting the device maybe?
<re_irc>
<@tk.cket:matrix.org> This is my embed.toml
rardiol has joined #rust-embedded
<re_irc>
<@tk.cket:matrix.org> remote :1337
<re_irc>
<@tk.cket:matrix.org> instead of target
<re_irc>
<@tk.cket:matrix.org> Remote debugging using :1337
<re_irc>
<@tk.cket:matrix.org> 0x00000116 in nrf52833_pac::{{impl}}::fmt (self=0xd472e165, f=0x3c195ff7) at /home/nix/.cargo/registry/src/github.com-1ecc6299db9ec823/nrf52833-pac-0.9.0/src/lib.rs:157
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<re_irc>
<@9names:matrix.org> you'll need to install the rest of the toolchain just to get gdb which is a waste, but at least it's well tested, up to date, and from a reliable source
<re_irc>
<@tk.cket:matrix.org> ok checking... flashing stopped so figuring that out first
<re_irc>
<@robgal519:matrix.org> Hi i have a quick question about embedded-hal. I wanted to create a simple application that will read/set gpio. I wanted to be platfrom independent, so I started by wrinting platform init function, and my idea was that this function will return struct with gpio used by application. My issue is that I can not create such platform independent struct. I tried
<re_irc>
<@robgal519:matrix.org> pub use embedded_hal::digital::v2::InputPin;
<re_irc>
<@robgal519:matrix.org> pub use embedded_hal::digital::v2::OutputPin;
<re_irc>
<@adamgreig:matrix.org> in short: it didn't work in practice. our dependencies would bump their msrv without a semver-breaking change, so short of never depending on anything outside the wg, we couldn't actually maintain that promise
<re_irc>
<@adamgreig:matrix.org> I would say it's not "settled opinion" that bumping msrv is a semver break
<re_irc>
<@dirbaio:matrix.org> hm but if 0.7 was released with a "compiles on stable Rust 1.40 and up", this is reneging on that promise
<re_irc>
<@adamgreig:matrix.org> and 0.7.0 would continue to build on stable rust 1.40, but 0.7.8 might not
<re_irc>
<@adamgreig:matrix.org> you can always pin 0.7.0
<re_irc>
<@dirbaio:matrix.org> but the whole point of semver is you can always update patch releases without anything breaking
<re_irc>
<@adamgreig:matrix.org> unfortunately that just doesn't turn out to be true in the rust ecosystem when it comes to msrv
<re_irc>
<@dirbaio:matrix.org> another thing would be if it was released with the "compiles on latest stable rust" promise
<re_irc>
<@dirbaio:matrix.org> as time passes "latest stable rust" changes
<re_irc>
<@adamgreig:matrix.org> another aspect of this discussion at the time was that we're not proving commercial legacy support here, the conclusion was that "latest stable" is good enough and anyone wanting more can pay someone for it
<re_irc>
<@adamgreig:matrix.org> also literally no one said they needed to support older rustc
<re_irc>
<@dirbaio:matrix.org> it's not that I personally care, I use nightly 🤣
<re_irc>
<@adamgreig:matrix.org> every use-case for supporting legacy rustc was hypothetical
<re_irc>
<@dirbaio:matrix.org> so I'm OK with bumping msrv, let's use all the latest shiny features
<re_irc>
<@adamgreig:matrix.org> like I said, it used to be the policy that updating msrv required bumping semver (and we would always be stable-1) but it caused a bunch of very hard to resolve problems (not least because it was impossible in practice due to dependencies)
<re_irc>
<@dirbaio:matrix.org> it's just a bit surprising that msrv policy change applies "retroactively"
<re_irc>
<@ryan-summers:matrix.org> I would imagine this is why people wanted to abandon msrv policies entirely
<re_irc>
<@adamgreig:matrix.org> meh, I think most of the crates where it's relevant are probably already semver bumped since we updated that policy over a year ago
<re_irc>
<@adamgreig:matrix.org> most of our crates do track their specific msrv, test it in CI, and only bump it when actually required for some specific new feature
<re_irc>
<@dirbaio:matrix.org> but yeah, not applying it retroactively would suck
<re_irc>
<@dirbaio:matrix.org> for example you can't semver-hack 0.7 -> 0.8
<re_irc>
<@adamgreig:matrix.org> so it's not a total wild west of "we only test on stable and good luck", and indeed many crates end up with quite generous old msrv
<re_irc>
<@dirbaio:matrix.org> as 0.7 would depend on 0.8 which would bump the msrv, so the result wouldn't build in rust 1.40 💀
<re_irc>
<@adamgreig:matrix.org> cortex-m 0.7 was released after we changed our msrv policy anyway
<re_irc>
<@adamgreig:matrix.org> we'd have to release a 0.7.X which depended on 0.8, and 0.7.X's msrv would not be 1.40
<re_irc>
<@dirbaio:matrix.org> and being able to semver-hack it is more valuable than keeping compatibility with rust 0.40 🤣
<re_irc>
<@adamgreig:matrix.org> and so, yes, someone with rustc 1.40 who ran cargo update would find the build broke and they needed to now either pin older c-m or update 1.40
<re_irc>
<@adamgreig:matrix.org> but in practice this happens _all the time_
<re_irc>
<@dirbaio:matrix.org> yeah....
<re_irc>
<@adamgreig:matrix.org> many common and popular dependencies will bump msrv in patch releases
<re_irc>
<@adamgreig:matrix.org> including things we depend on
<re_irc>
<@adamgreig:matrix.org> so anyone in that situation is already stuffed, basically
<re_irc>
<@adamgreig:matrix.org> (or at least, should expect that 'cargo update' might need to be managed carefully if they're tied to an old rustc)
<re_irc>
<@adamgreig:matrix.org> it's not like it will break out of the blue, right? only when you do `cargo update`
<re_irc>
<@ryan-summers:matrix.org> Honestly I consider cargo update pretty reckless :P
<re_irc>
<@ryan-summers:matrix.org> Opening yourself up to supply-chain attacks
<re_irc>
<@adamgreig:matrix.org> yea, I tend to just update my direct dependencies manually
<re_irc>
<@adamgreig:matrix.org> for "serious" projects you're probably already vendoring everything
<re_irc>
<@adamgreig:matrix.org> (or using a private git fork or private cargo repository or whatever)
<re_irc>
<@adamgreig:matrix.org> but opinions are strong and vary wildly on this sort of thing :P
<re_irc>
<@ryan-summers:matrix.org> Very true :) Although I completely agree with what you've said so far
<re_irc>
<@adamgreig:matrix.org> I suspect we share a slightly more conservative embedded mindset when it comes to dependencies, heh
<re_irc>
<@adamgreig:matrix.org> or maybe just the paperwork burden of updating deps 💀
<re_irc>
<@dirbaio:matrix.org> i'm excited to finally have inline asm by default :D
<re_irc>
<@adamgreig:matrix.org> i am _so_ excited for stable inline_asm (and global_asm...)
<re_irc>
<@ryan-summers:matrix.org> One of the projects I'm on is just now re-releasing a few changed lines and the verification process is expected to last until April :^)
<re_irc>
<@dirbaio:matrix.org> the current outline-inline-asm is failing to inline in my builds (last I checked, even with LTO)
<re_irc>
<@adamgreig:matrix.org> gotta keep the V&V team employed somehow
<re_irc>
<@adamgreig:matrix.org> cortex-m-rt's linker script can probably become a global_asm call too
<re_irc>
<@adamgreig:matrix.org> uh
<re_irc>
<@adamgreig:matrix.org> I mean, reset vector
<re_irc>
<@ryan-summers:matrix.org> Can you have linker commands in asm?
<re_irc>
<@ryan-summers:matrix.org> Oh
<re_irc>
<@adamgreig:matrix.org> linker script will remain
<re_irc>
<@adamgreig:matrix.org> but not `asm.S`
<re_irc>
<@adamgreig:matrix.org> use rust for the proprocessing hopefully...
<re_irc>
<@ryan-summers:matrix.org> I thought a lot of cortex-m's assembly was because the contracts with rust's runtime weren't yet established
<re_irc>
<@adamgreig:matrix.org> could then have cargo features enable stuff too.... yay
<re_irc>
<@ryan-summers:matrix.org> Think you answered my comment
<re_irc>
<@ryan-summers:matrix.org> Wait no, why can we replace some of the crt0.s work?
<re_irc>
<@ryan-summers:matrix.org> I thought that had to be asm because we aren't respecting contracts of rust pointer aliasing etc.
<re_irc>
<@adamgreig:matrix.org> we still need a reset vector written in asm, which handles memory init
<re_irc>
<@ryan-summers:matrix.org> Okay, gotcha
<re_irc>
<@adamgreig:matrix.org> but, global_asm should let us put that routine into a .rs file
<re_irc>
<@adamgreig:matrix.org> (I haven't tested this, I just hope so)
<re_irc>
<@ryan-summers:matrix.org> global_asm doesn't require that you respect aliasing rules etc?
<re_irc>
<@ryan-summers:matrix.org> Or is it because we never pass the variables into rust code?
<re_irc>
<@adamgreig:matrix.org> yea, the latter
<re_irc>
<@dirbaio:matrix.org> it's UB to execute rust before data/bss is inited
<re_irc>
<@dirbaio:matrix.org> but it's not UB to execute ASM, and it doesn't matter if it's in a `.S` or in `global_asm!` inside a `.rs`
<re_irc>
<@ryan-summers:matrix.org> Can you access linker symbols directly in global_asm?
<re_irc>
<@adamgreig:matrix.org> I expect so?
<re_irc>
<@adamgreig:matrix.org> but doesn't really matter if not, I can extern access them from rust and pass in the addresses without creating any aliasing references
<re_irc>
<@ryan-summers:matrix.org> Ah true
<re_irc>
<@adamgreig:matrix.org> (but I'm sure you can, they're global symbols)
<re_irc>
<@ryan-summers:matrix.org> Yeah I'd be surprised if you couldn't
<re_irc>
<@adamgreig:matrix.org> so no more pre-built binary blobs at all, no more arm-none-eabi-gcc for anything
<re_irc>
<@ryan-summers:matrix.org> That's a very welcome reality
<re_irc>
<@adamgreig:matrix.org> and all the cortex_m::asm calls can inline
<re_irc>
<@adamgreig:matrix.org> probably still quite unsound to have the call to write sp though, lol
<re_irc>
<@adamgreig:matrix.org> maybe if inline(always).........
<re_irc>
<@dirbaio:matrix.org> adamgreig: lol which one?
<re_irc>
<@adamgreig:matrix.org> the problem is that if you update MSP but it's not inlined and needs to read the return address from the stack....
<re_irc>
<@adamgreig:matrix.org> (in practice it often assembles to a single level of subroutine call using blx and bx lr, which is OK? but still)
<re_irc>
<@dirbaio:matrix.org> oh wow
<re_irc>
<@dirbaio:matrix.org> yeah I think there's no way to use that soundly! :D
<re_irc>
<@adamgreig:matrix.org> well if it inlines maybe you can
<re_irc>
<@adamgreig:matrix.org> its purpose is for things like bootloaders mostly
<re_irc>
<@adamgreig:matrix.org> OSs more likely to write PSP I guess
<re_irc>
<@dirbaio:matrix.org> uh, it's still UB, the compiler doesn'tt guarantee inlining
<re_irc>
<@adamgreig:matrix.org> yea, true
<re_irc>
<@adamgreig:matrix.org> "often works in practice" 💀
<re_irc>
<@adamgreig:matrix.org> anyway hence deprecating it
<re_irc>
<@adamgreig:matrix.org> should be a moot point with stable asm! as end-users can just write their little snippet by hand when required (or use cortex_m::asm::bootload / bootstrap of course)
rardiol has quit [Ping timeout: 256 seconds]
<re_irc>
<@mathias_koch:matrix.org> Is it possible to do stm32-rs patches to the svd for stm32l47x & stm32l48x? The device SVD's are called stm32l4x5 etc..?
rardiol has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> MathiasKoch: yea, annoyingly ST name their SVDs differently to their reference manuals, check the crate README for the list of devices: https://crates.io/crates/stm32l4
<re_irc>
<@adamgreig:matrix.org> L476, L486 are in the stm32l4x6 device/svd, L471 is the stm32l4x1 device
<re_irc>
<@adamgreig:matrix.org> L475 is in stm32l4x5
<re_irc>
<@mathias_koch:matrix.org> Yeah, that was not really the question..
<re_irc>
<@mathias_koch:matrix.org> Problem is i wanted to do a PR fixing this. (Check the footnote)
<re_irc>
<@fragadaleta:matrix.org> what's the state of Rust support for ADAFRUIT FEATHER NRF52840 ?
<re_irc>
<@k900:0upti.me> Good
<re_irc>
<@k900:0upti.me> All nRF52 things generally work well with Rust
<re_irc>
<@adamgreig:matrix.org> MathiasKoch: what's the issue? the l4x5 and l4x6 are the only devices on RM0351, though as well as 47x and 48x they use 49x and 4Ax, does 49x and 4Ax not have the register?
<re_irc>
<@mathias_koch:matrix.org> > does 49x and 4Ax not have the register
<re_irc>
<@mathias_koch:matrix.org> Exactly
<re_irc>
<@adamgreig:matrix.org> the only practical thing to do is include that register for all l4x6 devices really. you could copy a new svd just for the l496 and l4a6 but it's probably not worth it...?
<re_irc>
<@mathias_koch:matrix.org> So currently this register is completely missing in the pac
<re_irc>
<@adamgreig:matrix.org> sure, I think just add the register to l4x5 and l4x6 then
<re_irc>
<@mathias_koch:matrix.org> but should be included for only `stm32l47x & stm32l48x`
<re_irc>
<@fragadaleta:matrix.org> k900:0upti.me: so there is a hal or something for all periphereals?
<re_irc>
<@mathias_koch:matrix.org> adamgreig: But wouldn't that be wrong? Then it would also be added for l495 and l4A5 ? correct?
<re_irc>
<@adamgreig:matrix.org> it would be
<re_irc>
<@adamgreig:matrix.org> that's just how it is, though
<re_irc>
<@mathias_koch:matrix.org> But i don't think the register exists in those
<re_irc>
<@adamgreig:matrix.org> indeed
<re_irc>
<@mathias_koch:matrix.org> Ohh.. Soo either live with some devices having registers pointing to random mem, or live with other devices not being able to access it?
<re_irc>
<@k900:0upti.me> fragadaleta:matrix.org: That just wraps the nrf-rs HAL and pre-configures it to match the board's pinout
<re_irc>
<@adamgreig:matrix.org> yea, or create a whole new device that has identical SVDs and all identical code except for that one register
<re_irc>
<@mathias_koch:matrix.org> Awww :( That sucks..
<re_irc>
<@adamgreig:matrix.org> the groupings we use are the SVDs that ST provide, more or less
<re_irc>
<@adamgreig:matrix.org> we do that copying in some situations where there's huge differences
<re_irc>
<@mathias_koch:matrix.org> Yeah, that makes sense
<re_irc>
<@adamgreig:matrix.org> but for example F405 and F415 differ in "do they have the crypto peripheral or not" and we just have one device for those (which does have crypto, and it just doesn't work on the f405)
<re_irc>
<@adamgreig:matrix.org> svd2rust doesn't know how to handle "these are the same chip except a few small differences", so the only choice is a total duplication
<re_irc>
<@mathias_koch:matrix.org> Alright. So how would i go around adding that single register? A patch, or directly to the device yaml?
<re_irc>
<@adamgreig:matrix.org> unfortunately for other families ST provide like a hundred SVDs, sometimes literally identical
<re_irc>
<@adamgreig:matrix.org> either is fine but since you'll want it in both l4x5 and l4x6 I'd suggest writing it inside common_patches and then including it in both
<re_irc>
<@mathias_koch:matrix.org> (y) Will give it a shot.. What's the easiest way of building it locally for me to patch my HAL?
<re_irc>
<@adamgreig:matrix.org> you should be able to just run `CRATES=stm32l4 make` inside `stm32-rs`
<re_irc>
<@mathias_koch:matrix.org> awesome 👍️
<re_irc>
<@adamgreig:matrix.org> and it will generate the stm32l4/ folder, then in your HAL you can `[patch.crates-io] stm32l4 = { path = "../stm32-rs/stm32l4" }` sort of thing
<re_irc>
<@mathias_koch:matrix.org> adamgreig: everything works perfectly! Will open a PR on it tomorrow 👍️
<re_irc>
<@adamgreig:matrix.org> great! thanks :)
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
xnor has quit [Changing host]
xnor has joined #rust-embedded
<re_irc>
<@conrad:conradlparker.com> Hi there! I'm getting started with Embedded rust and figured I would join this matrix!
<re_irc>
<@tholmie:matrix.org> Welcome 👋🏼
rardiol has quit [Quit: No Ping reply in 180 seconds.]
rardiol has joined #rust-embedded
<re_irc>
<@henrik_alser:matrix.org> marvin: Welcome! Good idea! ✨
<re_irc>
<@firefrommoonlight:matrix.org> mathias_koch:matrix.org: I had to add a new variant to the stm32-rs PAC for something similar. See L412 PAC item, for newer RTC on L41x and L42x
<re_irc>
<@firefrommoonlight:matrix.org> So, didn't find an easy fix
<re_irc>
<@firefrommoonlight:matrix.org> But got a working solution
<re_irc>
<@mathias_koch:matrix.org> where would that be?
<re_irc>
<@mathias_koch:matrix.org> Ahh.. `stm32l412.yaml` i suspect?
<re_irc>
<@mathias_koch:matrix.org> I like that better than adding a register that does not exist to other devices, on the other hand i guess it just makes it incrementally harder to implement the HAL's ? even more features?
<re_irc>
<@adamgreig:matrix.org> for the sake of one register that's in the same reference manual but with a little note saying it's only on some devices, I'd just add it to the current SVDs
<re_irc>
<@adamgreig:matrix.org> if there were lots more differences - like the entire RTC peripheral in the L412 case iirc? - then maybe it's more worthwhile
<re_irc>
<@mathias_koch:matrix.org> I am totally fine with this solution from my end 👍️ It's more the principle of doing something that you know MIGHT negatively impact other implementations fells a bit off :p Guess we need to compromise somewhere, given the resources available to maintain this, as well as keeping it simple enough to use for HAL's
<re_irc>
<@dirbaio:matrix.org> oh no a GPIO reg variation? ☠️
<re_irc>
<@dirbaio:matrix.org> why only `L4[78]x`? others don't have ADC? or is the "analog switch" always connected in those? 🤔
<re_irc>
<@mathias_koch:matrix.org> Guess i will try to find and fix them all here..
<re_irc>
<@mathias_koch:matrix.org> dirbaio:matrix.org: No idea :p Someone in the office ST had a "great" idea, that turned out not to be great after two series?
<re_irc>
<@mathias_koch:matrix.org> when looking in the yamls of stm32-rs, what makes the difference on whether a field is "covered" vs not? `82/209 fields covered`
<re_irc>
<@adamgreig:matrix.org> a field is "covered" if it either has enumeratedValues or has a writeConstraint (where you specify a range of permitted numbers)
<re_irc>
<@mathias_koch:matrix.org> aha.. How would those look? searching for `writeConstraint` & `enumeratedValues` yields 0 results?
<re_irc>
<@adamgreig:matrix.org> enumeratedValues is where you specify the possible values the field can take as a list of named values
<re_irc>
<@adamgreig:matrix.org> and writeConstraint is when you give the [start, end] permissible values, useful for numeric fields
<re_irc>
<@mathias_koch:matrix.org> Ahh, right 👍️
<re_irc>
<@ubik:matrix.org> anyone using rp2040 with probe-run and pico-debug?
<re_irc>
<@richardeoin:matrix.org> jamesmunns:beeper.com: There was a blog post about that board a couple of months back (inspired by [thejpster](https://matrix.to/#/thejpster:matrix.org) 's work even 🙌) and the author open-sourced their WIP repo