<re_irc> <@f​irefrommoonlight:m​atrix.org> The project requirements
<re_irc> <@f​irefrommoonlight:m​atrix.org> What the project it must accomplish
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ie if it does everything on the list, it's winning
<re_irc> <@f​irefrommoonlight:m​atrix.org> And if it does extra stuff, it's bloated
<re_irc> <@f​irefrommoonlight:m​atrix.org> If it's too jargony, does "Goals" work better?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Or something else
<re_irc> <@f​irefrommoonlight:m​atrix.org> Engineering thing
<re_irc> <@d​irbaio:m​atrix.org> was just curious
<re_irc> <@d​irbaio:m​atrix.org> maybe "goals" is more obvious it's for EH itself and not HALs impling EH traits
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'll make the change
<re_irc> <@d​irbaio:m​atrix.org> PSA: generic_array will happily blow up your stack.
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> fn new<N: ArrayLength<u8>>() -> BigThing<N> {
<re_irc> <@d​irbaio:m​atrix.org> BigThing { buf: GenericArray::default() }
<re_irc> <@d​irbaio:m​atrix.org> struct BigThing<N: ArrayLength<u8>> { buf: GenericArray<u8, N> }
<re_irc> <@d​irbaio:m​atrix.org> }
<re_irc> <@d​irbaio:m​atrix.org> `new` there uses `N*3` bytes of stack
<re_irc> <@d​irbaio:m​atrix.org> with all optimizations cranked up (LTO etc)
<re_irc> <@d​irbaio:m​atrix.org> while the equivalent code with const generics uses zero bytes of stack
<re_irc> <@d​irbaio:m​atrix.org> yes, zero! it constructs the result in-place wherever the caller wants it
<re_irc> <@d​irbaio:m​atrix.org> it's hilariously bad https://gist.github.com/Dirbaio/6a8df22cbf94009d725a28cf63ccd62d
<re_irc> <@t​halesfragoso:m​atrix.org> Can confirm, was battling my 4kB stack for hours trying to understand why I had 3x the stack as expected
<re_irc> <@t​halesfragoso:m​atrix.org> I even would thought 2 were okay, since it might not do in-place, but 3 was crazy
<re_irc> <@j​amesmunns:m​atrix.org> Yup, I think this specifically in the lto tracking issue
<re_irc> <@d​irbaio:m​atrix.org> it doesn't do that on the playground though https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=8ad05b5ab1bc16e0c6be38104211cb76
<re_irc> <@d​irbaio:m​atrix.org> ah it's due to LTO?
<re_irc> <@j​amesmunns:m​atrix.org> Oops, I mean the nrvo tracking issue
<re_irc> <@d​irbaio:m​atrix.org> link?
<re_irc> <@d​irbaio:m​atrix.org> how does an NRVO failure cause it to have THREE copies of the buffer?
<re_irc> <@j​amesmunns:m​atrix.org> (I also blew my stack using postcard with heapless vec)
<re_irc> <@d​irbaio:m​atrix.org> three NRVO failures in a row, and inlining is still unable to get rid of it?
<re_irc> <@j​amesmunns:m​atrix.org> Uhh, I was just noting a pessimal case
<re_irc> <@j​amesmunns:m​atrix.org> I don't have the link handy and am going to bed
<re_irc> <@j​amesmunns:m​atrix.org> Will look tomorrow, I don't have an explanation why it's three
<re_irc> <@t​halesfragoso:m​atrix.org> Generic-array is cursed
<re_irc> <@d​irbaio:m​atrix.org> it's very cursed
<re_irc> <@t​halesfragoso:m​atrix.org> Can't blame rustc that much
<re_irc> <@j​amesmunns:m​atrix.org> But this is in the realm of "compiler should be able to see through this, but doesn't"
<re_irc> <@t​halesfragoso:m​atrix.org> Yeah, glad we have const generics now, time to PR it to ssd1306
<re_irc> <@t​halesfragoso:m​atrix.org> Probably not today though
<re_irc> <@d​irbaio:m​atrix.org> it goes `my code -> GenericArray::default() -> generate -> ArrayBuilder::new(), ArrayBuilder::into_inner()`
<re_irc> <@d​irbaio:m​atrix.org> and closures and stuff
<re_irc> <@d​irbaio:m​atrix.org> lots of room for it to go wrong yup
fabic has joined #rust-embedded
Amanieu has quit [Quit: No Ping reply in 180 seconds.]
Amanieu has joined #rust-embedded
njha has quit [Quit: a funny/inspired quit message]
aquijoule_ has joined #rust-embedded
richbridger has quit [Ping timeout: 246 seconds]
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 246 seconds]
fabic has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
hifi has quit [Ping timeout: 246 seconds]
hifi has joined #rust-embedded
hifi has quit [Ping timeout: 246 seconds]
hifi has joined #rust-embedded
hifi has quit [Read error: Connection reset by peer]
hifi has joined #rust-embedded
hifi has quit [Read error: Connection reset by peer]
hifi has joined #rust-embedded
hifi has quit [Ping timeout: 252 seconds]
hifi has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
<re_irc> <@s​ympatron:m​atrix.org> jamesmunns: BBBuffers currently own the actual buffer. Would it be possible to accept a `&mut [u8]` and use that instead?
<re_irc> <@s​ympatron:m​atrix.org> As far as I understand it, `flip-link` swaps heap and stack to prevent stack overflows and therefore UB. Why isn't this the default then? Seems very reasonable. Otherwise you can easily have UB with safe code in an embedded system. Especially with footguns like GenericArray
<re_irc> <@s​ympatron:m​atrix.org> *by prevent I mean hard fault on stack overflow instead of silently continuing
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
neceve has joined #rust-embedded
<re_irc> <@s​ympatron:m​atrix.org> adamgreig: I know `spi-flash` wasn't meant for embedded. But I didn't want to reinvent the wheel and `spi-flash` is so complete and well documented compared to alternatives, that I thought this would be the best solution to adapt it for embedded use cases. Maybe I'll just fork and see where it goes...
<re_irc> <@s​ympatron:m​atrix.org> Having automatic runtime detection of the flash can be really useful, too. Because of the current market situation, I cannot guarantee that every batch of some device will have the same flash and I don't want to compile and maintain a different firmware for each batch, so runtime detection would actually be...
<re_irc> ... really nice to have.
<re_irc> <@9​names:m​atrix.org> flip-link doesn't do anything with the heap - most embedded rust projects don't even have one. it just measures static allocations, then uses that size information to adjust the link script to move the stack to the bottom of RAM.
<re_irc> <@9​names:m​atrix.org> as for why it's not the default, most users of the linker have an MMU which makes detecting stack overflow easier and more generic - you can have multiple stacks and detect an overflow on any of them.
<re_irc> <@a​damgreig:m​atrix.org> sympatron: Thank you for the nice comments about it :) I am definitely interested in it getting no_std support so let's see where it goes, even if the best thing is a fork or maybe a second api for no_std or whatever.
<re_irc> <@s​ympatron:m​atrix.org> 9names: You are right, I misremembered the part about the heap. And if you have a MMU and set it up correctly that's obviously better, but I would disagree that "most" MCU have a MMU and for those who don't stack overflows are very dangerous. I was just wondering if there was a downside to this. The `flip-link`...
<re_irc> ... docs don't mention any.
<Lumpio-> How does flip-link deal with recursive functions?
<Lumpio-> oh wait
<Lumpio-> Ah it only calculates bss and data, alright
<Lumpio-> I thought it actually figured out the max stack size or something.
crabbedhaloablut has quit [Ping timeout: 244 seconds]
crabbedhaloablut has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
<re_irc> <@d​ngrs:m​atrix.org> ahoy!
<re_irc> <@d​ngrs:m​atrix.org> am I right in my assumption that neither `stm32f1xx-hal` nor `stm32f4xx-hal` offer functionality to use timers in input capture mode?
<re_irc> <@r​yan-summers:m​atrix.org> Very likely not. If you want an example of wrapping HAL timers to add support for input capture, we did it for the H7 HAL: https://github.com/quartiq/stabilizer/blob/master/src/hardware/timers.rs#L292
<re_irc> <@r​yan-summers:m​atrix.org> That entire file is basically us extending the functionality of the HAL timer by wrapping up unsafe register instantiation + manipulation
<re_irc> <@d​ngrs:m​atrix.org> thx! So I'm thinking, if I were to write a PR, how to structure it ... the f4xx one has a `Timeout` event, maybe extend it with `InputCapture`?
<re_irc> <@f​irefrommoonlight:m​atrix.org> theunknown is working on this now in the stm32-rs channel
<re_irc> <@d​ngrs:m​atrix.org> forgot that one exists. Thx!
<re_irc> <@l​achlansneff:m​atrix.org> I'm thinking of getting rid of the timer/`CountDown` traits in the `embedded-hal::futures` module and switching to some sort of async delay trait
<re_irc> <@l​achlansneff:m​atrix.org> Since it's async, it could be used to implement io timeouts and things like that even though it's blocking sort of
<re_irc> <@l​achlansneff:m​atrix.org> And I'm wondering if we should stick with the `DelayMs`, `DelayUs` style or have a single trait that takes a duration.
<re_irc> <@l​achlansneff:m​atrix.org> The `CountDown` trait has a `Time` associated type, but maybe it'd make sense to actually have a Duration type?
<re_irc> <@d​irbaio:m​atrix.org> Duration type or Duration trait?
<re_irc> <@l​achlansneff:m​atrix.org> Well, I was thinking a `Duration` _type_, but a trait would be okay too I guess.
<re_irc> <@l​achlansneff:m​atrix.org> I'm recalling the conversation we had a few days ago about all the traits in `core+`
<re_irc> <@d​irbaio:m​atrix.org> Problem with single type is how is it represented
<re_irc> <@d​irbaio:m​atrix.org> u32 might overflow too fast for some
<re_irc> <@d​irbaio:m​atrix.org> u64 might be too big for others
<re_irc> <@d​irbaio:m​atrix.org> 🤣
<re_irc> <@d​irbaio:m​atrix.org> but a trait is overengineering
<re_irc> <@d​irbaio:m​atrix.org> there's also embedded-time, but imo it's too complex too :D
<re_irc> <@l​achlansneff:m​atrix.org> Even if it were a trait, the hal implementors would be deciding the size of it, not the user, so I'm not sure it really matters
<re_irc> <@l​achlansneff:m​atrix.org> Or, I guess the `delay` method could be generic on the duration impl
<re_irc> <@l​achlansneff:m​atrix.org> `fn delay(&mut self, duration: impl Duration) -> ...`
<re_irc> <@l​achlansneff:m​atrix.org> And the duration trait would have method that return large integers, and if an impl just wanted to store small ones, it could upcast
<re_irc> <@l​achlansneff:m​atrix.org> Thoughts?
<re_irc> <@j​amesmunns:m​atrix.org> sympatron: There are talks about this! The answer is: It makes the code harder, and I want to fix this, but it's not a priority for me.
<re_irc> <@r​yan-summers:m​atrix.org> I honestly think embedded-time is a nice solution, although it definitely is complex enough that I've been hesitant to add it to my crates
<re_irc> <@r​yan-summers:m​atrix.org> I think it would be easier if there were more default implementations for embedded-time
<re_irc> <@e​ldruin:m​atrix.org> I would say durations get complicated _fast_. See embedded-time
<re_irc> <@j​amesmunns:m​atrix.org> ryan-summers: As always, if you want a "like instant, but a little worse, but way simpler as long as you hold it right", https://docs.rs/groundhog is exactly for that.
<re_irc> <@r​yan-summers:m​atrix.org> That's still an overhead form someone to impl groundhog::RollingTimer though
<re_irc> <@r​yan-summers:m​atrix.org> I'm talking about making a crate that needs some timekeeping impl
<re_irc> <@j​amesmunns:m​atrix.org> Implementing for basically any hardware is like... a handful of lines: https://github.com/jamesmunns/groundhog/blob/main/drivers/groundhog-nrf52/src/lib.rs
<re_irc> <@r​yan-summers:m​atrix.org> e.g. a networking interface that needs to set timeouts in the future etc.
<re_irc> <@r​yan-summers:m​atrix.org> Honestly, embedded-time impls look very similar imo
<re_irc> <@j​amesmunns:m​atrix.org> Yup, I use it for more or less this purpose in `choreographer`: https://docs.rs/choreographer/
<re_irc> <@j​amesmunns:m​atrix.org> Lachlan Sneff: I use an associated type in groundhog, so it would be something like: `duration: Timer::Tick`.
<re_irc> <@l​achlansneff:m​atrix.org> So, would `Timer` be a type parameter of the trait or an associated type?
<re_irc> <@l​achlansneff:m​atrix.org> Or a type parameter of the function
<re_irc> <@r​yan-summers:m​atrix.org> generic type that impls a trait
<re_irc> <@r​yan-summers:m​atrix.org> I believe
<re_irc> <@j​amesmunns:m​atrix.org> you'd be generic over your timer impl e.g. `Timer: RollingTimer`, and then you could use the associated type.
<re_irc> <@l​achlansneff:m​atrix.org> Which thing would be generic over the Timer?
<re_irc> <@l​achlansneff:m​atrix.org> The trait or the function
<re_irc> <@r​yan-summers:m​atrix.org> It depends on how you impl
<re_irc> <@r​yan-summers:m​atrix.org> You can make either whole structs, traits, or single funcs depending on the use case
<re_irc> <@j​amesmunns:m​atrix.org> (I do have some hax here on the struct itself, because I want a const constructor: https://docs.rs/choreographer/0.0.4/src/choreographer/engine.rs.html#370-380)
<re_irc> <@l​achlansneff:m​atrix.org> Oh interesting.
<re_irc> <@j​amesmunns:m​atrix.org> (because no trait bounds for const fns)
<re_irc> <@j​amesmunns:m​atrix.org> So I can do this: https://docs.rs/choreographer/0.0.4/src/choreographer/engine.rs.html#72-79
<re_irc> <@j​amesmunns:m​atrix.org> you could give that any type, and it would compile, but then you couldn't use any of the actual methods
<re_irc> <@j​amesmunns:m​atrix.org> So pretty hard to misuse, in practice.
<re_irc> <@l​achlansneff:m​atrix.org> Hmm
<re_irc> <@l​achlansneff:m​atrix.org> Well, that seems pretty nice
<re_irc> <@j​amesmunns:m​atrix.org> It works really well!
<re_irc> <@j​amesmunns:m​atrix.org> As long as you never hold a tick value for more than the wraparound time :D
<re_irc> <@j​amesmunns:m​atrix.org> at which time it will silently give you garbage values.
<re_irc> <@l​achlansneff:m​atrix.org> :/
<re_irc> <@j​amesmunns:m​atrix.org> (for 1MHz timer, this is a 71min window)
<re_irc> <@r​yan-summers:m​atrix.org> For reference, that's the case that I believe embedded-time is trying to force people to resolve, right?
<re_irc> <@r​yan-summers:m​atrix.org> E.g. handle the overflow errors and react in code as opposed to silently ignoring?
<re_irc> <@d​irbaio:m​atrix.org> how would ET detect overflow in this case?
<re_irc> <@d​irbaio:m​atrix.org> if your duration is u32
<re_irc> <@j​amesmunns:m​atrix.org> it wouldn't detect it.
<re_irc> <@d​irbaio:m​atrix.org> there's no way it can know it's from the current "overflow period" or the previous one
<re_irc> <@j​amesmunns:m​atrix.org> it would tell you it has been T-71 minutes, instead of T minutes.
<re_irc> <@r​yan-summers:m​atrix.org> Hmm, yeah maybe it can't detect that either
<re_irc> <@r​yan-summers:m​atrix.org> I don't know if you can ever generically handle those cases
<re_irc> <@d​irbaio:m​atrix.org> it's still nice because it lets you choose between u32 and u64
<re_irc> <@j​amesmunns:m​atrix.org> (sorry, my "it" answers were re: groundhog)
<re_irc> <@d​irbaio:m​atrix.org> in embassy I decided to just have u64 for simplicity
<re_irc> <@j​amesmunns:m​atrix.org> (I have not experience with e-t)
<re_irc> <@d​irbaio:m​atrix.org> but yeah that means you're wasting 4 bytes if you don't need such long times! 🤷‍♂️
<re_irc> <@j​amesmunns:m​atrix.org> Yeah, you could impl groundhog with a 64-bit value!
<re_irc> <@j​amesmunns:m​atrix.org> buuuuut then you need u128 support
<re_irc> <@d​irbaio:m​atrix.org> u128? why? lol
<re_irc> <@j​amesmunns:m​atrix.org> to make sure you don't overflow when mult/dividing to get ticks/sec
<re_irc> <@j​amesmunns:m​atrix.org> there's probably a smarter way to do it
<re_irc> <@j​amesmunns:m​atrix.org> (it's for these calculations: https://github.com/jamesmunns/groundhog/blob/main/core/src/lib.rs#L46-L73)
<re_irc> <@d​irbaio:m​atrix.org> ooh, fancy
<re_irc> <@d​irbaio:m​atrix.org> embassy doesn't do that
<re_irc> <@d​irbaio:m​atrix.org> maybe it overflows? :P
<re_irc> <@j​amesmunns:m​atrix.org> could, you'd need pretty high numbers IIRC?
<re_irc> <@j​amesmunns:m​atrix.org> but honestly
<re_irc> <@j​amesmunns:m​atrix.org> with a u64, you're not going to use enough of the u64 to get close enough to rollover.
<re_irc> <@j​amesmunns:m​atrix.org> but if you have 70m in a 71m range, and multiply it by 1M, you're gunna have a bad time.
<re_irc> <@j​amesmunns:m​atrix.org> so like, I'd probably also accept a "close enough" u64 feature that didn't actually do extension promotion, as long as you promise never count more than u64::MAX / 1_000_000 ticks lol
<re_irc> <@j​amesmunns:m​atrix.org> (groundhog is very much my "ship useful, imperfect code for situations where it doesn't matter" policy on display)
<re_irc> <@j​amesmunns:m​atrix.org> I'd never do it this way for safety critical, but for pretty little LED lights? sure, why not.
<re_irc> <@j​amesmunns:m​atrix.org> (and in hot timing loops, I don't actually want u64s)
<re_irc> <@j​amesmunns:m​atrix.org> (but that's STILL probably premature optimization)
<re_irc> <@j​amesmunns:m​atrix.org> anyway, sorry for derailing the conversation.
<re_irc> <@d​irbaio:m​atrix.org> right, for u32 you need it.. for u64 you don't
<re_irc> <@d​irbaio:m​atrix.org> you could make u64 "promote" to u64 :D
<re_irc> <@j​amesmunns:m​atrix.org> sympatron: Because you can't do it with a single linker script (llvm-ld can't do the offset calcs necessary), and it also gets odd with multiple RAM banks or split stacks like you might have with an RTOS.
<re_irc> <@j​amesmunns:m​atrix.org> dirbaio: Yeah, that's what I meant by a `u64-is-fine-i-promise` feature flag that swapped the u128 promotion for just another u64.
<re_irc> <@d​irbaio:m​atrix.org> aah :D
<re_irc> <@j​amesmunns:m​atrix.org> I just like the default to be correct, and you opt-in to the "good enough" choice.
<re_irc> <@j​amesmunns:m​atrix.org> because seriously, u64 microseconds, even picoseconds, is still "heat death of the universe" stuff.
<re_irc> <@j​amesmunns:m​atrix.org> No! I am wrong!
<re_irc> <@j​amesmunns:m​atrix.org> 2 ^ 64 picoseconds is 31 weeks.
<re_irc> <@d​irbaio:m​atrix.org> picoseconds? lol
<re_irc> <@j​amesmunns:m​atrix.org> but 2 ^ 64 microseconds is 585 years.
<re_irc> <@d​irbaio:m​atrix.org> to measure nanoseconds you need 1ghz
<re_irc> <@j​amesmunns:m​atrix.org> Sorry, 585000 years
<re_irc> <@j​amesmunns:m​atrix.org> so, not heat death
<re_irc> <@j​amesmunns:m​atrix.org> but like... your SW isn't gunna be running.
<re_irc> <@d​irbaio:m​atrix.org> maybe not universe death, but probably humankind extinction
<re_irc> <@l​achlansneff:m​atrix.org> Well, so what's the plan for the `Delay` trait?
<re_irc> <@d​irbaio:m​atrix.org> no idea
<re_irc> <@d​irbaio:m​atrix.org> delay_ms/delay_us is not that bad
<re_irc> <@l​achlansneff:m​atrix.org> That's true
<re_irc> <@l​achlansneff:m​atrix.org> I'll go with that for now I guess
<re_irc> <@d​irbaio:m​atrix.org> plus it'd be a shame if blocking adn async were inconsistent
<re_irc> <@d​irbaio:m​atrix.org> if we can think of something better, we should change both
<re_irc> <@j​amesmunns:m​atrix.org> I sort of just want to make an "all embedded-dma hal" crate.
<re_irc> <@j​amesmunns:m​atrix.org> at least to see what it would look like.
<re_irc> <@j​amesmunns:m​atrix.org> maybe even have blanket impls (or conversions?) for the blocking embedded-hal methods.
<re_irc> <@j​amesmunns:m​atrix.org> not sure how you would get "dma && async"
<re_irc> <@j​amesmunns:m​atrix.org> though I feel like that's just "Poll on" the dma? but then you also don't have wakers.
<re_irc> <@j​amesmunns:m​atrix.org> (don't let me start a flame war, this is just idle thoughts, people smarter than me have probably already thought about this)
<re_irc> <@l​achlansneff:m​atrix.org> Can't you get an interrupt when the DMA is finished?
<re_irc> <@d​irbaio:m​atrix.org> HAL has to own the interrupts (SPI/UART/I2C/whatever interrupt, and DMA interrupt if there's a separate one)
<re_irc> <@j​amesmunns:m​atrix.org> yeah... this is one of those areas where I don't think interrupts match 1:1 to the waker model, but they are deceptively close.
<re_irc> <@d​irbaio:m​atrix.org> HAL handles the interrupts, if transfer is done HAL wakes the wkaer
<re_irc> <@j​amesmunns:m​atrix.org> I think embassy takes one of the reasonable paths here.
<re_irc> <@d​irbaio:m​atrix.org> what *doesn't* work is a "await interrupt" abstraction
<re_irc> <@l​achlansneff:m​atrix.org> dirbaio: Why wouldn't that work?
<re_irc> <@d​irbaio:m​atrix.org> 1. usually you have to do "things" in the interrupt, like clearing event flags. You can't simply consider "interrupt happened means transfer's done, ok bye"
<re_irc> <@d​irbaio:m​atrix.org> 2. often you have multiple "things" in the same interrupt
<re_irc> <@d​irbaio:m​atrix.org> example 1: task A is reading from uart and task B is writing. both "rx ready" and "tx ready" events go to the same interrupt.
<re_irc> <@d​irbaio:m​atrix.org> example 2: multiple DMA channels all fire the same interrupt when done
<re_irc> <@l​achlansneff:m​atrix.org> Ah, I thought you were saying that that wasn't possible. But yet, agreed, it wouldn't be useful
<re_irc> <@d​irbaio:m​atrix.org> i don't think other reasonable paths exist to be honest
<re_irc> <@d​irbaio:m​atrix.org> awaiting interrupts doens't work
<re_irc> <@d​irbaio:m​atrix.org> polling futures from interrupts doesn't work either
<re_irc> <@d​irbaio:m​atrix.org> ignoring wakers altogether and busylooping sucks, it's not low power
<re_irc> <@l​achlansneff:m​atrix.org> Hals owning the interrupts definitely would be more batteries included than things are right now I think.
<re_irc> <@j​amesmunns:m​atrix.org> So far for most of my non-blocking stuff, I've had a HAL impl provide an "interrupt" method, that expects to be called in any interrupt (so in an `#[interrupt]` or `#[task]`, depending on what you're doing)
<re_irc> <@d​irbaio:m​atrix.org> that makes sense when no infra for owning interrupts exists...
<re_irc> <@d​irbaio:m​atrix.org> and leaves lots of room to the user to fuck it up
<re_irc> <@d​irbaio:m​atrix.org> user can not wire it up, wire it up to the wrong one..
<re_irc> <@d​irbaio:m​atrix.org> with owned interrupts it's guaranteed at compile time that it's wired up properly
<re_irc> <@l​achlansneff:m​atrix.org> What would that look like?
<re_irc> <@x​groleau:m​atrix.org> Is embassy mature enough for production? I've played with RTIC and it seems pretty complete, though embassy seems very recent. I'm not really familiar with embassy and don't really know how it compares with RTIC.
<re_irc> <@d​irbaio:m​atrix.org> embassy-nrf yep, I'm shipping products with it myself :)
<re_irc> <@d​irbaio:m​atrix.org> embasys-stm32 is still mostly WiP
<re_irc> <@x​groleau:m​atrix.org> Nice, and how is the bluetooth support for nrf chip on rust? I've seen rubble but it's not ready
<re_irc> <@d​irbaio:m​atrix.org> https://github.com/embassy-rs/nrf-softdevice
<re_irc> <@d​irbaio:m​atrix.org> again, i'm shipping products with it
<re_irc> <@l​achlansneff:m​atrix.org> Very neat
<re_irc> <@d​irbaio:m​atrix.org> it's missing some softdevice features (most notably pairing/bonding) but the features that are there are solid
<re_irc> <@d​irbaio:m​atrix.org> and since it uses the softdevice it's all pre-=certified
<re_irc> <@x​groleau:m​atrix.org> Very cool, it's been some time since I've used nordic devices, does the softdevice still trigger a hardfault when using breakpoints?
<re_irc> <@d​irbaio:m​atrix.org> yes :(
<re_irc> <@x​groleau:m​atrix.org> Ohhh :/ it was pretty painful to debug some things even with a logger :(
<re_irc> <@d​irbaio:m​atrix.org> yeah it's quite annoying
<re_irc> <@j​amesmunns:m​atrix.org> defmt should make that easier these days: https://knurling.ferrous-systems.com/tools/
<re_irc> <@j​amesmunns:m​atrix.org> though, still some things that are not perfect, for sure :D
<re_irc> <@d​irbaio:m​atrix.org> breakpoint debugging is doomed with bluetooth stuff though
<re_irc> <@d​irbaio:m​atrix.org> unless you run bluetooth on a separate core
<re_irc> <@d​irbaio:m​atrix.org> because if the core is stopped it won't reply to radio packets and the peer device will think we're gone and disconnect
<re_irc> <@j​amesmunns:m​atrix.org> (same with USB, tbh)
<re_irc> <@x​groleau:m​atrix.org> Yea just started rust, defmt is a godsend. I got some stange characters some times, but I think it's my terminal emulator.
<re_irc> <@d​irbaio:m​atrix.org> the softdevice could handle it more gracefully though...
<re_irc> <@d​irbaio:m​atrix.org> letting the connection fail, instead of crashing
<re_irc> <@j​amesmunns:m​atrix.org> that's why we show logging instead of gdb in our advanced training where we write a minimal USB stack.
<re_irc> <@x​groleau:m​atrix.org> Yea that what I understood at the time. I think the nrf53 got a dual core though
<re_irc> <@x​groleau:m​atrix.org> And how do you feel with RTIC vs Embassy? They seem to try to tackle a similar problem, but with different approach.
<re_irc> <@d​irbaio:m​atrix.org> they're completely different
<re_irc> <@d​irbaio:m​atrix.org> rtic is "make interrupt-driven programming super safe"
<re_irc> <@d​irbaio:m​atrix.org> embassy is "I don't even want to touch interrupts"
<re_irc> <@d​irbaio:m​atrix.org> rtic is great if you have hard realtime stuff, embassy is great for non-realtime stuff like networking
fabic has quit [Ping timeout: 246 seconds]
<re_irc> <@d​irbaio:m​atrix.org> in some applications it might even make sense to use both
<re_irc> <@r​yan-summers:m​atrix.org> Yeah, I'm actually interested in looking into using async for the RTIC `idle` task
<re_irc> <@x​groleau:m​atrix.org> I see, pretty interesting stuff, I'll go check embassy too I guess
<re_irc> <@r​yan-summers:m​atrix.org> Since we have hard real-time requirements in our app (which RTIC resolves), but then lots of timing-insensitive networking when the real-time stuff isn't going
<re_irc> <@r​yan-summers:m​atrix.org> I don't really see any reason why async and RTIC should be mutually exclusive, but I don't have much async experience
<re_irc> <@l​achlansneff:m​atrix.org> I think RTIC had some experiments with async, but I'm not sure where that is right now.
<re_irc> <@j​amesmunns:m​atrix.org> I've used async (like, the bad version, with my `cassette` crate) using the idle loop as an executor.
<re_irc> <@j​amesmunns:m​atrix.org> it actually works really well.
<re_irc> <@j​amesmunns:m​atrix.org> it's waaaaaay dumber than embassy
<re_irc> <@j​amesmunns:m​atrix.org> but I think it could be a reasonable model.
<re_irc> <@l​achlansneff:m​atrix.org> That's essentially what it would be, just with `wfe` when no tasks are pending
<re_irc> <@j​amesmunns:m​atrix.org> esp if rtic had a "native executor" that was a little smarter, or could handle task<->waker events/messages/notifications.
<re_irc> <@l​achlansneff:m​atrix.org> Would there be any interop issues between owned interrupts and RTIC?
<re_irc> <@d​irbaio:m​atrix.org> you can still use custom `#[interrupt]` with RTIC. It only touches the interrupts you tell it to
<re_irc> <@d​irbaio:m​atrix.org> so you're free to do whatever you want with interrupts not used by rtic
<re_irc> <@l​achlansneff:m​atrix.org> True.
<re_irc> <@d​irbaio:m​atrix.org> so yes, it works
<re_irc> <@d​irbaio:m​atrix.org> embassy's works
<re_irc> <@d​irbaio:m​atrix.org> you even get a compile-time error if you try to use the same interrupt with both :D
<re_irc> <@l​achlansneff:m​atrix.org> I wonder if it could be integrated into the way rtic handles the extra interrupts
<re_irc> <@l​achlansneff:m​atrix.org> Since you can hand it an interrupt to use for timers
<re_irc> <@r​yan-summers:m​atrix.org> Or you could just bind it manually - it's not too much work honestly
<re_irc> <@r​yan-summers:m​atrix.org> RTIC supports hardware interrupt sources or software sources - just bind the ISR to your peripheral ISR and you're good to go
<re_irc> <@r​yan-summers:m​atrix.org> Then in the task, just run some schedule updater on the executor
<re_irc> <@l​achlansneff:m​atrix.org> What if we had this trait in embedded-hal:
<re_irc> <@l​achlansneff:m​atrix.org> ```rust
<re_irc> <@l​achlansneff:m​atrix.org> pub trait Duration {
<re_irc> <@l​achlansneff:m​atrix.org> /// A duration of time, no smaller than 1 microsecond.
<re_irc> <@l​achlansneff:m​atrix.org> `DelayMs` and `DelayUs` could be replaced with a single delay trait.
<re_irc> <@l​achlansneff:m​atrix.org> `embedded-time` has its own `Duration` trait, but it's too complex to put in `embedded-hal` imo. And things like `CountDown` would be a lot simpler to use with this trait.
<re_irc> <@a​damgreig:m​atrix.org> shame we can't all just use core's Duration but I guess having the fractional part always be nanos means everyone has to do some maths to get millis or micros
<re_irc> <@a​damgreig:m​atrix.org> but jeez, would simplify having a different duration trait everywhere
<re_irc> <@l​achlansneff:m​atrix.org> Also means that your platform needs to support `u128`
<re_irc> <@l​achlansneff:m​atrix.org> Actually that's wrong
<re_irc> <@l​achlansneff:m​atrix.org> I mean, I'd be all for adding `Duration` to core, if that's what you're suggesting
<re_irc> <@l​achlansneff:m​atrix.org> Wait what?!
<re_irc> <@a​damgreig:m​atrix.org> it's in core
<re_irc> <@l​achlansneff:m​atrix.org> `core` has `Duration`??
<re_irc> <@a​damgreig:m​atrix.org> always has been
<re_irc> <@l​achlansneff:m​atrix.org> Amazing
<re_irc> <@a​damgreig:m​atrix.org> it's a u32 seconds and u64 nanos
<re_irc> <@l​achlansneff:m​atrix.org> Well, lets just use that then
<re_irc> <@d​irbaio:m​atrix.org> problem is that forces maths and u64 on everyone
<re_irc> <@a​damgreig:m​atrix.org> I mean, I think I'm onboard, but a lot of people don't like it because of the u64
<re_irc> <@d​irbaio:m​atrix.org> u32 secs + u64 nanos is even worse
<re_irc> <@a​damgreig:m​atrix.org> sorry, I had it wrong
<re_irc> <@l​achlansneff:m​atrix.org> It has methods to return the time in different units thogh
<re_irc> <@a​damgreig:m​atrix.org> obviously u64 nanos would be senseless
<re_irc> <@a​damgreig:m​atrix.org> yea, but to return the time in different units, you potentially have to do maths on a u64
<re_irc> <@d​irbaio:m​atrix.org> and splitting secs/nanos means you have to mul/div by 1e9 to do maths which is not free
<re_irc> <@a​damgreig:m​atrix.org> I mean, mostly I don't think this is a huge problem, but on lower-resource microcontrollers doing things like division can involve a big bundle of aeabi software impls
<re_irc> <@a​damgreig:m​atrix.org> so there's definitely appetite for a non-u64 version for embedded use
<re_irc> <@a​damgreig:m​atrix.org> (specifically cortex-m0 would suffer this problem due to being armv6 and so not having good support for longs)
<re_irc> <@a​damgreig:m​atrix.org> how bad it is depends a lot on use case though, it would be catastrophic on 8-bit avrs, probably
<re_irc> <@a​damgreig:m​atrix.org> otoh maybe using a u32 for seconds would be asking for trouble :P
<re_irc> <@a​damgreig:m​atrix.org> I think the other half of it is that most use cases in embedded want millis or micros, so dealing with nanos means a conversion every time, but that's a u32 conversion which should not be that expensive
<re_irc> <@l​achlansneff:m​atrix.org> Yeah, that would just be a bitshift and add I think
<re_irc> <@l​achlansneff:m​atrix.org> Well no, not quite a bitshift
<re_irc> <@l​achlansneff:m​atrix.org> But pretty cheap
<re_irc> <@a​damgreig:m​atrix.org> it would be ok if it was a bitshift
<re_irc> <@a​damgreig:m​atrix.org> sadly not though
<re_irc> <@p​inkhatbeard:m​atrix.org> pinkhatbeard: For those following along. I was finally able to get the modem working from Rust on the `nrf9160`. Sometime after I get past this demo on Friday I will make a PR somewhere showing the correct order of operations so hopefully someone else has less banging of their head against the wall.
<re_irc> <@p​inkhatbeard:m​atrix.org> ...now that I've got a working modem....hopefully I still have time to do the actual work of the project!
<re_irc> <@a​damgreig:m​atrix.org> nanos -> micros/millis requires a u32 division which adds at least a few hundred bytes of software routines to a cortex-m0 binary
<re_irc> <@a​damgreig:m​atrix.org> (actually maybe more like 100 bytes... idk)
<re_irc> <@l​achlansneff:m​atrix.org> Maybe time should be represented in terms kibinanoseconds to all these things are bitshifts
<re_irc> <@a​damgreig:m​atrix.org> probably in some cases the compiler can optimise that away but probably not in others
<re_irc> <@a​damgreig:m​atrix.org> hah, binary SI time, dope
<re_irc> <@l​achlansneff:m​atrix.org> Lachlan Sneff: this is a joke btw
<re_irc> <@l​achlansneff:m​atrix.org> But yeah, binary SI time would be epic
<re_irc> <@a​damgreig:m​atrix.org> yea just divide by 1024 instead of 1000, "close enough" and very quick :P
<re_irc> <@l​achlansneff:m​atrix.org> I'm honestly kind of surprised that never was a thing. I would've thought programmers a couple decades would've done that for efficiency
<re_irc> <@a​damgreig:m​atrix.org> swatch really missed a trick
<re_irc> <@a​damgreig:m​atrix.org> could have made https://en.wikipedia.org/wiki/Swatch_Internet_Time use 1024
<re_irc> <@a​damgreig:m​atrix.org> "Instead of hours and minutes, the mean solar day is divided into 1000 parts called ".beats". Each .beat is equal to one decimal minute in the French Revolutionary decimal time system and lasts 1 minute and 26.4 seconds (86.4 seconds) in standard time. Times are notated as a 3-digit number out of 1000 after...
<re_irc> ... midnight." absolutely wild
<re_irc> <@a​damgreig:m​atrix.org> -> "french revolutionary decimal time system"
<re_irc> <@l​achlansneff:m​atrix.org> That's awesome
<re_irc> <@l​achlansneff:m​atrix.org> Unfortunately I think we're stuck with our weird time system
<re_irc> <@l​achlansneff:m​atrix.org> I wonder if there'd be any efficiency gains if `core::time::Duration` represented time as binary, and then converted to regular time when the methods were called.
<re_irc> <@l​achlansneff:m​atrix.org> And additional `as_kibi_*` methods were added
<re_irc> <@l​achlansneff:m​atrix.org> Which people could call if they needed really fast conversation
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 246 seconds]
<re_irc> <@a​damgreig:m​atrix.org> hi @room, meeting time again! We'll start in 5 minutes, agenda's up here: https://hackmd.io/5QOG78xsSvWiAVAilVTexA, please add anything you'd like to announce or discuss
<re_irc> <@l​achlansneff:m​atrix.org> I was going to say we should talk about time/duration stuff for embedded-hal, but I'm not sure what else could be said
<re_irc> <@a​damgreig:m​atrix.org> sorry, a cat jumped in my window.. ok, let's start!
<re_irc> <@a​damgreig:m​atrix.org> quick announcement for cortex-m, we released 0.7.3 which includes a simpler-to-use Delay impl from firefrommoonlight and also fixes building natively on non-x86 hosts
<re_irc> <@a​damgreig:m​atrix.org> there's a few more PRs that might be nice to get merged so perhaps we'll get another minor release out soonish
<re_irc> <@a​damgreig:m​atrix.org> (and I'm working on some sort of DSP intrinsics/functions for it too, hit me up if you're interested in that...)
<re_irc> <@a​damgreig:m​atrix.org> does anyone else have any announcements?
<re_irc> <@d​irbaio:m​atrix.org> cortex-m-cursed-asm :D
<re_irc> <@j​amesmunns:m​atrix.org> Super off topic, but I'm interested in feedback in how people could see a "Ferrous Supported Hardware" board: https://twitter.com/bitshiftmask/status/1412150675904118786 (happy to save this chat until the far end of the meeting)
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: LLVM patch for unsigned saturated add is in BTW. 😉
<re_irc> <@a​damgreig:m​atrix.org> wow, nice work!
<re_irc> <@t​herealprof:m​atrix.org> Still in review.
<re_irc> <@t​hejpster:m​atrix.org> Could I get an update on the roadmap to 1.0 for our key crates? Or a pointer to a document that discusses it?
<re_irc> <@a​damgreig:m​atrix.org> dirbaio: ...would have been a better name :P the DSP thing is what led me down that road but I was expecting to do this in cortex-m itself using the existing asm infra
<re_irc> <@j​amesmunns:m​atrix.org> would it be possible to inline-outline-inline dsp instructions as well?
<re_irc> <@a​damgreig:m​atrix.org> yep
<re_irc> <@a​damgreig:m​atrix.org> well, it would still need the linker plugin lto to get it to inline properly
<re_irc> <@a​damgreig:m​atrix.org> but my experiments so far are fairly compelling
<re_irc> <@a​damgreig:m​atrix.org> like, check this out https://rust.godbolt.org/
<re_irc> <@a​damgreig:m​atrix.org> uh
<re_irc> <@a​damgreig:m​atrix.org> https://rust.godbolt.org/z/35bcG6TrP
<re_irc> <@a​damgreig:m​atrix.org> lotta rust for literally one instruction
<re_irc> <@j​amesmunns:m​atrix.org> yooooooo
<re_irc> <@j​amesmunns:m​atrix.org> that's the happy path :D
<re_irc> <@a​damgreig:m​atrix.org> right??
<re_irc> <@a​damgreig:m​atrix.org> as far as I can tell, cortex-m can provide that unsafe{asm!()} bit in its usual way, and it should inline the same
<re_irc> <@a​damgreig:m​atrix.org> and I've already written all those wrappers in cortex-m too
<re_irc> <@a​damgreig:m​atrix.org> all 119 of them...
<re_irc> <@t​herealprof:m​atrix.org> Yeah, I wouldn't hold my breath for LLVM automatic (and useful) code generation for everything... long way to go.
<re_irc> <@a​damgreig:m​atrix.org> for some use cases I think it's nice to be able to use intrinsics and know you'll get those instructions out the other end, but ultimately having llvm do it is really good
<re_irc> <@t​herealprof:m​atrix.org> I might do a bit more depending on how smoothly that first one goes.
<re_irc> <@t​herealprof:m​atrix.org> Reminds me of the good old times when I did pretty much the same thing for Altivec in gcc. 😀
<re_irc> <@a​damgreig:m​atrix.org> sounds good!
<re_irc> <@a​damgreig:m​atrix.org> so, I didn't get to adding anything else to the agenda, I was just looking over the embedded-hal PRs and I don't think any are _new_ beyond updating the readme, but are there any that want some further discussion?
<re_irc> <@a​damgreig:m​atrix.org> and/or Lachlan Sneff if you did want to chat about Durations, now might be a good time, if anyone else here has thoughts on the matter...
<re_irc> <@l​achlansneff:m​atrix.org> Yeah, I'm interested to hear if anyone has any additional thoughts.
<re_irc> <@l​achlansneff:m​atrix.org> e.g. a `Duration` trait, whether `core::time::Duration` could be changed (in a backwards-compatible way of course) to make it more palatable for embedded.
<re_irc> <@l​achlansneff:m​atrix.org> Stuff like that
<re_irc> <@d​irbaio:m​atrix.org> I don't think `core::time::Duration` is changeable
<re_irc> <@a​damgreig:m​atrix.org> this came up recently in https://github.com/adamgreig/spi-flash-rs/pull/9 too
<re_irc> <@t​hejpster:m​atrix.org> thejpster: ^^ sorry, can't get to the agenda rn
<re_irc> <@a​damgreig:m​atrix.org> which currently uses Duration since it was originally for std, but now wants to be no_std and that's one major pain
<re_irc> <@a​damgreig:m​atrix.org> thejpster: ah, sorry, yep
<re_irc> <@a​damgreig:m​atrix.org> I don't know if we have any document that's up-to-date about it really
<re_irc> <@a​damgreig:m​atrix.org> the update is that essentially we lost a bunch of momentum on key crates after getting r0 to 1.0 and then discovering we should deprecate it all together, and no one has pushed for the various interesting plans around splitting up cortex-m and/or implementing the porcelain/plumbing ideas for cortex-m-rt
<re_irc> <@a​damgreig:m​atrix.org> right now I'd say the most momentum is on embedded-hal 1.0
<re_irc> <@a​damgreig:m​atrix.org> `nb` also got to 1.0 and probably we'll also want to deprecate it once futures become suitably stable...
<re_irc> <@y​atekii:m​atrix.org> adamgreig: yesyes DSP is great :)
<re_irc> <@l​achlansneff:m​atrix.org> adamgreig: And this should wait for GATs to be stabilized imo
<re_irc> <@a​damgreig:m​atrix.org> well, we can always add futures in to 1.1 or whatever, so does it need to block 1.0?
<re_irc> <@a​damgreig:m​atrix.org> (or rather, stabilise them from out of an experimental feature flag)
<re_irc> <@a​damgreig:m​atrix.org> in any event that's where a lot of momentum is going
<re_irc> <@l​achlansneff:m​atrix.org> I guess not, but it does feel weird to go to 1.0 with the plan to depreciate the `nb` module later
<re_irc> <@l​achlansneff:m​atrix.org> Like, 1.0 should be for when you've sorted all that out
<re_irc> <@l​achlansneff:m​atrix.org> in my opinion
<re_irc> <@t​herealprof:m​atrix.org> Let's just say 1.0 is long overdue anyway...
<re_irc> <@a​damgreig:m​atrix.org> perhaps! but I suspect it will be some time before we want to remove it all together, and not much harm in having it around in the nonblocking module alongside blocking and futures?
<re_irc> <@l​achlansneff:m​atrix.org> adamgreig: I suppose no harm, true!
<re_irc> <@a​damgreig:m​atrix.org> if there are people interested in pushing for cortex-m and cortex-m-rt to get to 1.0 as well, that could be cool, there were a lot of interesting ideas in the last year or two but I don't think there's been much experimentation
<re_irc> <@a​damgreig:m​atrix.org> dirbaio, have you found they mostly work for embassy style stuff too, or do you end up reimplementing a lot of that?
<re_irc> <@j​amesmunns:m​atrix.org> IMO if we had shipped 1.0 a year ago, it would have been a reasonable amount of time elapsed to start talking about 2.0 :)
<re_irc> <@l​achlansneff:m​atrix.org> Ship 1.0 now then, and then talk about 2.0 once all the futures experimentation has died down?
<re_irc> <@d​irbaio:m​atrix.org> the async traits? they're very similar to the embassy ones, embassy will switch over when they're out
<re_irc> <@a​damgreig:m​atrix.org> dirbaio: sorry, I mean the cortex-m and cortex-m-rt crates
<re_irc> <@t​hejpster:m​atrix.org> My view is, you can (and people do) ship production code with these crates. So we should call it 1.0.
<re_irc> <@a​damgreig:m​atrix.org> yep, it's a fair point! we've certainly been _extremely_ reluctant to finally say "ok, we like this design enough" and "those ideas on the roadmap are not happening soon enough to be worth it"
<re_irc> <@a​damgreig:m​atrix.org> given how stable the cortex-m and cortex-m-rt APIs have been for the last 2 years or so I think in retrospect it would have been fair to call it 1.0
<re_irc> <@a​damgreig:m​atrix.org> but nevertheless people do still have some big and very disruptive ideas about ways to break them apart and put them back together better.
<re_irc> <@a​damgreig:m​atrix.org> not that that necessarily precludes releasing 1.0 first, of course
<re_irc> <@t​hejpster:m​atrix.org> Exactly. That sounds like a good V2
<re_irc> <@a​damgreig:m​atrix.org> I think at the least we'd probably want to try and resolve some open PRs and issues though, since a few are fairly boring breaking changes that would suck to be stuck with til 2.0
<re_irc> <@a​damgreig:m​atrix.org> and it turns out in the last 18 months or so there's not been much energy to spend on that
<re_irc> <@j​amesmunns:m​atrix.org> If it's breaking changes, we'll have to break anything anyway
<re_irc> <@j​amesmunns:m​atrix.org> "if it hurts, do it more often"
<re_irc> <@t​hejpster:m​atrix.org> A 1.0 also gives you a release branch you can make hot fixes on
<re_irc> <@t​hejpster:m​atrix.org> Whilst main gets the wild stuff
<re_irc> <@a​damgreig:m​atrix.org> we have that for 0.5, 0.6, 0.7 too :P
<re_irc> <@t​hejpster:m​atrix.org> So you shipped a 1.0 but didn't call it that
<re_irc> <@j​amesmunns:m​atrix.org> :D
<re_irc> <@j​amesmunns:m​atrix.org> let's just ship 2.0 and call it done
<re_irc> <@a​damgreig:m​atrix.org> I mean, we could just multiply all the version numbers by ten and I guess it wouldn't fundamentally change anything
<re_irc> <@j​amesmunns:m​atrix.org> hop right over the awkward "1.x" forever argument.
<re_irc> <@a​damgreig:m​atrix.org> cortex-m v7 babeeeee
<re_irc> <@a​damgreig:m​atrix.org> very confusing given it supports armv6 and armv8 too
<re_irc> <@t​hejpster:m​atrix.org> adamgreig: I think what it changes is external perceptions about whether we rate what we've made
<re_irc> <@j​amesmunns:m​atrix.org> "cortex-m-rt v6.0.0-TDMI"
<re_irc> <@t​hejpster:m​atrix.org> But yes, our models and workflows all still work
<re_irc> <@a​damgreig:m​atrix.org> I could imagine a concerted effort to push e.g. cortex-m-rt towards 1.0 by trying to nail a few last issues, make a few last hard decisions, then press go
<re_irc> <@t​hejpster:m​atrix.org> cortex-m 11zjf-s
<re_irc> <@a​damgreig:m​atrix.org> that's probably easiest to start with, since it has zero dependencies except its own macros, which in turn depend on >1.0 versions of quote, syn, and proc-macro2
<re_irc> <@a​damgreig:m​atrix.org> cortex-m is a little trickier given the current dep on bare-metal 0.2 which we can't easily bump to 1.0 without removing cortex_m::interrupt::Mutex which would be quite an exciting breaking change for everyone, and volatile-register 0.2, bitfield 0.13, embedded-hal 0.2... shrug
<re_irc> <@a​damgreig:m​atrix.org> I don't personally mind too much the idea of releasing a 1.0 crate with <1.0 dependencies, but I understand in principle it's recommended not to?
<re_irc> <@e​ldruin:m​atrix.org> no <1.0 dependencies for stuff in the public api is the requirement IIRC
<re_irc> <@t​hejpster:m​atrix.org> porcelain / plumbing. To me, version numbers speak to the external interface
<re_irc> <@d​irbaio:m​atrix.org> adamgreig: Yeah, works fine! the only thing it's reimplementing is `#[interrupt]` for registering owned interrupts, because it breaks when reexported
<re_irc> <@a​damgreig:m​atrix.org> ah, ok, so we could feature-gate the e-h impls until e-h 1.0, not sure about Mutex but maybe vendor it, I don't think we expose volatile-register or bitfield (and anyway we should replace volatile-register due to the dereferenceablegate thing)
<re_irc> <@a​damgreig:m​atrix.org> so probably not a million miles away from being able to 1.0 cortex-m either, except generally it having a lot more open issues and PRs that should probably get looked at
<re_irc> <@a​damgreig:m​atrix.org> thejpster: sure, but that external interface is a big part of what we'd be ripping up and replacing
<re_irc> <@d​irbaio:m​atrix.org> for CMRT 1.0 i'd remove the "resources" thing though
<re_irc> <@a​damgreig:m​atrix.org> i want a shiny new toilet to sit on, not just a larger sewage pipe or whatever the metaphor is
<re_irc> <@t​herealprof:m​atrix.org> LOL
<re_irc> <@a​damgreig:m​atrix.org> dirbaio: yea.. have you seen the new RTIC resources?
<re_irc> <@a​damgreig:m​atrix.org> but perhaps it just shouldn't go in cortex-m-rt as it stands today
<re_irc> <@d​irbaio:m​atrix.org> if you want resources you use RTIC or some other abstraction built "on top of" cmrt
<re_irc> <@d​irbaio:m​atrix.org> no need to have it in cmrt itself
<re_irc> <@a​damgreig:m​atrix.org> maybe, but since cmrt does provide the basic interrupt registration, it doesn't seem totally wild for the runtime to also provide interrupt-local resources like that
<re_irc> <@a​damgreig:m​atrix.org> I think it's a balance of whether it's worth the extra complexity in the macros and potential for confusion
<re_irc> <@a​damgreig:m​atrix.org> (and perhaps it's not worth the balance, but doesn't mean there's no use in the idea being in c-m-rt, imo)
<re_irc> <@d​irbaio:m​atrix.org> imo it's "too opinionated"
<re_irc> <@t​halesfragoso:m​atrix.org> how is it today for interrupts ? do they also gain a resource struct or the old static mut transformation ?
<re_irc> <@a​damgreig:m​atrix.org> I think that's compelling, and after all you can always put your static resource inside your ISR without c-m-rt's help, and you just need to use unsafe to access it or use something with interior mutability (which could be provided by another crate)
<re_irc> <@a​damgreig:m​atrix.org> the static mut transform
<re_irc> <@a​damgreig:m​atrix.org> there is a draft PR with a proposed alternative in https://github.com/rust-embedded/cortex-m-rt/pull/313 but it's more or less the same idea
<re_irc> <@d​irbaio:m​atrix.org> also the cmrt resources don't cover the most common usecase which is moving stuff from main to interrupt
<re_irc> <@t​halesfragoso:m​atrix.org> I think the transform is really unexpected
<re_irc> <@d​irbaio:m​atrix.org> imo there's 2 things
<re_irc> <@d​irbaio:m​atrix.org> 1. the static mut transform is super unintuitive indeed. can be fixed by switching to another syntax, like that PR does, which looks much nicer
<re_irc> <@d​irbaio:m​atrix.org> 2. imo cmrt is the wrong place for a resource abstraction in the first place, no matter how nice the syntax is...
<cr1901> What's the static mut transform (sorry, not up to date w/ cmrt land lately)?
<re_irc> <@a​damgreig:m​atrix.org> this is where you type ```#[interrupt] fn SysTick() { static mut CTR: u32 = 0u32; *ctr++; }```
<re_irc> <@a​damgreig:m​atrix.org> and you wonder " 🤔 why don't i need unsafe"
<re_irc> <@a​damgreig:m​atrix.org> and it's because c-m-rt's interrupt macro has rewritten your handler through a trampline to instead receive CTR: &mut u32, a reference to the static mut, which you can now safely write to
<re_irc> <@d​irbaio:m​atrix.org> and you try to pass that to something requiring `&'static mut` and it doesn't work, where it'd work normally
<re_irc> <@a​damgreig:m​atrix.org> it's not a &'static mut is why :P
<re_irc> <@t​halesfragoso:m​atrix.org> "And also, why if I put a couple lines down I now need unsafe"
<cr1901> > "And also, why if I put a couple lines down I now need unsafe"
<cr1901> Which couple of lines?
<re_irc> <@a​damgreig:m​atrix.org> the macro only transforms static muts at the start of a function
<re_irc> <@t​halesfragoso:m​atrix.org> it has to be the first thing in the interrupt for it to work
<re_irc> <@a​damgreig:m​atrix.org> so if you have anything else before one, it's left alone
<cr1901> And I remember this feature, I don't think I ever used it
<re_irc> <@a​damgreig:m​atrix.org> indeed, as dirbaio points out it's not actually that useful
<re_irc> <@a​damgreig:m​atrix.org> since you can't then move that resource out of the interrupt handler
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: Huh?
<re_irc> <@t​halesfragoso:m​atrix.org> It's somewhat useful to keep some state in the interrupt, like led on or off or something
<re_irc> <@t​halesfragoso:m​atrix.org> but it isn't that nice to be worth it
<re_irc> <@a​damgreig:m​atrix.org> yea, that's exactly what it's useful for, but...
<cr1901> I use Cells for everything mostly and just eat the cost
<cr1901> On msp430 the cost is reduced because you get a free CriticalSection token at the beginning of your interrupt
<re_irc> <@t​herealprof:m​atrix.org> Of course you can move things in and out of those static muts. I'm doing that all the time.
<re_irc> <@a​damgreig:m​atrix.org> therealprof: the interrupt handler gets given a &mut with a lifetime bound to the interrupt, so iirc you can't move that reference out or share it in any way
<re_irc> <@a​damgreig:m​atrix.org> the ones declared inside the interrupt handlers, which the macro transforms?
<re_irc> <@a​damgreig:m​atrix.org> i mean, of course you can mutate them, so you can store things in them for later or copy/move values out of them
<re_irc> <@a​damgreig:m​atrix.org> but you can't give anything else a reference to them
<cr1901> You can't access them from another thread, which is usually want you want
<re_irc> <@t​halesfragoso:m​atrix.org> cr1901: but Cell isn't Sync
<re_irc> <@t​herealprof:m​atrix.org> Nope, but you can make it an `Option` and then permanently move something out of a `Mutex` protected Cell into the interrupt handler.
<cr1901> thalesfragoso: Mutex<Cell<>>*
<re_irc> <@a​damgreig:m​atrix.org> thejpster: so this sort of breaking change is the sort of thing I had in mind for "a few things that would need wrapping up before 1.0"
<cr1901> therealprof: Could I see an example? I'm interested :o
<re_irc> <@t​herealprof:m​atrix.org> therealprof: Or also move it back if you're so inclined.
<re_irc> <@t​hejpster:m​atrix.org> This all sounds very good. And I know each crate has tickets, some labelled 1.0
<re_irc> <@t​halesfragoso:m​atrix.org> oh yeah, that's another use case
<re_irc> <@a​damgreig:m​atrix.org> therealprof: oh, I see! So you'd have a mutex cell at global scope, move a peripheral into it from main, then in the interrupt you first move it into the interrupt;
<re_irc> <@t​hejpster:m​atrix.org> But does EWG track this in any way?
<re_irc> <@t​hejpster:m​atrix.org> Or do we have the exact same convo next week.
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: Yes, that.
<re_irc> <@t​hejpster:m​atrix.org> Or next year.
<re_irc> <@t​halesfragoso:m​atrix.org> it's useful, but just one unsafe away
<re_irc> <@a​damgreig:m​atrix.org> beyond issues in repos and people's general working knowledge, I don't think we have much coherent cross-repo planning documents, no
<re_irc> <@e​ldruin:m​atrix.org> wasn't there an issue in the wg repo tracking the 1.0 status of the main projects?
<re_irc> <@e​ldruin:m​atrix.org> got it https://github.com/rust-embedded/wg/issues/383
<re_irc> <@t​halesfragoso:m​atrix.org> Maybe if we get the new resources syntax, then I would be more inclined to leave it there
<re_irc> <@l​achlansneff:m​atrix.org> What does the new resources syntax look like?
<re_irc> <@t​halesfragoso:m​atrix.org> ```rust
<re_irc> <@t​halesfragoso:m​atrix.org> #[exception(SysTick)]
<re_irc> <@t​halesfragoso:m​atrix.org> #[init(0)]
<re_irc> <@t​halesfragoso:m​atrix.org> fn on_systick(
<re_irc> <@l​achlansneff:m​atrix.org> neat
<re_irc> <@t​halesfragoso:m​atrix.org> but it looks like you're initing the reference to zero though, just noticed that
<re_irc> <@l​achlansneff:m​atrix.org> can it take any expr?
<cr1901> I'm w/ dirbaio on this one... this cmrt doesn't seem like the right place for these
<re_irc> <@t​halesfragoso:m​atrix.org> Lachlan Sneff: Only consts
<re_irc> <@t​halesfragoso:m​atrix.org> but probably a const fn ? not sure, I haven't looked that much at the PR
<re_irc> <@l​achlansneff:m​atrix.org> thalesfragoso: Maybe it should be `#[init(value = 0)]` then
<re_irc> <@p​er.lindgren:m​atrix.org> You may have a look at the new RTIC syntax, where the `static mut` transform is now gone. Instead you give the init value in the attribute (to the function item).
<re_irc> <@p​er.lindgren:m​atrix.org> (The idea is that the function body should remain pure Rust.)
<re_irc> <@a​damgreig:m​atrix.org> yea, I think it's quite similar to the RFC in c-m-rt, and motivated by the same reasoning
<re_irc> <@a​damgreig:m​atrix.org> but perhaps if people want these things they should be gently encouraged to check out rtic
SomeWeirdAnon has joined #rust-embedded
<re_irc> <@d​irbaio:m​atrix.org> who here is using the cmrt static mut transform?
<re_irc> <@t​herealprof:m​atrix.org> Every cmrt user?
<re_irc> <@t​halesfragoso:m​atrix.org> dirbaio: Used on the past for simple code
<re_irc> <@t​halesfragoso:m​atrix.org> where I didn't really needed RTIC
<re_irc> <@a​damgreig:m​atrix.org> yea, similarly
<re_irc> <@a​damgreig:m​atrix.org> like, last week, https://github.com/adamgreig/ledeaf/blob/master/firmware/src/main.rs#L141
<re_irc> <@p​er.lindgren:m​atrix.org> Maybe its better to keep CMRT just as a simple way of binding interrupts, no more no less.
<re_irc> <@a​damgreig:m​atrix.org> per.lindgren: well, it also provides the r0 memory init, linker script, etc
<re_irc> <@a​damgreig:m​atrix.org> i.e. it has to do a bunch more than just interrupt handling
<re_irc> <@p​er.lindgren:m​atrix.org> (and startup code, not to forget)
<re_irc> <@a​damgreig:m​atrix.org> but yea, crucially maybe keep the interrupt resource management out of it
<re_irc> <@a​damgreig:m​atrix.org> I wonder if we could make a crate that provides the same thing outside of c-m-rt
<re_irc> <@a​damgreig:m​atrix.org> (safely)
<re_irc> <@a​damgreig:m​atrix.org> (not necessarily "us" "we")
<re_irc> <@t​halesfragoso:m​atrix.org> creating it outside just for that doesn't seem that good, now I'm balancing to have it on cm-rt, hah
<re_irc> <@t​halesfragoso:m​atrix.org> we already have the interrupt macro in place, but again, pointing people to RTIC isn't half bad
<re_irc> <@t​herealprof:m​atrix.org> It's not great but it is there and it works.
<re_irc> <@p​er.lindgren:m​atrix.org> The upcoming RTIC 0.6.x will still be monolithic (i.e., provide all functionality out the box). We are discussing a modular approach, (multi-stage pipelined architecture), where the last stage is a very simple extension of CMRT, basically just the resource management.
<re_irc> <@t​herealprof:m​atrix.org> Getting it of it without alternative is not an option for me.
<re_irc> <@t​halesfragoso:m​atrix.org> With the new syntax I wouldn't oppose it
<re_irc> <@a​damgreig:m​atrix.org> therealprof: what if the replacement was a simple external crate just for providing safe interrupt-handler resources?
<re_irc> <@t​herealprof:m​atrix.org> thalesfragoso: Do we still get to use the "move-out-of-mutex" trick with that?
<re_irc> <@t​halesfragoso:m​atrix.org> therealprof: sure
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: That sounds too god to be true. I'd absolutely take it. 😉
<re_irc> <@d​irbaio:m​atrix.org> yeah the resources can be a `macro_rules!`on top of CMRT, doesn't need to be in CMRT
<cr1901> ^These don't require proc-macros?
<re_irc> <@a​damgreig:m​atrix.org> the new syntax adds like 600 lines of fairly complicated proc macro code to c-m-rt, whereas getting rid of the current resource handling would remove a bunch of the existing complexity, which is kinda nice
<re_irc> <@d​irbaio:m​atrix.org> the static mut transform did require proc macros
<re_irc> <@d​irbaio:m​atrix.org> the new syntax might be doable with declarative macros as it's less "horrible hack"?
<re_irc> <@t​halesfragoso:m​atrix.org> dirbaio: you need at least a trampoline to reduce the borrow, no ?
<re_irc> <@t​herealprof:m​atrix.org> thalesfragoso: Ah, so it's basically taking the function arguments and turning them into `static muts` instead out of the top of the body? That'd work.
<re_irc> <@a​damgreig:m​atrix.org> well, it sounds like it might at least be an interesting avenue for investigation
<re_irc> <@a​damgreig:m​atrix.org> we're out of time (in fact a bit overtime) for the meeting, thanks for your input everyone!
<re_irc> <@t​halesfragoso:m​atrix.org> thanks adam
<re_irc> <@a​damgreig:m​atrix.org> thejpster: I'm not sure how close we came to forward progress though... I think mostly what we need is some enthusiasm injected towards the goal, and probably c-m-rt is the first place to try and tackle that just because ti's smaller and simpler?
<re_irc> <@a​damgreig:m​atrix.org> thalesfragoso: I couldn't immediately think of any way to do it without a trampoline, but I guess maybe you could have the macro_rules create the trampline if it contained the whole ISR? bit gross though
<re_irc> <@a​damgreig:m​atrix.org> wonder how far into the rabbit hole you'd go trying to make this crate before you realised you'd rewritten RTIC
<re_irc> <@l​achlansneff:m​atrix.org> Should `Error` associated types require `Debug` so that `.unwrap` can work on them without extra bounds?
<re_irc> <@d​irbaio:m​atrix.org> requiring it is annoying
<re_irc> <@d​irbaio:m​atrix.org> if users want to unwrap they can do `where T: Uart, T::Error: Debug`
<re_irc> <@l​achlansneff:m​atrix.org> Is there documentation on rational for `InputPin` returning a `Result`?
<re_irc> <@a​damgreig:m​atrix.org> https://github.com/rust-embedded/embedded-hal/pull/108 might be relevant, but basically almost all the traits are fallible
<re_irc> <@a​damgreig:m​atrix.org> because for example your inputpin might be on linux, or implemented over an i2c gpio expander, or otherwise might be able to fail and return an error
<re_irc> <@a​damgreig:m​atrix.org> implementations that directly access a hardware peripheral (like gpio on most mcus) can't fail, but the trait covers more than that, so returns a result
<re_irc> <@l​achlansneff:m​atrix.org> Makes sense
<re_irc> <@l​achlansneff:m​atrix.org> Thanks
<re_irc> <@s​ympatron:m​atrix.org> Is there a difference between `struct T;` and `struct T(());`?
<re_irc> <@j​amesmunns:m​atrix.org> Yes, they are different types, but they are both zero sized
<re_irc> <@j​amesmunns:m​atrix.org> Like, they are not exchangeable, but the net effect is the same.
<re_irc> <@d​irbaio:m​atrix.org> `struct T(());` cannot be constructed from outside the current mod/crate (you'd need `struct T(pub ());` for that
<re_irc> <@j​amesmunns:m​atrix.org> Ahhhh good call
<re_irc> <@j​amesmunns:m​atrix.org> I forgot about visibility
<re_irc> <@d​irbaio:m​atrix.org> I find writing it like this is a bit more readable
<re_irc> <@d​irbaio:m​atrix.org> _private: (),
<re_irc> <@d​irbaio:m​atrix.org> }
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> struct T {
<re_irc> <@s​ympatron:m​atrix.org> That explains why you are using it here https://github.com/embassy-rs/embassy/blob/master/embassy-macros/src/lib.rs#L195
<re_irc> <@d​irbaio:m​atrix.org> yep
<re_irc> <@d​irbaio:m​atrix.org> lol
<re_irc> <@d​irbaio:m​atrix.org> criticized readability of it... then it turns out it's my own code 🤣
<re_irc> <@d​irbaio:m​atrix.org> 🙈
<re_irc> <@s​ympatron:m​atrix.org> btw your `interrupt::take!` macro is quite interesting. Do you know if any other hal/crate has something like that?
<re_irc> <@y​atekii:m​atrix.org> dirbaio: we all suffer from that; means we improve; which is great :)
neceve has quit [Ping timeout: 240 seconds]
<re_irc> <@a​damgreig:m​atrix.org> dirbaio: hmm, I wonder if a procmacro could just add a lifetime like this to allow safe static mut access https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b070d9fa729f23cfa1f40c83bdaa48dc
<re_irc> <@a​damgreig:m​atrix.org> i'm not sure you can do it with a macro_rules
<re_irc> <@a​damgreig:m​atrix.org> you need to write the outer lifetime yourself otherwise a cheeky user could put `<'a: 'static>` lol
<re_irc> <@a​damgreig:m​atrix.org> annoying though, I really want to be able to just decorate the resource, not the function itself
<re_irc> <@d​irbaio:m​atrix.org> so the macro would only generate the "statik" thing?
<re_irc> <@a​damgreig:m​atrix.org> well I'd like that but I don't think it works with what's in that playground
<re_irc> <@a​damgreig:m​atrix.org> because you can't trust the user to have provided a suitable lifetime
<re_irc> <@d​irbaio:m​atrix.org> not just that, you can't trust the user to call that macro only in an irq handler 🤣
<re_irc> <@a​damgreig:m​atrix.org> sure, that too, although
<re_irc> <@d​irbaio:m​atrix.org> they could call it in a normal functoin and call it reentrantly
<re_irc> <@a​damgreig:m​atrix.org> mmm, yea
<re_irc> <@a​damgreig:m​atrix.org> yea, forgot the function still must not be callable from anywhere else
<re_irc> <@a​damgreig:m​atrix.org> so you probably do need to create the function inside the macro one way or another
<re_irc> <@a​damgreig:m​atrix.org> might avoid the trampoline this way though
<re_irc> <@a​damgreig:m​atrix.org> and generating the function from a macro-by-example is a bit boring so i suspect it will have to be a proc macro one way or another
<re_irc> <@d​irbaio:m​atrix.org> proc macros are definitely more *exciting* :)
<re_irc> <@a​damgreig:m​atrix.org> only way the proc macro can really be sure it's also making an ISR is probably for it to call the c-m-rt interrupt macro itself, too, at which point it seems less and less useful to put it into its own crate instead of having it be in c-m-rt :/
<re_irc> <@a​damgreig:m​atrix.org> maybe it could at least just see that you've also put #[interrupt] on it
rektide has joined #rust-embedded
<cr1901> I'll let the ARM ppl fight it out and take inspiration from the decisions :)
<re_irc> <@t​herealprof:m​atrix.org> Hm, weird. Mutably iterating over an `Option` produces smaller code than simply `as_mut`ing it...
<re_irc> <@l​achlansneff:m​atrix.org> therealprof: uhhh