vulfe has quit [Remote host closed the connection]
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 240 seconds]
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 240 seconds]
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 240 seconds]
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 268 seconds]
<re_irc>
<@amusil:matrix.org> Hi, I was just wondering if "atomic-polyfill" shouldn't use "write_volatile"/"read_volatile" instead of the direct read/write through the pointer? Maybe I'm overthinking it, however not being volatile can cause issues when those atomics are used in interrupts
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 268 seconds]
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 268 seconds]
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 276 seconds]
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 250 seconds]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 240 seconds]
limpkin_ is now known as limpkin
<re_irc>
<@korken89:matrix.org> : How can it be impacted by interrupts?
<re_irc>
<@amusil:matrix.org> If the read and write isn't volatile, compiler can remove it from interrupt handler
<re_irc>
<@amusil:matrix.org> Or optimize it to something else, because it doesn't see clear connection between something that happens in main program and interrupt handler
<re_irc>
<@korken89:matrix.org> Since they are connected via a static variable the compiler will see that reads and writes are connected and not optimize them out , unless the atomic is never read but then it's a valid optimization
<re_irc>
<@korken89:matrix.org> Do you have a reproduction of a miss optimization?
<re_irc>
<@amusil:matrix.org> Not really, I was just wondering why is it ok in Rust but not in C
vulfe has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> Volatile in C and Rust are not the same
<re_irc>
<@amusil:matrix.org> Well I know there isn't anything like volatile in Rus, just the read_volatile/write_volatile
<re_irc>
<@amusil:matrix.org> Which the documentation doesn't specify very well and it puts to perspective of C volatile
<re_irc>
<@korken89:matrix.org> Or, the semantics of a volatile operation is the same, based on C11, but worth everything being in view of the compiler volatile is often not need
<re_irc>
<@korken89:matrix.org> * with
<re_irc>
<@korken89:matrix.org> * needed
<re_irc>
<@korken89:matrix.org> General accessing HW needs it as there is no variable connecting
<re_irc>
<@amusil:matrix.org> Yeah that use case is clear
<re_irc>
<@korken89:matrix.org> So it's not in view of the compilers analysis
<re_irc>
<@korken89:matrix.org> Generally UnsafeCell makes the compiler defensive as well
<re_irc>
<@korken89:matrix.org> E.g. making your own Sync struct wrapping UnsafeCell only needs compiler (atomic) barriers for reordering restriction
vulfe has quit [Ping timeout: 240 seconds]
<re_irc>
<@amusil:matrix.org> Alright, so it is safe to assume that any interaction with UnsafeCell should prevent read optimizations etc?
<re_irc>
<@korken89:matrix.org> Every sequential atomic access is protected via the critical section implementation, so 2 reads should never optimize into 1
<re_irc>
<@korken89:matrix.org> Unless the critical section implementation is faulty and allows for the access to be moved outside the critical section
<re_irc>
<@amusil:matrix.org> Ok, thanks
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 240 seconds]
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 276 seconds]
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 268 seconds]
<re_irc>
<@diondokter:matrix.org> Anybody know how to make this compile?
<re_irc>
I've been trying to convince the compiler to turn a "*mut dyn Trait" into a "&'static mut dyn Trait"
<re_irc>
<@xiretza:xiretza.xyz> : where is it supposed to get the vtable pointer from? "*mut c_void" is only a single pointer
vulfe has joined #rust-embedded
<re_irc>
<@diondokter:matrix.org> Ok, so maybe I don't have this sharp enough... So to my understanding, a "dyn Trait" is an object that has some data and a vtable. This is not sized because the sizes can differ.
<re_irc>
So a "&dyn Trait" is a reference to both the data and the vtable, which means a "*const dyn Trait" is a pointer to the data and the vtable
<re_irc>
<@diondokter:matrix.org> But maybe I'm wrong
<re_irc>
<@xiretza:xiretza.xyz> : well, it's two pointers, one to the data and one to the vtable
<re_irc>
<@diondokter:matrix.org> : Ok, but then still a "&dyn Trait" would be a reference to those two pointers, right?
<re_irc>
<@xiretza:xiretza.xyz> if you cast it to a non-dyn pointer such as "*mut c_void", the metadata (vtable pointer) is lost
<re_irc>
<@xiretza:xiretza.xyz> : no, that's also two pointers
<re_irc>
<@xiretza:xiretza.xyz> in this regard pointers and references are the same thing conceptually
<re_irc>
<@diondokter:matrix.org> Hmmmm... But then I don't understand why a "dyn Trait" is not "Sized". If it's just two pointers, that has a size right?
<re_irc>
<@xiretza:xiretza.xyz> no, a "dyn Trait" is not two pointers, anything that _points_ to one is two pointers
<re_irc>
<@xiretza:xiretza.xyz> same as for slices, "[u8]" is unsized, "&[u8]" is a pointer and a length (in this case the metadata is a length, not a vtable pointer)
<re_irc>
<@diondokter:matrix.org> Ah
<re_irc>
<@diondokter:matrix.org> Hmmm... Ok, thanks for the clarification! I've got some reading up to do it seems
<re_irc>
<@xiretza:xiretza.xyz> "std::ptr::Pointee" and friends might be useful as a representation of how you could access those parts of pointers
<re_irc>
<@diondokter:matrix.org> Well, this is for the use in a C library. It has a driver kind of thing and it gives you one pointer to put your driver data in. We need to be able to plug in multiple types so the idea is to give it a trait object from the rust side and when the C driver asks us to do anything, we cast the pointer back to the trait object
<re_irc>
<@diondokter:matrix.org> Can't use generics because these are extern C functions
vulfe has joined #rust-embedded
<re_irc>
<@xiretza:xiretza.xyz> you'll have to make it a pointer to a struct that contains what you need (like a trait object fat pointer)
<re_irc>
<@diondokter:matrix.org> Pretty annoying though that you need the double reference, but it's workable
<re_irc>
<@xiretza:xiretza.xyz> yeah, language support for interior vtables would be nice
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
vancz_ has quit [Ping timeout: 240 seconds]
vulfe has joined #rust-embedded
vancz has joined #rust-embedded
<re_irc>
<@elpiel:matrix.org> Hey everyone 👋,
<re_irc>
What approach should I use for loading toml config and serializing it in another format to be included when flashing the device?
starblue has quit [Ping timeout: 268 seconds]
<re_irc>
<@diondokter:matrix.org> : Loading when compiling I presume?
<re_irc>
<@elpiel:matrix.org> : yes
vulfe has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
<re_irc>
<@diondokter:matrix.org> I'd say deserialize in your build script, serialize it to a binary blob with something like Postcard and output it to the out folder.
<re_irc>
In your code, do an "include_bytes!" and deserialize that in your firmware
<re_irc>
<@diondokter:matrix.org> Or generate some code with constants using the "quote" crate output the generated code to a text file and do an "include!" in your firmware
<re_irc>
<@diondokter:matrix.org> With the last option you have actual constants with which you can change buffer sizes
<re_irc>
<@elpiel:matrix.org> Hmmm.. yeah, the first approach sounds good, second - I can try if the first doesn't work as expected.
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 240 seconds]
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 240 seconds]
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 268 seconds]
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 248 seconds]
<re_irc>
<@halfbit:matrix.org> It seems like e-h has been trimmed down quite a bit for 1.0
<re_irc>
<@dirbaio:matrix.org> ✂️
vulfe has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> yes, some traits had design flaws that made them not really usable to write hal-independent drivers
<re_irc>
<@halfbit:matrix.org> that's actually a nice way to view it
<re_irc>
<@halfbit:matrix.org> rather than trying to imply every device needs to comply withan arbitrary interface
<re_irc>
<@dirbaio:matrix.org> since 1.0 is forever, it's best to remove them, and add them back later once we figure out the right way to do them...
<re_irc>
<@halfbit:matrix.org> * with an arbitrary interface for every peripheral
<re_irc>
<@dirbaio:matrix.org> most of the issues were traits with unconstrained "type Time" associated types
vulfe has quit [Ping timeout: 268 seconds]
<re_irc>
<@halfbit:matrix.org> ah... yeah time on embedded systems is interesting...
<re_irc>
<@dirbaio:matrix.org> some HALs would impl them with "Time = u32" as microseconds, other as clock cycles, others use "embedded-time" or "fugit", others define their own types
<re_irc>
<@dirbaio:matrix.org> so to write a driver if you do "where T: Timer", you can't really use it because you don't know what type "T::Time" is, so you can't create values of it
<re_irc>
<@dirbaio:matrix.org> and if you do "where T: Timer<Time=u32>" then your driver only works with HALs that define "Time = u32" as microseconds
<re_irc>
<@dirbaio:matrix.org> and misbehaves with the ones that use u32 as clock cycles
<re_irc>
<@dirbaio:matrix.org> and doesn't compile at all with the others ;D
<re_irc>
<@halfbit:matrix.org> yeah, probably best to have a trait Instant of sorts, that knows the source clock rate, rollover count, and an exact counter value of the clock perhaps...
<re_irc>
<@dirbaio:matrix.org> ... and that's when it gets complicated, everyone has _opinions_
lehmrob has joined #rust-embedded
<re_irc>
<@halfbit:matrix.org> yeah of course
vulfe has joined #rust-embedded
vulfe has quit [Ping timeout: 246 seconds]
vulfe has joined #rust-embedded
lehmrob has quit [Ping timeout: 260 seconds]
vulfe has quit [Ping timeout: 276 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
vulfe has joined #rust-embedded
vulfe has quit [Quit: Leaving...]
vulfe has joined #rust-embedded
<re_irc>
<@yruama_lairba:matrix.org> i think i should ask here. i'm trying to do a HAL for full duplex i2s operation. The device have basically 2 coupled i2s interface, a main part and an extension. So for many functions i can design 2 API style.
<re_irc>
<@yruama_lairba:matrix.org> 1. driver.main().some_function() and driver.ext().some_function() : pro code factorisation, cons may difficult to implement
<re_irc>
<@yruama_lairba:matrix.org> 2. driver.main_some_function() adn driver.ext_some_function(): pro straightforward to implement, cons: code duplication