Removed sensors, so they can be put in separate crate

[Kixunil]

Fixes #27

[nastevens]

Prior to merging this, the code that has been deleted should first be moved to a new repo. Is this something that we want to create in rust-embedded? Or something that would maybe make sense in someone's personal github area? I don't know that it makes much sense in rust-embedded. Are these libraries something that you want to keep maintaining @posborne?

[posborne]

I'm fine with maintaining them to some degree. Since individual drivers are pretty small, I wonder if it might make sense to have a single repo with several drivers (possibly not just i2c drivers). Each driver would still be its own crate.

I feel this might help with driver maintainability/etc. as we get some scale and infrastructure reuse. Thoughts?

Thinking something like rust-embedded/rust-device-drivers for the repo which each crate being something like i2cdev-wii-nunchuck (although I would like to see as many of these as possible move towards being based purely on traits at their core).

[Kixunil]

I agree that putting drivers in single repo is fine if they are small. Especially, if each of them will be separate crate. rust-embedded/rust-device-drivers sounds good to me.

[tafia]

I also agree for a separate crate.
What about traits management? Do we need a dedicated repo to handle them all as well (out of i2c)?

[posborne]

What about traits management? Do we need a dedicated repo to handle them all as well (out of i2c)?

I don't know on a final location as of yet, but we have been tossing around a few ideas for sync/async traits for doing I2C and other interfacing here: rust-embedded/wg#19

[tafia]

Thanks!

[posborne]

I'm going to close this as it is a little out of date now that we have a more clear path forward for defining things on top of the embedded-hal traits. I still think there might be a place for an umbrella project that maintains multiple sensor crates in a single repository but it probably shouldn't be this repository as it is very tightly coupled to Linux and, ideally, device drivers would have minimal dependencies and be able to work on a no-std environment to support a wide variety of host operating environments.