Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds I2C implementation and basic accelerometer crate. #30

Merged
merged 10 commits into from
Sep 1, 2016
Merged

Conversation

tcr
Copy link
Member

@tcr tcr commented Sep 1, 2016

This commits the I2C interface and an accelerometer crate that can read acceleration values.

Note that API design questions should be surfaced on #29. Our goal is to get our interfaces working and tested asap, but design the ergonomics more carefully before 1.0.

@johnnyman727
Copy link
Contributor

@Dr-Emann
Copy link
Contributor

Dr-Emann commented Sep 1, 2016

Rc<Mutex<T>> is probably not what you want. Rc is not shareable across threads. If you want to lock the port to a single thread, you can use Rc<RefCell<T>> (RefCell is basically a mutex for a single thread). If you want it to be shareable across threads, you want Arc<Mutex<T>> instead.

@tcr
Copy link
Member Author

tcr commented Sep 1, 2016

@Dr-Emann Agreed; I'll swap that for this release.

@@ -69,7 +71,7 @@ extern crate alloc_system;

* Build the project (in release mode to optimize the size of the binary)
```
cargo build --release
cargo build --release --target=mipsel-unknown-linux-gnu
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you add this just for clarity? I don't think I needed this but maybe my setup was just different.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, mine required it. Guess it doesn't hurt to be specific when cross-compiling.

@johnnyman727
Copy link
Contributor

johnnyman727 commented Sep 1, 2016

I'm not experienced enough to comment on that API design as-is but I'm curious about why the accel-mma84 driver is living within the tessel-rust repo. Shouldn't that be an addition to its own repo?

@tcr
Copy link
Member Author

tcr commented Sep 1, 2016

@johnnyman727 I think we did something like this when we started with T1; basically we had all the code in one repo to help evolve the API all at once, and broke out the modules once the API settled down. I expect that to happen here.

Also, whoops, did not notice the Rust version of the MMA84 code. Probably past the point of using it now though :(

@tcr tcr merged commit 841b401 into master Sep 1, 2016
@tcr tcr deleted the tcr-rust branch September 1, 2016 21:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants