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

Changed Sensor Constructors to allow Variable Polling Frequency #39

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

matthewcn56
Copy link

@matthewcn56 matthewcn56 commented Dec 4, 2020

Closes #29.

When I try running the build command, it says that there is a fatal error inside of the data packet.cpp file, but I did not edit that file.

@matthewcn56 matthewcn56 changed the title Changed Constructor to allow Variable Polling Frequency Changed Sensor Constructors to allow Variable Polling Frequency Dec 4, 2020
@kevinl120 kevinl120 self-requested a review December 4, 2020 21:34
Changed code modifications to abide with coding conventions within repo, still running into datapacket.cpp issues when attempting to build however
@@ -21,21 +21,24 @@ namespace spartan {
virtual int powerOn() = 0;
virtual int powerOff() = 0;
virtual int poll(MasterDataPacket &dp) = 0;

Copy link
Contributor

Choose a reason for hiding this comment

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

Remove unneeded indentation to keep proper style.

LSM6DS33(int busID, int lsm6ID, lsm6Settings settings);
LSM6DS33(int busID, int lsm6ID);
LSM6DS33(int busID, int lsm6ID, int polling_frequency, lsm6Settings settings);
LSM6DS33(int busID, int lsm6IDm, int polling_frequency);
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason why we changed the second parameter to lsm6ID to lsm6IDm? This probably should be producing a compilation error.

@harrisonCassar
Copy link
Contributor

Hm.... @matthewcn56 I realize that this PR is trying to implement the same thing as what PR #38 opened by @allosaurus7000 is doing... can we perhaps combine these changes into one PR? or abandon one in favor of the other?

Many of the comments and requested changes I put on the other PR are partially or completely implemented by this PR, so that's great! If I had to say which one we should work off of, I'd say it'd probably be this one.

@matthewcn56
Copy link
Author

Hm.... @matthewcn56 I realize that this PR is trying to implement the same thing as what PR #38 opened by @allosaurus7000 is doing... can we perhaps combine these changes into one PR? or abandon one in favor of the other?

Many of the comments and requested changes I put on the other PR are partially or completely implemented by this PR, so that's great! If I had to say which one we should work off of, I'd say it'd probably be this one.

Sounds good! I'll check in with him rn and see if we can merge changes to here

@allosaurus7000
Copy link

allosaurus7000 commented Jan 25, 2021 via email

I assume that getTimeMillis and the other functions will be handled inside the implementation of the sensor polling functions themselves, and not part of this pull request?
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.

Add sensor polling frequency/period
3 participants