You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The embedded ecosystem is very likely to have multiple ways of allocating data, from statically to managed-static to full dynamic. However, most libraries should not care who allocated data -- only that it will not get freed and is not being used by others.
Therefore there is a strong need for a single trait that all of these libraries can use for wrapping the data they return.
Issue at Hand
The existing Buffer API will tie us to the following:
a specific buffer type and way of representing data
a lock/unlocking mechanism that can not be easily extended by other crates. For instance, it would be difficult to implement a memory manager using the Buffer API
This design aims to address this by providing a Mutextrait which can then be implemented in any way we please. Something like the Buffer proposed would be free to implement this trait and then be used for the full API.
The text was updated successfully, but these errors were encountered:
15: Release new patch on crates.io with minimised i2c dependencies r=therealprof a=ryankurte
Following rust-embedded#14 this release contains a newer version of the i2cdev crate that decreases the number of dependencies and thus build time (measured on an rpi3 from 1hr 20 mins to 20 mins).
Co-authored-by: Ryan Kurte <ryankurte@gmail.com>
This is a counter proposal to #14 and aims to be simpler and more future proof.
I have sketched out an implementation which compiles (but is not tested) here:
https://github.com/vitiral/utex/blob/master/src/lib.rs
Reason of need
The embedded ecosystem is very likely to have multiple ways of allocating data, from statically to managed-static to full dynamic. However, most libraries should not care who allocated data -- only that it will not get freed and is not being used by others.
Therefore there is a strong need for a single trait that all of these libraries can use for wrapping the data they return.
Issue at Hand
The existing
Buffer
API will tie us to the following:This design aims to address this by providing a
Mutex
trait which can then be implemented in any way we please. Something like theBuffer
proposed would be free to implement this trait and then be used for the full API.The text was updated successfully, but these errors were encountered: