starblue3 has joined #rust-embedded
starblue2 has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
<re_irc> <@r​eecestevens24:m​atrix.org> 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 (https://github.com/rust-embedded/cortex-m/issues/336). 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​atrix.org> 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​atrix.org> @ryan-summers:matrix.org: 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​atrix.org> 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​atrix.org> Sorry :s
<re_irc> <@r​yan-summers:m​atrix.org> @reecestevens24:matrix.org: 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​atrix.org> 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​atrix.org> hi, anyone using an USB DFU bootloader on an STM32F103?
<re_irc> <@g​rantm11235:m​atrix.org> @evils.devils:matrix.org: You need to edit your linker file so that the flash section starts at `0x08002000` instead of `0x08000000`
<re_irc> <@e​vils.devils:m​atrix.org> hmm, was just wondering if it could be something like that
<re_irc> <@e​vils.devils:m​atrix.org> any way to do that automatically so i can use both cargo embed and dfu?
<re_irc> <@g​rantm11235:m​atrix.org> Not that I know of, but I never really looked into it
<re_irc> <@e​vils.devils:m​atrix.org> oh had to `cargo clean` to get the new memory.x address to be used
<re_irc> <@e​vils.devils:m​atrix.org> hmm, shouldn't this still work via SWD, just waste some memory
<re_irc> <@e​vils.devils:m​atrix.org> nope, doesn't work
<re_irc> <@g​rantm11235:m​atrix.org> @evils.devils:matrix.org: 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​atrix.org> here's the project so far
<re_irc> <@e​vils.devils:m​atrix.org> 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​atrix.org> https://gitlab.com/evils/pedals
<re_irc> <@t​iwalun:m​atrix.org> @grantm11235:matrix.org: 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​atrix.org> hmm, where does it get the magic number?
<re_irc> <@e​vils.devils:m​atrix.org> i may have misunderstood xD
<re_irc> <@t​iwalun:m​atrix.org> 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​atrix.org> The actual code is still at the right place, just the ELF headers are different.
<re_irc> <@e​vils.devils:m​atrix.org> jup, now both seem to work
<re_irc> <@e​vils.devils:m​atrix.org> thanks
<re_irc> <@e​vils.devils:m​atrix.org> hmm, i think i'm out of excuses to not write Rust again
* re_irc @e​vils.devils:m​atrix.org 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​atrix.org> 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​atrix.org> 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​atrix.org> Lachlan Sneff:
<re_irc> <@l​achlansneff:m​atrix.org> Right, they rely on GATs, which are apparently working well enough for prototyping at this point.
<re_irc> <@l​achlansneff:m​atrix.org> A lot of embedded-hal would need redesigning.
<re_irc> <@d​iondokter:m​atrix.org> Not really redesigning. Just another module with new async interfaces. The blocking interfaces are still just fine
<re_irc> <@l​achlansneff:m​atrix.org> And would the non-blocking interfaces switch to async?
<re_irc> <@d​iondokter:m​atrix.org> 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​atrix.org> :/
<re_irc> <@l​achlansneff:m​atrix.org> 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​atrix.org> But why if that's not necessary?
<re_irc> <@d​iondokter:m​atrix.org> 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​atrix.org> What do you think would be the downside for leaving NB and blocking in?
<re_irc> <@d​iondokter:m​atrix.org> 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​atrix.org> Is anyone going to register #rust-embedded on Libera?
<re_irc> <@h​ifi:v​i.fi> it's not registered?
<re_irc> <@h​ifi:v​i.fi> apparently not, I think it's @adamgreig:matrix.org who manages the IRC side
<re_irc> <@a​damgreig:m​atrix.org> 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​atrix.org> Same issue you have with retro thejpster
<re_irc> <@t​hejpster:m​atrix.org> Yeah, but you're an actual WG
<re_irc> <@t​hejpster:m​atrix.org> and also, we registered the ## version as a backup
<re_irc> <@a​damgreig:m​atrix.org> Yes, pursuing the various process to get it registered as an actual wg
<re_irc> <@t​hejpster:m​atrix.org> Cool
<re_irc> <@j​duchniewicz:m​atrix.org> Will the communication move over to Zulip then?
<re_irc> <@l​achlansneff:m​atrix.org> @diondokter:matrix.org: That's true, switching completely over does put a burden on the HAL devs.
<re_irc> <@l​achlansneff:m​atrix.org> The reason why I suggested breaking the api was to avoid a split in the ecosystem.
<re_irc> <@d​irbaio:m​atrix.org> IMO nb should be deprecated once async is ready, yup
<re_irc> <@d​irbaio:m​atrix.org> embedded-hal is very delicate though, major-bumping it splits the ecosystem
<re_irc> <@d​irbaio:m​atrix.org> because "embedded_hal v1 InputPin" is a different trait than "embedded_hal v2 InputPin"
<re_irc> <@d​irbaio:m​atrix.org> even if the trait is identical
<re_irc> <@d​irbaio:m​atrix.org> so if a driver requires v1 and a hal implements v2, you can't use them together
<re_irc> <@l​achlansneff:m​atrix.org> Same thing happened with the futures ecosystem irrc
<re_irc> <@l​achlansneff:m​atrix.org> It sorted itself out eventually
<re_irc> <@d​irbaio:m​atrix.org> yeah, but that was because they did changes to the Future trait itself to improve it
<re_irc> <@d​irbaio:m​atrix.org> removing nb would be a major release that removes nb traits and leaves the blocking traits unchanged
<re_irc> <@d​irbaio:m​atrix.org> but that'd still split the blocking traits ecosystem
<re_irc> <@l​achlansneff:m​atrix.org> Speaking of, there are a lot of traits in `embedded-hal::blocking` that I think should be async.
<re_irc> <@l​achlansneff:m​atrix.org> They're blocking now because it wouldn't make sense for them to be async with nb
<re_irc> <@d​irbaio:m​atrix.org> yeah the plan is to add async flavored traits alongside
<re_irc> <@d​irbaio:m​atrix.org> so you can use uart both blocking or async
<re_irc> <@l​achlansneff:m​atrix.org> I see, okay.
<re_irc> <@d​irbaio:m​atrix.org> there's already some traits that have both blocking and nb flavors
<re_irc> <@l​achlansneff:m​atrix.org> What should the async module be called.
<re_irc> <@l​achlansneff:m​atrix.org> Since requiring raw idents isn't ideal
<re_irc> <@d​irbaio:m​atrix.org> probably `futures`
<re_irc> <@l​achlansneff:m​atrix.org> Hmm
<re_irc> <@l​achlansneff:m​atrix.org> Honestly, `nb` would be the perfect name :P
<re_irc> <@d​irbaio:m​atrix.org> hahaha
<re_irc> <@d​irbaio:m​atrix.org> well that'd be very confusing
<re_irc> <@l​achlansneff:m​atrix.org> 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​atrix.org> even with gats and min_type_alias_impl_trait
<re_irc> <@l​achlansneff:m​atrix.org> All the nb traits were easy, but the blocking traits are not
<re_irc> <@l​achlansneff:m​atrix.org> Oop, they work
<re_irc> <@l​achlansneff:m​atrix.org> That link was helpful actually
<re_irc> <@d​irbaio:m​atrix.org> embassy has hal impls for these
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> 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​atrix.org> 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​atrix.org> yeah
<re_irc> <@d​irbaio:m​atrix.org> still, you don't want interrupts exposed in the trait API
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> embassy does it by having "owned interrupt" types
<re_irc> <@d​irbaio:m​atrix.org> user has to `take!` the interrupt and pass it to the driver
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> I'm also thinking about how it could integrate into rtic
<re_irc> <@d​irbaio:m​atrix.org> hehe
<re_irc> <@d​irbaio:m​atrix.org> well rtic's core premise is the user handles interrupts
<re_irc> <@d​irbaio:m​atrix.org> so it's the complete opposite
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> rtic also lets you hand over interrupts for it to use for scheduling internally
<re_irc> <@l​achlansneff:m​atrix.org> I would think it could do the same thing for async
<re_irc> <@d​irbaio:m​atrix.org> imo it wouldn't make sense to have rtic manage the interrupts that are used for async drivers
<re_irc> <@d​irbaio:m​atrix.org> one of the huge advantages of async is that you *can* make APIs that abstract interrupts away
<re_irc> <@d​irbaio:m​atrix.org> so forcing the user to worry about them defeats the point
<re_irc> <@d​irbaio:m​atrix.org> there's talks of extending rtic so it can be an async executor
<re_irc> <@d​irbaio:m​atrix.org> but the argument about interrupts for the drivers still stands
<re_irc> <@l​achlansneff:m​atrix.org> Right
<re_irc> <@l​achlansneff:m​atrix.org> Do you think embassy's approach is the best one?
<re_irc> <@d​irbaio:m​atrix.org> i'm the author :D
<re_irc> <@d​irbaio:m​atrix.org> I wrote it that way because I think it is, yeah...
<re_irc> <@l​achlansneff:m​atrix.org> Didn't realize that haha
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> I see
<re_irc> <@d​irbaio:m​atrix.org> and for the remaining 5% you use manual interrupts or rtic or whatever
<re_irc> <@l​achlansneff:m​atrix.org> There must be some way of getting these all to fit together
<re_irc> <@d​irbaio:m​atrix.org> you can mix interrupt management styles in the same firmware
<re_irc> <@d​irbaio:m​atrix.org> embassy is a lib, not an rtos/framework
<re_irc> <@d​irbaio:m​atrix.org> it won't touch interrupts/peripherals you don't tell it to, so you can mix
<re_irc> <@l​achlansneff:m​atrix.org> I might play around with a runtime that you call the corresponding trigger_x from the x interrupt
<re_irc> <@d​irbaio:m​atrix.org> question for the language lawyers out there:
<re_irc> <@d​irbaio:m​atrix.org> is it UB to transmute a repr(Rust) to/from bytes?
<re_irc> <@d​irbaio:m​atrix.org> like, I know repr(Rust) means the layout is not guaranteed, but is the transmute itself UB?
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> It's contentious because of undefined padding.
<re_irc> <@f​irefrommoonlight:m​atrix.org> 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​atrix.org> what do you mean?
<re_irc> <@f​irefrommoonlight:m​atrix.org> 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​atrix.org> hm but such a lib can only own *some* irqs
<re_irc> <@f​irefrommoonlight:m​atrix.org> Eg the equiv in web dev of "don't manipulate the DOM if you're using React"
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> I guess that allows for flexibility
<re_irc> <@d​irbaio:m​atrix.org> you want hard realtime in the motor control part
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> so you may have RTIC manage the TIMERx IRQ to do the motor control in a fully realtime way
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's a good point
<re_irc> <@f​irefrommoonlight:m​atrix.org> Should alleviate most or all of the issues I was worried about
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> As long as you're carful not to directly, or through a lib also interact with that specific interrupt
<re_irc> <@d​irbaio:m​atrix.org> both embassy and rtic only manage the irqs you tell them to manage, so you can mix them
<re_irc> <@d​irbaio:m​atrix.org> that's already possible today, it's not a hypothetical enhancement
<re_irc> <@t​halesfragoso:m​atrix.org> @dirbaio:matrix.org: That's a trick one, from the same program, or from on program to another ?
<re_irc> <@d​irbaio:m​atrix.org> within same exact binary
<re_irc> <@t​halesfragoso:m​atrix.org> Also, padding but maybe you could get away with [MaybeUninit<u8>]
<re_irc> <@t​halesfragoso:m​atrix.org> Also alignment...
<re_irc> <@t​halesfragoso:m​atrix.org> Very tricky, take a look at zerocopy, maybe you can find some answers in the safety docs
<re_irc> <@t​halesfragoso:m​atrix.org> But I think zerocopy asks for repr(C)
<re_irc> <@d​irbaio:m​atrix.org> yea... the padding/alignment issues also apply to repr(C) though
<re_irc> <@t​halesfragoso:m​atrix.org> Sure
<re_irc> <@d​irbaio:m​atrix.org> the question is "is repr(Rust) inherently UB?"
<re_irc> <@d​irbaio:m​atrix.org> 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​atrix.org> From the exact same binary, probably not ? But maybe yes
<re_irc> <@t​halesfragoso:m​atrix.org> Sorry, I don't dare to answer that... Good question
<re_irc> <@d​irbaio:m​atrix.org> it's still probably a bad idea, i'm not going to do that
<re_irc> <@d​irbaio:m​atrix.org> I was just curious
<re_irc> <@f​irefrommoonlight:m​atrix.org> Re above chat on libs and interrupts - nice!
<re_irc> <@d​irbaio:m​atrix.org> also if you try to use the same irq with both embassy and rtic it won't compile
<re_irc> <@d​irbaio:m​atrix.org> because both will define the handler with the same symbol name which won't link
<re_irc> <@d​irbaio:m​atrix.org> so it's somewhat safe I guess
<re_irc> <@d​irbaio:m​atrix.org> you can still break stuff by using cortex_m::nvic stuff directly
<re_irc> <@f​irefrommoonlight:m​atrix.org> 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​atrix.org> The nvic stuff is marked unsafe, so that helps
<re_irc> <@d​irbaio:m​atrix.org> embassy defines a singleton type for each interrupt, like peripheral singletons
<re_irc> <@f​irefrommoonlight:m​atrix.org> 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]