ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
gdamjan[m]1 has quit [Quit: Idle timeout reached: 172800s]
AtleoS has joined #rust-embedded
<cbjamo[m]> Alexander van Saase: Do you happen to have the model numbers for those cards? I'd be happy to pick up some and try to reproduce here.
djdisodo[m] has quit [Quit: Idle timeout reached: 172800s]
<AlexandervanSaas> <cbjamo[m]> "Alexander van Saase: Do you..." <- The 32GB card is a SanDisk Extreme micro SDHC 32GB U3 V30, model number `SDSQXAF-032G-GN6MN`. The other one is a cheap no-name Chinese card I got with a RC remote once. It wouldn't surprise me if doesn't follow the spec.
xypron has joined #rust-embedded
<cbjamo[m]> I poked around in my pile of SD cards and I happen to have the 64GB version of that SanDisk. I'll give it a try later today and hopefully be able to repro.
AtleoS has quit [Ping timeout: 264 seconds]
AtleoS has joined #rust-embedded
<AlexandervanSaas> cbjamo: It's possible I had a power supply issue. I'm now feeding the SD card reader with 5V and the card initialization succeeds but now I get `Io(Io(RegisterError(245)))` when initializing the file system.
<AlexandervanSaas> That's with the example from
diondokter[m] has joined #rust-embedded
<diondokter[m]> :D
<diondokter[m]> It's getting merged
IlPalazzo-ojiisa has joined #rust-embedded
cr1901_ is now known as cr1901
inara has quit [Ping timeout: 252 seconds]
inara has joined #rust-embedded
IlPalazzo-ojiisa has quit [Ping timeout: 240 seconds]
hmw has quit [Quit: Bye.]
sknebel has quit [Quit: No Ping reply in 180 seconds.]
hmw has joined #rust-embedded
sknebel has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
BenPh[m] has joined #rust-embedded
<thejpster[m]> clock as in calendar, or clock as in "some number of ticks at some given frequency, since some epoch (probably boot time)"
<thejpster[m]> ah, clock as in "a thing that can produce an Instant" (
<BenPh[m]> <thejpster[m]> "ah, clock as in "a thing that..." <- yeah, that.
<BenPh[m]> `clock` is a bit more specific than the encapsulation I have in mind. `TickCount` might be better. it would be up to the implementation to interpret that as "since boot time", and how to map that to wall-time/instant., but that's splitting hairs over semantics
<pkoevesdi[m]> <pkoevesdi[m]> "Hey. Maybe somebody can help..." <- Anybody here who ever successfully wrote a SPI flash algorithm?
AtleoS has quit [Ping timeout: 252 seconds]
AtleoS has joined #rust-embedded
limpkin has quit [Read error: Connection reset by peer]
limpkin has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
jedugsem[m] has joined #rust-embedded
<jedugsem[m]> Does anyone know how to use a uart tx pin as rx pin, I need this for implementing a protocol for video transmitters called smartaudio
<jedugsem[m]> Im using a stm32f411 which is known to be able to use that protocol
<whitequark[cis]> is it bidirectional or something?
<jedugsem[m]> Bidirectional but supposed to only use the tx pin on the micro
<dirbaio[m]> you do it with the HDSEL bit in the CR3 register of the uart
<dirbaio[m]> that'll do both rx and tx on the tx pn
<dirbaio[m]> s/pn/pin/
<dirbaio[m]> check if there's any special requirement electrically, you might need open-drain io
<jedugsem[m]> Ah ok, not hal like, have to look at registers again, didnt really learn c on micros
<jedugsem[m]> Ok thanks
<dirbaio[m]> at the hal level there's Uart::new_half_duplex
<jedugsem[m]> Thanks a lot, will probally use that, but good reminder to learn more about typical registers
MikePanetta[m] has joined #rust-embedded
<MikePanetta[m]> Hi all, good evening! I was wondering if anyone could help me with my state machine impl in rust... I'm not sure I like what I have...
<MikePanetta[m]> Its half converted to use an "Actor" type to do things, but I'm doing it without traits...
<dirbaio[m]> why do you need a state machine?
<MikePanetta[m]> Trying to figure out how to implement the USB PD Policy Engine in a rusty way... It has 195 states split across several state machines, not all of which need be implemented...
<MikePanetta[m]> Atleast that is how it is done in the spec :)
<dirbaio[m]> the cool thing about async is you can write plain code with if/for/while/match/etc and the compiler translates it to state machines for you
<dirbaio[m]> but
<dirbaio[m]> > 195 states
<dirbaio[m]> yeah yikes
<dirbaio[m]> maybe that's too annoying to translate to if/for/while/match/etc 🤣
<dirbaio[m]> okay
<MikePanetta[m]> Yeah, I'm kind of unsure how to directly take care of it in async code...
<MikePanetta[m]> Each state basically boils down to send an event somewhere on enter, wait for one of several events and set the next state based on that, possibly send an event on exit.
<dirbaio[m]> I see you write
<dirbaio[m]> > I can't use async functions in the trait
<dirbaio[m]> what happens if you try? async fn in traits is supported since december
<MikePanetta[m]> Am I incorrect? I could not figure out how...
nadja has quit [Quit: bye!]
<MikePanetta[m]> I tried but it kept complaining that it was not object safe
<dirbaio[m]> it works exactly the same as async fns not in traits
<dirbaio[m]> ah yea
<dirbaio[m]> the main thing async fns in traits can't do is dyn (ie object-safetye)
<dirbaio[m]> but you're not using dyn in your code as far as I can see?
<MikePanetta[m]> I was trying something like actor: &dyn StateActor = thing to get state actor for that state
<MikePanetta[m]> Before...
<MikePanetta[m]> It did not like that
<MikePanetta[m]> I guess the way I have it now it could still be a trait
<MikePanetta[m]> Since I am no longer trying to use dyn.
<MikePanetta[m]> Not a hard change to do.
<MikePanetta[m]> What would a better way, if any be to the Actor thingy I am switching to?
<dirbaio[m]> i'm not sure I understand the actor thing
<MikePanetta[m]> Its just a container for what gets done during the state.
<dirbaio[m]> i'd personally try doing the simplest code possible first: represent the with enums, write plain rust code that matches on the enum and does the thing based on the state
<MikePanetta[m]> A way to keep the code local
<MikePanetta[m]> Hmm ok
<MikePanetta[m]> That is kind of what I had at the beginning.
<MikePanetta[m]> the matching stuff
<MikePanetta[m]> But in 3 different places, one for enter, one for the wait event loop and one for exit, which is probably where I went astray....
<dirbaio[m]> maybe you can merge them all?
slabity[m] has quit [Quit: Idle timeout reached: 172800s]
<MikePanetta[m]> Yeah, I think so.
<MikePanetta[m]> Exactly what I was thinking.
<MikePanetta[m]> Would not be much more than moving some code around.