farcaller
commented
8 years ago That sounds like an overall good idea, but I'm not sure that the hardware is always used in exclusive mode, e.g. it's a valid, and often used scenario to have several devices on SPI bus, so you can't hold the &mut on it. This noted, it should be a scheduled exclusive access, so maybe it's actually a job for a mutex-like thing.
gsnoff
Currently, all methods in traits describing hardware classes (such as GPIO pins and SPI bus interfaces) use non-mutable
&selfpointers. This might cause problems with two or more consumers meddling with hardware state at the same time and getting into race conditions, for example, which are going to be very hard to diagnose at some point.I have a suggestion to make the methods require
&mut selfpointers, except for those which are generally thread-safe and, more importantly, guaranteed to not change hardware state. What this means, is that operations such as send, receive (since it shifts buffer registers), write pin state, change pinmux configuration etc. should require mutability of the corresponding hardware resource. However peek (get buffer contents without shifting it), read pin state, get current time and similar operations may be made to work with non-mutable resources.Also, in case of devices depending on underlying lower-level resources (for example, most real-time clocks and on-board sensors using buses such as I2C or SPI), the device driver owning mutable references to those resources may expose methods which don't require mutability - for operations which don't change the overall hardware state except for lower level bus registers etc., abstracted away by the driver. The driver, however, should ensure thread safety of those methods via locking mechanisms, atomicity guarantees and whatnot.