How is embedded-dma designed? It uses StableDeref, would Pin be acceptible here?

it's very similar to Pin but not exactly the same

the main problem it solves is safety against leaking (like with mem::forget)

<luojia65[m] "How is embedded-dma designed? It"> It revolves around buffers, which are Unpin, causing Pin to not work as expected

What could work would be to Pin the transfer, but even that there are a few problems

That I don't know how to solve without macros

* What could work would be to Pin the transfer, but even with that there are a few problems

For more information about problems with Pin, see rust-embedded/embedonomicon #64

Which reminds me that I still need to fix the docs, I completely forgot about that, damn

<uep[m] "> <@mathias_koch:matrix.org> How"> Aha.. That's a bummer! I had it working previously, but after updating vscode or R-A, unknown which one? it seems to have broken :(

see the workaround above

that's fine for me / now

Ahh.. cool! Missed that it was related to this. Thanks!

Is there a way I can configure `cargo run` with probe-rtt so that it flashes via dfu but still debugs over the ST-LINK? I'm just trying to make the default in my code base to flash with DFU so end users don't *need* to have an ST-LINK in order to update the firmware.

Write a script that flashes via DFU and then run cargo-embed or something?

riskable: ^

Yeah I was thinking about doing that but I thought maybe there was maybe a better way

Better in what sense?

I don't know if it's possible but maybe you can run bash with the .cargo/config.toml runner property?

You just call `cargo run` and this scripts does the job

<diondokter[m] "I don't know if it's possible bu"> Yes, this

Ah ok

Or you could do it more cross platform with powershell 😉

How is powershell more cross platform lol

works everywhere! it's even opensource now! microsoft are now the good guys! yay

what is that preview icon?

good question 🤷‍♂️

Something from marix.org

matrix proxies the images, it's probably some github user's avatar

Ah, ok that's just an on-demand render

it's not someone's avatar...

well I mean it's an avatar

in the original sense I suppose

oh wow it's actually an official image :D

cute

maybe i should install powershell after all :p

oh lol

it seems they had a non-chibi version originally github.com/PowerShell/PowerShell/blob/master/assets/Avatar.svg

why and how matrix pulled that out though i have no idea

from the html header: `<meta property="og:image" content="repository-images.githubusercontent…ad0ad80-cdec-11ea-8248-a37bc0571bfd" />`

in repo settings: " Social preview Upload an image to customize your repository’s social media preview. "

TIL that exists haha

aah of course. wild that they don't show the social preview image anywhere on the actual html page

though i guess this is much nicer than the default where twitter github links include my avatar in huge instead which is quite offputting

adamgreig: I've updated rust-embedded/wg #449, though I ended up disagreeing with one of your points.

I likely won't be around fully during the meeting, but happy to discuss async on comments (and I'll have my ipad open while cooking dinner)

Is it possible to put an stm32f4 into DFU mode via software? So if a user presses a certain key combo on my keyboard it goes into DFU mode?

I'd like to put a soft limit on proposing any new changes to the MSRV management I described, unless there is something internally inconsistent with the policy I proposed. I understand if people don't *like* the behavior I proposed, but I don't see any other way of "connecting the dots" without just making *different* tradeoffs

<riskable[m] "Is it possible to put an stm32f4"> Which STM32F4? But generally yes, let me find you an example

jamesmunns: stm32f401/stm32f411

I mean, I just started putting the schema together so I can still choose a different MCU :)

jamesmunns: thanks!

<riskable[m] "Is it possible to put an stm32f4"> Possibly.

riskable: github.com/jamesmunns/feather-405/b…ter/hello-405/src/main.rs#L148-L175

jamesmunns: Awesome, thanks! Looking at that now

TIL I learned what "Chibi" style is.

There's me doing it for the F405, using an internal implementation detail of `panic-persist`, where it sets a RAM flag when a panic occurs

* TIL what "Chibi" style is.

you might find the relevant address is different on the F411/401, but the idea is the same

For some reason, that didn't *always* work on the F405 (or at least it was much more reliable on the stm32f072), which might be because this would be better to do in a `naked` assembly function.

but yeah, adamgreig is right, there's an app note that gives you the values you need for the stack pointer and jump-to location

You might also consider resetting the vector table and stack pointer back to the "right" location if you don't jump to bootloader. I'm not sure how "clean" the bootloader leaves the operating environment

(but then definitely do that in ASM, not Rust)

if you don't jump to the bootloader, you shouldn't need to touch vtor/sp i wouldn't have thought

I meant if the bootloader moved them, and expected you to put them back

if the bootloader has touched them your code won't be running though

all the vendor C startup code I've seen manually sets the VTOR and SP

hmm, unless you can ask the bootloader to jump into your code over dfu?

i thought you could just reset

No idea, I'm guessing at that.

it was flaky, that was all I knew for sure. Never found out why.

the built in bootloader doesn't run at boot on the stm32, only if you manually jump to it somehow

(unlike some platforms where the bootloader ROM always runs first and can decide whether or not to jump to your code)

I got burned by this before, the STM32F1 ROM bootloader also modifies VTOR and you gotto reset them manually

manually setting vtor and sp always seems like such a cludge to me but i guess welcome to embedded

timokrgr: were you asking the f1 bootloader to jump back to your code without going through a reset/

* timokrgr: were you asking the f1 bootloader to jump back to your code without going through a reset?

yes

<adamgreig-m "manually setting vtor and sp alw"> to be clear, I mean doing this on every boot, irregardless of whether it should be needed

timokrgr: I guess that's fair then, since vtor needs to be correct for the bootloader to service interrupts, kind of handy that it sets it itself perhaps

Does dfu util command this after a program?

but in the USB DFU bootloader case I don't think you can ask it to jump to your code, only to reset, which should clear vtor... aiui

To jump to the new image?

adamgreig: yeah I agree

We should probably offer that as an opt in feature for cmrt

why have a dedicated GO command and not reset VTOR? ST shenanigan :D

To set things we shouldn't have to set

so dfu-util supports sending a 'detach' request which should trigger a reset

st's protocol description also says they support a non-standard "2. Leave DFU is achieved by a 0 data download request followed by GetStatus request and device reset." which triggers "jump to application address and exit DFU mode"

so possibly you can wrangle it into jumping to your code but I think the usual thing is a reset

see also rust-embedded/cortex-m-rt #55 and rust-embedded/cortex-m-rt #283

That's dfu-util command I used

aah, `:leave` instead of `-e`

wonder what it does to the device

Nb: I have no idea what I'm doing with dfu-util, so I probably just copied that from someone else's project :p

the other nice thing you can do is implement DFU in your device's USB descriptor and handle just the 'detach' event, so you can use dfu-util to trigger your not-in-bootloader device to jump to bootloader

(from st.com/resource/en/application_note…2-bootloader-stmicroelectronics.pdf )

Does this mean that leave SHOULD work?

leave should work, but you do need to set VTOR yourself if you're doing it

assuming dfu-util correctly does the things that st require, which I guess is likely

[adamgreig](matrix.to/#/@adamgreig:matrix.org) don't we want to remove the (not working) deprecated warning from cortex-m ?

though on this stm32f0 it causes it to re-enter the bootloader, heh

thalesfragoso: yep i think so

agenda for upcoming meeting is hackmd.io/hz2ImTjZQA2qJWShrb9bxA if anyone wants to add items

thalesfragoso: from 0.7, you mean?

Yeah, I mean, it shouldn't be breaking, but doesn't make sense to leave it there anyways

It doesn't work and breaks CI on nightly

anyone got a smoltcp dns implementation? can't find much online

thanks, I've pushed an update removing the deprecation warning

@room meeting in 5 min, please sign in add anything you'd like to discuss to the agenda: hackmd.io/hz2ImTjZQA2qJWShrb9bxA

ok, let's get started!

as far as I know there's no update on the REC issue, if eldruin is around later or we have time at the end let's come back to that

jamesmunns updated the MSRV policy PR here: rust-embedded/wg #449 which is now ready for voting

the new scorched earth alternative of throwing msrv in the bin certainly has appeal, hah

I'm sort of at this point

on balance I think you're right, handle dependencies that bump our MSRV by pinning a max version of that dependency and soon/simultaneously releasing a new semver bump that increases our MSRV, and that is just how we handle that edge case

We have provided little to no value (in my opinion) for discussing it or maintaining it, and I don't think that has changed since April (!!!) since I originally wrote this RFC.

I'm surprised to hear that.

<adamgreig-m "on balance I think you're right,"> It's a mistake the RISC-V team already made and got dependency hell for half a year

I think MSRV leads to "pick your poison".

this doesn't really sit right with me, do any other crates do something like this?

I honestly think keeping things simple and "must build for the last three stable releases at the time of crate release" would be a much better and simpler policy.

shouldn't the MSRV policy be picked such that no dependencies have a looser MSRV?

jschievink: the problem is we don't control all our dependencies

because if not, what's the worth that our policy adds?

I'm aware

so they could and have released semver-trivial updates that break our msrv, at which point we have no good options really

jamesmunns: is that meaningfully different?

ehhh ignore me

I'm not proposing any new MSRV policies.

I guess the key difference is it means we can ignore dependencies changing after release, heh

to a user, it doesn't matter if our code or our dependencies caused breakage, so I don't see how a policy that ignores dependencies is useful

I definitely think disasm and jschievink have salient points (though I think my RFC addresses how we handle dependencies)

* I honestly think keeping things simple and "must build for the last three stable releases at the time of crate release" would be a much better and simpler policy.

Edit: Don't listen to this.

My main surprise here is that not having a strict MSRV policy would that not counter the idea of having something like sealed Rust?

Sealed Rust is likely to require paid/maintained third party support (if for no other reason than certification), so pushing that on open source maintainers is undesirable and likely unhelpful.

or rather

in the situation where a dependency releases an update after us which breaks our released crate's msrv, can the end user just pin the earlier version of the dependency themselves? perhaps that's a reasonable thing to ask of someone wanting an older msrv to work

to use libraries in a safety criticial context, they are likely to require documentation, due diligence, and process that is unlikely to be useful for general purpose open source development.

If you can use off the shelf open source libraries: You probably don't need sealed rust, IMO.

Interesting.

or at the very least you can vendor them all yourself and therefore not get msrv surprises

Also that

Taking open source "in house" and writing your own docs and verification plan is also totally a legit option

OR: If the desire to have them certified is enough, a company that is getting paid to maintain that (and deal with all the pain in the ass work or multiple release trains) should be doing that and contributing back to open source.

Don't let me derail the meeting though. I'm always happy to share my opinions on less limited time.

still, I don't want us to just not care and release say cortex-m 0.7 that requires a week-old rustc

I've never been a fan of MSRV. It's a rather strange concept causing a lot of effort and providing little benefit; especially for a well working environment like Rust.

I sorta disagree, but that's me.

or to take a PR that incidentally uses some new feature that bumps msrv to something very new without much benefit, perhaps

would you basically be happy just so long as it builds on current stable at the time of release?

Sorry for sabotaging my own RFC, but the fact that this has been in open discussion since April sort of makes me agree with therealprof more strongly

<adamgreig-m "would you basically be happy jus"> Yeah, honestly.

Again, I'm not the maintainer of these crates, so take my opinions with a grain of salt

If someone complains, I will be happy to offer them an LTS service contract for any of the WG crates, or refer them to other contractors who could

<adamgreig-m "would you basically be happy jus"> Fix: works, not builds ;)

I think it's far more important to ensure forward compatibility than backwards compatibility, yeah.

But I don't like the idea of asking OSS maintainers to bend over backwards for LTS

disasm: if only we had some sort of hardware-in-loop testing :p

IM WORKING ON IT, OKAY

<jamesmunns[m] "But I don't like the idea of ask"> yea, that's totally fair and quite appealing

:D

though perhaps you have a slight conflict of interest :p

Sure! Feel free not to point people my way.

well, maybe the thing is to do a second very simple PR suggesting nuking the MSRV and vote between them?

Lots of other folks doing great embedded-rust contracting work. I'd be happy to point folks to Hanno Braun or eldruin, who also do excellent work.

I don't think your opinion is any less valid

(also thanks to therealprof for bringing up sealed rust, I saw that in the scroll buffer a while back, and wanted to weigh in on that, but forgot)

if there's no strong interest in maintaining MSRVs and there is interest in using newer rustc features, perhaps dumping the msrv policy is the way forward

at least maybe an rfc about it might get some comments from anyone who actually benefits from it

There's certainly a cost to maintaining one.

which I think we're sort of lacking at the moment, beyond hypothetical users

I'm always hoping someone comes forward with a strong opinion so I don't have to forge one. 😛

ok, shall I put together a very minimal alternative rfc, specifically also asking for feedback from anyone benefitting from having msrv, and see what we get?

Yeah, explicit 👍️ to making a "nuke the MSRV" RFC.

(and open it for voting immediately too, no need to wait I don't think, it will be at least 2 weeks before we have a majority vote I expect)

I do think we should keep periodic CI tests for the current stable rust version

in case some dependency decides to intro an unstable features

but outside that, yolo

yea, just need to add some sort of cron entry to the new github actions stuff

and some sort of email altering for it I guess, or maybe it could open an issue for us :p

<jamesmunns[m] "I do think we should keep period"> Yes, that's quite important. You don't want to find forward breakage only if someone PRs a change.

ok, thanks

any last comments/thoughts on msrv?

good riddance

lol

(another 25 minutes lost to msrv)

We might even test an "expected MSRV" for documentation purposes

and we still cant use `rustup install stable-3`, so the MSRV requires periodic bumps anyways :|

jschievink: not if the msrv is just "stable" :p

yup :)

* We might even want to test an "expected MSRV" for documentation purposes

Maybe find another name other than MSRV for that, it got a bit burned, heh

eh, if we don't care, let's explicitly not care.

"minimum suggested rust version"

ok, let's move on to the next agenda bits, we can come back if there's time after

cortex-m 0.7 is in principle ready to go I think: rust-embedded/cortex-m #286

End of the Delay impl copy-paste, finally!

haha yep it's been a while coming

hopefully we can move towards 1.0 after this

though we'll see, might be a few things worth tidying up

should also allow moving to bare-metal 1.0

the main questions for c-m 0.7 is whether we're missing anything we should get in, and whether the changelog is missing anything we already got in :p

I'll check later.

this has all the breaking changes we've been accumulating since 0.6.1 or so

I just noticed I've been asked to review it, oops. ;)

there's some nuisance in that a lot of wg crates depend on cortex-m <0.7, so they'll all need updating when/if they still build with 0.7

I said "a lot" but it's not that many really. there's more in the generic ecosystem.

* I said "a lot" but it's not that many really. there's more in the general ecosystem.

I believe lots of them can use 0.6 and 0.7 at the same time

lots of them could but I don't think any have a cargo.toml that would allow it

(since that would be pretty naughty to have specified before 0.7 was even released)

premature anticipation? 😀

I guess my point is: each breaking release requires a lot of other crates to eventually update their dependencies, so ideally we wouldn't do them all the time, but this one is long overdue

... or a good crystal ball.

Indeed.

Let's get that shipped ASAP.

ok, if there's any other comments please drop them on the PR

for the remaining time I wanted to see if anyone wanted to chat about rust-embedded/svd2rust #478#issuecomment-724732527

have people tested cortex-m master? I'm still somewhat uneasy about having 0 integration tests

I don't see any good reason to not make breaking changes, everyone can still use older svd2rust versions to generate the code if they don't like the newer ones

re: 478 I have not read the whole thread but would it be possible to make write's closure's return type generic so that it accepts both `()` (statement) and `&mut W` -- unsure if that would even compile

Also think about this: people make positive changes, they spend their time on implementation, so this implementation already has value. Ignoring it just because it's not "valuable enough" is really strange.

It's not a hacktober fest PR after all

it is fair to reject minor improvements over widespread breakage imo

provided it is deemed too minor to be worth the breakage

I think that the breakage itself is overestimated

but I'm not sure if embedded rust is at that point yet

how is it widespread breakage tho? svd2rust is only used once to generate the PAC, then the PAC is fixed without a new release, so I don't see much issue here?

(genuinely curious :))

<japaric[m] "re: 478 I have not read the whol"> seems like it doesn't, because the return type would have to contain a higher-ranked lifetime bound by the closure's FnOnce bound

<disasm[m] "Also think about this: people ma"> No one is ignoring anyone.

<jschievink "seems like it doesn't, because t"> hmm, yeah. this does compile play.rust-lang.org/?version=stable&…st=29358fd7d9a016c5c28c1c1cfa9babba but that generic `'a` feels not right

I don't think you could call that closure with the right argument lifetime though

yep, the closure argument cannot be called (`let mut w = W; f(&mut w);` within `write` doesn't compile)

yatekii: yea, the breakage is when the PACs update (for example to cover more registers), and choose to use the latest svd2rust, and then all the HALs need to do a load of small syntax changes to get them to build with the new PAC version

so it creates work for HAL maintainers and for users directly using the PACs

but it's not work they have to undertake until they want to use the new versions of the PAC

ok, I totally see that one :)

beyond that specific and relatively simple breaking change I worry a bit more about the idea that svd2rust doesn't really have a clear long-term plan or policy for breaking changes

perhaps the plan is basically "svd2rust is more or less stable, so we won't make non-bug-fix changes that aren't really necessary, because it's now widely used and good enough"

Yeah, that.

Tho, I feel like if the change is actually seen as an improvement by the majority of folks it is better doing it sooner than later. Not having a strong opionion which one I'd like more :)

or perhaps it's "anything better would have to be so radically different we need to experiment with it out-of-tree, see if it's popular, and then consider swapping over to it wholesale"

it's fair to not just accept whatever breaking changes come along if they're not in the direction we want to go, but it's harder to explain that if we don't know what the direction is either

I think if we make a breaking change we need to have a complete remodel.

certainly for this particular change i think it would be fair to go either way; it's not a complicated break and it does make the api a little nicer, but it is a breaking change that would require a bunch of mechanical changes

Also svd2rust is version 0.17.0, so about ~16 breaking releases already

if we were currently releasing a few breaking changes every few months it would definitely get included, no doubt

would this be the one and only breaking change in the next release?

but we're not, the last was 10 months ago and that didn't even break existing code iirc

disasm: Not really correct.

jschievink: we have the Nr/InterruptNumber thing pending, and some small msp430 breaks, I think

okay, seems fine to bundle them up then

That's not really an general API brreakage.

* That's not really an general API breakage.

If we break the API we're going to split the whole ecosystem which is really bad.

hmm

I'm not sure when the last API breakage was, but they're very rare

it seems to be that this change would not really split the whole ecosystem, since PACs/HALs can update at their leisure

* it seems to me that this change would not really split the whole ecosystem, since PACs/HALs can update at their leisure

HALs "split the ecosystem" in pretty the same way

so it's no like in async land where tokio uses one set of traits and has one reactor, and the rest uses entirely different foundations

You also have have applications and helper crates like stm32-usbd which might also be affected.

disasm: Not rreally.

* disasm: Not really.

hmm, yeah, stm32-usbd is a good example

<therealprof[m] "disasm: Not rreally."> Explain then please

I think stm32-usbd is a bad example, doesn't it vendor its own pac entirely?

oh

It does, but before it did this was a huge pain

But for different reason

disasm: Well, that was your claim; I haven't seen that yet. Or do you mean different APIs for different families?

because the types were wrong for cross-device compat?

<therealprof[m] "disasm: Well, that was your clai"> Some HALs update their API in a breaking way and it's not a huge problem in general

disasm: That happens rarely and not wholesale. PAC updates are also breaking but they often don't require any or only minor changes.

<adamgreig-m "because the types were wrong for"> Because it depended on multiple hal versions at once and it was painful to update stm32-usbd each time one of the HALs releases a new version. But yeah, different PACs were incompatible too

<therealprof[m] "disasm: That happens rarely and "> But you still have to fix something in your code, like RCC setup. Is that a lot different from pac register accesses?

Again rarely.

You don't usually notice it because it's an easy change and it's distributed

Also PACs are different because they're forwarded by the HAL. If you access a PAC in an application through the HAL it will usually just work with a dependency bump of the HAL and you don't need to worry.

If the PAC changes the interface that's a whole different story.

no one's denying that people will have to make some changes when they update to a newer PAC/HAL, whether they're HAL authors or end users

quite possibly people will have to do so anyway for the Nr thing

<therealprof[m] "Also PACs are different because "> It's not something that breaks accidentally, you have to update the HAL version explicitly. And it's ok to get different API in this case

I disagree.

That's how semver works

And we don't have "stable" channels like Rust does

Breaking the API for a minor feelgood change is not a good idea.

Is there a rule that forces all users to only use the latest svd2rust to build pacs?

Don't like the release? Wait until the next one you like

<disasm[m] "Is there a rule that forces all "> no, but it would default to this, which I guess most fear will cause lots of confusion :)

disasm: I agree you can do that technically. I disagree is that this should be done lightly because it's technically okay.

The next release will be kind of mandatory due to the Nr change.

(we're out of time for the meeting, sorry, I didn't notice)

Well, I think that the main point is that we don't have understanding of the development direction

And we have problems due to this

right, I think if we had a better handle on that it would be much easier to make a decision about this pr

Indeed we don't.

if we're "still doing active development, we expect there might be more breaking changes coming, we're working on things", then the pr seems really good to merge

if we're "basically done, stable, bug fixes, maybe one day we'll change the whole thing for 1.0 or just swap everyone to a new project", no point accepting it

if we're sort of somewhere in the middle it's harder :p

Maybe. But if we're breaking things we could go into a completely different direction altogether.

Why people are thinking in a way that 1.0 is the end of the world?

It's not? 😛

Like, "we should do everything before 1.0 and then stop"

at one point we were hoping to get to 1.0 really soon so we could have a stable set of 1.0 releases and start planning some very different 2.0s

which honestly sounds like a nicer place to be, so we can get all three digits of sember to be meaningful again, heh

But what actually changes? You still have semver, but one more digit for differentiating between "minor release" and "patch-fix release"

We could actually just call it 1.0 now.

I think part of the problem of answering "what's the development direction" is also "who are the developers"

Right.

What I really liked about EWG ecosystem is fast development pace, and making these super-stable 1.0 releases basically destroys this.

svd2rust is pretty much that. A rock in the ecosystem.

It's not perfect but it's used all over the map.

It wasn't a rock, I remember these times

but there's definitely lots of things people want to change about it, it's just become (as one of the comments called it) weighed down by its dependants

Remember, therealprof asked me to join the tools team to help with lots of svd2rust PRs :)

Honestly we haven't had that many changes which were turned down.

Yes, tons of good and compatible improvements which needed reviewing.

But what's being complained about now is that there's not checklist of things to do next or roadmap.

I have some opinions on that

But they get very close to "delete svd2rust and rewrite it from scratch"

So I'm not sure how helpful that is

<therealprof[m] "Yes, tons of good and compatible"> Some of them changed API in a breaking, but good way. For example, riscv-rust/e310x-hal 3edab54

svd3rust :D

disasm: Yeah, but not cortex-m.

that change definitely affected cortex-m?

<jschievink "But they get very close to "dele"> Actually I want to do something similar

it's where the union types changed to method calls right?

jschievink: Very much. I think that's the way to go.

<adamgreig-m "that change definitely affected "> It technically affected hal, why are you asking about cortex-m?

disasm: I'm just saying that the change there affected all users, not just riscv

Well, let's stop making breaking changes, they affect all users

The other architectures were bolted on later (and technically shouldn't even be using it) so assuming the same sort of API stability is weird.

<disasm[m] "Well, let's stop making breaking"> I feel you're missing the point. It's all about unjustified breaking changes out of the blue.

disasm: sorry!! I agree with you here, I was replying to therealprof who I thought was suggesting your link only related to risc-v

Hmm why rewrite the svd2rust tooling completely. I mean I am complaining about the API a lot, but what would actually change; I don't know too much specifics here :/

And you're about to release a new cortex-m version with breaking changes "for the whole ecosystem"

yea, including the huge Nr/InterruptNumber churn

Who are we doing that for again? 😛

yatekii: well, hopefully you could keep most of the tooling and backend, it's the generated api that most wants to change

It's not exactly that we're making that change lightly but because there's an actual need to do it. And that's the difference between nice-to-have and a requirement.

Well, I think I'm done with my thoughts here. Anyone interested in my vision of PAC v2.0 concept?

I am, but I have to run for now

disasm: Absolutely.

does it start by rewriting stm32ral in rust :p

(bbl)

Not really :D

<disasm[m] "Well, I think I'm done with my t"> yes :D

Well, the main idea is to separate ownership and register access. Completely, maybe into a separate crates. The idea is to have a stable "base" with peripherals to provide ownership, but moving "register access" crate to access the peripherals

This enables one to use different register accessors for the same peripherals

For example, you can update "pac" in a non-breaking way in each hal, you can fix bugs in register definitions without breaking HAL API, because PAC will not be reexported

How'd that work?

Also, you can build only a subset of register accessors, only those you actually need

And how is ownership realised or are you giving up on the concept?

Well, you can implement you own set of functions, "deref" and whatever you need to access the peripheral

<therealprof[m] "And how is ownership realised or"> Ownership is implemented in the very same way as before: you get the Peripheral structure in a singleton way and get separate peripherals from it

But this structure, as well as the peripherals, know nothing about register access layer

You can use svd2rust layer, stm32ral layer or whatever you like

Hm...

The peripheral crate will be super-stable, and it's easy to achieve, because peripheral usually don't appear out of the blue

* The peripheral crate will be super-stable, and it's easy to achieve, because peripherals usually don't appear out of the blue

Well, don't tell that to ST. ;)

What level of abstraction would the peripheral crate provide?

Only the Peripheral structure and ZST peripheral types

<therealprof[m] "Well, don't tell that to ST. ;)"> XD kekd

That's basically it

I guess there're three main points for me such a new concept has to deliver: Register documentation, compile speed, code efficiency for non-optimized code.

Sure, it should be at least not worse

The only item of those three which is currently provided by svd2rust is barely acceptable documentation.

The other two points are abysmal.

I'm very much okay with anything else including the API.

I think that the first one is too, documentation became much worse in terms of usability

svd2rust's API is incredibly hard to understand, even for people who are working with it for a long time

The `Reg` concept made it almost unusable

<jschievink "svd2rust's API is incredibly har"> Switch to stm32ral :D

I don't even use STM much :D

It works with anything

They need to change the name

Yep, basically everything that is ARM :D

<jschievink "svd2rust's API is incredibly har"> I don't think so. I've also explained it to a lot of people and they understood and liked it.

Well, survivorship bias makes this hard to judge

I agree with jschievink on this one :) Maybe I am just below average IQ then :)

Heh.

<Lumpio- "They need to change the name"> Heh, I should probably have written a generic svd2ral and then used it in stm32ral but, well, hindsight

ral docs are broken docs.rs/crate/stm32ral/0.4.1

I mean the API is not all bad. what I struggle most with is that there is a basic trait with generics which is implemented like 10k times for all the different regs and it's hard to find the right call for anything related to that. And everytime I have to figure this out anew. I did not work with it nearly as much as you folks did, so my sample might be an outlier :)

mhmm, and that is a workaround for slow compile times, I believe

(ironically running straight into other compile time issues in rustc)

It looks like rustdoc is getting some work that should specifically help svd2rust crates

I guess they are sort of especially pathological

I'll praise the day intuitive type links hit in rustdoc =) I think this is still nightly tho

rustc build times are also very poor imo

I always get annoyed when I have to rebuild PACs for something

yeah, I mean I can live with build times personnally, but I guess the impact on things like r-a matter to me very much :)

yup, r-a is also taking a fair while longer on PACs than on most other crates

Has anyone made some sort of abstraction that works on both mcu peripherals and spi/i2c peripherals?

They both involve reading/writing/rmw-ing registers

<jschievink "I always get annoyed when I have"> This was a major motivator for stm32ral which is about 3s to build from cold

yeah, I know

it should be a primary goal of whatever svd2rust's successor will be

Oh, any replacement for svd2rust should probably address dereferenceable etc

svd2rust is literally impossible to use for some chips because of this

yeah, that too

hey guys am new here and also new to hardware coming from sofware dev background

what's preferable to start out with in C or Rust??

<adamgreig-m "Oh, any replacement for svd2rust"> What do you mean?

not using references to registers and register blocks

Not using references into mmio addresses anyway

Hmm, interesting. Anything I can read about the impact?

I had some vague ideas for doing it in ral but didn't implement any yet

I guess raw pointers are ok

Raw pointers are probably the only thing that's ok, just passing them into read_volatile etc

andodeki - are you comfortable with C or Rust already?

ian_rees I am comfortable with C

If we had non-multiple-of-8-bits native types we could do really smooth things.

<adamgreig-m "Not using references into mmio a"> why is this bad?

<disasm[m] "Well, the main idea is to separa"> This was sort of my hope with the nosync feature in ral but only ever did the ral half

But it seems nice that the actual register access is globally available and always unsafe, and a hal or other ownership structure wraps unsafe access in a way that ensures single use

But it's not clear how you enforce that globally (eg if users just use two such wrappers in one project), maybe using a pre-agreed links key in cargo

You still have ownership

<yatekii[m] "why is this bad?"> Check that wg pr I linked, the gist is rust may insert extra reads to them at any time, which might have side effects

<disasm[m] "You still have ownership"> Managed by the register access layer?

<adamgreig-m "But it's not clear how you enfor"> You can't create two wrappers in a safe way, because you have only one peripheral "object"

Oh, maybe I gave the layers the wrong way around, would you sort of give that single peripheral object to the register access layer?

<adamgreig-m "Oh, maybe I gave the layers the "> Yes, sure

<adamgreig-m "Check that wg pr I linked, the g"> oh sorry, missed that one, thanks, will read! sounds kinda bad, but folks warned me on discord that references can have sideeffects if you do not actually treat it as the reference rustc does :)

It's not clear it has ever caused any actual problem

But at least theoretically it could

<disasm[m] "Yes, sure"> Either by wrapping or with deref, but register access layer should not allow you to get round the ownership

I don't think it's possible to implement Deref due to the orphan rule, but anyway, the idea is "to achieve register access via a trait method"

andodeki: I work on firmware for a living, almost all in C, and am fairly new to Rust. Embedded Rust has been fun so far, and is very promising, but it's a steep learning curve. There is a whole lot of C-based example code available, including Arduino (C++ but with lots of helper).

ian_rees thanks man

I agree lots of material in C than Rust

no problem, I guess the answer depends on what you're looking to do. If I were just starting out and considering a career in embedded, I'd be tempted to go the Rust route. If your goal is just to get something working for a hobby project, probably Arduino.

LLVM does definitely use `dereferenceable` for optimizations (just checked, there's several uses that look like they can become issues in practice)

ian_rees I am seriously considering a career in embedded I have been hearing lots of Rust in hardware so was curious how the future of C and Rust in hardware is.

andodeki: at this point nobody can really tell, as we are still trying out what's best in Rust in a lot of ways, but there is a lot of folks already using rust embedded production :)

yatekii: thanks for the response.

I, personally, would never go back. I do have to for some clients :)

<yatekii[m] "I, personally, would never go ba"> 🤣🤣

I imagine that a person who's proficient in Rust would not have a hard time learning C, but it would feel dirty

<ian_rees[m] "I imagine that a person who's pr"> oooh really

I mean only with Rust I actually learned to code properly. before it was a hot mess even tho, back then, I would have insisted on the contrary :) does not mean my code is proper today tho :D

kinda general career advice: having a skill set that's useful but relatively rare (maybe an uncommon combination of fields or technologies) can be a good thing

<ian_rees[m] "kinda general career advice: hav"> I see sounds good

<yatekii[m] "I mean only with Rust I actually"> it's a strict language huh?

Rust's path of least resistance is to write code that would generally also work well in C. C isn't particularly strict but requires you to provide your own discipline which you have to be taught somehow, either through painful experience or good example code or a mentor or something.

^ this

For embedded uses C is only easier if you're buying into an existing ecosystem. If not then Rust much easier to get started.

<pinealservo[m] "Rust's path of least resistance "> insightful pinealservo🤔

<therealprof[m] "For embedded uses C is only easi"> at the expense of painfully experience as pinealservo pointed out

I have some time for rust-embedded stuff now, do we want to do the big cortex-m merge before 0.7?

I have lots of panic message strings bloating my .rodata

even building with release, LTO, and with panic-probe

dirbaio: Avoid panicing branches wherever possible.

yeah but many are in library code

Fix the libraries. ;)

is there really no way for the compiler to see these are unused?

Nope.

😱

😱😱

I don't think there's any fundamental reason it can't see that

it's just that the panic entry points are always considered cold, and there's too much indirection in the panic arguments

maybe because core comes prebuilt?

is it prebuilt without LTO?

not sure

it should be LTO-enabled at least

Getting rid of the tons of indirections in panic! calls is currently WIP.

maybe monkeypatching core somehow

More like directly using the most apropriate code for the task at hand.

* More like directly using the most appropriate code for the task at hand.

everything panics in rust! I can't rewrite the world

It really shouldn't.

even reading from a slice it's easy to get a bounds check that calls panic

sure I can add my own bounds check before, and hope it'll cause the compiler to optimize out its own

Or use iterators.

but still

panic is now a const item and things are being reworked to be much leaner. I'm not following everything that's going on but it looks as if it could turn into a profit for embedded as well.

Still, panicking code is bad style, especially panicking library code.

say I have some complex datastructure/algorithm

and if the program gets into a certain state that means I got a bug

shouldn't I use panic in that case?

No.

Unless you can't code your code in a resilient way.

what? that's definitely a place where you should panic

A panic really means: There's no clean way out of a situation.

that sounds like something where an assertion would fail

sometimes there IS no clean way out

and many of these are panics that I know will never be hit at runtime once i've got rid of all bugs

but the compiler can't still prove it

* but the compiler still can't prove it

> C++ requires implementations to detect UB during constexpr evaluation

wow, cool

If you say so.

let's replace them all with `unsafe { core::intrinsics::unreachable_unchecked() }` :D

(jk)

The only situation I every recall where there was no way out if when I ran out of memory I needed to tell the user I ran out of memory.

* The only situation I every recall where there was no way out is when I ran out of memory I needed to tell the user I ran out of memory.

* The only situation I ever recall where there was no way out is when I ran out of memory I needed to tell the user I ran out of memory.

But hey, feel free to panic wherever you like. I'm not going to stop you...

<dirbaio[m] "is there really no way for the c"> `panic-halt` usually works for me, I can't remember a time when it didn't

how are you building?

LTO? any special sauce thing?

Uhm, nope doesn't.

and if you `panic!("foo")` you don't get "foo" in your ".rodata"?

hmm, I usually just check if I get formatting, not strings

do you still get formatting code ?

Yes.

yeah, with panic-probe I don't get any of the `fmt` code

but I still get the strings

let me try with panic-halt

loads the string, calls panic

panic does nothing with the string

it's also quite frustrating that it's 10 bytes when it could be 2 🤷‍♂️

std-aware cargo could also help with this, since you could then turn on `feature = "panic_immediate_abort"`

I messed with it a while ago but didn't find any way to enable std/core featuers

has that changed?

-Zbuild-std-features

ooooooooooooh

oh right you're on nightly anyways

Hmm, just tested here, I actually get 10B of panic_fmt, probably didn't notice before since it's close to nothing

but I don't get nothing on rodata

and if I don't panic it seems that rust inlines my main (for the very simple test I have)

which saves a few bytes more

Yeah, but panic_halt alone doesn't give you anything.

LTO + `-Zbuild-std=core -Zbuild-std-features=panic_immediate_abort`

aaaaaand panic strings are gone!!!

YES

nice!

this also disables the inline(never) annotations

`-Zbuild-std` seems broken if using lto + overflow_checks though

* `-Zbuild-std` seems broken with lto + overflow_checks though

<jschievink "this also disables the inline(ne"> just on core ? or all code ?

on the panic entry points

in core

nothing else

got it

it builds compiler_builtins with overflow_checks, which results in it having panic calls, which apparently is not okay

yeah, sounds reasonable

compiler_builtins is `#![no_core]` I believe

huh, no, just no_std

wat

but still better than before

🤷‍♂️

probably the result of an abort intrinsic followed by an unreachable intrinsic when trap-unreachable is enabled

we will turn trap-unreachable off once the loop misoptimizations are fixed

Hm, I don't see any difference with those options on Cortex-M.

huh, how did to turn off TrapUnreachable?

I thought that wasn't configurable

oh you mean `-Zbuild-std-features`

now this is weird:

this works: cortex-m/inline-asm + -Zbuild-std=core -Zbuild-std-features=panic_immediate_abort

this fails: cortex-m/inline-asm + -Zbuild-std=core -Zbuild-std-features=panic_immediate_abort

* now this is weird:

this works: cortex-m/inline-asm + -Zbuild-std=core -Zbuild-std-features=panic_immediate_abort

this fails: cortex-m/inline-asm

with

no indication of where, but I guess it's in `cortex_m::asm::udf()`

hwat

llvm_asm!("udf" :::: "volatile");

it wants `udf #0xfe`

but `asm!("udf");` works

oh, I think we fixed that on master

ah no it doesn't

true, master has `udf #0`

cool

no idea why `-Zbuild-std` affects it tho

yeah that is weird

return -ETOOMUCHMAGIC

writing my own panic_handler that calls `udf`, I still get panic strings

so the problem is not panic-probe

I can only get rid of panic strings with `-Zbuild-std=core -Zbuild-std-features=panic_immediate_abort`

i'm cursed

probably the `inline(never)` obscures stuff

Have you tried `panic-halt` ? just for kicks

I didn't get strings with that

but it was a very simplistic example

yes, this is pretty cursed in my experience as well :)

panic-halt sometimes does and sometimes doesn't include the strings

nope, still get strings with panic-halt

I'll always get strings with panic-halt as shown above.

even with `-Zbuild-std=core -Zbuild-std-features=panic_immediate_abort` ?

Yes, even then but that was a one-off check. I don't really care about esoteric nightly options. I do run code size tests for all releases and some nightly regularly for comparison.

🤷‍♂️

panic_immediate_abort does work solidly for me it seems

solid 10% binary size reduction!

what if you use panic-halt but without the fence?

only `loop {}`

I wonder if putting `#[inline]` on the panic handler does anything :)

lemme try

well it's already being inlined

github.com/rust-embedded/cortex-m-semihosting is now archived o/

has nrf-softdevice, smoltcp, ppp driver, ethernet driver, our custom protocol with crypto shit, a "tiny VM script interpreter"

and I'm still not done :S

how much flash do you have?

nrf52840

1mb

* 1mbyte

but I have to fit softdevice, 2 oartitions of the app firmware for DFU, bootloader, config data

so unfortunately space is tight 😂

fun

<jschievink "what if you use panic-halt but w"> exactly the same as my `udf` panic

because loop{} becomes udf hah

hmm, even on the current nightly?

because `loop {}` should be fixed there

rustc 1.49.0-nightly (25f6938da 2020-11-09)

<dirbaio[m] "has nrf-softdevice, smoltcp, ppp"> sounds like basically what we want too, except I dooubt anyone is willing to learn rust ... they want async tho

hah, i left my scope on from before the meeting by mistake and it entered screensaver, forgot keysight included a portal easter egg imgur.com/a/Eb3nPRu

also sound like we finally need to implement page hashing :D

`udf`, `loop{}` and `loop{fence}` give me essentially the same binary

xd nicd

<adamgreig-m "hah, i left my scope on from bef"> wow :D

it scrolls a bunch of portal 2 quotes and swaps between ascii cake and ascii keysight logo

while printing the names of presumably the dev team

hmm, how do we plan on tagging releases in the cortex-m monorepo?

with a prefix per crate?

that's what i've done so far

for c-m-sh

and p-sh

have you recreated the tags for old releases?

though i had left c-m itself unprefixed

welp back to optimizing other shit

still got strings left, but they're from somewhere else now

no, it doesn't have the history anyway

the changelog points to the old repository and tags, and the old url remains valid

oh, right

we could have done a subtree merge i guess

shrug

might be more worthwhile for c-m-rt if we merge that too

currently importing panic-itm

will do rt afterwards

I know that miri was merged into rustc via history merge

so now we have 2 "initial commit"s there :)

the linux kernel has like 4

yea

i just archived github.com/rust-embedded/panic-semihosting

i force merged my old PR to add the note to readme

don't need to replace ci with a dummy job, just turned off branch protection instead :p

is there a problem in running a `thumbv7em-none-eabi` in a cortex-m4f?

eabihf is 1kb larger lol

it's fine

cortex-m-rt won't enable the FPU though

in fact I think rustc won't

so no hardware floating point

yeah I'm not using floats

no problem then

so eabi is a strict subset

* so eabi is a strict subset of eabihf

that's very neat

you could even see if thumbv6m-none-eabi is smaller

<adamgreig-m "don't need to replace ci with a "> yeah I can't do that

it's actually a different ABI

the instructions are the same

esy

* wat

in C, you can use hardware floating point while using the eabi (non-hf) ABI

in Rust, -hf will use FPU instructions, non-hf will not

in rust, our eabihf target tells rustc to do hardware fp, and also tells cortex-m-rt to enable the fpu at startup

but the real difference is in how you pass float arguments to function calls

in hf they go in the float registers

1kb larger seems like a lot, the additional code should be way smaller than that

what _is_ a strict subset is thumbv6m-none-eabi < thumbv7m-none-eabi < thumbv7em-none-eabi

i.e. you can run all the thumbv6 instructions on a cortex-m4f

haha build fails because I'm using github.com/Emill/X25519-Cortex-M4

which requires v7em

ah, fair

I would doubt v6 will be smaller anyway

and it'd definitely be slower right?

it has fewer instructions but they take the same space to encode, so some sequences will just require more instructions -> more flash used

it wouldn't be faster

1kb does seem a big difference admittedly, wonder what's causing it

:shrug

hmm, guess I should release c-m 0.7

* 🤷‍♂️

i hope it's less cursed than the last two c-m-sh releases

> <@dirbaio:matrix.org> haha build fails because I'm using github.com/Emill/X25519-Cortex-M4

> which requires v7em

You wouldn't be able to use v6 anyways, because of the atomics...

Yeah, v6 is quite limited.

damn atomics xD

No long branch targets, no int division, no CAS.

Manufacturers to like the M0/M0+ alot though :/

* Manufacturers do like the M0/M0+ alot though :/

ok, cortex-m v0.7.0 published and tagged

brace for impact :p

No division is also tough ugh

It's not that bad, I love the M0 but one should be aware of the ristrictions and things the compiler won't work around like odd divisions.

huh?

On the plus side rustc won't go out of it's way to bloat the code for you just to make it faster...

dirbaio: have you played around with the inlining threshold?

nope

that might help if you're using `-Os`

you might try -Oz too I guess

though it seems like -Os is usually better anyway somehow

-Os in rust is not that great

Seems the compiler options haven't really been tweaked to give a nice small binary size.

<therealprof[m] "-Os in rust is not that great"> I have found it to be similar to clang's Oz, although I haven't used clang for embedded all that much

just a few tests tbh

<adamgreig-m "ok, cortex-m v0.7.0 published an"> heh, that `const-fn` feature sure took its time

I did it!! 100% size reduction!! 🎉

hahaha

what the fuck broke

perfect, done, home time

<thalesfragoso[m] "I have found it to be similar to"> I don't really have any comparison between clang and rust. I just noticed from analyzing various options that the rust options are not picking up a lot of low hanging fruit.

And for whatever reason if you go thumbv7m instead of thumbv6m rustc really goes nuts.

Hmm, I sure haven't look all that much at the generated code in that regards

Easily observable by the memcpy done by r0.

only for looking for holes

Rustc is like: Oh, this loop sure looks like a memcpy so let's replace it with one. Hey look, we even have a "go fast" implementation for that so let's just paste it in and call it day.

"gotta go fast, don't mind Os"

Yeah.