starblue3 has joined #rust-embedded
starblue2 has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
<re_irc> <@r​eecestevens24:m​> Hi rust-embedded team! I am trying to find information on this and not sure if it's the right place to ask-- but does anyone know if the `cortex-m` project is planning on putting out a minor release anytime soon? They fixed a bug a few months ago that prevents the `cortex-m` crate from compiling when being...
<re_irc> ... built on a Raspberry Pi ( However, it hasn't hit a release yet. Just wondering if anyone knew of any plans to push a minor release in the short term or if I should look into a workaround for now. I am using a raspberry pi as a CI server, and part of the test run is compiling and...
<re_irc> ... running the unit tests directly on the pi, so until I find a solution all my unit tests are failing to compile 😬
<re_irc> <@r​eecestevens24:m​> I've tried working around by using the git repository as the dependency source, but there's so many other libraries that depend on different versions of cortex-m that I keep getting version resolution errors.
<re_irc> <@w​illeml:m​> Note sure if you mean the h7 or f7, but I am wondering what I am doing wrong here, 0xC7 is the chip erase instruction
Wetmelon has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
Wetmelon has quit [Ping timeout: 264 seconds]
fabic has quit [Ping timeout: 268 seconds]
<re_irc> <@r​yan-summers:m​> I have no idea. Like I said, I used the QSPI as a 4-channel SPI. I never had to deal with external flash instructions etc.
<re_irc> <@r​yan-summers:m​> Sorry :s
<re_irc> <@r​yan-summers:m​> That's a question for adamgreig - in the meantime, you can try using `cargo patch` to patch the cortex-m dependency for all your downstream depends from the git repository as well....
<re_irc> <@e​vils.devils:m​> i'm trying out the roger clark stm32duino one, but it seems the firmware doesn't run when flashed via that (does work when flashed via SWD)
<re_irc> <@e​vils.devils:m​> hi, anyone using an USB DFU bootloader on an STM32F103?
<re_irc> <@g​rantm11235:m​> You need to edit your linker file so that the flash section starts at `0x08002000` instead of `0x08000000`
<re_irc> <@e​vils.devils:m​> hmm, was just wondering if it could be something like that
<re_irc> <@e​vils.devils:m​> any way to do that automatically so i can use both cargo embed and dfu?
<re_irc> <@g​rantm11235:m​> Not that I know of, but I never really looked into it
<re_irc> <@e​vils.devils:m​> oh had to `cargo clean` to get the new memory.x address to be used
<re_irc> <@e​vils.devils:m​> hmm, shouldn't this still work via SWD, just waste some memory
<re_irc> <@e​vils.devils:m​> nope, doesn't work
<re_irc> <@g​rantm11235:m​> I believe that cargo-embed does a full erase including the bootloader, so there is nothing at `0x08000000` for the chip to execute
<re_irc> <@e​vils.devils:m​> here's the project so far
<re_irc> <@e​vils.devils:m​> would be nice if i could pass the `0x08002000` in via the Makefile.toml where i'm putting the DFU stuff
<re_irc> <@e​vils.devils:m​>
<re_irc> <@t​iwalun:m​> cargo-embed should not erase the bootloader, it only erases the parts which you program. But you need to set the `--nmagic` linker flag, otherwise it can happen by accident. See...
<re_irc> <@e​vils.devils:m​> hmm, where does it get the magic number?
<re_irc> <@e​vils.devils:m​> i may have misunderstood xD
<re_irc> <@t​iwalun:m​> Without `--nmagic`, the linker tries to align everything to a page size, which is defined as 0x10000. This means that when you store something at 0x08002000, cargo-embed will start erasing at 0x08000000 .
<re_irc> <@t​iwalun:m​> The actual code is still at the right place, just the ELF headers are different.
<re_irc> <@e​vils.devils:m​> jup, now both seem to work
<re_irc> <@e​vils.devils:m​> thanks
<re_irc> <@e​vils.devils:m​> hmm, i think i'm out of excuses to not write Rust again
* re_irc @e​vils.devils:m​ grabs a soldering iron
neceve has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 244 seconds]
dreamcat4 has joined #rust-embedded
nemexis has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Remote host closed the connection]
ni has quit [Remote host closed the connection]
fabic has joined #rust-embedded
ni has joined #rust-embedded
rjframe has joined #rust-embedded
wose has joined #rust-embedded
<re_irc> <@l​achlansneff:m​> What does the future of async look like in embedded-hal? Right now, it looks like nb is all about busy waiting.
<re_irc> <@d​iondokter:m​> I believe the plans are to have an async module. But async traits are not a thing yet, so I don't know if we'll wait on that or do it another way
<re_irc> <@d​iondokter:m​> Lachlan Sneff:
<re_irc> <@l​achlansneff:m​> Right, they rely on GATs, which are apparently working well enough for prototyping at this point.
<re_irc> <@l​achlansneff:m​> A lot of embedded-hal would need redesigning.
<re_irc> <@d​iondokter:m​> Not really redesigning. Just another module with new async interfaces. The blocking interfaces are still just fine
<re_irc> <@l​achlansneff:m​> And would the non-blocking interfaces switch to async?
<re_irc> <@d​iondokter:m​> In practise? Probably. But I think the HAL will keep them around for a long time for Backwards Compatibility reasons
tech has joined #rust-embedded
<re_irc> <@l​achlansneff:m​> :/
<re_irc> <@l​achlansneff:m​> Futures are such a big change, it should cut a breaking change IMO
tech has quit [Client Quit]
nemexis has quit []
<re_irc> <@d​iondokter:m​> But why if that's not necessary?
<re_irc> <@d​iondokter:m​> All the HALs can decide which traits they implement and which not, so IMO it doesn't create an unreasonable burden for HAL devs
<re_irc> <@d​iondokter:m​> What do you think would be the downside for leaving NB and blocking in?
<re_irc> <@d​iondokter:m​> You can just add a bunch of new async traits and have the same result.
thejpster has joined #rust-embedded
<re_irc> <@t​hejpster:m​> Is anyone going to register #rust-embedded on Libera?
<re_irc> <@h​ifi:v​> it's not registered?
<re_irc> <@h​ifi:v​> apparently not, I think it's who manages the IRC side
<re_irc> <@a​damgreig:m​> I'd love to register it and am asking the various people who need to collaborate for it to happen but not a fast process
<re_irc> <@a​damgreig:m​> Same issue you have with retro thejpster
<re_irc> <@t​hejpster:m​> Yeah, but you're an actual WG
<re_irc> <@t​hejpster:m​> and also, we registered the ## version as a backup
<re_irc> <@a​damgreig:m​> Yes, pursuing the various process to get it registered as an actual wg
<re_irc> <@t​hejpster:m​> Cool
<re_irc> <@j​duchniewicz:m​> Will the communication move over to Zulip then?
<re_irc> <@l​achlansneff:m​> That's true, switching completely over does put a burden on the HAL devs.
<re_irc> <@l​achlansneff:m​> The reason why I suggested breaking the api was to avoid a split in the ecosystem.
<re_irc> <@d​irbaio:m​> IMO nb should be deprecated once async is ready, yup
<re_irc> <@d​irbaio:m​> embedded-hal is very delicate though, major-bumping it splits the ecosystem
<re_irc> <@d​irbaio:m​> because "embedded_hal v1 InputPin" is a different trait than "embedded_hal v2 InputPin"
<re_irc> <@d​irbaio:m​> even if the trait is identical
<re_irc> <@d​irbaio:m​> so if a driver requires v1 and a hal implements v2, you can't use them together
<re_irc> <@l​achlansneff:m​> Same thing happened with the futures ecosystem irrc
<re_irc> <@l​achlansneff:m​> It sorted itself out eventually
<re_irc> <@d​irbaio:m​> yeah, but that was because they did changes to the Future trait itself to improve it
<re_irc> <@d​irbaio:m​> removing nb would be a major release that removes nb traits and leaves the blocking traits unchanged
<re_irc> <@d​irbaio:m​> but that'd still split the blocking traits ecosystem
<re_irc> <@l​achlansneff:m​> Speaking of, there are a lot of traits in `embedded-hal::blocking` that I think should be async.
<re_irc> <@l​achlansneff:m​> They're blocking now because it wouldn't make sense for them to be async with nb
<re_irc> <@d​irbaio:m​> yeah the plan is to add async flavored traits alongside
<re_irc> <@d​irbaio:m​> so you can use uart both blocking or async
<re_irc> <@l​achlansneff:m​> I see, okay.
<re_irc> <@d​irbaio:m​> there's already some traits that have both blocking and nb flavors
<re_irc> <@l​achlansneff:m​> What should the async module be called.
<re_irc> <@l​achlansneff:m​> Since requiring raw idents isn't ideal
<re_irc> <@d​irbaio:m​> probably `futures`
<re_irc> <@l​achlansneff:m​> Hmm
<re_irc> <@l​achlansneff:m​> Honestly, `nb` would be the perfect name :P
<re_irc> <@d​irbaio:m​> hahaha
<re_irc> <@d​irbaio:m​> well that'd be very confusing
<re_irc> <@l​achlansneff:m​> I'm doing a bit of work to try to write some async versions of the blocking traits and it's rough
<re_irc> <@l​achlansneff:m​> even with gats and min_type_alias_impl_trait
<re_irc> <@l​achlansneff:m​> All the nb traits were easy, but the blocking traits are not
<re_irc> <@l​achlansneff:m​> Oop, they work
<re_irc> <@l​achlansneff:m​> That link was helpful actually
<re_irc> <@d​irbaio:m​> embassy has hal impls for these
<re_irc> <@d​irbaio:m​> one issue is if you want to do async HALs like that, the HAL driver struct needs to own the interrupt so it can wake the wakers
<re_irc> <@d​irbaio:m​> so it really doesn't work well with the current HAL way of doing things, where it's the user that handles the interrupt
<re_irc> <@l​achlansneff:m​> I suspect there is some way around that by exposing a runtime that the user hooks into interrupts and whatnot
<re_irc> <@d​irbaio:m​> yeah
<re_irc> <@d​irbaio:m​> still, you don't want interrupts exposed in the trait API
<re_irc> <@d​irbaio:m​> there might even be impls that don't use interrupts at all, like an uart impl for linux /dev/ttyXX
<re_irc> <@d​irbaio:m​> embassy does it by having "owned interrupt" types
<re_irc> <@d​irbaio:m​> user has to `take!` the interrupt and pass it to the driver
<re_irc> <@d​irbaio:m​> so then you can do async read/write without worrying at all about interrupts, but on the inside everything is async interrupt-driven automagically
<re_irc> <@l​achlansneff:m​> I'm also thinking about how it could integrate into rtic
<re_irc> <@d​irbaio:m​> hehe
<re_irc> <@d​irbaio:m​> well rtic's core premise is the user handles interrupts
<re_irc> <@d​irbaio:m​> so it's the complete opposite
<re_irc> <@d​irbaio:m​> you can run embassy executor inside an rtic task, but then the interrupts you use for embassy stuff are not managed by rtic
<re_irc> <@l​achlansneff:m​> rtic also lets you hand over interrupts for it to use for scheduling internally
<re_irc> <@l​achlansneff:m​> I would think it could do the same thing for async
<re_irc> <@d​irbaio:m​> imo it wouldn't make sense to have rtic manage the interrupts that are used for async drivers
<re_irc> <@d​irbaio:m​> one of the huge advantages of async is that you *can* make APIs that abstract interrupts away
<re_irc> <@d​irbaio:m​> so forcing the user to worry about them defeats the point
<re_irc> <@d​irbaio:m​> there's talks of extending rtic so it can be an async executor
<re_irc> <@d​irbaio:m​> but the argument about interrupts for the drivers still stands
<re_irc> <@l​achlansneff:m​> Right
<re_irc> <@l​achlansneff:m​> Do you think embassy's approach is the best one?
<re_irc> <@d​irbaio:m​> i'm the author :D
<re_irc> <@d​irbaio:m​> I wrote it that way because I think it is, yeah...
<re_irc> <@l​achlansneff:m​> Didn't realize that haha
<re_irc> <@d​irbaio:m​> it's quite opinionated on how it manages interrupts, but for 95% of the usecases it's fine and it allows for super clean, abstracted code
<re_irc> <@l​achlansneff:m​> I see
<re_irc> <@d​irbaio:m​> and for the remaining 5% you use manual interrupts or rtic or whatever
<re_irc> <@l​achlansneff:m​> There must be some way of getting these all to fit together
<re_irc> <@d​irbaio:m​> you can mix interrupt management styles in the same firmware
<re_irc> <@d​irbaio:m​> embassy is a lib, not an rtos/framework
<re_irc> <@d​irbaio:m​> it won't touch interrupts/peripherals you don't tell it to, so you can mix
<re_irc> <@l​achlansneff:m​> I might play around with a runtime that you call the corresponding trigger_x from the x interrupt
<re_irc> <@d​irbaio:m​> question for the language lawyers out there:
<re_irc> <@d​irbaio:m​> is it UB to transmute a repr(Rust) to/from bytes?
<re_irc> <@d​irbaio:m​> like, I know repr(Rust) means the layout is not guaranteed, but is the transmute itself UB?
<re_irc> <@d​irbaio:m​> like, is it fine to transmute a repr(Rust) to bytes and back? because it's the same layout (even though you're not guaranteed anything about what the layout actually is)
thejpster has quit [Remote host closed the connection]
<re_irc> <@l​achlansneff:m​> It's contentious because of undefined padding.
<re_irc> <@f​irefrommoonlight:m​> Re handling interrupts in a high-level lib: I think it necessary means the lib doesn't play nice with others. Eg embassy doesn't need to worry about this, but RTIC does
<re_irc> <@d​irbaio:m​> what do you mean?
<re_irc> <@f​irefrommoonlight:m​> If a library expects to own the interrupts, it doesn't work cleanly with other libs that so the same
<re_irc> <@d​irbaio:m​> hm but such a lib can only own *some* irqs
<re_irc> <@f​irefrommoonlight:m​> Eg the equiv in web dev of "don't manipulate the DOM if you're using React"
<re_irc> <@d​irbaio:m​> example: say you're doing a motor controller with crazy PID PWM super-realtime controllers, and with a web UI
<re_irc> <@f​irefrommoonlight:m​> I guess that allows for flexibility
<re_irc> <@d​irbaio:m​> you want hard realtime in the motor control part
<re_irc> <@d​irbaio:m​> but you don't in the web UI part, you don't care if the page loads in 50 or 100ms as long as it's fast enough
<re_irc> <@d​irbaio:m​> so you may have RTIC manage the TIMERx IRQ to do the motor control in a fully realtime way
<re_irc> <@f​irefrommoonlight:m​> That's a good point
<re_irc> <@f​irefrommoonlight:m​> Should alleviate most or all of the issues I was worried about
<re_irc> <@d​irbaio:m​> and have an embassy executor inside rtic's idle task, and do all the networking with async, having embassy manage the ETH irq
rjframe has quit [Ping timeout: 268 seconds]
<re_irc> <@f​irefrommoonlight:m​> As long as you're carful not to directly, or through a lib also interact with that specific interrupt
<re_irc> <@d​irbaio:m​> both embassy and rtic only manage the irqs you tell them to manage, so you can mix them
<re_irc> <@d​irbaio:m​> that's already possible today, it's not a hypothetical enhancement
<re_irc> <@t​halesfragoso:m​> That's a trick one, from the same program, or from on program to another ?
<re_irc> <@d​irbaio:m​> within same exact binary
<re_irc> <@t​halesfragoso:m​> Also, padding but maybe you could get away with [MaybeUninit<u8>]
<re_irc> <@t​halesfragoso:m​> Also alignment...
<re_irc> <@t​halesfragoso:m​> Very tricky, take a look at zerocopy, maybe you can find some answers in the safety docs
<re_irc> <@t​halesfragoso:m​> But I think zerocopy asks for repr(C)
<re_irc> <@d​irbaio:m​> yea... the padding/alignment issues also apply to repr(C) though
<re_irc> <@t​halesfragoso:m​> Sure
<re_irc> <@d​irbaio:m​> the question is "is repr(Rust) inherently UB?"
<re_irc> <@d​irbaio:m​> or is it "it's fine as long as it's within the same exact struct, same exact binary, and you don't fuck up uninit/alighment/whatever"
<re_irc> <@t​halesfragoso:m​> From the exact same binary, probably not ? But maybe yes
<re_irc> <@t​halesfragoso:m​> Sorry, I don't dare to answer that... Good question
<re_irc> <@d​irbaio:m​> it's still probably a bad idea, i'm not going to do that
<re_irc> <@d​irbaio:m​> I was just curious
<re_irc> <@f​irefrommoonlight:m​> Re above chat on libs and interrupts - nice!
<re_irc> <@d​irbaio:m​> also if you try to use the same irq with both embassy and rtic it won't compile
<re_irc> <@d​irbaio:m​> because both will define the handler with the same symbol name which won't link
<re_irc> <@d​irbaio:m​> so it's somewhat safe I guess
<re_irc> <@d​irbaio:m​> you can still break stuff by using cortex_m::nvic stuff directly
<re_irc> <@f​irefrommoonlight:m​> Nice - I was wondering how you'd 'own' the interrupt, other than being careful
gsalazar has quit [Ping timeout: 272 seconds]
<re_irc> <@f​irefrommoonlight:m​> The nvic stuff is marked unsafe, so that helps
<re_irc> <@d​irbaio:m​> embassy defines a singleton type for each interrupt, like peripheral singletons
<re_irc> <@f​irefrommoonlight:m​> Nice
neceve has quit [Ping timeout: 272 seconds]
neceve has joined #rust-embedded
cyrozap-ZNC has joined #rust-embedded
cyrozap has quit [*.net *.split]
cyrozap-ZNC has quit [Client Quit]
cyrozap has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
Wetmelon has joined #rust-embedded
neceve has quit [Ping timeout: 268 seconds]