Initial working commit with I2C only

[siddacious]

This is to address adafruit/circuitpython#1198

I did notice one issue with the RTD build where the docs for the constructor doesn't understand how to get the value of a const I'm using for a default value and instead displays
class adafruit_adxl34x.ADXL345(i2c, address=<sphinx.ext.autodoc.importer._MockObject object>) instead. If anyone knows how to fix this, please let me know. Making the variable in question not a const seems to work but I'd rather fix the docs than change the code.

On thing I was thinking about was the enum-like classes for the range and data_rate values. Having to say adafruit_adxl34x.Range.RANGE_2_G seems repetitive but I can't just have the class variable named 2G. If anyone can think of a cleaner way to do this, I'm open to it.

[microbuilder]

Thanks for the PR!

I'm doing some code tests on this today and will do a review after the initial HW sanity checks. I did notice that the first sample is always 0.0 0.0 0.0, though.

The results being returned are most likely the previous buffered conversion request, so you might simply need a tiny delay between the read request and reading the device output the first time here (between the write that sends the request, and the read to retrieve it): c6c3a3d#diff-f32cde418fbcd2f8d3b666d82e153a17R203

UPDATE: You'll only see the 0.0 0.0 0.0 the first time you power the device up or after a reset, though. If you just re-run code.py without resetting the ADXL345, it will still have queued data to return since the sensor itself is continuously running irrespective of the state of the CP board.

[microbuilder]

There are a few spacing and formatting issues, but this works great on my initial HW tests here, and I didn't spot anything in the core functions that would be problematic. You might want to run this through pylint or something similar, though, since the automated build system will reject anything that has warnings Good job on this, though, and thanks for the PR.

If you don't mind testing against pylint and fixing any issues, I'm happy to approve this. A quick run of pylint here gives me the following, for example:

$ pylint adafruit_adxl34x.py 
************* Module adafruit_adxl34x
adafruit_adxl34x.py:54:33: C0326: Exactly one space required around assignment
_ADXL345_DEFAULT_ADDRESS         =const(0x53) # Assumes ALT address pin low
                                 ^ (bad-whitespace)
adafruit_adxl34x.py:91:0: R0903: Too few public methods (0/1) (too-few-public-methods)
adafruit_adxl34x.py:130:0: R0903: Too few public methods (0/1) (too-few-public-methods)

------------------------------------------------------------------
Your code has been rated at 9.70/10 (previous run: 8.08/10, +1.62)

[microbuilder]

Presumably this should be mA?

[siddacious]

Yea, I thought it was just my terminal not rendering properly but I'll fix this.

[microbuilder]

This will need to be changed, missed it during the review sorry.

[microbuilder]

Same issue here (max31856)

[siddacious]

I committed, rebased and force pushed an update that corrects the things you mentioned but my local python environment is pretty fubared and I can't get pylint running even though it's installed. It should be passing pylint now but I'll check again when I get my environment sorted.

[siddacious]

D'oh! I recycled the hidden files because the cookiecutter didn't generate them (or I missed something). Should be fixed now.

[microbuilder]

I still see a lot of warnings here, mostly about white space (image below), but these are from a different parser I'm using that checks against PEP8 style inside Atom.

pylint seems happy, though, which should be enough for travis.ci.

@kattni Are there specific requirements around PEP8, line spacing, etc. before this can be merged?

[kattni]

@microbuilder So, in theory, if Pylint passes, we're happy with it. Personally I'd want some of those fixed up. Your linter seems to be ignoring the pylint: disable= line. When it comes to setting registers, the decision to have them all be even with "bad" whitespace is up to the author.

In the end though, as long as Travis is happy, the builds will succeed and that's the important part.

[siddacious]

@caternuson I re-enabled whitespace complaints a bit lower than you requested because there were some additional lines that I wanted it disabled on. Travis looks to be passing again.

[caternuson]

I approved, but now realize a better way would be to add the enable where I said. For turning it off in your Range class, just add it to the class level modifier.

class Range: #pylint: disable=too-few-public-methods, bad-whitespace

EDIT same for DataRate class

[microbuilder]

@caternuson I merged this in just to get something started, but feel free to raise an issue with any new suggestions?

[caternuson]

@microbuilder Thanks. Sounds good. It's mainly cosmetic linting issues at this point. Not worth holding up a release.