rjframe has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
<re_irc> <@l​achlansneff:m​atrix.org> Could hal crates install a timer interrupt handler by default to enable async delay functions automatically?
emerent has joined #rust-embedded
<re_irc> <@d​irbaio:m​atrix.org> that's exactly what embassy does :D
<re_irc> <@n​ewam:m​atrix.org> Lachlan Sneff: Would need to abstract the interrupt handler installer if it is going to work cross platform, but yeah.
<re_irc> <@n​ewam:m​atrix.org> Cortex-A's get a little weird with the GIC
<re_irc> <@d​irbaio:m​atrix.org> that's easy to do with a fn() callback
<re_irc> <@d​irbaio:m​atrix.org> so it's the HAL that registers the interrupt
<re_irc> <@l​achlansneff:m​atrix.org> newam: How does rtic generically do timers on each system?
<re_irc> <@l​achlansneff:m​atrix.org> Cause it can do scheduling automatically
<re_irc> <@n​ewam:m​atrix.org> RTIC gets you to implement a monotonic timer trait
<re_irc> <@d​irbaio:m​atrix.org> rtic has the "Monotonic" trait which is somewhat similar, but a bit more lowlevel
<re_irc> <@d​irbaio:m​atrix.org> it's RTIC what registers the interrupt so it can't be hardware-independent
<re_irc> <@d​irbaio:m​atrix.org> (not that rtic tries to be)
<re_irc> <@f​irefrommoonlight:m​atrix.org> I've been using timers to presumably accomplish these tasks, but without an Async/Futures abstraction
<re_irc> <@n​ewam:m​atrix.org> async doesn't need timers though (for the scheduler), since it is cooperative and not pre-emptive.
<re_irc> <@l​achlansneff:m​atrix.org> An async timer would be useful
<re_irc> <@d​irbaio:m​atrix.org> it does need timers if oyu want to wait
<re_irc> <@d​irbaio:m​atrix.org> embassy can do `Timer::after(Duration::from_secs(1)).await`
<re_irc> <@d​irbaio:m​atrix.org> during the second the task is sleeping, other tasks can run
<re_irc> <@n​ewam:m​atrix.org> Yeah, users need timers, but the scheduler doesn't for async.
<re_irc> <@d​irbaio:m​atrix.org> the executor doesn't *need* timers, but it can *support* timers for the user to use
<re_irc> <@l​achlansneff:m​atrix.org> I'd like to see things from embassy make their way into embedded-hal, personally
<re_irc> <@d​irbaio:m​atrix.org> you can also write a timer that doesn't require collaboration for the executor, but then it's more inefficient
<re_irc> <@l​achlansneff:m​atrix.org> If async could work for hals by default, well that's the shiny future I'd like to see
<re_irc> <@d​irbaio:m​atrix.org> embassy has its own async hals
<re_irc> <@d​irbaio:m​atrix.org> the nrf one is quite complete
<re_irc> <@d​irbaio:m​atrix.org> you can have that shiny future today :D
<re_irc> <@f​irefrommoonlight:m​atrix.org> Not sure if this is related, but this is a common abstraction I use:
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> make_globals!(
<re_irc> <@f​irefrommoonlight:m​atrix.org> (DEBOUNCE_TIMER, Timer<pac::TIM15>),
<re_irc> <@f​irefrommoonlight:m​atrix.org> Presumably you could make that more concise with it baked into the framework / Await etc
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> with embassy:
<re_irc> <@d​irbaio:m​atrix.org> let btn1 = gpiote::PortInput::new(Input::new(p.P0_11, Pull::Up));
<re_irc> <@d​irbaio:m​atrix.org> loop {
<re_irc> <@d​irbaio:m​atrix.org> (nrf's gpiote is like stm32's exti)
<re_irc> <@d​irbaio:m​atrix.org> so it all uses interrupts internally, other tasks run while waiting for the button press
<re_irc> <@d​irbaio:m​atrix.org> uses interrupts without the ugly code of using interrupts
<re_irc> <@f​irefrommoonlight:m​atrix.org> Def more concise
<re_irc> <@d​irbaio:m​atrix.org> actually I think it needs 2 sleeps so it doesn't fire when you release the button...?
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> loop {
<re_irc> <@d​irbaio:m​atrix.org> pin.wait_for_high().await;
<re_irc> <@d​irbaio:m​atrix.org> Timer::after(Duration::from_millis(20)).await;
<re_irc> <@t​halesfragoso:m​atrix.org> You want it to fire on press or release ?
<re_irc> <@d​irbaio:m​atrix.org> press
<re_irc> <@t​halesfragoso:m​atrix.org> Is low pressed ?
<re_irc> <@d​irbaio:m​atrix.org> that code is assuming the button connects to gnd when pressed
<re_irc> <@t​halesfragoso:m​atrix.org> Okeis
<re_irc> <@d​irbaio:m​atrix.org> like the nrf52840dk
<re_irc> <@t​halesfragoso:m​atrix.org> I still wonder if connecting buttons to interrupts is a good idea
<re_irc> <@t​halesfragoso:m​atrix.org> I heard some people saying it could confuse the flip flops, but not sure if that really applies
<re_irc> <@d​irbaio:m​atrix.org> with GPIOTE? why wouldn't it be? that's its whole purpose
<re_irc> <@d​irbaio:m​atrix.org> it's the only way to do a low-power device that does something when you press a button
<re_irc> <@t​halesfragoso:m​atrix.org> Not necessarily buttons, more like stuff that doesn't bounce that much
<re_irc> <@t​halesfragoso:m​atrix.org> You can have a timer denounce that fires every 20ms or so
<re_irc> <@t​halesfragoso:m​atrix.org> But yeah, not that low power
<re_irc> <@d​irbaio:m​atrix.org> I can't afford that :D
<re_irc> <@t​halesfragoso:m​atrix.org> Again, this is something I heard (that using bounce buttons in exti is a bad idea) but never got a proof
<re_irc> <@d​irbaio:m​atrix.org> O_o
<re_irc> <@t​herealprof:m​atrix.org> Nah, should work just fine hardware wise. If in doubt and you care about debouncing (and your MCU won't give it to you for free) you'd probably debounce with circuitry instead.
<re_irc> <@a​damgreig:m​atrix.org> the stm32 input circuitry should have sufficient protection against metastability iirc, which is more of a worry with slow-changing than bouncing inputs really
<re_irc> <@a​damgreig:m​atrix.org> wouldn't have thought there were particular issues otherwise, you might get a bunch of interrupts if you don't disable the interrupt after the first irq, but it's not like the cortex-m can't handle a bunch of interrupts
<re_irc> <@a​damgreig:m​atrix.org> there might be more specific reasons against doing it though i guess...
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm not sure how you'd so low power without button etc interrupts
<re_irc> <@t​halesfragoso:m​atrix.org> adamgreig iirc I got that opinion from here: http://www.ganssle.com/debouncing.htm
<re_irc> <@l​achlansneff:m​atrix.org> dirbaio does the embassy executor put the mcu in low-power mode when no tasks are running?
<re_irc> <@f​irefrommoonlight:m​atrix.org> And on stm32, you have to immediately clear the interrupt flag or it will keep firing
<re_irc> <@t​halesfragoso:m​atrix.org> It's a good research
<re_irc> <@d​irbaio:m​atrix.org> Lachlan Sneff: yup (uses `WFE`)
<re_irc> <@f​irefrommoonlight:m​atrix.org> And you need either soft or hard denouncing
<re_irc> <@t​halesfragoso:m​atrix.org> firefrommoonlight: Do a quick check at every 10ms or so, after N checks you know the debounced state
<re_irc> <@t​halesfragoso:m​atrix.org> You can even debounce a whole port at the same time that way
<re_irc> <@f​irefrommoonlight:m​atrix.org> How does "don't use buttons in interrupts" follows from the article if you debiunce?
<re_irc> <@f​irefrommoonlight:m​atrix.org> I may have misread i
<re_irc> <@a​damgreig:m​atrix.org> thalesfragoso: it says "Similarly, don't tie undebounced switches, even if Schmitt Triggered, to interrupt inputs on the CPU. Usually the interrupt pin goes to the clock input of an internal flip flop. As processors become more complex their datasheets give less useful electrical information; they're awash in...
<re_irc> ... programming data but leave designers adrift without complete timing specs. Generally we have no idea what the CPU expects as a max rise time or the min pulse width. Those internal flops aren't perfect, so don't flirt with danger by feeding them garbage."
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'd prefer to just use the interrupt, but don't see any obv downsides from that internittent polling approach
<re_irc> <@a​damgreig:m​atrix.org> I think that advice may have made more sense in the past, but these days the GPIO to EXTI connection should not have this sort of problem
<re_irc> <@a​damgreig:m​atrix.org> the input is sampled on the mcu's internal clock, resynchronised, and a change in level will trigger the interrupt
<re_irc> <@a​damgreig:m​atrix.org> also, the stm32 does actually specify a minimum pulse width for detection, typically 10ns
<re_irc> <@t​halesfragoso:m​atrix.org> Good to know
<re_irc> <@f​irefrommoonlight:m​atrix.org> Cool article, btw
<re_irc> <@a​damgreig:m​atrix.org> the stm32 reference manuals generally say something like (e.g. f411): "The data present on the I/O pin are sampled into the input data register every AHB1 clock cycle"
<re_irc> <@f​irefrommoonlight:m​atrix.org> And for anyone not familiar with debouncing: the code I posted above is one approach using a timer with period between max bounce completion and min actuation time, but for other uses, there are better ways
<re_irc> <@f​irefrommoonlight:m​atrix.org> Hardware is fine too, but it's a lot easier and cheaper to modify software than respin a batch of boards
<re_irc> <@a​damgreig:m​atrix.org> adamgreig: (although it looks like actually the EXTI edge detection happens before the input data register gets sampled... the RM I'm looking at doesn't really give any detail of how that works, exactly)
<re_irc> <@a​damgreig:m​atrix.org> anyway I wouldn't be concerned about attaching a non-debounced button to an stm32 exti, and anyway pcb-mount tactile switches tend to be pretty low bounce anyway
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: That depends quite a bit on the manufacturer but nowadays I'd say they're generally very high quality.
<re_irc> <@t​halesfragoso:m​atrix.org> Yeah, I would also think it's fine
<re_irc> <@t​herealprof:m​atrix.org> I had an article which compaired a number of them in terms of construction and bounce behaviour but I can't find it in a pinch.
<re_irc> <@a​damgreig:m​atrix.org> I've got a board with the cheapest JLCPCB tactile switch and I can't make it bounce, lol
<re_irc> <@a​damgreig:m​atrix.org> just hammered it like 50 times and my scope resolutely measures one rising edge and one falling edge
<re_irc> <@a​damgreig:m​atrix.org> ooh... managed to just flick it into two edges
<re_irc> <@a​damgreig:m​atrix.org> anyway, pretty respectable
<re_irc> <@f​irefrommoonlight:m​atrix.org> Oh wow! Surprising
<re_irc> <@a​damgreig:m​atrix.org> even that "bounce" is quite sharp
<re_irc> <@a​damgreig:m​atrix.org> (that's zoomed right in on the bounce from the first image)
<re_irc> <@a​damgreig:m​atrix.org> 199.9µs bounce... 🤔
<re_irc> <@t​herealprof:m​atrix.org> Yeah, there's also the topic of consistency and long term stability (some of them use cheaper materials which can degrade and then not only cause general failure but also start bouncing).
<re_irc> <@a​damgreig:m​atrix.org> yea, for sure, I'm not saying one should not debounce switches in software
<re_irc> <@t​herealprof:m​atrix.org> But as you said, they're in general pretty decent nowadays.
<re_irc> <@a​damgreig:m​atrix.org> you're quite right that they will degrade over time
<re_irc> <@a​damgreig:m​atrix.org> but definitely modern ones are better than switches of yore
<re_irc> <@t​herealprof:m​atrix.org> Yup.
<re_irc> <@a​damgreig:m​atrix.org> modern pcb-mount tactile switches, anyway!
<re_irc> <@a​damgreig:m​atrix.org> if you're playing with big serious switches they can still be pretty bouncy too
rjframe has quit [Quit: Leaving]
fabic has joined #rust-embedded
<re_irc> <@b​urrbull:m​atrix.org> therealprof: Please, look at https://github.com/stm32-rs/stm32f4xx-hal/pull/328. This is another simple PR. Not #327. It just lets you write `Alternate<4>` instead of `Alternate<AF<4>>` or `Alternate<AF4>`
<re_irc> <@l​achlansneff:m​atrix.org> Could AF4 be aliased to Alternate<4>?
<re_irc> <@l​achlansneff:m​atrix.org> So, PB4<AF4>
<re_irc> <@b​urrbull:m​atrix.org> I can add such aliases if you need
<re_irc> <@d​irbaio:m​atrix.org> usually it's confusing if there's two ways of writing the same thing
<re_irc> <@b​urrbull:m​atrix.org> dirbaio: You are right. Such aliase can be added in user code.
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <@r​ukai:m​atrix.org> I'm investigating writing a lint to ensure rust default formatting isnt being called by anything e.g. via format/unwrap/panic
<re_irc> <@r​ukai:m​atrix.org> Does anything like that already exist?
<re_irc> <@k​orken89:m​atrix.org> rukai: Cool! I have not seen something like that.
<re_irc> <@b​urrbull:m​atrix.org> Should we disable peripheral clocking on `release`?
neceve has joined #rust-embedded
<re_irc> <@t​herealprof:m​atrix.org> burrbull: That might be bad. You can't guarantee there's nothing else using the same clock.
<re_irc> <@t​herealprof:m​atrix.org> burrbull: Sorry, was offline for some hours.
<re_irc> <@t​herealprof:m​atrix.org> burrbull: I created https://github.com/stm32-rs/stm32f4xx-hal/pull/329 to add AFx as constants so old code keeps on working without changes. In general I'm very happy with the way you managed to simplify everything but keep the APIs intact. 😍
<re_irc> <@a​damgreig:m​atrix.org> what else could be using the clock if you've just released the driver (that had exclusive access)?
<re_irc> <@t​herealprof:m​atrix.org> Depends on the clocks we're talking about. I can totally see peripheral clock sharing, e.g. for EXTI.
<re_irc> <@a​damgreig:m​atrix.org> hm, yea, I guess it depends - for like spi or uart it seems like they shouldn't be shared, but for a gpio pin that's been split then of course you can't disable the whole port
<re_irc> <@a​damgreig:m​atrix.org> does EXTI even have a clock?
<re_irc> <@t​herealprof:m​atrix.org> Wasn't that a common problem that people forgot to enable it? I should do more dogfooding. 😀
<re_irc> <@b​urrbull:m​atrix.org> https://github.com/stm32-rs/stm32f4xx-hal/pull/330
<re_irc> <@t​herealprof:m​atrix.org> burrbull: There's a ton of stuff going on there. 😅
<re_irc> <@t​herealprof:m​atrix.org> Can I ask you to factor out some stuff into seperate PRs? E.g. the `free`->`release` changes should be in a separate PR, be mentioned in the Changelog and wherever possible the deprecation notes should also provide guidance on what to do/use instead.
fabic has joined #rust-embedded
<re_irc> <@b​urrbull:m​atrix.org> https://github.com/stm32-rs/stm32f4xx-hal/pull/331
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: Are you aware of any way to use the DSP extensions or is rustc even using them automatically?
<re_irc> <@b​urrbull:m​atrix.org> https://github.com/stm32-rs/stm32f4xx-hal/pull/332
<re_irc> <@a​damgreig:m​atrix.org> In principle for the thumbv7em targets it should use them automatically but I'm not sure I've ever seen it doing it; not aware of any way to do it manually beyond writing some asm (but I think I've seen some things using it, maybe the cortex-m optimised encryption stuff?)
<re_irc> <@t​herealprof:m​atrix.org> Yeah, I'm already deep in the rabbit hole chasing where that could potentially make an impact. rustc is only passing down the arch type as is to LLVM, the rest of the spec is the same so rustc is most definitely not making use of it internally.
<re_irc> <@t​herealprof:m​atrix.org> What on earth is `thumbv7em-none-windows-eabi`?
<re_irc> <@a​damgreig:m​atrix.org> Lol what
<re_irc> <@a​damgreig:m​atrix.org> No idea
<re_irc> <@t​herealprof:m​atrix.org> Microsoft seems very keen on thumb2 support...
<re_irc> <@b​urrbull:m​atrix.org> https://github.com/stm32-rs/stm32f4xx-hal/pull/333
neceve has quit [Ping timeout: 240 seconds]
<re_irc> <@b​urrbull:m​atrix.org> https://github.com/stm32-rs/stm32f4xx-hal/pull/330 Rebased
<re_irc> <@a​damgreig:m​atrix.org> therealprof: ok, it definitely can use the -E extensions sometimes automatically, example: https://rust.godbolt.org/z/WbT349Grx vs https://rust.godbolt.org/z/xW9d11MEj
<re_irc> <@a​damgreig:m​atrix.org> but I don't know how keen it is to use the vector instructions
starblue has joined #rust-embedded
<re_irc> <@t​herealprof:m​atrix.org> It seems to me that's all left up to LLVM at the moment. They do have some very limited passes trying to use those instructions if they see fit; I don't see any code paths in rust/libcore specifically catered to them.
<re_irc> <@a​damgreig:m​atrix.org> yea, that's more or less what I'd expect though, llvm should take care of that sort of thing
<re_irc> <@t​herealprof:m​atrix.org> Do you know of any cookbook for DSP extension use showing some examples where they come in handy to allow some quick checks on whether LLVM knows those tricks already?
<re_irc> <@a​damgreig:m​atrix.org> can't think of anything like that
<re_irc> <@t​herealprof:m​atrix.org> Unfortunately entering those keywords in a searchengine hits all the right spots to find 1000s of shady ebook providers.
<re_irc> <@a​damgreig:m​atrix.org> nice, saturating_add() compiles to QADD on -E
<re_irc> <@a​damgreig:m​atrix.org> https://rust.godbolt.org/z/Y8rnecd5c change target to -e to see the difference
<re_irc> <@a​damgreig:m​atrix.org> it seems like all the non-vector instructions just work, but I remember struggling to get the vector ones to work
<re_irc> <@a​damgreig:m​atrix.org> ooh, I have got it to invoke qadd16 actually, but it doesn't seem quite perfect
<re_irc> <@a​damgreig:m​atrix.org> this is so close... but it does two qadds x_x https://rust.godbolt.org/z/EoTj3516K
fabic has quit [Ping timeout: 268 seconds]
<re_irc> <@t​herealprof:m​atrix.org> lol, I'm trying something similar but also failing.
<re_irc> <@t​herealprof:m​atrix.org> https://rust.godbolt.org/z/Mbchn5Y51
<re_irc> <@a​damgreig:m​atrix.org> I would have hoped giving it already-packed inputs would help but seemingly not
<re_irc> <@a​damgreig:m​atrix.org> I think there's a difference with how the sign extension works that means the source code isn't quite the same as a single sadd16
<re_irc> <@a​damgreig:m​atrix.org> the unsigned ones might be easier to try out
<re_irc> <@a​damgreig:m​atrix.org> but not having much luck with uadd8 either lol
<re_irc> <@t​herealprof:m​atrix.org> I unsigned first but since the instructions are very specific I thought catering for the exact usecase might make it easier.
<re_irc> <@t​herealprof:m​atrix.org> Funny enough, if I add an explicit alignment to the struct the generated code gets far worse. 😀
<re_irc> <@t​herealprof:m​atrix.org> Sure enough, also using `u16` with saturating add makes things far worse.
<re_irc> <@t​herealprof:m​atrix.org> Argh, nonsense, I was reading that wrong. The one I posted above is actually optimal, having 2 additions is of course expected...
<re_irc> <@a​damgreig:m​atrix.org> is it?
<re_irc> <@a​damgreig:m​atrix.org> qadd16 should do two additions in one instruction
<re_irc> <@a​damgreig:m​atrix.org> i.e. it adds {a, b} and {u, v} to get {x, y} in a single instruction, where all are i16 and x=a+u and y=b+v
<re_irc> <@a​damgreig:m​atrix.org> (if i'm understanding it right..)
<re_irc> <@a​damgreig:m​atrix.org> in your example, `a.x`, `a.y`, `b.x`, and `b.y` are being passed in as four 32-bit registers to the function
<re_irc> <@a​damgreig:m​atrix.org> so what it does is optimal for that - because they're not already packed, and this is more efficient than packing them, adding, then unpacking
<re_irc> <@t​herealprof:m​atrix.org> True but isn't that an ABI issue? Need to write a different test. ;)
<re_irc> <@a​damgreig:m​atrix.org> yes, the ABI won't let you have them packed, I think your test needs to pass in an already-packed i32 (or u32...)
<re_irc> <@a​damgreig:m​atrix.org> or have a long enough body that it becomes worthwhile to pack them, do vector ops, and unpack at the end
<re_irc> <@t​herealprof:m​atrix.org> Well, putting `#[attr(packed)]` on the struct certainly did pessimize this quite a bit.
fabic has joined #rust-embedded
<re_irc> <@a​damgreig:m​atrix.org> what about them? looks like they're all there
<re_irc> <@t​herealprof:m​atrix.org> Oh and the "b" stands for bottom lane which (if my interpretation is correct) means that it only deals with 1 of the values (which would explain what we're seeing).
<re_irc> <@t​herealprof:m​atrix.org> The instructions are all there, but only the ones with a `Thumb2DSPPat` are lowered to actual instructions.
<re_irc> <@t​herealprof:m​atrix.org> e.g. there's no UQADD16 lowering which is why we only see this working for signed integers.
<re_irc> <@a​damgreig:m​atrix.org> huh, I wonder why they don't have the unsigned ones
<re_irc> <@a​damgreig:m​atrix.org> also no e.g. sadd16
<re_irc> <@t​herealprof:m​atrix.org> No idea. And even that was added not too long ago: https://reviews.llvm.org/D68974
<re_irc> <@a​damgreig:m​atrix.org> ah, I guess it's not as simple as just adding that extra Thumb2DSPPat to the file, it also needs all the code to actually do the right lowering
<re_irc> <@a​damgreig:m​atrix.org> so maybe one day someone will add that to llvm
<re_irc> <@a​damgreig:m​atrix.org> guess we could put them in cortex_m::asm in the interim, hm
<re_irc> <@a​damgreig:m​atrix.org> the not-inlining might make it kinda annoying though
<re_irc> <@a​damgreig:m​atrix.org> stable asm when...
<re_irc> <@a​damgreig:m​atrix.org> oh...oh!!! brb
<re_irc> <@a​damgreig:m​atrix.org> haha disasm I see you beat me to the PR, even though my commit was before yours
<re_irc> <@d​isasm-ewg:m​atrix.org> Mine was merged in 2 minutes!
<re_irc> <@d​isasm-ewg:m​atrix.org> I also checked inline asm and GAT
<re_irc> <@a​damgreig:m​atrix.org> it's not enough for embassy though, it doesn't work fully with some const fn features
<re_irc> <@a​damgreig:m​atrix.org> I wasn't sure whether to PR it, do I really want my name on that crate :P
<re_irc> <@l​achlansneff:m​atrix.org> Enabling gats in stable with nightly-crimes when :P
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: If there wasn't such a huge overhead contributing to LLVM I'd do that right now. Maybe we can nerdsnipe someone with frequent contributions to LLVM to do that. 😉
<re_irc> <@d​isasm-ewg:m​atrix.org> Maybe it's time to make a crate that contains all the useful assembly compiled with a nightly compier, with workarounds for different Rust versions and so on
<re_irc> <@a​damgreig:m​atrix.org> Lachlan Sneff: that works fine
<re_irc> <@l​achlansneff:m​atrix.org> Guess we don’t need to wait for gats to be stabilized then for that async embedded-hal PR :P
<re_irc> <@a​damgreig:m​atrix.org> 💀
<re_irc> <@d​isasm-ewg:m​atrix.org> We need another crate that allows us to imagine that embedded-hal 1.0 is published and stable
<re_irc> <@l​achlansneff:m​atrix.org> It's a good thing module macros don't exist yet, cause someone would make an attribute that you add to your crate that lets the whole thing use nightly features on stable.
<re_irc> <@d​isasm-ewg:m​atrix.org> > yet
neceve has joined #rust-embedded
<re_irc> <@l​achlansneff:m​atrix.org> I wish that methods could borrow only certain fields from structs :/
fabic has quit [Ping timeout: 268 seconds]
<re_irc> <@j​amesmunns:m​atrix.org> Lachlan Sneff: You can do destructuring to do this within a single scope.
<re_irc> <@j​amesmunns:m​atrix.org> Lemme find an example I wrote during a training
<re_irc> <@l​achlansneff:m​atrix.org> Yep. I have some sort of weird guard pattern though unfortunately
<re_irc> <@a​damgreig:m​atrix.org> ok folks, you hate to see it, https://crates.io/crates/cortex-m-asm
<re_irc> <@a​damgreig:m​atrix.org> inline asm on stable for cortex-m 💀
<re_irc> <@a​damgreig:m​atrix.org> without plugin-linker-lto at that
<re_irc> <@l​achlansneff:m​atrix.org> I feel like that's bad
<re_irc> <@a​damgreig:m​atrix.org> yea
<re_irc> <@j​amesmunns:m​atrix.org> ```rust
<re_irc> <@j​amesmunns:m​atrix.org> pub struct Trigger {
<re_irc> <@j​amesmunns:m​atrix.org> #[derive(Debug, Eq, PartialEq, Hash)]
<re_irc> <@j​amesmunns:m​atrix.org> id: u64,
<re_irc> <@j​amesmunns:m​atrix.org> (you're missing some of the context, but destructuring can help with the "borrow the same struct twice" problem, but yeah, if you have odd guards or something, it might not cover you)
<re_irc> <@a​damgreig:m​atrix.org> this should sure make it easier to support the packed DSP instructions though
<re_irc> <@l​achlansneff:m​atrix.org> In the end I just did this:
<re_irc> <@l​achlansneff:m​atrix.org> ```rust
<re_irc> <@l​achlansneff:m​atrix.org> fn guard(&mut self) -> (SpiGuard<SPI, CS>, Rest<READY, RESET, GPIO0, TIMER>) {
<re_irc> <@l​achlansneff:m​atrix.org> (
<re_irc> <@j​amesmunns:m​atrix.org> https://crates.io/crates/cortex-m-asm/0.1.0/dependencies
<re_irc> <@a​damgreig:m​atrix.org> I prefer to look at https://crates.io/crates/nightly-crimes/reverse_dependencies
<re_irc> <@j​amesmunns:m​atrix.org> ಠ_ಠ
<re_irc> <@t​herealprof:m​atrix.org> I love the innocent "Please do not use this." remark.
<re_irc> <@j​amesmunns:m​atrix.org> "please. no. stop. don't"
<re_irc> <@a​damgreig:m​atrix.org> anyway when `feature(asm)` stabilises I simply delete nightly_crimes and publish 0.1.1
<re_irc> <@a​damgreig:m​atrix.org> I do sorta wonder if rustc can do something to stop this, it seems, you know, bad
<re_irc> <@a​damgreig:m​atrix.org> less work than the current cortex-m outlined inlined asm built to a prebuild binary file that we plug into linker-plugin-lto, though!
<re_irc> <@j​amesmunns:m​atrix.org> I mean
<re_irc> <@j​amesmunns:m​atrix.org> if rustc doesn't stop it
<re_irc> <@j​amesmunns:m​atrix.org> we'll either do it in ferrocene, or make it review item.
<re_irc> <@j​amesmunns:m​atrix.org> but I would guess this is going to cause like... twelve PITA threads in the reddit, until someone harasses the libs team about it, and it will lead to a fix that someone eventually finds a workaround for
<re_irc> <@j​amesmunns:m​atrix.org> like, wearing a manager hat, this is just a social headache.
<re_irc> <@j​amesmunns:m​atrix.org> and if it gets adopted, it will get pointed at by people outside the rust project who don't know wtf they are talking about, the same as RUSTC_BOOTSTRAP
<re_irc> <@j​amesmunns:m​atrix.org> technically, it's whatever.
<re_irc> <@l​achlansneff:m​atrix.org> Yeah, in the end, it just hurts people's views of rust
<re_irc> <@j​amesmunns:m​atrix.org> (Mara is very smart, I would be more upset if she wasn't already on the libs team)
<re_irc> <@j​amesmunns:m​atrix.org> she's probably just making headaches for herself, or other teams around her lol
<re_irc> <@j​amesmunns:m​atrix.org> I guess better the rust project is trolling itself, rather than someone outside
<re_irc> <@a​damgreig:m​atrix.org> it _is_ the same as RUSTC_BOOTSTRAP, right?
<re_irc> <@j​amesmunns:m​atrix.org> with more steps, and a bit harder to detect, yeah.
<re_irc> <@j​amesmunns:m​atrix.org> (if someone just copy/pastes the code, instead of depending directly)
<re_irc> <@a​damgreig:m​atrix.org> indeed
<re_irc> <@j​amesmunns:m​atrix.org> I guess by making it an easily named crate, it's actually harm reduction
<re_irc> <@j​amesmunns:m​atrix.org> it'll probably get a finger wag from the cargo-geiger/rustsec crowd.
<re_irc> <@a​damgreig:m​atrix.org> the other trolling crates are very neat though, the edition macros and the python inline stuff
<re_irc> <@a​damgreig:m​atrix.org> this does seem a bit more "stability guarantees? what are they"
<re_irc> <@j​amesmunns:m​atrix.org> Last time it was quiet for a while until it became high profile when the firefox teams was publishing crates that set rustc_bootstrap in the build.rs
<re_irc> <@j​amesmunns:m​atrix.org> then eventually that got denied
<re_irc> <@j​amesmunns:m​atrix.org> as long as rustc uses in-band-signalling, it'll always be a cat and mouse game.
<re_irc> <@l​achlansneff:m​atrix.org> Could the bootstrap var ever get removed somehow?
<re_irc> <@j​amesmunns:m​atrix.org> could
<re_irc> <@j​amesmunns:m​atrix.org> you'd need to build a version of the compiler that allowed it, build libstd, then build a version of the compiler that DOESN'T allow it, and publish THAT as the release bin
<re_irc> <@j​amesmunns:m​atrix.org> but then you have a problem that your compiler to build the stdlib isn't the EXACT SAME as the one you released.
<re_irc> <@a​damgreig:m​atrix.org> even then, the macros make it very tricky
<re_irc> <@a​damgreig:m​atrix.org> the stdlib macros generate code that uses features
<re_irc> <@j​amesmunns:m​atrix.org> which may or may not be a problem, depending on your threat model.
<re_irc> <@j​amesmunns:m​atrix.org> adamgreig: Ah yeah, I forgot about that. The change would have to be more extensive.
<re_irc> <@a​damgreig:m​atrix.org> I guess that's OK though, if your stable compiler doesn't permit allow_internal_unstable it's OK
<re_irc> <@j​amesmunns:m​atrix.org> yeah
<re_irc> <@l​achlansneff:m​atrix.org> Could be a static boolean that could get written into the binary before release?
<re_irc> <@a​damgreig:m​atrix.org> you need to be able to run #![feature(allow_internal_unstable)] to get to use it, and you couldn't do that without RUSTC_BOOTSTRAP
<re_irc> <@l​achlansneff:m​atrix.org> Ah, huh
<re_irc> <@j​amesmunns:m​atrix.org> basically, it would add a total recompile to the entire release process
<re_irc> <@j​amesmunns:m​atrix.org> which is like... 30-60m every 6 weeks, but also a pain in the ass to maintain.
<re_irc> <@j​amesmunns:m​atrix.org> (you'd add a stage-4 compile step, that totally blew a "no unstable features" fuse)
<re_irc> <@j​amesmunns:m​atrix.org> I mean, you do what you want adamgreig, and even if you yank the crate, someone else will depend on it to, but people will probably now point "oh, the embedded-wg is using this hack, we can too".
<re_irc> <@j​amesmunns:m​atrix.org> https://twitter.com/SimonSapin/status/1411713930406379525
<re_irc> <@j​amesmunns:m​atrix.org> Please don't move that to the `rust-embedded` space.
<re_irc> <@j​amesmunns:m​atrix.org> at least.
<re_irc> <@a​damgreig:m​atrix.org> hah yea, my twitter notifications are kicking off for sure
<re_irc> <@a​damgreig:m​atrix.org> I think I might rework it a little bit to make nightly-crimes an optional dependency, with the default configuration requiring nightly
<re_irc> <@a​damgreig:m​atrix.org> certainly wouldn't put it inside rust-embedded 💀
<re_irc> <@t​herealprof:m​atrix.org> jamesmunns: Not going to happen for sure. Officially we can't touch that even with a 10ft pole.
<Lumpio-> Excuse me but what
<re_irc> <@t​herealprof:m​atrix.org> Lumpio-: FNORD!
<Lumpio-> This code is an abomination
<Lumpio-> I love it
<re_irc> <@d​isasm-ewg:m​atrix.org> Close relative of eager-const :D
<Lumpio-> I think eager-const actually stopped working on the current rustc :(
<Lumpio-> Such a shame
<re_irc> <@d​isasm-ewg:m​atrix.org> I hope this will not eventually lead to a situation when proc-macros will only be allowed on nightly
<re_irc> <@a​damgreig:m​atrix.org> possibly a situation where proc-macros are sandboxed rather than getting to just run arbitrary code inside rustc
<re_irc> <@f​irefrommoonlight:m​atrix.org> Pls don't take away my cfg-if and paste. I wil
<re_irc> <@l​achlansneff:m​atrix.org> adamgreig: It would be backwards incompatible to force all macros to be compiled to wasm
<Lumpio-> This is why there's editions
<Lumpio-> Letting proc macros access files and such is nice though.
<Lumpio-> I mean build.rs can, and a lot of the time, has to, too.
<re_irc> <@j​amesmunns:m​atrix.org> (we're past the '21 edition threshold, so that would be moving forward to '24 and beyond)
<re_irc> <@j​amesmunns:m​atrix.org> (AFAIK)
<re_irc> <@l​achlansneff:m​atrix.org> Lumpio-: They could use wasi, so file access would be sandboxed
<re_irc> <@m​-ou-se:m​atrix.org> this problem isn't specific to proc macros. same thing can be done with build.rs. and it's very normal for pretty much any build system in any language to execute arbitrary commands. tons of crates invoke some C compiler or Make or CMake or whatever.
<Lumpio-> I get that it's a small security issue that things can execute code and access arbitrary OS stuff at compile time
<Lumpio-> But then again they'll be able to do that once you run the executable anyways. If you're *only* building, just sandbox the entire build process.
<re_irc> <@a​damgreig:m​atrix.org> well, I've made the cursed crate in question slightly less radioactive
<re_irc> <@a​damgreig:m​atrix.org> you at least have to opt-in to do crimes now
<re_irc> <@m​-ou-se:m​atrix.org> yay
<re_irc> <@a​damgreig:m​atrix.org> sorry Mara, I love your work, I don't mean to bring it into disrepute!
<re_irc> <@j​amesmunns:m​atrix.org> (same here!)
<re_irc> <@a​damgreig:m​atrix.org> but, also, extremely useful crimes
<re_irc> <@m​-ou-se:m​atrix.org> haha
<re_irc> <@j​amesmunns:m​atrix.org> I mean, if it's possible, someone would have figured it out eventually :D
<re_irc> <@j​amesmunns:m​atrix.org> I'm glad it was you, and not someone who silently smuggled it inside of a popular crate everyone uses :p
fabic has joined #rust-embedded
<re_irc> <@m​-ou-se:m​atrix.org> this one at least has a very scary name and spits out a whole bunch of scary messages to make it obvious something bad is happening. that 0.1.0 version of that cortex-m-asm crate would've been a whole lot worse if it silently did this.
<re_irc> <@m​-ou-se:m​atrix.org> this is just a "yes, we know it is possible. no, you shouldn't do this" message in crate form.
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <@j​amesmunns:m​atrix.org> Changing topics, I wonder if this would be useful for embedded too? https://github.com/Rust-for-Linux/linux/pull/402
<re_irc> <@a​damgreig:m​atrix.org> as in, also setting RUSTC_BOOTSTRAP to build our own `alloc` lib? :P
<re_irc> <@d​irbaio:m​atrix.org> forking alloc, lol
<cr1901> The proc macro thing reminds me of this fun: https://github.com/rust-lang/rust/issues/28179#issuecomment-361320369
<re_irc> <@l​achlansneff:m​atrix.org> It works! I got the driver to communicate over spi with the wifi peripheral!
<re_irc> <@j​amesmunns:m​atrix.org> cr1901: cr1901: I sort of disagree
<re_irc> <@j​amesmunns:m​atrix.org> (I see your point, though)
<re_irc> <@j​amesmunns:m​atrix.org> but IMO, anything "past" the complier, e.g. OS or linker, I see as being outside that purview
<re_irc> <@j​amesmunns:m​atrix.org> I guess " call the compiler twice to make two programs" does sort of still fall outside of "what the compiler can check"
<re_irc> <@a​damgreig:m​atrix.org> yea, same deal as `link_section` readily leading to surprises
<re_irc> <@j​amesmunns:m​atrix.org> So maybe I take that back and agree with you again.
<re_irc> <@d​irbaio:m​atrix.org> the no_mangle thing is "unsafe", not "unstable" (?)
<re_irc> <@a​damgreig:m​atrix.org> whereas `asm!()` is both unsafe _and_ unstable, heh
<re_irc> <@j​amesmunns:m​atrix.org> Allows segfault, but not "unstable": https://twitter.com/bitshiftmask/status/1324171751094390785
<cr1901> jamesmunns: I'm a bit grumpy about the linked issue (what else is new?), but having trouble putting it into words
<re_irc> <@j​amesmunns:m​atrix.org> I dunno
<re_irc> <@j​amesmunns:m​atrix.org> I guess my opinion on that is "it's a linker thing, and safety is a compiler thing. they're really unrelated, even though we want them not to be"
<re_irc> <@j​amesmunns:m​atrix.org> until rustc writes it's own linker that can ALSO uphold safety guarantees
<re_irc> <@a​damgreig:m​atrix.org> I've cleaned up the scene of the crime at https://crates.io/crates/nightly-crimes/reverse_dependencies btw
<re_irc> <@j​amesmunns:m​atrix.org> until then, code is only safe to the object code level.
<cr1901> I think I would like to avoid the temptation of making every possible unsound thing you can do under unsafe, and make some of them that are outright just a bad idea UB
<re_irc> <@j​amesmunns:m​atrix.org> Yeah, IMO those linker args should either: ALL be unsafe, or NONE of them be unsafe.
<re_irc> <@j​amesmunns:m​atrix.org> tossup which one is "more correct"
<re_irc> <@a​damgreig:m​atrix.org> in principle you're not meant to be able to do UB without unsafe, though
<cr1901> To avoid constraining what safe Rust can do to "you can read and write memory locations, but you can't actually do anything with the results to present them to the user"
<re_irc> <@j​amesmunns:m​atrix.org> but if FFI is all unsafe, then IMO all linker interactions are too.
<cr1901> (which, tbf, is the current situation)
<re_irc> <@a​damgreig:m​atrix.org> it's the current situation, but in practice people write convenient safe wrappers that generally work well
<re_irc> <@j​amesmunns:m​atrix.org> Yeah
<re_irc> <@a​damgreig:m​atrix.org> wonder if you could write a safe wrapper for those sorts of things though
<re_irc> <@j​amesmunns:m​atrix.org> All the interactions with libc are unsafe
<re_irc> <@j​amesmunns:m​atrix.org> we just write safe wrappers for those
<re_irc> <@a​damgreig:m​atrix.org> perhaps c-m-rt could provide safe macros that check and add the unsafe linker attributes
<re_irc> <@j​amesmunns:m​atrix.org> BUT if they break their promises (or we misunderstood them), UB can still sneak back in.
<re_irc> <@a​damgreig:m​atrix.org> seems hard to get right, but at least in principle the option's there
<re_irc> <@j​amesmunns:m​atrix.org> adamgreig: (I would also see this as an acceptable outcome, the same as the libc/libstd crates)
<re_irc> <@j​amesmunns:m​atrix.org> "this is not a compiler's place for deciding, but libraries may take it upon themselves to provide safety guarantees"
<re_irc> <@j​amesmunns:m​atrix.org> (see my notes above, it agrees with that position)
<cr1901> A program that only reads and writes memory is boring. Thus safe Rust is boring :P.
<re_irc> <@a​damgreig:m​atrix.org> if anything it would be nicer if you could write something like `#[cortex_m_rt::in_rw_section("ram3")]` or something
<cr1901> And well, if you don't have volatile access, you can just optimize out the whole program ;)
<re_irc> <@a​damgreig:m​atrix.org> but with the default c-m-rt linker script I'm not sure what you'd need anyway, it's really only useful when you add custom user sections
<re_irc> <@a​damgreig:m​atrix.org> back to needing c-m-rt to have some API for adding them, perhaps in build.rs, that then generates the whole linker script for you, and I guess could configure those safe macros
<re_irc> <@a​damgreig:m​atrix.org> heck, at that point you can probably integrate it with probe-rs' targets database to know the memory map from the chip name
<re_irc> <@j​amesmunns:m​atrix.org> anyway, I'm out of "controversy juice" today. I'll have to leave this argument to others. I do explain my position in my notes though.
<re_irc> <@j​amesmunns:m​atrix.org> Feel free to leave a comment on the tracking issue (https://github.com/jamesmunns/lab-notebook/issues/3) if you disagree with any of my notes.
<re_irc> <@j​amesmunns:m​atrix.org> Also, summarized here: https://github.com/rust-lang/lang-team/issues/87#issuecomment-806527704
<cr1901> jamesmunns: Anyways, my visceral reaction is "I don't want linker attributes marked as unsafe and explicitly say tricks like that are UB, not welcome, don't do that, etc"
<re_irc> <@j​amesmunns:m​atrix.org> IMO, `unsafe` != `bad`.
<re_irc> <@j​amesmunns:m​atrix.org> it just means "you're leaving the realm where the compiler will 100% have your back".
<cr1901> No, but tell that to 90% of programmers
<re_irc> <@j​amesmunns:m​atrix.org> I do. Sometimes they pay me for it.
<cr1901> You mark it special, it will be treated as special
<re_irc> <@j​amesmunns:m​atrix.org> it *IS* special.
<re_irc> <@j​amesmunns:m​atrix.org> we shouldn't lie about that.
<re_irc> <@j​amesmunns:m​atrix.org> but it still doesn't mean "bad".
<re_irc> <@j​amesmunns:m​atrix.org> just unsafe.
<re_irc> <@j​amesmunns:m​atrix.org> (potentially)
<re_irc> <@j​amesmunns:m​atrix.org> ideally, all `unsafe` code is safe, actually.
<cr1901> That's a marketing problem then... unsafe IS seen as bad
<re_irc> <@j​amesmunns:m​atrix.org> It's just not checkable by the compiler.
<re_irc> <@j​amesmunns:m​atrix.org> `#define unsafe manual_safety_mode`
<re_irc> <@d​irbaio:m​atrix.org> my response to that is "you were writing C before, which was ALL unsafe." :D
<re_irc> <@j​amesmunns:m​atrix.org> I explain this in my trainings as "harm reduction"
<re_irc> <@j​amesmunns:m​atrix.org> "you know EXACTLY where to look when things start acting strange"
<re_irc> <@d​irbaio:m​atrix.org> "so be glad that now only 1% of your code is unsafe"
<re_irc> <@d​irbaio:m​atrix.org> exactly :D :D
<cr1901> dirbaio: Most ppl who embraced Rust don't like C, news at 11
<re_irc> <@d​irbaio:m​atrix.org> hahaha
<re_irc> <@j​amesmunns:m​atrix.org> I don't dislike C. I just think it is unreasonably hard to use correctly.
<re_irc> <@j​amesmunns:m​atrix.org> sometimes you still need it. most of the time you don't.
<re_irc> <@y​atekii:m​atrix.org> adamgreig: maybe we should really start a curated DB with all ARM target properties somewhere
<re_irc> <@y​atekii:m​atrix.org> sounds hard and tricky tho :D
<re_irc> <@a​damgreig:m​atrix.org> I mean, the current target yaml files are pretty much there!
<re_irc> <@a​damgreig:m​atrix.org> all cortex-m-rt would need is the start address and length of the flash and main ram
<re_irc> <@y​atekii:m​atrix.org> What I really want is more validation with probe-rs. so if you try to flash a thumb v6 binary to a thumbv7 it will cry for example
<re_irc> <@a​damgreig:m​atrix.org> well, having all the ram sections would be cool
<re_irc> <@a​damgreig:m​atrix.org> other way around? flashing v6 to a v7 is fine
<re_irc> <@y​atekii:m​atrix.org> or if it finds symbols about an nRF HAL and you try to flash to an STM32 it will warn you, etc
<cr1901> jamesmunns: Yea, I have... long form thoughts on this (C vs Rust), but none of them are particularly positive/kind. Maybe one day we can chat about it privately :D
<re_irc> <@y​atekii:m​atrix.org> adamgreig: yeah, sorry, was a poorly made up example
<re_irc> <@a​damgreig:m​atrix.org> but yea in general i get you, lots you could check
<cr1901> "Rust is the C replacement we deserve. It's not the C replacement I wanted."
<re_irc> <@a​damgreig:m​atrix.org> maybe 'cargo embed' could configure --target, since it knows the chip
<re_irc> <@y​atekii:m​atrix.org> adamgreig: fair =)
<re_irc> <@j​amesmunns:m​atrix.org> Yeah, sounds about right for you cr1901
<re_irc> <@y​atekii:m​atrix.org> adamgreig: yeah I mean that'd work =)
<re_irc> <@t​halesfragoso:m​atrix.org> I wanted Rust so bad...
<re_irc> <@a​damgreig:m​atrix.org> I guess you can still honour --target on the command line to override in case someone really wants a different one
<re_irc> <@d​irbaio:m​atrix.org> which of the zillion RAMs would the autolinkerscript it pick for the H7? 🤣
<re_irc> <@d​irbaio:m​atrix.org> also it wouldn't play nice with bootloaders and stuff
<re_irc> <@j​amesmunns:m​atrix.org> "perfect is the enemy of pretty good"
<re_irc> <@y​atekii:m​atrix.org> adamgreig: fair point :) I never thought of that lol ... should make my PR to fix architectures then I guess
<re_irc> <@y​atekii:m​atrix.org> but first I want sequences fixed
<re_irc> <@a​damgreig:m​atrix.org> yes sequences ❤️
<re_irc> <@j​amesmunns:m​atrix.org> slash: make sure there is just some way to override the default
<re_irc> <@y​atekii:m​atrix.org> rebase took me 1 day ...
<re_irc> <@j​amesmunns:m​atrix.org> yatekii: I am a pleb, and I pretty much exclusively squash merge using beyondcompare
<re_irc> <@a​damgreig:m​atrix.org> dirbaio: ideally it would put all of them into the linker script and one (the first?) would be the default "RAM", I guess? not like you couldn't customise further if needed
<re_irc> <@y​atekii:m​atrix.org> our internals are kinda messy ... we need to clean up ... or I do :D
<re_irc> <@a​damgreig:m​atrix.org> but anyway having it be a function call in build.rs instead of a memory.x snippet of linker script sounds like a nicer UI for 90% of use cases
<re_irc> <@y​atekii:m​atrix.org> jamesmunns: hah! I tried rebasing then was like "wat is dis, lets merge" and then tiwalun scolded me and I rebased :D
<re_irc> <@a​damgreig:m​atrix.org> or, well, hopefully; perhaps as with many embedded things everyone needs a different 10%
<re_irc> <@d​irbaio:m​atrix.org> would the HAL do the generating?
<re_irc> <@a​damgreig:m​atrix.org> it could!
<re_irc> <@a​damgreig:m​atrix.org> same as they can provide memory.x now
<re_irc> <@y​atekii:m​atrix.org> and I mean it's fair because we have SO MUCH going on atm, we can't keep track if we just do wololo :D
<re_irc> <@d​irbaio:m​atrix.org> this means the HAL would need a Cargo fetaure for each ram/flash size chip variant
<re_irc> <@d​irbaio:m​atrix.org> which is a looooooot of features
<re_irc> <@d​irbaio:m​atrix.org> 1200 chips
<re_irc> <@a​damgreig:m​atrix.org> some already do, but if not, it can still just go in the user's build.rs
<re_irc> <@d​irbaio:m​atrix.org> we did discuss autogenerating memory.x for stm32-metapac
<re_irc> <@a​damgreig:m​atrix.org> I mean, it has to come from somewhere
<cr1901> jamesmunns: Just to wrap up: the desire to further restrict safe Rust, to say "no you shouldn't be doing X"- such as marking linker attrs unsafe because you can use them _intentionally_ in a way that's unsound- is one of those things in Rust I didn't want.
<re_irc> <@a​damgreig:m​atrix.org> HAL could provide the smallest RAM+FLASH sizes for the device, and the user can make their own build.rs that sets their own values, or whatever
<cr1901> Security ruins a lot of the joy in computing for me :P
<re_irc> <@d​irbaio:m​atrix.org> stm32-metapac has feature for each flash/ram size variant
<re_irc> <@d​irbaio:m​atrix.org> but in the end we're probably going to removethem
<re_irc> <@d​irbaio:m​atrix.org> because it's way too many, generating the docs is unmanageable
<re_irc> <@a​damgreig:m​atrix.org> my point is just that it would be nicer for most users if cortex-m-rt replaces user-provided memory.x with a user-called or HAL-called or PAC-called function inside a build.rs, that can then intelligently check and put together a link script that could also work with some more macros
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea - Maybe there's. A way to get the MCU to report flash and mem
<re_irc> <@a​damgreig:m​atrix.org> the linker script syntax is not exactly user friendly
<re_irc> <@t​halesfragoso:m​atrix.org> adamgreig: AXI SRAM would make more sense for the H7 maybe, but hard to choose tbh
<re_irc> <@d​irbaio:m​atrix.org> and in the end autogenertaing memory.x won't be that useful if it's likely the user will have to customize it anywya
<re_irc> <@a​damgreig:m​atrix.org> (and of course, it's still simple for a user to just provide their own complete linker script instead; hopefully soon we can have it specified without the .cargo/config adding RUSTFLAGS too)
<re_irc> <@y​atekii:m​atrix.org> adamgreig: wadaya mean, it's very intuitive!
<re_irc> <@d​irbaio:m​atrix.org> and standing up an entire macro/dsl system for customizing everything from build.rs seems like overengineering to me
<re_irc> <@f​irefrommoonlight:m​atrix.org> Not feasible to specify variant to map to sizes - then you may as well let user input sizes, as in memory.x
<re_irc> <@d​irbaio:m​atrix.org> linker script syntax sucks? sure
<re_irc> <@d​irbaio:m​atrix.org> but having to learn a custom syntax sucks more imo
<re_irc> <@a​damgreig:m​atrix.org> thalesfragoso: or the DTCM? h7xx-hal uses that as default RAM, probe-rs could use it for flashing too, just can't be accessed by the m4 core
<re_irc> <@t​halesfragoso:m​atrix.org> DTCM is really hard to DMA from/to
<re_irc> <@t​halesfragoso:m​atrix.org> only MDMA reaches it, I never used it though
<re_irc> <@t​halesfragoso:m​atrix.org> but DTCM is nice for stack, that's why I said it's hard to choose ~_~
<re_irc> <@a​damgreig:m​atrix.org> ideally it would be easy to place some buffers into the other SRAMs for DMA use
<re_irc> <@a​damgreig:m​atrix.org> nice to have them separate from the stack RAM anyway to avoid contention
<re_irc> <@a​damgreig:m​atrix.org> dirbaio: there's so many things we can only do if cortex-m-rt knows about the custom sections and everything, like making r0 do the right thing initialising/zeroing them
<re_irc> <@t​halesfragoso:m​atrix.org> adamgreig: question time, does that only works with statics ?
<re_irc> <@a​damgreig:m​atrix.org> thalesfragoso: yes, by definition, right? if not static it will be on the stack, which is then no use for DMA
<re_irc> <@t​halesfragoso:m​atrix.org> :/ statics are hard to use, unsafe stuff
<re_irc> <@a​damgreig:m​atrix.org> well, excluding some kind of alloc
<re_irc> <@t​halesfragoso:m​atrix.org> and it's so easy to use stack allocated buffers with async
<re_irc> <@a​damgreig:m​atrix.org> where you put the alloc pool is another choice though :P
<re_irc> <@a​damgreig:m​atrix.org> sure, but then you're throwing away performance by having all the stack live on the same sram block that dma is using, and not using a huge chunk of your available RAM for anything
<re_irc> <@a​damgreig:m​atrix.org> sometimes that's fine of course
<re_irc> <@a​damgreig:m​atrix.org> but I think we'd want to at least support putting buffers on other rams than the stack
<re_irc> <@t​halesfragoso:m​atrix.org> wouldn't you say that it's the easy route at least 60% of the time ?
<re_irc> <@d​irbaio:m​atrix.org> yeah with embassy's "you may not leak futures" policy, you often stack-allocate buffers
<re_irc> <@d​irbaio:m​atrix.org> though these buffers often go into the future, not in the "real" stack
<re_irc> <@a​damgreig:m​atrix.org> but the future is then also stack allocated, right?
<re_irc> <@t​halesfragoso:m​atrix.org> I would expect a lot of users to come asking why their DMA doesn't work
<re_irc> <@a​damgreig:m​atrix.org> it's definitely easy, yes, but at the cost of not using the DTCM and having more DMA:CPU contention
<re_irc> <@d​irbaio:m​atrix.org> the executor puts futures in `static`s
<re_irc> <@a​damgreig:m​atrix.org> ah, ok, so the future (and the buffer) could live in another sram?
<re_irc> <@d​irbaio:m​atrix.org> yeah
<re_irc> <@t​halesfragoso:m​atrix.org> not easy to control that on embassy I would think
<re_irc> <@a​damgreig:m​atrix.org> thalesfragoso: hopefully something can detect this, like the HAL can refuse to start a DMA transfer for an address that's not in an accessible memory
<re_irc> <@d​irbaio:m​atrix.org> it's very fragile to rely on that though
<re_irc> <@a​damgreig:m​atrix.org> seems a very detectable error, even C RTOSs manage
<re_irc> <@d​irbaio:m​atrix.org> nrf's can't do DMA from flash, nrf-hal and embassy-nrf detect that and return an error
<re_irc> <@d​irbaio:m​atrix.org> embassy-stm32 should do the same
<re_irc> <@a​damgreig:m​atrix.org> right, same deal here
<re_irc> <@d​irbaio:m​atrix.org> but still
<re_irc> <@t​halesfragoso:m​atrix.org> a bit harder to do that on embassy-stm32 though, with all the chips...
<re_irc> <@t​halesfragoso:m​atrix.org> and only some having this problem
<re_irc> <@a​damgreig:m​atrix.org> I'm not saying "you must use dtcm for the stack!", just that if you make it impossible to do so you leave a bunch of performance and memory on the table, and some users are gonna need it
<re_irc> <@d​irbaio:m​atrix.org> just throw MORE macrotables at it! :D
<re_irc> <@d​irbaio:m​atrix.org> either way
<re_irc> <@d​irbaio:m​atrix.org> it seems quite fragile to rely on that
<re_irc> <@t​halesfragoso:m​atrix.org> adamgreig: oh, not impossible
<re_irc> <@d​irbaio:m​atrix.org> your buffer will be in dtcm or main ram depening on whether you hold it across an .await 🤣
<re_irc> <@a​damgreig:m​atrix.org> lol, yikes
<re_irc> <@a​damgreig:m​atrix.org> statically? or would it get copied across?
<re_irc> <@d​irbaio:m​atrix.org> statically, rust will place it either on the fut or on the stack automatically
<re_irc> <@t​halesfragoso:m​atrix.org> btw dirbaio have you benched `Forever` to see if it construct stuff in place ?
<re_irc> <@d​irbaio:m​atrix.org> it tries to not "move" stuff between the future and the stack
<re_irc> <@d​irbaio:m​atrix.org> if you're using the buffer for async io you definitely are holding the buffer across one await though...
<re_irc> <@d​irbaio:m​atrix.org> the await where you read/write to that buffer :D
<re_irc> <@d​irbaio:m​atrix.org> so I guess in practice it'd be really hard to run into issues with this
<re_irc> <@d​irbaio:m​atrix.org> the only way to get it to explode I can think of is to use dma AND only locking
<re_irc> <@d​irbaio:m​atrix.org> thalesfragoso: `put` doesn't, `put_with` does
<re_irc> <@t​halesfragoso:m​atrix.org> interesting, thanks
<re_irc> <@d​irbaio:m​atrix.org> with the closure trick...
<re_irc> <@t​halesfragoso:m​atrix.org> dirbaio: Does the macro for embassy::task accept a place to put the static ?
<re_irc> <@d​irbaio:m​atrix.org> no..
<re_irc> <@t​halesfragoso:m​atrix.org> i.e. `link_section`
<re_irc> <@d​irbaio:m​atrix.org> but we can totally add that :D
<re_irc> <@t​halesfragoso:m​atrix.org> yeah, It makes sense for all chips with DTCM
<re_irc> <@d​irbaio:m​atrix.org> I've never seen `raw_ptr.write(my_fn())` fail to NRVO :D
<re_irc> <@d​irbaio:m​atrix.org> I *have* seen `*my_mut_ref = my_fn()` fail though :S
<re_irc> <@d​irbaio:m​atrix.org> because it calls my_fn() first, then drops the old value in `my_mut_ref`, then moves
<re_irc> <@d​irbaio:m​atrix.org> and drop can do anything, including panic
<re_irc> <@d​irbaio:m​atrix.org> 😢
<cr1901> drop panicking isn't considered horrible form?
<re_irc> <@d​irbaio:m​atrix.org> it is
<re_irc> <@d​irbaio:m​atrix.org> but the compiler can't assume it doesn't happen
<cr1901> Make it UB :)
<re_irc> <@d​irbaio:m​atrix.org> so it doesn't do that optimization, just in case
<re_irc> <@d​irbaio:m​atrix.org> uh then all drop would be `unsafe`
<re_irc> <@t​halesfragoso:m​atrix.org> in safe rust ? ~_~
<re_irc> <@d​irbaio:m​atrix.org> `unsafe impl Drop for Foo` 💩
<cr1901> I meant make panicking in drop UB
<re_irc> <@t​halesfragoso:m​atrix.org> famous exception safety...
<cr1901> grep for all Drop impls in all Rust source ever
<cr1901> make sure no one has done it
<cr1901> and if they have, too bad :P
<re_irc> <@t​halesfragoso:m​atrix.org> everything can panic...
<re_irc> <@d​irbaio:m​atrix.org> if you make it UB you should make it `unsafe`
<re_irc> <@t​halesfragoso:m​atrix.org> even a simple index
<re_irc> <@d​irbaio:m​atrix.org> `panic!()` is not unsafe
<re_irc> <@d​irbaio:m​atrix.org> array indexing is not unsafe! yup
<cr1901> It's a great idea and definitely not ill-advised
<cr1901> Anyways, I wonder if assuming Drop can panic has any actual meaningful perf costs in practice? Just doesn't sound like something you'd want to do.
<re_irc> <@t​halesfragoso:m​atrix.org> cr1901: it has in NRVO at least
<re_irc> <@t​halesfragoso:m​atrix.org> but it at least makes sense
<re_irc> <@d​irbaio:m​atrix.org> it's not just "drop can panic"
<re_irc> <@d​irbaio:m​atrix.org> it can have side effects
<cr1901> (global side effects?)
<re_irc> <@d​irbaio:m​atrix.org> yeah
<re_irc> <@d​irbaio:m​atrix.org> just a `println!` even
<re_irc> <@d​irbaio:m​atrix.org> in `*my_mut_ref = my_fn()`, the side effects of `my_fn` have to happen *before* the side effects of the drop of the old value
<re_irc> <@d​irbaio:m​atrix.org> so the compiler simply *can't* do NRVO
<re_irc> <@d​irbaio:m​atrix.org> it has to call `my_fn` storing the result in the stack temporarily
<re_irc> <@d​irbaio:m​atrix.org> then call `drop`
<re_irc> <@d​irbaio:m​atrix.org> then move
<re_irc> <@d​irbaio:m​atrix.org> result, your stack goes boom
<cr1901> What do you mean "boom"?
<re_irc> <@d​irbaio:m​atrix.org> if the value is 10kb and you only have 1kb of stack...
<cr1901> Oh oops
<re_irc> <@d​irbaio:m​atrix.org> you want 'my_fn' to write the return value directly to the destination... but the compiler won't do that if the type has a Drop
<cr1901> (Uhhh, this might be a silly q, but if bare "static mut" goes away, does this help the side effects of Drop situation)?
<re_irc> <@d​irbaio:m​atrix.org> it's a super common footgun
<re_irc> <@d​irbaio:m​atrix.org> this has nothing to do with static mut
<cr1901> Because the only side effects I can think of for Drop would have to be global
<cr1901> (you can't persist side effects to vars on the stack, because no other vars will be in scope to be accessed from drop() impl)
<re_irc> <@d​irbaio:m​atrix.org> you can have side effects in looots of ways
<re_irc> <@d​irbaio:m​atrix.org> with a `static FOO: Mutex<u8>` or whatever
<re_irc> <@d​irbaio:m​atrix.org> no need for `static mut`
<cr1901> dirbaio: I'm all over the place, sorry.
<cr1901> I said static mut specifically because "you either will do side effects through static mut or an unsafeCell". And I thought maybe "since UnsafeCell is special, if bare static mut is eliminated, maybe UnsafeCell's special properties will allow the compiler to assume that drop is safe for NRVO"
<cr1901> But 1. I have NOT thought deeply about this
<cr1901> 2. I didn't know Mutex<u8> without an UnsafeCell was usable
<re_irc> <@d​irbaio:m​atrix.org> Mutex has an unsafecell internally in the end
<re_irc> <@d​irbaio:m​atrix.org> but UnsafeCell doesn't make a difference, the side effects have to happen in the defined order
<re_irc> <@d​irbaio:m​atrix.org> doesn't matter how the side effects happen
<re_irc> <@d​irbaio:m​atrix.org> could be UnsafeCell mutation, could be a syscall for a println, could be a volatile register write
<re_irc> <@d​irbaio:m​atrix.org> the compiler simply can't shuffle them
<cr1901> Those all fall under "global state modification" in my overly reductive view :). Actually, I'm not trying to be pedantic... that's how I interpreted the possible set of Drop's side effects... I swear!
<cr1901> (And if Mutex uses UnsafeCell internally, why is Mutex<Cell<whatever>> a pattern?)
<re_irc> <@d​irbaio:m​atrix.org> std's mutex gives you &mut to the contents
<cr1901> Right... I forgot... the bare metal Mutex does not give you &mut
<cr1901> (and can't)
<re_irc> <@d​irbaio:m​atrix.org> critical section mutex gives you & to the contents beacuse you can lock it reentrantly, then dealing with reentrancy is up to you with Cell/RefCell
<cr1901> (Well, you can't take the lock w/o interrupts disabled, so that limits you to screwing yourself over- by e.g. taking a mut to RefCell twice- within a single thread I think)
<cr1901> dirbaio: What do you mean by reentrant? Calling the get() function again before the drop() of the first call happens?
simba has joined #rust-embedded
<cr1901> I usually think of "reentrancy" applying to a single function, but get() and drop() are two functions
<re_irc> <@d​irbaio:m​atrix.org> if it would return &mut, you could do
<re_irc> <@d​irbaio:m​atrix.org> static THING: Mutex<u8> = ...;
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> interrupt::free(|cs| {
<cr1901> Right, but that's not calling borrow() reentrantly AIUI. The first call to borrow finishes before the second one begins
<re_irc> <@d​irbaio:m​atrix.org> yeah but the lifetime doesn't
<re_irc> <@d​irbaio:m​atrix.org> both &muts are alive in the `// oops` line
<re_irc> <@d​irbaio:m​atrix.org> if the fn was `pub fn borrow<'cs>(&'cs self, _cs: CriticalSection<'cs>) -> &'cs mut T`
<cr1901> hmmm, I'm getting hung up on terminology, sorry. In any case, I see the problem
<re_irc> <@d​irbaio:m​atrix.org> it's definitely "reentrant locking"
<re_irc> <@d​irbaio:m​atrix.org> maybe this example is more obvious
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> fn foo() {
<re_irc> <@d​irbaio:m​atrix.org> static THING: Mutex<u8> = ...;
<re_irc> <@d​irbaio:m​atrix.org> interrupt::free(|cs| {
<re_irc> <@d​irbaio:m​atrix.org> with std mutex the inner lock would hang forever, avoiding the UB
* cr1901 nods
<re_irc> <@d​irbaio:m​atrix.org> but since we don't want that with CS mutexes (nesting CSs should be allowed), then the mutex can't return &mut to the contents, or there would be UB
<cr1901> Which means you should only ever modify through copies (Cell) or use a runtime check to panic (RefCell) when a copy isn't practical
<cr1901> Splitting it into two functions makes it more obvious
<re_irc> <@f​irefrommoonlight:m​atrix.org> They should call them `CopyCell` and `PanicCell` to make it easier
<re_irc> <@f​irefrommoonlight:m​atrix.org> It took me a while to figure out that distinction you posted!
<re_irc> <@a​damgreig:m​atrix.org> do any macro wizards know if you can now create an identifier by concatenation in a macro_rules? iirc this wasn't possible in the past
<re_irc> <@a​damgreig:m​atrix.org> ah, yes, https://doc.rust-lang.org/std/macro.concat_idents.html, nightly-only
<re_irc> <@d​irbaio:m​atrix.org> It's very cursed, I'd say just don't
<re_irc> <@a​damgreig:m​atrix.org> yea
<re_irc> <@d​irbaio:m​atrix.org> You'll run into hygiene crap
<re_irc> <@d​irbaio:m​atrix.org> :D
<re_irc> <@a​damgreig:m​atrix.org> nevermind, nothing a vim macro can't solve
<re_irc> <@d​irbaio:m​atrix.org> Hahahahaha
<re_irc> <@a​damgreig:m​atrix.org> codegen all the way down
<re_irc> <@a​damgreig:m​atrix.org> 126 instructions in the armv7-m dsp extension 💀
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think so? Eg with `paste!`?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Can you post an example?
<re_irc> <@f​irefrommoonlight:m​atrix.org> If it's what I think, I do it all the time
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> paste! {
<re_irc> <@f​irefrommoonlight:m​atrix.org> }
<re_irc> <@f​irefrommoonlight:m​atrix.org> // ... &mut pac::[<GPIO $Port>]
<re_irc> <@f​irefrommoonlight:m​atrix.org> Where that turns into `pac::GPIOA` etc
<re_irc> <@t​herealprof:m​atrix.org> Grr. And in ACLE the intrinsics are not symmetric. There's e.g. none for UQADD (without size).
<re_irc> <@t​herealprof:m​atrix.org> I nerdsniped myself to add them to LLVM and hit a couple of snags already.
<re_irc> <@a​damgreig:m​atrix.org> I don't think UQADD exists at all?
<re_irc> <@a​damgreig:m​atrix.org> at least your nerdsniping was more effective than mine creating cortex-m-asm 💀
<re_irc> <@a​damgreig:m​atrix.org> I think we can add DSP intrinsics to c-m pretty easily at least though
<re_irc> <@a​damgreig:m​atrix.org> though shame we can't yet use const generics for the asm
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: Yeah, seems so.
mightypork_ has quit [Quit: ZNC - https://znc.in]
mightypork has joined #rust-embedded
mightypork has quit [Quit: ZNC - https://znc.in]
mightypork has joined #rust-embedded
<re_irc> <@w​indfisch42:m​atrix.org> hey all! is async/await on embedded a thing yet?
<re_irc> <@w​indfisch42:m​atrix.org> I'm developing a USB host driver for stm32f4 chips, and I would love to wrap this state machine in an async/await-future. Currently, I am using a generator which `yield`s whenever we are busy-waiting on stuff;
<re_irc> <@w​indfisch42:m​atrix.org> however, currently, `delay_ms` is still executed as is; I will probably change this to busy-waiting on a "current time" global variable, and then throw in a `yield` in that loop, but this feels like I'm developing my own (half) async await runtime...
Windfisch has left #rust-embedded [#rust-embedded]
<re_irc> <@f​irefrommoonlight:m​atrix.org> Trip report: For mutable global atomics, use `static VAR_NAME: AtomicBool` etc - NOT const. `const` will fail silently when you attempt to mutate using `store`
<re_irc> <@f​irefrommoonlight:m​atrix.org> That one took a while to figure out
<re_irc> <@a​damgreig:m​atrix.org> Windfisch: https://github.com/embassy-rs/embassy is probably the main thing to look at, and https://github.com/rust-embedded/embedded-hal/pull/285
<re_irc> <@a​damgreig:m​atrix.org> In short yes but most of the features you'll want aren't stable yet so it's quite nascent
<re_irc> <@b​urrbull:m​atrix.org> https://github.com/stm32-rs/stm32f4xx-hal/pull/334
<re_irc> <@b​urrbull:m​atrix.org> therealprof: https://github.com/stm32-rs/stm32f4xx-hal/pull/335
<re_irc> <@f​irefrommoonlight:m​atrix.org> What's the use case for timer delay? I've implemented that as well in a moment of boredom, but don't have a use
<re_irc> <@f​irefrommoonlight:m​atrix.org> Although I use nonblocking (interrupt-based) timer countdowns all the time
<re_irc> <@w​indfisch42:m​atrix.org> generators themselves aren't stable either, right :\?
<re_irc> <@w​indfisch42:m​atrix.org> i'm not sure whether I just want to rely on unstable, or whether to spell out that statemachine and be compatible with stable rust...
<re_irc> <@a​damgreig:m​atrix.org> therealprof: packed 2xi16 qadd16 using inline asm, optimising perfectly: https://rust.godbolt.org/z/E95Gbnrof
<re_irc> <@a​damgreig:m​atrix.org> I think we could probably add an interface like this to c-m so at least on nightly it would inline, and maybe with xlto too
<re_irc> <@f​irefrommoonlight:m​atrix.org> Are there any svd2rust wizards that can help with a YAML patch for stm32-rs? A few changes are not taking, and I can't figure out why
<re_irc> <@a​damgreig:m​atrix.org> ack, sorry, reviewing those issues was on my list for today and i got totally sniped by this dsp stuff
<re_irc> <@a​damgreig:m​atrix.org> wanna try and work one out now?
simba has quit [Quit: WeeChat 3.1]
<re_irc> <@f​irefrommoonlight:m​atrix.org> No rush! I've made sep crates for now, so no rush to upstream it. I'm focused now on why some of the changes I made don't work
<re_irc> <@f​irefrommoonlight:m​atrix.org> (indeed, the ones in the PR text)
<re_irc> <@f​irefrommoonlight:m​atrix.org> At gym, will be able to build in 30 mins
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: It's quite a bit of work to make and use these intrinsics, do you think people are actually going to use it?
<re_irc> <@a​damgreig:m​atrix.org> adding just the basic fn(u32, u32) -> u32 is quite OK I think (I've already done it)
<re_irc> <@a​damgreig:m​atrix.org> adding the higher-level version that takes a packed struct is a bit trickier and I'm not sure what the best representation is
<re_irc> <@t​herealprof:m​atrix.org> Yeah, but there're a lot of bits and pieces to get right (and a custom API) just to end up with the ideal instructions in the binary. In a way it's nice that people can use intrinsics like in C/C++ if they really want to squeeze out the last couple percent of performance; OTOH it always felt like kludge in C...
<re_irc> ... and I don't think a lot of people would have cared for it if there was any better way. 😉
<re_irc> <@t​herealprof:m​atrix.org> I'm not at all opposed to adding it, I'm just anything but sure if people would use it and it's the best use of our precious time.
<re_irc> <@t​herealprof:m​atrix.org> Anyway, hours later my poor little backup laptop is still chugging away at the LLVM testsuite in what I hope is the last run before I can hand over a patch to add support for unsigned saturated add/sub lowering.
<re_irc> <@a​damgreig:m​atrix.org> definitely llvm doing it is the best option
<re_irc> <@t​herealprof:m​atrix.org> There's a ton of room for improvement there.
<re_irc> <@f​irefrommoonlight:m​atrix.org> adamgreig: hacking at it now - First thing I'm working is reverting naming the USB interrupt USB instead of USB_FS on L4x2. The RM calls it USB_FS, and the reason for calling is USB was "to be aligned with `mvirkkunen/stm32f103-usb`"
<re_irc> <@t​herealprof:m​atrix.org> It seems the generated ARM code in LLVM is still miles away from being optimal.
<re_irc> <@f​irefrommoonlight:m​atrix.org> btw, what does `-j` do for make?
<re_irc> <@d​irbaio:m​atrix.org> number of concurrent jobs
<re_irc> <@f​irefrommoonlight:m​atrix.org> Thank you
<re_irc> <@t​herealprof:m​atrix.org> Really curious why that is, shouldn't at least Apple have a very big interest in halfway decent good code generation? Or did they skip the lowly DSP stuff altogether and have SIMD code generation running at full steam everywhere?
<re_irc> <@d​irbaio:m​atrix.org> apple only cares about arm-A don't they? not arm-M
<re_irc> <@a​damgreig:m​atrix.org> apple uses arm-m in some stuff iirc, but even without apple you'd think someone else might
<re_irc> <@t​herealprof:m​atrix.org> IIRC also the other architectures have DSP extensions, at least the LLVM code implies that it's not just -M.
<re_irc> <@f​irefrommoonlight:m​atrix.org> edit - It looks like if I keep the USB: _add section and just delete the
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> it works, from initial look
<re_irc> <@f​irefrommoonlight:m​atrix.org> - USB_FS
<re_irc> <@f​irefrommoonlight:m​atrix.org> _delete:
<re_irc> <@a​damgreig:m​atrix.org> this is in L412 yaml?
<re_irc> <@a​damgreig:m​atrix.org> oh, L4x2
<re_irc> <@f​irefrommoonlight:m​atrix.org> This applies to both
<re_irc> <@f​irefrommoonlight:m​atrix.org> Actually, what I just posted builds the lib and shows the interrupt as USB_FS in teh module, but fails on compile
<re_irc> <@a​damgreig:m​atrix.org> so the rename happens in the USB_SRAM: name: USB bit
<re_irc> <@a​damgreig:m​atrix.org> it looks like the deletion isn't right, though, if it's trying to delete the interrupt
<re_irc> <@f​irefrommoonlight:m​atrix.org> (And btw, this one is a bit pedantic, but I'm hoping to learn more about these YAMLs in teh process)
<re_irc> <@f​irefrommoonlight:m​atrix.org> I tried removing the `name: USB` line, but it won't built
<re_irc> <@f​irefrommoonlight:m​atrix.org> `svdtools.patch.MissingPeripheralError: Could not find USB`
<re_irc> <@f​irefrommoonlight:m​atrix.org> Of note, I was able to successfully add the USB interrupt to l4x3 with this:
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> USB:
<re_irc> <@f​irefrommoonlight:m​atrix.org> _add:
<re_irc> <@a​damgreig:m​atrix.org> that makes sense, since it's later including a patch that works on the renamed USB
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm trying to make l4x2 match it
<re_irc> <@a​damgreig:m​atrix.org> what's your objective?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Make the interrupt name `USB_FS`
<re_irc> <@t​herealprof:m​atrix.org> dirbaio: I just checked, the CPU architectures including Armv8-A also mandate the inclusion of the DSP extensions, they're just not called that anymore but part of the SIMD instructions.
<re_irc> <@d​irbaio:m​atrix.org> oh, the same instructions? interesting
<re_irc> <@a​damgreig:m​atrix.org> therealprof: doesn't -A have a different set than -M?
<re_irc> <@a​damgreig:m​atrix.org> I haven't checked, dunno
<re_irc> <@a​damgreig:m​atrix.org> rust core::arch::arm has a bunch of vector intrinsics for arm-a
<re_irc> <@a​damgreig:m​atrix.org> firefrommoonlight: so, peripheral called USB, but interrupt called USB_FS?
<re_irc> <@f​irefrommoonlight:m​atrix.org> adamgreig: We can skip this one if you want, since it isn't required for any functinoality
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yep!
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's the way it is in teh RMs
<re_irc> <@f​irefrommoonlight:m​atrix.org> Making it work on L4x3 was fine because the SVD was flat out missing the interrupt. The prior art in the L4x2 module is causing some conflict, but just deleting it causes trouble
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: Maybe, but they seem to include all the DSP ones:
<re_irc> <@t​herealprof:m​atrix.org> 0b0001 Adds the SSAT and USAT instructions, and the Q bit in the PSRs.
<re_irc> <@t​herealprof:m​atrix.org> 0b0000 None implemented.
<re_irc> <@t​herealprof:m​atrix.org> Indicates the implemented SIMD instructions. Defined values are:
<re_irc> <@t​herealprof:m​atrix.org> In LLVM they call the DSP extension of Cortex-M `BaseDSP` (though that constant is never used 🤷‍♂️
<re_irc> <@a​damgreig:m​atrix.org> firefrommoonlight: aah, I see I think, the interrupt was defined on USB_FS, but we're renaming USB_SRAM to USB and deleting USB_FS
<re_irc> <@a​damgreig:m​atrix.org> so I have this diff from your branch: https://dpaste.com/9HXDCZNDD
<re_irc> <@a​damgreig:m​atrix.org> on L412.yaml
<re_irc> <@a​damgreig:m​atrix.org> and that generates an SVD that has the one USB peripheral named USB and one interrupt named USB_FS
<re_irc> <@a​damgreig:m​atrix.org> (RM0393 right?)
<re_irc> <@f​irefrommoonlight:m​atrix.org> Hey, I think I got it!
<re_irc> <@a​damgreig:m​atrix.org> oh, RM0394 perhaps
<re_irc> <@f​irefrommoonlight:m​atrix.org> I was using 0394
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea!
<re_irc> <@t​herealprof:m​atrix.org> dirbaio: Seems so, they're all tested within the same unittest file even and generate the same output.
<re_irc> <@f​irefrommoonlight:m​atrix.org> So, I think the fix is just changing 3 chars:
<re_irc> <@f​irefrommoonlight:m​atrix.org> `USB:
<re_irc> <@f​irefrommoonlight:m​atrix.org> _add:
<re_irc> <@f​irefrommoonlight:m​atrix.org> _interrupts:
<re_irc> <@d​irbaio:m​atrix.org> strange
<re_irc> <@d​irbaio:m​atrix.org> maybe they implemetned it in their sekrit fork
<re_irc> <@f​irefrommoonlight:m​atrix.org> And yea - this fix is solely to be in line with the RM
<re_irc> <@d​irbaio:m​atrix.org> ah the joys of yaml patches :P
<re_irc> <@t​herealprof:m​atrix.org> define zeroext i8 @func8(i8 zeroext %x, i8 zeroext %y, i8 zeroext %z) nounwind {
<re_irc> <@t​herealprof:m​atrix.org> ; CHECK-T1-LABEL: func8:
<re_irc> <@t​herealprof:m​atrix.org> ; CHECK-T1-NEXT: muls r1, r2, r1
<re_irc> <@t​herealprof:m​atrix.org> ; CHECK-T1: @ %bb.0:
<re_irc> <@f​irefrommoonlight:m​atrix.org> Pushed
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ok, Now... Why most of the L412 RTC changes I made worked, but the 3 reg adds at the end didn't...
<re_irc> <@f​irefrommoonlight:m​atrix.org> The end being by offset
<re_irc> <@a​damgreig:m​atrix.org> which in particular?
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm looking at 34.6.21 in that RM. (Note that this whole chapter is dedicated to this RTC variant that's not in the SVD at all)
<re_irc> <@f​irefrommoonlight:m​atrix.org> RTC_SR, RTC_MISR, and RTC_SCR aren't adding
<re_irc> <@f​irefrommoonlight:m​atrix.org> All the other modifications and changes (from the l4x2 SVD, ie the one based on the Chapter 36 RTC) work
<re_irc> <@a​damgreig:m​atrix.org> so ICSR works and SR doesn't?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yep
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm looking at this bit of the generated `mod.rs`:
<re_irc> <@f​irefrommoonlight:m​atrix.org> ///Real-time clock
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> pub mod rtc {
<re_irc> <@f​irefrommoonlight:m​atrix.org> Its final entry is `alrmbssr`
<re_irc> <@f​irefrommoonlight:m​atrix.org> Hmm... directly below that it's showing this:
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```rust
<re_irc> <@f​irefrommoonlight:m​atrix.org> impl RegisterBlock {
<re_irc> <@f​irefrommoonlight:m​atrix.org> ///0x50 - RTC status register
<re_irc> <@f​irefrommoonlight:m​atrix.org> So, the backup register, which take up these spots on the SVD its replacing, aren't totally getting deleted?
<re_irc> <@a​damgreig:m​atrix.org> hmm
<re_irc> <@f​irefrommoonlight:m​atrix.org> (eg the Chapter 36 RTC)
<re_irc> <@a​damgreig:m​atrix.org> yes, looks like that's it
<re_irc> <@a​damgreig:m​atrix.org> svd2rust emits those functions when registers alias
<re_irc> <@f​irefrommoonlight:m​atrix.org> I have this:
<re_irc> <@f​irefrommoonlight:m​atrix.org> RTC:
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```yaml
<re_irc> <@f​irefrommoonlight:m​atrix.org> _delete:
<re_irc> <@a​damgreig:m​atrix.org> and the various backup registers are still present, so it's doing that
<re_irc> <@a​damgreig:m​atrix.org> but they're named like BKP1R, BKP2R, etc
<re_irc> <@f​irefrommoonlight:m​atrix.org> AHAH
<re_irc> <@a​damgreig:m​atrix.org> so deleting BKPR doesn't get them, I suppose
<re_irc> <@a​damgreig:m​atrix.org> ah, interesting, I guess it's getting array-ified
<re_irc> <@a​damgreig:m​atrix.org> by the inclusion of common_patches/rtc/rtc_bkpr.yaml
<re_irc> <@a​damgreig:m​atrix.org> get rid of that file, and delete BKP*R
<re_irc> <@a​damgreig:m​atrix.org> (as in, don't include that file in the devices with this new RTC)
<re_irc> <@a​damgreig:m​atrix.org> btw, I'm using `svd mmap svd/stm32l412.svd.patched` to get a clearer look at the output svd
neceve has quit [Ping timeout: 240 seconds]
<re_irc> <@f​irefrommoonlight:m​atrix.org> Nailed it! Works.
<re_irc> <@f​irefrommoonlight:m​atrix.org> 2 down!
<re_irc> <@f​irefrommoonlight:m​atrix.org> Now looking at l4x3 USB BCDR not adding
<re_irc> <@f​irefrommoonlight:m​atrix.org> Note that this isn't used commonly since most people use USBD which provides its own pac for that reg
<re_irc> <@f​irefrommoonlight:m​atrix.org> Uh... I have no idea. It's working now
<re_irc> <@f​irefrommoonlight:m​atrix.org> Sorry
<re_irc> <@a​damgreig:m​atrix.org> hah, even better
<re_irc> <@f​irefrommoonlight:m​atrix.org> Last one is IPCC and HSEM not adding on WB
<re_irc> <@f​irefrommoonlight:m​atrix.org> We deliberately ommit this, compared to l4x2.
<re_irc> <@f​irefrommoonlight:m​atrix.org> (This is a change to match RM)
<re_irc> <@f​irefrommoonlight:m​atrix.org> ```yaml
<re_irc> <@f​irefrommoonlight:m​atrix.org> HSEM:
<re_irc> <@f​irefrommoonlight:m​atrix.org> _modify:
<re_irc> <@f​irefrommoonlight:m​atrix.org> C1IER0:
<re_irc> <@a​damgreig:m​atrix.org> this one's easier
<re_irc> <@a​damgreig:m​atrix.org> ```yaml
<re_irc> <@a​damgreig:m​atrix.org> HSEM:
<re_irc> <@a​damgreig:m​atrix.org> C1IER0:
<re_irc> <@a​damgreig:m​atrix.org> _modify:
<re_irc> <@f​irefrommoonlight:m​atrix.org> Oh shit
<re_irc> <@f​irefrommoonlight:m​atrix.org> hmm: `svdtools.patch.UnknownTagError: ('register', '_modify')`
<re_irc> <@a​damgreig:m​atrix.org> huh, I just ran that OK
<re_irc> <@a​damgreig:m​atrix.org> check indentation/spelling/etc?