<thejpster[m]>
> There is some disagreement in the Rust community about the soundness of references to MMIO space, and the facilities for working with raw pointers in stable Rust are currently somewhat limited. The stabilisation of offset_of, slice_ptr_get, slice_ptr_len, offset_of and other nightly features will improve this, but it is still challenging to encapsulate cleanly. Better syntax for accessing struct fields and array indices via raw
<thejpster[m]>
pointers without creating references would also be helpful.
<thejpster[m]>
We should fix that
<thejpster[m]>
If VolatileRegister is unsound we should fix rustc to make it sound, or we should stop using it.
<thejpster[m]>
(IIRC it’s about the compiler being allowed to add reads to & ref whenever it likes, but ours can Deref to a pointer read with a side effect).
emerent is now known as Guest6031
emerent has joined #rust-embedded
Guest6031 has quit [Killed (iridium.libera.chat (Nickname regained by services))]
<FlixtheNewbie[m]>
But that's frustrating, because the keyboard works perfectly.
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
tamme[m] has joined #rust-embedded
<tamme[m]>
Hey, I recently had a lot of time to think while being on a long bike ride. And thought about crater and how nice it would be to have in the embedded Rust ecosystem as well. So I started thinking about how a system could look like where "all" the supported MCUs and "all" driver-supported devices could be housed. Basically I wanted to have the ability to have any MCU connect to any device and run its test cases.
<tamme[m]>
It might still be a bit unstructured, but I would be happy about any feedback or comments on the idea. And also any <del>pointers</del> references to existing work in this area (I already know about the Ferrous Systems posts and tele-probe). I will also be at Eurorust in Brussels from Tomorrow (workshop) until Saturday noon in case somebody would like to meet.
<tamme[m]>
Now this is too big of a project to do in just one go, so I will start with only testing HAL implementations against another MCU (like the RP2040 with its nice PIO). I did collect some of my thoughts in this doc: [https://hackmd.io/@tamme/Hy7-REalp]
<korken89[m]>
For people more bewildered in cryptogrophy, should one now use the p256-cortex-m4 or the p256-cm4 crate? :) They both seem to stem from the same initial implementation.
<korken89[m]>
Maybe Nicolas | SoloKeys or newam knows as they are the respective authors :D
<dirbaio[m]>
seems the difference is p256-cm4 has ported the C stuff to Rust?
<korken89[m]>
Yeah, or rather just reexported the ASM and put it in a global asm
<dirbaio[m]>
ah that too
<dirbaio[m]>
which is nice because it means you don't need a C compiler :D
<korken89[m]>
I generally go for the "latest released on crates.io" but here bot have the
<korken89[m]>
* I generally go for the "latest released on crates.io" but here both have similar release dates and similar no of downloads
<korken89[m]>
xD
<dirbaio[m]>
so perhaps p256-cm4 is slightly better due to that
<dirbaio[m]>
assuming no mistakes have been done while porting
<korken89[m]>
Indeed
<korken89[m]>
It seems more like thin wrapper on the C stuff, while the "older" has a more refined API
<dirbaio[m]>
the exported api of p256-cm4 is a bit more dangerous yes
<dirbaio[m]>
but did for x25519: rustcrypto was like 500ms, Emill's asm was 9ms :D
<dirbaio[m]>
s///
<korken89[m]>
xD
<korken89[m]>
slight improvement
<dirbaio[m]>
Emill's asm beats the nrf52 CC310
<dirbaio[m]>
it's insane
<korken89[m]>
That's awesome
<korken89[m]>
Looking at ECDSA, it seems the cost comes from generating the hash
<korken89[m]>
The rest of the operations seems to be in his ASM
<korken89[m]>
Nah, I'll probably pay the 2x slower for full support xD
<korken89[m]>
I'm going in the wrong direction haha
<korken89[m]>
Huh the private key is only 64 bits, seems oddly short
<dirbaio[m]>
`[u32; 8]` -> 256 bits
<korken89[m]>
Ahhh u32 xD
ruabmbua[m] has joined #rust-embedded
<ruabmbua[m]>
Anyone else at embedded connect in Linz / Pasching today?
<ruabmbua[m]>
Probably not since it's pretty local 😅
newam[m] has joined #rust-embedded
<newam[m]>
<korken89[m]> "For people more bewildered in..." <- `p256-cm4` is the same thing, but without C preprocessor compile time switches, which allows for no `build.rs` script. That was the only motivation for `p256-cm4`, reducing toolchain dependencies. In all other cases `p256-cortex-m4` is more flexible.
<newam[m]>
Been using it in my really awful TLS stack for some time, happy to answer any questions!
<newam[m]>
* In reply to @korken89:matrix.org
<newam[m]>
For people more bewildered in cryptogrophy, should one now use the p256-cortex-m4 or the p256-cm4 crate? :) They both seem to stem from the same initial implementation.
<newam[m]>
p256-cm4 is the same thing, but without C preprocessor compile time switches, which allows for no build.rs script. That was the only motivation for p256-cm4, reducing toolchain dependencies (no C compiler needed). In all other cases p256-cortex-m4 is more flexible.
cr1901_ is now known as cr1901
<korken89[m]>
<newam[m]> "Been using it in my really awful..." <- Awesome?
<korken89[m]>
* In reply to @newam:matrix.org
<korken89[m]>
Been using it in my really awful TLS stack for some time, happy to answer any questions!
<korken89[m]>
Awesome!
<korken89[m]>
It's that open as well? I'm trying to learn right now :) in our system we need a way to generate a shared secret that we then encrypt/decrypt messages using ChaCha8Poly1305 in our radio communication
<korken89[m]>
And these creates did implement ECDH which is great, plus with the signing it fixed two issues with one crate
<korken89[m]>
Why we use ChaCha is because we don't have any HW crypto unit
<newam[m]>
It's built for the W5500 which has its own TCP/IP stack, made it difficult to leverage existing libraries that build on lower network layers.
<korken89[m]>
Very cool!
<newam[m]>
korken89[m]: HW crypto is sometimes overrated anyway. STM32's PKA and AES units are pretty slow. 10x slower than code in some cases
<korken89[m]>
Lol
<korken89[m]>
We find ChaCha surprisingly fast
<korken89[m]>
As soon as I've put my daughter to bed I'm going to spelunk your code :D
<newam[m]>
Yeah, embedded TLS is great too, I help maintain that as well. Eventually I'll get around to adding PSKs to it. The H7 micro with an ethernet PHY that I want is still out of stock though 😢
lulf[m] has joined #rust-embedded
<lulf[m]>
newam: It supports psk now, configured using with_psk on the config
<ilpalazzo-ojiis4>
<korken89[m]> "We find ChaCha surprisingly fast" <- Would you say that it is… _real smooth_?
Guest7221 has left #rust-embedded [Error from remote client]
<newam[m]>
<lulf[m]> "newam: It supports psk now..." <- Oooo I had forgotten about that, yay!
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
<thejpster[m]> "> There is some disagreement..." <- I'm not sure it is true to call it "disagreement", the rust op-sem people have been pretty clear that spurious reads of `VolatileCell`s are allowed to happen
<GrantM11235[m]>
The only valid reason to still use VolatileCell is "I haven't gotten around to changing it yet"
<dirbaio[m]>
the stacked borrows, tree borrows memory models allow it to happen
<dirbaio[m]>
but they're not "official" yet
<dirbaio[m]>
vs today's implementation doesn't do it (it did a while ago, then it was changed to not add the `dereferenceable` attribute on `&` to types that contain interior mutability
<dirbaio[m]>
but the implementation not doing it doesn't mean it won't in the future
<dirbaio[m]>
so the state is more like "nobody knows 🤷"
<dirbaio[m]>
or more accurately "nobody knows, but it's very likely the final official memory model will allow spurious reads on `&`, so better start preparing your code for it today"
<dirbaio[m]>
so yea we should get rid of VolatileCell asap :P
<dirbaio[m]>
* interior mutability)
<adamgreig[m]>
hi @room , meeting time! agenda is https://hackmd.io/FdDD7t8mRdqLE1nZ85su8A, please add anything you'd like to discuss or announce and we'll start in a few minutes
<adamgreig[m]>
ok, let's start! only announcement from me is probe-rs 0.21 release is out, go update your probe-rs installs :P
<adamgreig[m]>
anyone else have anything to announce?
<adamgreig[m]>
ok, quick check if anyone's noticed any issues with the anti-spam bot
posborne[m] has joined #rust-embedded
<posborne[m]>
We don't have specific release versions in meta-rust-bin but these changes essentially represent a new major version and we encourage users to give these changes a go.
<posborne[m]>
We've recently landed a few PRs for long outstanding issues in [meta-rust-bin](https://github.com/rust-embedded/meta-rust-bin) including some changes to `bbclass` names to avoid conflicts with the rust support in meta-oe.
<adamgreig[m]>
nice, i'd seen some pr notifications fly by!
<adamgreig[m]>
we discussed last week about volunteering wg teams as maintainers for various embedded rust targets, I started preparing a PR and opened an issue to track here: https://github.com/rust-embedded/wg/issues/704
<adamgreig[m]>
one thing it seems nice to put into these target support files is the little tips like "how to enable double precision fpu for cortex-m7"
<adamgreig[m]>
thejpster suggested we could talk about how to use the fpu but keep a soft float abi, but iirc cortex-m-rt won't enable the fpu on a non-hf target, so I don't think it works without additional mucking around
<adamgreig[m]>
but if anyone can think of any other things to put in these target files, please leave a comment, otherwise hopefully I'll turn this into a PR some time this week
<adamgreig[m]>
hmm, I feel like I didn't finish writing up the minutes for the mutex trait discussions last week 😅
<adamgreig[m]>
I was planning to leave a summary on the recent issue there so i'll try and get that done soon and we can consider what we want to do about the trait
<adamgreig[m]>
(probably either leave it floating around or officially stop recommending it)
<adamgreig[m]>
let's revisit mutex-trait if we have time, but go through the other bits first
<adamgreig[m]>
dirbaio, wanna briefly talk about your point about heapless?
<dirbaio[m]>
yea
<dirbaio[m]>
it's been brought up in the past
<dirbaio[m]>
it'd be cool to get maintenance of heapless unstuck. japaric is not very active, korken89 has merge access but has said he doesn't have much time either
<adamgreig[m]>
what team do you think?
<dirbaio[m]>
does r-e-c have teams?
<dirbaio[m]>
or you mean moving to r-e
<adamgreig[m]>
ah sorry, I missed the -c on the agenda line item
<adamgreig[m]>
yep, no teams in r-e-c
<adamgreig[m]>
could try emailing japaric? looks like jpster isn't around today and he's the only other mode of contact I can think of
<adamgreig[m]>
the other outstanding issue is the volatile-register thing, which has a similar problem where the PR to fix the unsoundness of not having repr(c) on the struct hasn't been merged in some years, but it's used by cortex-m
<adamgreig[m]>
as an easy fix we could fork volatile-register, or more easily just vendor the 50loc or so into cortex-m along with the fix
<adamgreig[m]>
as a better fix we could stop using volatile-register, but I fear that's a bigger change
<JamesMunns[m]>
I have little conclusive data here
<JamesMunns[m]>
but I'd wager that embassy is the largest and most consistent set of HALs at the moment
<JamesMunns[m]>
and embassy uses ptrs-not-structs, right?
<adamgreig[m]>
I don't think there's any argument that anything new should even consider using structs
<adamgreig[m]>
it's just that rewriting all of cortex-m to use pointers is a lot more work than at least fixing the repr(c) thing
<adamgreig[m]>
admittedly, I think it's clear that neither will cause immediate unsoundness in practice in today's rustc
<dirbaio[m]>
rp-pac and stm32-metapac are chiptool-based, which use ptrs
<dirbaio[m]>
embassy-nrf still uses the nrf-rs pacs which are svd2rust-based, which use volatilecell
<cr1901>
I'm just waiting for upstream svd2rust to change over to ptrs before I change anything
<adamgreig[m]>
the problem here is volatile-register
<adamgreig[m]>
which is different to vcell
<korken89[m]>
<dirbaio[m]> "it'd be cool to get maintenance..." <- If more can help it would be awesome, as you say I don't have the time (nor energy) to maintain `heapless`
<dirbaio[m]>
I want to help, yes
<adamgreig[m]>
I mean, both are very similar crates maintained by japaric, but vcell does have repr(transparent) on its wrapper struct
<adamgreig[m]>
but cortex-m uses volatile-register
<dirbaio[m]>
ah right we're talking about this other new unsoundness :D
<dirbaio[m]>
not the "`&` to peripheral memory" one
<korken89[m]>
dirbaio[m]: I think only japaric has the right to add another maintainer
<cr1901>
what's the new new unsoundness?
<adamgreig[m]>
korken89: the suggestion is to transfer the whole repo to rust-embedded-community (and add a team to crates.io) rather than just a new maintainer on github, I think
<adamgreig[m]>
cr1901: it's not new as such, there's been a PR open to fix it in volatile-register since 2019, it's that the wrapper struct doesn't have a repr but we assume it has the same layout as the type it wraps
<cr1901>
I mean, I don't see the problem w/ merging the repr(C) PR and cutting new minor (breaking!) release
<adamgreig[m]>
that would be fine, but we don't maintain volatile-register
<dirbaio[m]>
the problem is japaric has disappeared :D
<adamgreig[m]>
or rather, it's maintained by the third rewg core team member japaric :p
<cr1901>
Ferrous systems seems to have a way of taking away embedded Rust members :P
<dirbaio[m]>
not even a separate crate, just copypaste
<adamgreig[m]>
yea, my suggestion above is to just include it directly in cortex-m
<adamgreig[m]>
<adamgreig[m]> "as an easy fix we could fork..." <- ^
<adamgreig[m]>
I think that's the easiest thing to do
<dirbaio[m]>
i'd love to see a cortex-m-pac someday, autogenerated from svd or similar
<adamgreig[m]>
bad news for the other 19 dependents and doesn't resolve the "we should be using pointers anyway" but... yea
<cr1901>
I'd be fine w/ that as long as there's a comment explaining the current state of affairs for ppl who aren't aware why things are done like this
<adamgreig[m]>
me too 🥲 I have written the first 20% of that svd file
<adamgreig[m]>
would anyone like to make a pr to include a fixed volatile-register in cortex-m?
<adamgreig[m]>
seems like that's the best option for now, anyway
<dirbaio[m]>
will do
<cr1901>
I'll just steal the PR when it's done :P
<adamgreig[m]>
adamgreig[m]: this is every register for armv6m/armv7m but none of the fields, and I think nothing for armv8
<adamgreig[m]>
so maybe 20% is an exaggeration but since cortex-m as-stands doesn't use any field definitions anyway.... :P
<cr1901>
Oh wait. I don't use volatile-register. lol.
<dirbaio[m]>
switching to a vendored volatile-register is breaking though, since dependents can observe it's no longer the same type
<dirbaio[m]>
but cortex-m git master already has breaking changes queued, right?
thalesfragoso[m] has joined #rust-embedded
<thalesfragoso[m]>
<dirbaio[m]> "or more accurately "nobody knows..." <- Although it makes sense, I think the chances of UnsafeCell going back to derefereciable aren't as big as initially thought. Unless LLVM changes how it deals with the derefereciable attribute
<dirbaio[m]>
it's unlikely to break anyone though
<dirbaio[m]>
so, do we do the change for 0.7 or not?
<adamgreig[m]>
oh, ugh. good point.
<thalesfragoso[m]>
Derefereciable is placed on functions arguments, which means that it needs to hold true for the whole function. That kinda makes some implementations very hard (or impossible?)
<thalesfragoso[m]>
e.g. the Drop on Arc, which caused the UnsafeCell to lose derefereciable in the first place.
<adamgreig[m]>
cortex-m thing is tricky. it's nominally a breaking change so should go into 0.8, which only has one other breaking change (nvic::request not needing self) so there wasn't much impetus to wreck the ecosystem with such a small break
<adamgreig[m]>
I think almost everything else in master is already backported to the 0.7 release branch
<adamgreig[m]>
we do expose the volatile_register types publically so you're right, it would be a breaking change, even if we'd probably not cause much trouble
<dirbaio[m]>
ahh
<adamgreig[m]>
but conversely, the missing repr is very unlikely to cause any trouble in practice either
<JamesMunns[m]>
Make the change, schedule a release in 3mo, give everyone a heads up?
<adamgreig[m]>
so perhaps it should just go into 0.8 to be released whenever that is released, but it's quite unsatisfying and I think ideally 0.8 would use pointers anyway
<adamgreig[m]>
we could, but it would still cause a lot of strife for essentially no benefit to anyone
<dirbaio[m]>
JamesMunns[m]: 0.7, or 0.8?
<adamgreig[m]>
it maybe swings the balance vs "push to get a new version of volatile-register published with the fix", which isn't a breaking change
<JamesMunns[m]>
dirbaio[m]: I was going to say 0.8
<dirbaio[m]>
perhaps we can save 0.8 for cortex-m-pac ;D
<adamgreig[m]>
the only thing in 0.8 would be "we fixed a hypothetical issue in volatile_register since 2019 that we could have fixed with a new version but decided to vendor and thus change the type because the maintainer couldn't be reached", and "you no longer need self when calling nvic::request"
<adamgreig[m]>
not a compelling release
<JamesMunns[m]>
IMO releasing a major version less often than once a year isn't an unreasonable ask :p
<adamgreig[m]>
it would be for like, embedded-hal
<adamgreig[m]>
can you imagine
<adamgreig[m]>
all the cortex-m PACs depend on cortex-m, so there's similar levels of pain
<JamesMunns[m]>
adamgreig[m]: idk. "release often" or "release never" :p
<adamgreig[m]>
you might recall all the semver hacks we do to allow old versions to work
<adamgreig[m]>
and last time we swore off them because it's a lot of hateful work too
<adamgreig[m]>
I think there's a middle ground for crates that are so embedded in dependency networks
<adamgreig[m]>
but I worry in practice that means I am choosing "release never", yes :P
<adamgreig[m]>
or you just "release often but never a breaking release" which is probably a better way to go
<JamesMunns[m]>
idk, I don't have anything novel to add. I think we could afford to be a little more inconvenient a little more often :)
<adamgreig[m]>
anyway embedded-hal 1.0 should be out any day now
<adamgreig[m]>
JamesMunns[m]: I don't mind so much but a lot of the inconvenience falls on me too :P
<dirbaio[m]>
what do the PACs need out of cortex-m/cortex-m-rt?
<adamgreig[m]>
cortex-m-rt is for exporting the interrupt macro business iirc
<dirbaio[m]>
ah shit yeah
<adamgreig[m]>
but that's ok, it's distinct from cortex-m
<adamgreig[m]>
I don't recall off the top of my head what they need from cortex-m...
<adamgreig[m]>
it better not just be re-exporting CorePeripherals lmao
<dirbaio[m]>
there's still pub use cortex_m_rt::interrupt; tho
<adamgreig[m]>
I guess in principle things like embassy should be able to use cortex-m-hal, but maybe in such a way that they can use 1.0 and a final application can use 2.0 without a problem
<adamgreig[m]>
hm, won't changing the interruptnumber trait to be a re-export mean it's a different type, same problem as volatile_register?
<adamgreig[m]>
but since you can't have two versions of cortex-m 0.7 in your application perhaps it works out?
<dirbaio[m]>
it's only breaking if you make two import paths "no longer the same type"
<dirbaio[m]>
* same type/trait"
<dirbaio[m]>
like, the user can import cortex-m and volatile-register, and write code that only compiles if the regs they get from cortex-m are the same type as from volatile-register
<adamgreig[m]>
right, and they can't import cortex-m 0.7.7 and cortex-m 0.7.8 together
<dirbaio[m]>
that's not the case for this reexport, we're only adding a new way to name the trait (through importing cortex-m-interrupt-number)
<dirbaio[m]>
yeah
<dirbaio[m]>
but even if they could (you kinda can if one is from crates.io and another is from git/path), they already are considered different traits
<adamgreig[m]>
you can't because of the links key
<adamgreig[m]>
but yea, ok, makes sense
<dirbaio[m]>
ahhhh trie
<dirbaio[m]>
* ahhhh ture
<dirbaio[m]>
* ahhhh true
<adamgreig[m]>
worth double checking there's nothing else in cortex-m that should be in this trait crate I guess, but otherwise that should be a very easy thing to release
<adamgreig[m]>
and easy enough to swap svd2rust to... less easy to get into all the pacs but it should happen in time
<dirbaio[m]>
<dirbaio[m]> "there's still pub use cortex_m_..." <- it doesn't fix the problem because this
<dirbaio[m]>
pacs still depend on cortex-m-rt, cortex-m-rt depends on cortex-m
<adamgreig[m]>
I don't think it does
<adamgreig[m]>
not sure if we could pull a similar trick there or if it's as worthwhile
<adamgreig[m]>
cortex-m-rt could split naturally into "the actual runtime, with the linker script and init code your application needs", and "the interrupt related traits and macro that you use to bind interrupts"
<adamgreig[m]>
it's not like armv6m is going to grow new exception names any time soon
<dirbaio[m]>
well there's still "controversial" stuff in the macros
<adamgreig[m]>
the slightly weird aliasing enum/macro business is a bit annoying though
<dirbaio[m]>
like the hardfault trampoline or the static mut transform
<adamgreig[m]>
true, and the PACs shouldn't need to depend on that stuff
<adamgreig[m]>
hardfault trampoline is soon to be optional at least
<dirbaio[m]>
ideally you should be able to "use the pac interrupt enum with the cortex-m-rt macro"
<dirbaio[m]>
without the pac having to "know about" the macro
<adamgreig[m]>
or even #[cortex_m_rt::interrupt(nrf52840_pac::Interrupt)] fn UARTE1 {}
<adamgreig[m]>
or even just nrf52840, it can add Interrupt itself
<dirbaio[m]>
ah yeah
<adamgreig[m]>
or you tell people to import the pac as pac lol
<dirbaio[m]>
noooo
<adamgreig[m]>
you could have the argument default to pac and be optionally filled in
<adamgreig[m]>
#[interrupt] fn UART1 {} or #[interrupt(nrf52840_pac)] fn UART1 {}`
<adamgreig[m]>
s/#/`#/, s//`/, s/#/`#/
<dirbaio[m]>
that'd be confusing
<adamgreig[m]>
but it's "backwards compatible"
<adamgreig[m]>
🙃
<adamgreig[m]>
anyway, it does seem like maybe the pacs could be decoupled from c-m-rt this way
<dirbaio[m]>
"backwards compatible" with lots of """, you ahve to add the magic use ... as pac;
<adamgreig[m]>
maybe the pacs could export an interrupt macro that itself emits #[cortex_m_rt::interrupt(pac_name)] and don't themselves add a dependency on c-m-rt
<adamgreig[m]>
i don't love it
<dirbaio[m]>
that breaks if you use the PAC through a reexport from the HAL
<adamgreig[m]>
ah indeed
<dirbaio[m]>
it's all so cursed
<dirbaio[m]>
I wish proc macros had $crate
<adamgreig[m]>
well, maybe just "put the pac name in the interrupt macro" is not too bad, in exchange for "you can actually use new versions of c-m-rt"
<dirbaio[m]>
or there was support for non-proc attribute macros ...
<adamgreig[m]>
I still think having "if you don't put a name, it defaults to pac" isn't terrible as a convenience
<adamgreig[m]>
yea, if only
<adamgreig[m]>
I'd better run, still at work and my cat is going to be hungry and/or angry, but this sounds like a fairly promising and easy thing to do?
<dirbaio[m]>
yea
<dirbaio[m]>
maybe? :D
<adamgreig[m]>
making it so it's plausible to cut new c-m and c-m-rt releases without bumping every pac and (and then every hal after that) sounds quite nice
<dirbaio[m]>
> and then every hal after that
<dirbaio[m]>
I think HALs shouldn't reexport pacs ... but that's another story 🤣
<adamgreig[m]>
as in, the PACs have to publish an update, and then the HALs using them have to bump versions and publish their own update, before end users can use the new c-m dependency
<adamgreig[m]>
even if they don't re-export it they still depend on it and thus transitively on the old c-m
<dirbaio[m]>
ah true, so only the 1st time
<adamgreig[m]>
yea, once the pacs don't depend on c-m it's all happy
<dirbaio[m]>
HALs reexporting the PAC means a PAC bump requires a HAL bump, every time :P
<dirbaio[m]>
well, with owned pac singletons it does even if the hal doesn't reexport it ☠️
<firefrommoonligh>
<dirbaio[m]> "I think HALs shouldn't reexport..." <- I do it as a convenience feature so firmware doesn't need to select the PAC; seems like that would be another thing to keep in sync on the firmware side that can be handled HAL side
<firefrommoonligh>
Since I assume the likelyhood of a PAC escape hatch for HAL limitations is inevitable
<firefrommoonligh>
s/likelyhood/need/
<GrantM11235[m]>
embassy-stm32 now also exports some enums from the pac for rcc stuff, right?
<firefrommoonligh>
For example, even though I control the HALs directlcy in firmware, I still use the escape hatch in some cases; mainly if I don't want to take ownership and lock something to clear an interrupt etc
lightningwright has joined #rust-embedded
<dirbaio[m]>
yeah, agreed it's nice to have, that's why I make it opt-in
<dirbaio[m]>
explicitly marked as "unstable"
<dirbaio[m]>
so a minor HAL bump can do a major PAC bump
<firefrommoonligh>
yea
<dirbaio[m]>
GrantM11235[m]: true. so a PAC bump is still technically breaking
<dirbaio[m]>
it's way more "theoretical" than if you outright reexport the PAC tho
crabbedhaloablut has quit []
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
TomB[m] has joined #rust-embedded
<TomB[m]>
so did i just read everything was switching from svd2rust to chiptool, with pointers and infinitely faster builds? or am I just hoping that this becomes the case
<adamgreig[m]>
that's not what we discussed, no
<dirbaio[m]>
lol
brazuca has joined #rust-embedded
brazuca has quit [Quit: Client closed]
Jonas[m]1 has quit [Quit: Idle timeout reached: 172800s]