<re_irc>
<Campbell He> dirbaio: What is the aim of chiptool? An alternative to svd2rust or maybe the next generation of svd2rust?
<re_irc>
<dirbaio> the README has some background on the improvements/differences vs svd2rust
<re_irc>
<dirbaio> I'd like for some to get merged back into svd2rust yeah
<re_irc>
<dirbaio> one is directly an unsoundness fix (use raw pointers instead of references), so it'd be great to get it into svd2rust
<re_irc>
<dirbaio> but I imagine others will be way, way too controversial (no owned peripheral singletons, all register access is unsafe)
<re_irc>
<dirbaio> so it's probably not going to happen
<re_irc>
<thalesfragoso> dirbaio: I would go with possibly broken behavior instead of unsound. And sorry for being soo pendantic
<re_irc>
<thalesfragoso> dirbaio: I was thinking, we use CS to steal peripherals today, but that still can cause races with the singletons
<re_irc>
<dirbaio> well there's the "dereferenceable" thing which is kinda theoretical
<re_irc>
<dirbaio> but there's the "provenance is erased, so you can no longer do pointer math on it"
<re_irc>
<thalesfragoso> And we don't usually care, shouldn't be unsound (i.e no data race) but still can cause weird behaviors
<re_irc>
<thalesfragoso> dirbaio: Well, raw pointers wouldn't solve that, they also have provenance
<re_irc>
<dirbaio> for example in RP2040 if you have a reg at address "X", writing to addr "X+0x1000" does an atomic "AND", writing to addr "X+0x2000" does an atomic "OR"
<re_irc>
<dirbaio> * "OR", etc
<re_irc>
<dirbaio> (actual numbers made up, I don't remember the offsets)
<re_irc>
<thalesfragoso> E.g. the user does a RMW safely with the singleton and we use CS or atomic writes in the interrupt
<re_irc>
<dirbaio> a pointer from a "&VolatileCell<u32>" only has provenance over that "u32", you can't simply add "0x1000" to that addr
<re_irc>
<thalesfragoso> dirbaio: MMIO has to escape provenance somehow, there is no way around it, so the spec will have to do something about
<re_irc>
<thalesfragoso> No sane spec will put provenance on MMIO
<re_irc>
<dirbaio> register pointers in chiptool have provenance over "whatever is the provenance of an integer casted from a usize constant"
<re_irc>
<dirbaio> which no one knows what it is
<re_irc>
<thalesfragoso> dirbaio: It's memory outside of the program compiled program, it has "infinite provenance"
<re_irc>
<dirbaio> but the provenance from a "&VolatileCell<u32>" is KNOWN to be "just the 4 bytes for the u32"
<re_irc>
<dirbaio> so that pointer math IS unsound on svd2rust pacs, 100% guaranteed
<re_irc>
<James Munns> What is the provenance?
<re_irc>
👈️ 😄 👈️
<re_irc>
<dirbaio> thalesfragoso: in that case, adding 0x1000 to the addr is sound in chiptool pacs
<re_irc>
<thalesfragoso> dirbaio: Hmm, but that was created from an usize that was outside of the compiled program
<re_irc>
<thalesfragoso> I think even strict provenance will allow that
<re_irc>
<dirbaio> "&" and "&mut" "downgrade" the provenance
<re_irc>
<dirbaio> +to just the pointed-to data
<re_irc>
<dirbaio> even if they originally come from a pointer/reference with "wider" provenance
<re_irc>
<dirbaio> while raw pointers don't, they always keep the provenance of the original pointer, just like in C
<re_irc>
<James Munns> Alright, new proposal, hold my beer
<re_irc>
<James Munns> We replace everything with statics with specific linker sections
<re_irc>
<thalesfragoso> Hmm, you got a point. But doesn't each register have a VolatileCell ?
<re_irc>
<James Munns> then mark all the linker sections as NOLOAD
<re_irc>
<thalesfragoso> Ah, you mean to do the rp2040 crazy stuff
<re_irc>
<thalesfragoso> Right
<re_irc>
<James Munns> so it's a PAC with all registers as a private static, you can only get a reference to via the singleton
<re_irc>
<James Munns> oh, does the rp2040 really do that? :D
<re_irc>
<James Munns> Then you have provenance of the entire struct
<re_irc>
<thalesfragoso> James Munns: That's what happens when you don't have CAS on multicore
<re_irc>
<James Munns> and yeet the ub to linkerland, which rustc dgaf about
<re_irc>
<dirbaio> thalesfragoso: yeah, my original point was the "fancy address math" like the rp2040 one is unsound in svd2rust pacs, not in chiptool pacs
<re_irc>
<thalesfragoso> dirbaio: Just create another struct for the atomics, haha
<re_irc>
<James Munns> okay my suggestion is sort of "hold my beer", but is there any reason that wouldn't remove the unsoundness?
<re_irc>
<dirbaio> (there's also the "LLVM dereferenceable" issue which is a 100% separate issue, which also affects svd2rust pacs and not chiptool pacs)
<re_irc>
<James Munns> (context: I have no idea what chiptool pacs are)
<re_irc>
<thalesfragoso> James Munns: That would be a hell of a linker script
<re_irc>
<dirbaio> James Munns: I believe that'd still involve getting "&" references to registers, so at least the "dereferenceable" problem applies
<re_irc>
<thalesfragoso> James Munns: aka metapac aka meat-pac 🍖
<re_irc>
<dirbaio> +still
<re_irc>
<James Munns> thalesfragoso: Yeah, svd2rust (or whatever) would have to spit it out
<re_irc>
<James Munns> I'm sure everyone's broken linker script support would fall over sideways like all linker script things do lol
<re_irc>
<James Munns> dirbaio: Ah, the side-effectful dereference problem?
<re_irc>
<James Munns> yeah
<re_irc>
<dirbaio> actually due to the dereferenceable thing, I believe ALL uses of VolatileCell are unsound
<re_irc>
<thalesfragoso> Yeah, I don't think it would have a benefit over doing it in rust if you take the reference to it
<re_irc>
<dirbaio> > The way to prevent this rustc/LLVM bug is to never create a reference (&- or &mut-) to a MMIO register, or in general to memory that is meant to be accessed only through volatile operations.
<re_irc>
<James Munns> I started getting notifications for it this week, and couldn't remember why I subscribed to it
<re_irc>
<James Munns> Yeah, I guess the fix would require "statics that exist at MMIO addresses", AND make it not possible to reference the fields, and instead use accessors that do volatile ops (or "vops", as no one calls them) via pointers
<re_irc>
<thalesfragoso> James Munns: chiptool uses consts
<re_irc>
<James Munns> Doesn't that still have the provenance problems?
<re_irc>
<thalesfragoso> statics could cause some problems
<re_irc>
<James Munns> (also context: none of my suggestions are "we should do this", just "would this solve problem X")
<re_irc>
<thalesfragoso> James Munns: The raw pointer would have unknown provenance, so no
<re_irc>
<James Munns> hmmm
<re_irc>
<James Munns> isn't there a "reference to pointer with the provenance of the reference" operation in gankra's suggestions?
<re_irc>
<dirbaio> I think currently a pointer casted from usize has provenance over "all memory"
<re_irc>
<dirbaio> and with the new "strict provenance" rules, it'll have "provenance over all non-program memory, and over all "exposed" program memory"
<re_irc>
<dirbaio> in both cases, casting usize->ptr for mmio is ok
<re_irc>
<dirbaio> and with the new "strict provenance" rules, it'll have provenance over "all non-program memory, and over all "exposed" program memory"
<re_irc>
<James Munns> Ah. gotcha. I'll put provenance back in the pile of things that I don't understand.
<re_irc>
<dirbaio> nobody understands it, not even the people speccing it out 🤣
<re_irc>
<James Munns> I assume gankra is the only person in the world who understands fully
<re_irc>
<James Munns> and is disappointed, CONSTANTLY
<re_irc>
<dirbaio> lol
<re_irc>
<dirbaio> well at that level it's still a "research" thing
<re_irc>
<dirbaio> like
<re_irc>
<dirbaio> "what provenance rules can we pick that don't break too many existing programs but still allow for lots of juicy optimizations"
<re_irc>
<James Munns> (that's a juice glass, for reference)
<re_irc>
<dirbaio> nobody knows! :D
starblue has quit [Ping timeout: 255 seconds]
<re_irc>
<thalesfragoso> dirbaio: Not only optimizations, but choosing strict rules you can be compatible with anything less strict
<re_irc>
<dirbaio> like C? 💩
<re_irc>
<thalesfragoso> As in LLVM, when they decide what their rules for provenances are
<re_irc>
<dirbaio> ahh right
starblue has joined #rust-embedded
<re_irc>
<thalesfragoso> Yep, C is playing with creating some provenance rules too
<re_irc>
<thalesfragoso> Very slowly
<re_irc>
<James Munns> Okay, I have some "fighting words" questions, should I ask them here, or take my shitposting to anachro?
<re_irc>
<dirbaio> a shitpost a day keeps the doctor away
<re_irc>
<James Munns> sold!
<re_irc>
<James Munns> What's the chance that we (the collective WG) could write a cohesive "how to write a HAL" guide?
<re_irc>
<James Munns> and, following that, push the ecosystem to homogenize on that guide's recommendations?
<re_irc>
<James Munns> Or, is that asking to create a forever-bike-shed?
<re_irc>
<James Munns> with, and without, potentially including some largely breaking changes (take that as far as you can imagine)
<re_irc>
<dirbaio> hmmmm
<re_irc>
<dirbaio> I don't think "what's the best way to write a HAL" is a settled question :S
<re_irc>
<dirbaio> +yet
<re_irc>
<James Munns> yeah
<re_irc>
<James Munns> collecting that guidance is sort of step one
<re_irc>
<James Munns> even if it's "2022 edition" HAL approach
<re_irc>
<James Munns> like, doesn't have to be a forever approach
<re_irc>
<James Munns> but like, only updated every few year(s)
<re_irc>
<James Munns> anyway, just asking, because I have some bandwidth to play hype man if there is some interesting effort to do, including trying to rustle up some funding to potentially getting some contributors paid to do it
<re_irc>
<James Munns> but like, that requires a cohesive destination/goal/task.
<re_irc>
<adamgreig> What's the point of trying to make, say, embassy-stm32, stm32-hal2, and stm32f4xx-hal all work the same?
<re_irc>
<thalesfragoso> James Munns: Take a look at Unborrow and the interrupt ideas from the embassy hals
<re_irc>
<thalesfragoso> They are quite interesting
<re_irc>
<James Munns> I admit I don't want to be the "taste maker" here
<re_irc>
<adamgreig> Or just "for new HALs, consider these patterns?"
<re_irc>
<James Munns> but I don't want to hype something that wouldn't be vaguely accepted as a decent "best/default practice"
<re_irc>
<adamgreig> Sadly people won't stop making new chips so I'm sure there will keep being new HALs and people do keep Innovating HAL technology
<re_irc>
<adamgreig> * innovating
<re_irc>
<James Munns> Second flamebait question: what change/effort/work/project/research would have the biggest impact to embedded rust adoption?
<re_irc>
<James Munns> (or, "developer quality of life" impact)
<re_irc>
<adamgreig> Port Arduino HAL :p
<re_irc>
<James Munns> isn't that like issue # 4 ?
<re_irc>
<dirbaio> adamgreig: I brought that up regarding stm32 specifically a while ago, you probably remember what happened... :D
<re_irc>
<thalesfragoso> adamgreig: Noo, you can't even divide right on avr
<re_irc>
<adamgreig> Arduino runs on Cortex M these days anyway, but I thought rust on avr is coming along too
<re_irc>
<James Munns> it has "transient compiler surprises"
<re_irc>
<adamgreig> Anyway I just mean the HAL they have, and perhaps only-joking-unless
<re_irc>
<dirbaio> since then, I simply stopped trying
<re_irc>
<thalesfragoso> adamgreig: What do you mean by Arduino HAL then ? What would be the difference from the usual HALs ?
<re_irc>
<James Munns> (imo arduino (but really wiring) had a goal, and stuck the landing)
<re_irc>
<adamgreig> Yea, 100% they did
<re_irc>
<James Munns> (engineers my not have aligned goals, but "you weren't the audience" is important to remember)
<re_irc>
<James Munns> * may
<re_irc>
<adamgreig> Combine this with a cortex-m-rt later that gives you init and loop
cr1901_ is now known as cr1901
<re_irc>
<adamgreig> * layer
<re_irc>
<James Munns> Anyway, it's dirbaio's bedtime, so I guess I'll leave my flamebait there for the night
<re_irc>
<adamgreig> It's 3am so it's probably hard for even me to know if this was a serious answer to your flamebait question about high impact API design but we so often get people wanting the Arduino millis() method for example
<re_irc>
<dirbaio> not going to bed, don't worry about me :')
<re_irc>
<dirbaio> * bed yet,
<re_irc>
<adamgreig> It's such a simple API that is widely used and loved
<re_irc>
<James Munns> I'm getting a bit of my fightin' spirit back, and I figured it was worth asking if there were any battle cries for making a serious QoL improvement for new/existing users
<re_irc>
<adamgreig> Probably most of it could use embedded-hal to wrap on top of existing HALs
<re_irc>
<dirbaio> embassy has a global "instant::now()" that Just Works :)
<re_irc>
<adamgreig> Obviously rust isn't c++ but you could port a lot of examples basically word for word if you had a corresponding api. Maybe even just a document showing correspondence between Arduino functions and rust/e-h methods? Like Octave and MATLAB and numpy (used to?) have
<re_irc>
<dirbaio> but anyway: if we were to create a "rusty arduino", as easy to use as the C API but in Rust
<re_irc>
<dirbaio> who would the audience for that be?
<re_irc>
<James Munns> I guess I'm asking for a vision :D
<re_irc>
<James Munns> less impl details
<re_irc>
<James Munns> more hopes and dreams.
<re_irc>
<dirbaio> certainly not "professional" users
<re_irc>
<adamgreig> Everyone who's used an Arduino or is picking one up for the first time, I guess, it's so popular
<re_irc>
<dirbaio> and C is good enough for hobby users, and now that most "arduino-like" boards are getting more powerful they're all shifting to micropython/circuitpython
<re_irc>
<adamgreig> Yea, I guess a lot of the market may be shifting to python too, I wonder how its HAL APIs compare
<re_irc>
<James Munns> There's something to be said about picking battles you can win
<re_irc>
<James Munns> e.g., find areas where rust can be an EASY choice
<re_irc>
<James Munns> rather than trying to compete with someone/thing else
<re_irc>
<James Munns> (be it tooling, docs, perf, whatever)
<re_irc>
<dirbaio> and AVR Rust is not in great shape, it wouldn't even work for the AVR arduino boards :(
<re_irc>
<James Munns> One battle I haven't seen taken on by embedded rust:
<re_irc>
<James Munns> "what if you know rust, but not embedded"
<re_irc>
<James Munns> IMO the esp folks are doing the biggest swings at that area atm
<re_irc>
<James Munns> Rust is not THAT niche anymore
<re_irc>
<James Munns> in the same way micro/circuit python is "what if you know python, but not embedded"
<re_irc>
<James Munns> like, I'm aware of the discovery book
<re_irc>
<James Munns> but that's still "coming to" bare metal dev
<re_irc>
<James Munns> maybe MnemOS will run again some day, and I can take a swing at that area :D
<re_irc>
<James Munns> Anyway, enough fight picking for one night. I guess I'm saying "i'm in the market for some big dreams"
<re_irc>
<James Munns> night y'all :D
<re_irc>
<thalesfragoso> dirbaio: Owned interrupts was a nice olay
<re_irc>
<thalesfragoso> * play
<re_irc>
<firefrommoonlight> dirbaio: Agreed. And, I tend to think this _let's set down guidelines from an abstract perspective_ tends to result in impractical results
<re_irc>
<firefrommoonlight> To be explicit: I think the best designs come from hacking at practical problems. And, these designs will differ depending on (among other things) the nature of the problems they were built around
<re_irc>
<firefrommoonlight> AFAIK, there are very few embedded Rust OSS devices
<re_irc>
<firefrommoonlight> so, going back to James' second _controversial_ question, my hopefully-non-controversiall answer is to write more firmware
<re_irc>
<firefrommoonlight> * _second flaimbait question_, my hopefully-non-flaimbait
<re_irc>
<firefrommoonlight> I'm constantly finding flaws, deficiencies, and missing features in my own libraries by tackling new projects
<re_irc>
<dirbaio> sadly most people using rust for work can't opensource their work
<re_irc>
<dirbaio> and most people using rust for work don't fix the deficiencies they find upstream because no time
<re_irc>
<dirbaio> or they fix it in the "path of least resistance way"
<re_irc>
<dirbaio> e.g. "oh there's no XJFR driver in stm32k8xx-hal? just copypaste the one from stm32z5xx-hal and PR it"
<re_irc>
<firefrommoonlight> I do wonder how many people and orgs use Rust on embedded for closed-source proprietary stuff
<re_irc>
<firefrommoonlight> This may be an iceberg tip
<re_irc>
<firefrommoonlight> Never let go, Jack
<re_irc>
<dirbaio> opensource is always "the tip of the iceberg"
bjc has joined #rust-embedded
<re_irc>
<Lachlan> I would think it’s quite a bit, at least a lot of new projects
<re_irc>
<Lachlan> Rust is at least in everyone’s radar
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
nohit_ has quit []
nohit has joined #rust-embedded
<re_irc>
<denna> Can you give me some recommendation wich is the best supported chip for using rust with os like freertos (and maybe other os) and without os? Primarily for learning purpose.
<re_irc>
<K900> Anything STM32 or nRF51 should be good
<re_irc>
<K900> Though I'm not sure how good Rust runs on FreeRTOS, there's a bunch of Rust-specific RTOSes out there
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<denna> K900: Thanks. Which chip i can use with std? All none some?
<re_irc>
<K900> Basically none
<re_irc>
<K900> Unless we count things like Raspberry Pis
<re_irc>
<K900> (like, the full size ones, running Linux)
<re_irc>
<denna> No i don't count these :)
<re_irc>
<denna> Esp32c3 seem to have std... using the esp c code. ... but its all a bit new so i worry it is not working as well as it is supposed to be.
<re_irc>
<K900> That's basically emulating an OS and making a bunch of decisions for you
emerent is now known as Guest7214
emerent_ has joined #rust-embedded
Guest7214 has quit [Killed (platinum.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
<re_irc>
<9names (@9names:matrix.org)> If you want to run std with a microcontroller esp32/esp32-c3 is basically your only choice. #esp-rs:matrix.org (https://matrix.to/#/#esp-rs:matrix.org) is very active and helpful.
<re_irc>
Their no-std support is much newer and isn't officially supported but you would still find help for it there.
<re_irc>
I'd still recommend going with one of the more established chips for no-std if you're still finding your feet.
<re_irc>
<9names (@9names:matrix.org)> Some of the no-std tooling only works on cortex-m too, and a lot of the examples / guides are written for these targets
<re_irc>
<K900> I'd probably say that if you want to run std, the first thing you should do is think about _why_ you want to run std
aspe has joined #rust-embedded
Socke has quit [Ping timeout: 244 seconds]
aspe has quit [Remote host closed the connection]
aspe has joined #rust-embedded
Socke has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
gsalazar has joined #rust-embedded
<re_irc>
<Tom> dirbaio: Yeah I mean, there's some structural issues there right... there should be IP drivers that HALs bundle up perhaps
causal has quit [Quit: WeeChat 3.5]
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
<re_irc>
<henrikssn> Would it be UB to store a peripheral register as "&'static"?
<re_irc>
<henrikssn> I'm not sure if that would break some aliasing rules or not
<re_irc>
<James Munns> It does look like an llvm codegen problem
<re_irc>
<James Munns> well, I shouldn't say that. I guess it could be Rust as well.
aspe has quit [Quit: aspe]
fabic has quit [Ping timeout: 246 seconds]
<re_irc>
<dirbaio> tcork
<re_irc>
<omar_u8> I am trying to set up input capture to measure a pulse duration using a timer peripheral in the stm32f4xx HAL. However, searching through the documentation, I couldn't find a way to set up input capture and connect pins to the peripheral. Looking into older versions of the HAL, it seems that in put capture was supported at some point though not any more. Am I missing something?
<re_irc>
<Kevin Clark> James Munns: I know I'm late to the party, but this is solidly the camp I'm in. I've done some rust but never embedded, and the discovery book was decent and I'm doing reading on my own, but understanding the constellation of hals/pacs and such and understanding how to find what I'm looking for and which crate to expect that thing to be in isn't totally straightforward.
<re_irc>
<Kevin Clark> f.e, on arduino I'd just look for an hc-sr04 library. In rust outside of embedded I'd do the same. For embedded there's a crate but it doesn't wire up to the mpu I'm working with (kicking the can down the road to hook up interrupts) so having an obvious place to fill in that knowledge or an interface that clearly composes might help in that situation
<re_irc>
<Kevin Clark> the story isn't bad by any means, but it's a lot more work than micropython or wiring f.e
<re_irc>
<Kevin Clark> that being said, all the things I was trying to do started working last night, so it's been a good week of hacking
<re_irc>
<dirbaio> you mean drivers using the embedded-hal traits that need to handle interrupts as well?
<re_irc>
<dirbaio> in my experience drivers using embedded-hal are mostly plug-and-play, unless they need to handle interrupts
<re_irc>
<Kevin Clark> that might be the crux of the issue. it might also be complicated by not having a clear intuition around what component is responsible when it comes to "I want to do X". Is it a driver? Is this something that's a embedded-hal trait? Is this something I have to go to the pac for because it's specific?
<re_irc>
<Kevin Clark> when I go digging, it's hard to know if I'm not finding what I'm looking for because I'm in the wrong place or searching for the wrong concept
<re_irc>
<omar_u8> Kevin Clark: Very true, it takes a while to wrap your head around that, everytime I feel I got the feel for the pattern or even where to find things, switching to another HAL I see a different pucture..
<re_irc>
<omar_u8> * picture.
<re_irc>
<Kevin Clark> yeah, it might not help that I was playing with a microbit first (so I could do the discovery book) and now the esp32c3 so I could play with wifi. And in the middle I was trying to use knurling with microbit (which worked nicely) but which doesn't seem to translate to the esp world
<re_irc>
<omar_u8> I guess due to the module system as well, in the beginning I felt that things kept going around in circles.
<re_irc>
<Kevin Clark> "oh none of the tools I learned work here" didn't help 🤪
<re_irc>
<omar_u8> Kevin Clark: Tooling is a mixed bag still based on the platform. I'm personally sticking to the traditional toolchains so to speak.
<re_irc>
<omar_u8> +experience for me
<re_irc>
<Kevin Clark> which tools are traditional?
<re_irc>
<omar_u8> GDB/OpenOCD
<re_irc>
<omar_u8> +is what I meant
<re_irc>
<Kevin Clark> ah sure
<re_irc>
<firefrommoonlight> I wonder if it would help to have a practical OSS ecosystem map
<re_irc>
<firefrommoonlight> Eg a living article etx
<re_irc>
<firefrommoonlight> Maps libs to use cases etc
<re_irc>
<firefrommoonlight> The sort of thing experienced people know, but is confusing to new people
<re_irc>
<Kevin Clark> That sounds like a useful thing