ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
fooker has joined #rust-embedded
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
<re_irc> <@mehmet:grusbv.com> I had written a device driver for TDK IIM42652, and by patching up things that I had seen I had come up with this signature:
<re_irc> /// Driver's implementation for given SPI and CS
<re_irc> impl<SPI, CS, E, PinError> IIM42652<SPI,CS>
<re_irc> where
<re_irc> SPI: spi::Transfer<u8, Error=E> + spi::Write<u8, Error=E>,
<re_irc> CS: OutputPin <Error= PinError>
<re_irc> {
<re_irc> pub fn new(spi: SPI, cs: CS, config: &Config) -> Result<Self,E> {
<re_irc> <@mehmet:grusbv.com> Now I would like to create an initialization function that returns an IIM42652 object, ready to go.
<re_irc> <@mehmet:grusbv.com> For testing purposes, like an initialization function
<re_irc> <@mehmet:grusbv.com> But this Error types are giving me hard time.
<re_irc> <@mehmet:grusbv.com> clippy asks for "specify the associated type: "Accelerometer<Error = Type>`
<re_irc> <@mehmet:grusbv.com> * Accelerometer<Error = Type>"
<re_irc> <@mehmet:grusbv.com> I think I was a bit lazy to include a generic Error there
<re_irc> <@mehmet:grusbv.com> What was the better way to do this?
<re_irc> <@mehmet:grusbv.com> Should I have selected an Error type for SPI in the signature, then would that Error type be selected and this was resolved?
<re_irc> <@mehmet:grusbv.com> For example, defining an Error enum like this: https://github.com/BenBergman/lis3dh-rs/blob/2d08c0717afc5456b13a7bd1ca39a0d8ab183707/src/lib.rs#L43
<re_irc> <@mehmet:grusbv.com> I see that this was addressed beforehand by here https://therealprof.github.io/blog/revamping-rust-embedded-error-handling/
<re_irc> <@mehmet:grusbv.com> * feel that sth similiar
<re_irc> <@mehmet:grusbv.com> Is embedded-error crate the convention here, or is there a more recently designated way?
IlPalazzo-ojiisa has joined #rust-embedded
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
<re_irc> <@dirbaio:matrix.org> best practice is to define your own enum
starblue has quit [Ping timeout: 252 seconds]
<re_irc> <@mehmet:grusbv.com> : Thanks, will keep in mind.
starblue has joined #rust-embedded
<re_irc> <@dirbaio:matrix.org> "embedded-error" hasn't gained much traction
<re_irc> <@dirbaio:matrix.org> omg matrix decided to eat all my messages
<re_irc> <@dirbaio:matrix.org> this is how you'd do the generics with a custom enum
<re_irc> Spi(SPIError),
<re_irc> enum Error<SPIError, PinError> {
<re_irc> OtherError2,
<re_irc> }
<re_irc> OtherError1,
<re_irc> Pin(PinError),
<re_irc> impl<SPI, CS> IIM42652<SPI,CS>
<re_irc> where
<re_irc> SPI: spi::Transfer<u8>,
<re_irc> CS: OutputPin,
<re_irc> {
<re_irc> pub fn new(spi: SPI, cs: CS, config: &Config) -> Result<Self,Error<SPI::Error, CS::Error> {
<re_irc> cs.set_low().map_err(Error::Pin)?;
<re_irc> spi.transfer(..).map_err(Error::Spi)?;
<re_irc> cs.set_high().map_err(Error::Pin)?;
<re_irc> }
<re_irc> }
<re_irc> <@dirbaio:matrix.org> note that if you want to require "spi::Transfer + spi::Write" it doesn't work as nicely because embedded-hal 0.2 didn't enforce the error types are the same
<re_irc> <@dirbaio:matrix.org> you can workaround it with the "E" generic in the impl, but it sometimes makes type inference not work (the error you were seeing)
<re_irc> <@dirbaio:matrix.org> this is fixed in embedded-hal 1.0
<re_irc> <@dirbaio:matrix.org> also in embedded-hal 1.0 there's a "SpiDevice" trait that manages CS for you, and supports bus sharing
<re_irc> <@dirbaio:matrix.org> so you take a single "SpiDevice", instead of "SpiBus + OutputPin".
<re_irc> <@dirbaio:matrix.org> and it simplifies the error handling even more, since now there's only one error type to deal with
<re_irc> <@dirbaio:matrix.org> enum Error<SPIError> {
<re_irc> Spi(SPIError),
<re_irc> OtherError1,
<re_irc> }
<re_irc> OtherError2,
<re_irc> where
<re_irc> impl<SPI> IIM42652<SPI>
<re_irc> SPI: spi::SpiDevice,
<re_irc> {
<re_irc> pub fn new(spi: SPI, config: &Config) -> Result<Self,Error<SPI::Error, CS::Error> {
<re_irc> spi.transfer(..).map_err(Error::Spi)?;
<re_irc> }
<re_irc> }
<re_irc> <@dirbaio:matrix.org> so I strongly recommend using embedded-hal 1.0 :)
<re_irc> <@dirbaio:matrix.org> : ^
<re_irc> <@mehmet:grusbv.com> : Wow thank you
lehmrob has joined #rust-embedded
lehmrob has quit [Ping timeout: 246 seconds]
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<re_irc> <@mehmet:grusbv.com> I am using the Testing an Embedded Application (https://ferrous-systems.com/blog/test-embedded-app/) blogpost by Ferrous Systems for my project.
<re_irc> For convenience, there is the structure:
<re_irc> │ ├───.cargo
<re_irc> ├───cross # folder for cross compiled code
<re_irc> │ ├───examples
<re_irc> │ ├───self-tests # <-- This is the on target tests with defmt_test
<re_irc> │ │ ├───src
<re_irc> │ │ └───tests
<re_irc> │ ├───src # <-- This is the app source
<re_irc> │ │ ├───tasks
<re_irc> │ │ └───memory.x
<re_irc> It seems that the tests adopt the memory.x of the
<re_irc> <@mehmet:grusbv.com> I am using the Testing an Embedded Application (https://ferrous-systems.com/blog/test-embedded-app/) blogpost by Ferrous Systems for my project.
<re_irc> ├───cross # folder for cross compiled code
<re_irc> For convenience, there is the structure:
<re_irc> │ ├───examples
<re_irc> │ ├───.cargo
<re_irc> │ ├───self-tests # <-- This is the on target tests with defmt_test
<re_irc> │ │ ├───src
<re_irc> │ │ ├───tests
<re_irc> │ │ └───memory.x
<re_irc> │ ├───src # <-- This is the app source
<re_irc> │ │ ├───tasks
<re_irc> │ │ └───memory.x
<re_irc> It seems that the tests adopt the memory.x of the cross crate
<re_irc> <@mehmet:grusbv.com> Is there a way that I can force self-tests folder to run with its own memory.x
<re_irc> <@mehmet:grusbv.com> My reason for that is that for some reason defmt_test flashes the tests, but communicates for an amount that exceeds the watchdog timer before running the test
<re_irc> <@mehmet:grusbv.com> I thought, well, tests can run vanilla, without softdevice, bootloader, and complexities assoc. with ti.
<re_irc> <@mehmet:grusbv.com> * it.
<re_irc> <@therealprof:matrix.org> : Indeed. We settled on a slightly different approach and built that into "embedded-hal".
<re_irc> <@therealprof:matrix.org> : 👆️
Darius has quit [Ping timeout: 260 seconds]
<re_irc> <@thejpster:matrix.org> : Is it out yet?
<re_irc> <@therealprof:matrix.org> Nah. ☹️
Dr_Who has quit [Quit: ZZZzzz…]
lehmrob has joined #rust-embedded
lehmrob has quit [Ping timeout: 256 seconds]
Dr_Who has joined #rust-embedded
<re_irc> <@yruama_lairba:matrix.org> hi, i'd like to know developping on multicore target look like with rust ? i'm interested by the rp2040 in particular.
<re_irc> <@yruama_lairba:matrix.org> is there a stuff like rtic available for multicore ?
<re_irc> <@dngrs:matrix.org> embassy can run tasks on different cores, not sure about rtic
<re_irc> <@yruama_lairba:matrix.org> last time i asked, rtic wasn't supporting multicore, but it was month ago
<re_irc> <@yruama_lairba:matrix.org> i'm looking rp2040-hal example and i don't see anything related to multicore. is there some function to schedule task on partocular core ?
<re_irc> <@yruama_lairba:matrix.org> lol, i don't know how to using async paradigm
<re_irc> <@yruama_lairba:matrix.org> * use
<re_irc> <@dngrs:matrix.org> the actual work is done in "spawn_core1" (%5Bg%5D(https://github.com/embassy-rs/embassy/blob/master/embassy-rp/src/multicore.rs#L112)) so you can also roll your own I suppose
<re_irc> <@dngrs:matrix.org> learning async and using embassy is probably a lot easier though I guess
<re_irc> <@yruama_lairba:matrix.org> i need tutorial for each, unfortunatly i don't think i can make some try soon
<re_irc> <@yruama_lairba:matrix.org> is it easy from embassy to manipulate interrupt ? i mean having a interrupt handler
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc> <@yruama_lairba:matrix.org> seems embassy redefine hal for all chip it support
<re_irc> <@yruama_lairba:matrix.org> i wonder if it easy to use custom hal
Dr_Who has quit [Quit: ZZZzzz…]
<re_irc> <@grantm11235:matrix.org> You can use the embassy async executor with any hal, or even without a hal at all
<re_irc> <@grantm11235:matrix.org> You can also use the embassy hals without using any async
<re_irc> <@yruama_lairba:matrix.org> Seems there is no release of embassy on crate.io
<re_irc> <@yruama_lairba:matrix.org> everything is version 0.0.0
<re_irc> <@grantm11235:matrix.org> Yeah, you need to use it as a git dependency for now
<re_irc> <@yruama_lairba:matrix.org> : can i use stm32f4xx-hal with embassy or it as no sense ?
<re_irc> <@grantm11235:matrix.org> You can, but stm32f4xx-hal doesn't have any async support, so you would need to do some work to actually use async
<re_irc> <@grantm11235:matrix.org> I would recommend switching to the embassy-stm32 hal without using any async first. Then you can start doing async after if you want
<re_irc> <@yruama_lairba:matrix.org> i should try ... one day.
<re_irc> <@grantm11235:matrix.org> embassy-stm32 is my favorite part of embassy. It is much easier to use than the other stm32 hals, and it supports all the stm32 families in a single crate
<re_irc> <@yruama_lairba:matrix.org> i'm currently looking inside embassy-stm32 doc, seems many things are missing at the moment
<re_irc> <@yruama_lairba:matrix.org> for example, i'm looking dma module and it deosn't seems to be usable yet
<re_irc> <@grantm11235:matrix.org> Are you looking at https://docs.embassy.dev/embassy-stm32 ? make sure to select your chip at the top of the page
<re_irc> <@yruama_lairba:matrix.org> yes, i looking at the stm32f11re
<re_irc> <@grantm11235:matrix.org> dma is handled automatically using async, like this https://github.com/embassy-rs/embassy/blob/master/examples/stm32f4/src/bin/spi_dma.rs
<re_irc> <@yruama_lairba:matrix.org> if i understand correctly, dma streams are owned by the peripheral driver
<re_irc> <@grantm11235:matrix.org> yes
<re_irc> <@mrjt:matrix.org> I'll help anyone interested in how to earn $30k within 3hrs and hours but you will reimburse 10% of your dividend when you collect it. Note only interested folks should apply, send me a friend request or Whatapp +15155144674 immediately.
<re_irc> <@yruama_lairba:matrix.org> in fact, i used dma transfert in circular mode to have ring buffer for i2s transfert. the code is unsafe and probably unsound
<re_irc> <@yruama_lairba:matrix.org> the unsoundness comes from concurrency, i have dma streams and a piece of code accessing concurrently to same buffer i can't guarantee at compile that dma streams and processor can't access to same data
<re_irc> <@dngrs:matrix.org> yeah, this was discussed in the embassy room a few days ago
<re_irc> <@yruama_lairba:matrix.org> what was discussed eactly ? dma with circualr buffer , using i2s with dma ?
<re_irc> <@grantm11235:matrix.org> Circular dma
<re_irc> <@dngrs:matrix.org> : here's a direct link to the conversation (https://matrix.to/#/!YoLPkieCYHGzdjUhOK:matrix.org/$vA_OUyUKlUnyS_QuXkPwkSrfPueELU5v1K-JoKU9hSM?via=matrix.org&via=grusbv.com&via=community.rs)
<re_irc> <@grantm11235:matrix.org> I think that it is possible to soundly use circular dma if you use "&[AtomicU8]" for your buffer
<re_irc> <@yruama_lairba:matrix.org> : i was thinking about using &[vcell]
<re_irc> <@yruama_lairba:matrix.org> vcell maybe be bad, it's doesn't implement !Sync so you can't share it across context
<re_irc> <@grantm11235:matrix.org> The accesses need to be atomic, but they don't need to be volatile
<re_irc> <@yruama_lairba:matrix.org> Sorry, i read several time about memory synchronisation, but i never understood it fully
<re_irc> <@mrjt:matrix.org> I'll help anyone interested in how to earn $30k within 3hrs and hours but you will reimburse 10% of your dividend when you collect it. Note only interested folks should apply, send me a friend request or Whatapp +15155144674 immediately.
<re_irc> <@yruama_lairba:matrix.org> the reason i wanted to make it volatile is because i see the buffer as a piece of hardware instead of a data, and vcell is what is used to read hardware register
<re_irc> <@grantm11235:matrix.org> You can think of dma as being like a separate thread. If you want to share data between threads without synchronization, you need to use atomics, not volatile
<re_irc> <@grantm11235:matrix.org> : you forgot to ban
<re_irc> <@therealprof:matrix.org> : That was on on purpose, I was trying something. 😉
Darius has joined #rust-embedded