11:16 <re_irc> <hartan> Hey,

11:16 <re_irc> I'm implementing the "SpiBus" trait from the latest EH alpha based on the current I2S implementation in embassy (https://github.com/embassy-rs/embassy/blob/master/embassy-embedded-hal/src/shared_bus/blocking/i2c.rs#L33-L37). I'm wondering why exactly does the generic "Mutex" there wrap a "RefCell<BUS>"? Once the "BUS" is in the "Mutex", only one thread at a time can access it, or am I mistaken?

11:16 <re_irc> <hartan> - "based on" as in "I have barely a clue what I'm doing, so this is my template".

12:01 <re_irc> <hartan> Hmm, based on the errors I'm hitting without the "RefCell", could it be that the "RefCell" here solely provides interior mutability?

12:02 <re_irc> <ryan-summers> Very likely so - that's the approach shared-bus uses IIRC

12:02 <re_irc> <ryan-summers> And I believe those traits were modeled after lessons learned in shared-bus

12:04 <re_irc> <hartan> Aw man, writing proper embedded code is hard... :/

12:04 <re_irc> Thanks!

12:05 <re_irc> <ryan-summers> Indeed, that's why it's all still alpha after years

12:42 <re_irc> <henrik_alser> hartan: The Mutex only does the "convert Send to Sync" part, not the "interior mutability" part, this is left to something else, like Cell/RefCell

12:47 <re_irc> <9names (@9names:matrix.org)> > based on the current I2S implementation in embassy

12:47 <re_irc> you made me look, i was surprised there was an I2S impl in embassy. but it's I2C

13:07 <re_irc> <henrik_alser> the advantage is that Mutex<Cell<u32>> is the same size as u32, so no memory overhead, and to get a &mut you use Mutex<RefCell<T>> which uses 1 extra byte for the "locked" flag

15:18 <re_irc> <matejcik> I'm running into an optimization issue: we're preparing some fairly large nested structures and then copying them into heap via ptr::write

15:18 <re_irc> (this is because we're interfacing with MicroPython and use the GC allocator, so we have a custom box-like "Gc<T>" type)

15:19 <re_irc> struct Outer {

15:19 <re_irc> basically like so:

15:19 <re_irc> ... long message truncated: http://localhost:8008/_matrix/media/r0/download/psion.agg.io/110aa35e86f723acb3ac4e4fdc2d8d37447b4cff409c207ecfd5751ca5afaed5 (22 lines)

15:24 <re_irc> <newam> matejcik: are the structs in the same crate or different crates?

15:26 <re_irc> <newam> Initial ideas would be inlining (maybe that would make the compiler smarter), or "codegen-units = 1" / "lto = true"

15:27 <re_irc> <newam> Also try opt-level 2

15:28 <re_irc> <newam> opt-level 2 and 3 are very similar, but 3 does more tradeoffs for speed at the expense of size, opt-level 2 might work for you

15:30 <re_irc> <Lumpio> If you're already using the heap, can't you use a heap string?

16:00 <re_irc> <Chris [pwnOrbitals]> "serial.listen(hal::serial::Event::Rxne);" Is this sufficient to allow for interrupts or is there anything more I should do ? My interrupt function "#[interrupt] fn UART8() { ... }" doesn’t seem to be called

16:16 <re_irc> <Chris [pwnOrbitals]> ah NVIC stuff yay found my way myself :)

16:37 <re_irc> <almindor> hey all, just wanted to shamelessly drop cargo-vcs (https://crates.io/crates/cargo-vcs) here in case someone finds it useful. It's a cargo extension to help manage git (for now) repositories in a cargo workspace "together" by allowing creation of profiles, switching of branches and MSRV overview. I wrote it to help me with some e310x-hal work when testing embedded-hal changes between 0.x and 1.0x-alpha

19:26 <re_irc> <GrantM11235> Should there be an embedded-hal trait for "half-duplex" SPI? As in an SPI bus where the MISO and MOSI signals go through the same pin

20:05 <re_irc> <newam> GrantM11235: Does the existing SPI trait not work for that?

20:10 <re_irc> <GrantM11235> You could just ask for a "SpiBusRead<Word> + SpiBusWrite<Word>", but I wonder if it would be useful to have a "SpiBusHalfDuplex" trait that just requires the read and write traits and doesn't have any additional methods

20:11 <re_irc> <GrantM11235> (Basically the "SpiBus" trait but without the transfer methods)

20:18 <re_irc> <GrantM11235> That would prevent you from accidentally passing a normal spi bus to a driver that expects to use a half duplex bus

20:19 <re_irc> <GrantM11235> Maybe that is more trouble that it is worth though