Frederick Vollbrecht

> Imo it's rather inconvenient that you have to create all the devices upfront. One should be able to create a bus then create devices using the bus. I see...

Another problem when allowing an dedicated rm of a device -> Because the identifier for an device is just an i32 this is a weak link. An device could be...

Thank you for your feedback. I tried really hard to create something that works without the i32 id's and have a similar interface like you proposed. I have a first...

Current Interface looks something like the following ``` let spi = SpiMaster2::new::(spi, sclk, tx, Some(rx)); spi.init_master(); let mut slave1 = SpiSlave::new(cs_pins.pop().unwrap(), conf_list[0])?; let mut slave2 = SpiSlave::new(cs_pins.pop().unwrap(), conf_list[1])?; let mut...

I got it down now for the most part. It is fully functional and i tested it for 11 parallel SPI devices. Usage Interface currently looks like the following: ```...

> Second improvement is to remove the forced use of `Arc`, not all users will want to pay the cost of runtime tracking and/or atomics. To allow flexibility, device constructor...

hmm i am kinda stuck, i don't think it is possible to use Borrow. Or maybe i am not understanding it correctly. The problem where it all breakes apart is...

> The solution you're looking for is to not hold a reference to the device directly in the bus but instead hold a reference to the data inside the device...

> > i dont like a software cs solution, its to "blocking" for me . but maybe when making it all async i just dont have to care see_no_evil >...

At least its not a total disaster: - We got a seperation from SpiDevice to SpiMasterDriver -> that allows multiple Devices :tada: - if one only ever create max 3...