next topic »

[Reply #60 on:]

Hey Jeff-

New topics on how you see the use of the device-specific libraries. 

1)
The way I'm using the ADS1115 library is to set the gain to the range I need, and then get the voltage.  This voltage multiplier changes based on the gain that is set.  So, let's say 100 counts at one gain is  x volts, and 100 counts at a different gain is x/2 volts.  Basically, if I change the gain, I have to also keep track of the multiplier.  A good example is how retrolefty (excellent examples, BTW) is doing it in his code.

I'd like to add in a 'getVoltage' type function that either maps to the getDifferentials (e.g. getVoltage0xGND, or is a general getVoltage using whatever that last mux and gain setting was).

Would this be acceptable to put into the ADS classes?  I don't know your feelings on how much function you want in the libraries, but it seems to go along the lines as to what you've done for some of the gyro type classes- you return more than the simple counts.

2)
I think the constructor for the ADS1115 class needs to go ahead and reset the settings back to the default.  What I found is that if I loaded one sketch (Retrolefty's example code) and changed some values; left the power to the ADS chip on;, and then did a new ADS() and started using your libraries, the assumed defaults.. were not- they were whatever I had last left them.

A simple way to do this would be to flesh out the 'initialize()' code and go ahead and set what all the defaults are rather than assume they were the defaults.

Comments?

[Reply #61 on:]

I'd like to add in a 'getVoltage' type function that either maps to the getDifferentials (e.g. getVoltage0xGND, or is a general getVoltage using whatever that last mux and gain setting was). Would this be acceptable to put into the ADS classes?

A couple of very fast replies to establish my reputation, and now here I am taking four days to get back to you. :-p Sorry about that.

First, let me preface this by saying I will in no way be miffed if you want to fork the project and customize/specialize it in a way that doesn't quite fit with what I had in mind. I don't mean to say that this is the case here, but if you feel like it is, know that it's always an option. It is very open source, after all.

I'm in the process of creating a sort of "stub" sample device class that people can use as a basis for writing their own classes to fit with the I2Cdevlib conventions as easily as possible, but that isn't quite done There will also be a "Contribute" page created on the i2cdevlib.com website with some more instructions, published at the same time as I finish the stub class. In the mean time, let me try to summarize what I'm hoping for here.

First, adding the kind of functions you mention should be totally fine, and I'd readily welcome those kinds of changes into the master branch if you write them and submit a pull request. As long as the functionality is likely to be valuable to the majority of people who are going to be using the device class, then it should be a good fit. If it's a "helper" or "convenience" function that they might end up using in some special case, and it isn't functionality specifically explained in the datasheet or other documentation, then leave it out.

Being able to get digital voltage difference from an A/D converter transparently without needing to calculate a scale factor is definitely valuable. In the ITG-3200 gyroscope, for example, you could add a getRotationDegrees() method or set of methods that would preemptively divide the axis measurements by 14.375, which is the scale factor to convert to degrees/sec according to the datasheet. I didn't do that, but I'd be fine with that. I'm currently in the process of adding some DMP-related convenience functions to the MPU-6050 class because I know they will be valuable, even though they aren't discussed in the datasheet (shame on InvenSense for that, ha!).

In order of decreasing importance, this is the functionality I'd like to see for any given device class:

• get*/set* style methods to read and write all specifically documented device registers, according to the register map
• initialize() and testConnection() methods to establish uniform functionality across the whole I2Cdevlib project
• Helpful Doxygen-style comments for those methods
• Convenience methods that most people are likely to need or want to use

I don't know if this is helpful enough, but hopefully it is. Let me know if not and I'll be happy to clarify anything I can.

As for the functionality of the initialize() method, I'd vote to keep things as simple as possible and still produce reliable results. Your example case is unlikely for production code; the chip will most likely always be run with the same code. But it could certainly happen during development and debugging. However, it does make sense that you would expect a function called "initialize" to actually set everything to a known, predicable state. Especially if some of the functionality of any convenience methods depend on knowing, for example, which MUX value is selected and what the gain is, then it's important to be very specific about the initial state. I'd say setting registers to the known default values shown in the datasheet is acceptable for the initialize() method.

Sometimes, too, a device has a single "reset" bit in one of the registers that will do it all for you. A lot of the motion sensors I've been messing with have that. I think the ADS1115 doesn't have one, but it's something to keep in mind for other devices.

Good questions!

[Reply #62 on:]

Thanks Jeff- I just sent a pull request.   I found out why the initial states weren't working- there was a definition error in the header file for: ADS1115_OS_ACTIVE; it and the inactive were swapped.

I've added in two functions: getMilliVolts and getMvPerCount- again I need to thank RetroLefty's examples in helping me get those set up.

[Reply #63 on:]

Thanks Jeff- I just sent a pull request.   I found out why the initial states weren't working- there was a definition error in the header file for: ADS1115_OS_ACTIVE; it and the inactive were swapped.

I've added in two functions: getMilliVolts and getMvPerCount- again I need to thank RetroLefty's examples in helping me get those set up.

Thanks! That looks great.

I've finally created a device stub .cpp/.h file set for a quick way to get started writing your own devices with the I2Cdev conventions. The files are here:

https://github.com/jrowberg/i2cdevlib/tree/master/_Stub

...and they contain a lot of comments describing the conventions and basic goals, and there are multiple TODO blocks that should make it a little easier to get started and know what to put where without much effort. If anyone has any recommendations or critiques, I'd love to hear them.

Also, there's a new device library up for the DS1307 real-time clock that appears to be working quite well. It doesn't have good Doxygen comments yet, but it does work and everything is pretty self-explanatory.

[Reply #64 on:]

The I2Cdevlib project hasn't seen a lot of activity recently, but the project is far from dead. I've just finished making some significant internal changes to the site's database so that much, much more detailed information can easily be stored about each device--especially registers, bitfields, data formats, and values. Here's a sample of what is now possible:



(This particular image shows data for the MPU-6050, visible here)

I have almost 100% complete information for the MPU-6050 register map (minus some DMP info, still actively talking with InvenSense about that), and minus some specific value sets for certain fields, which will be coming shortly. The AK8975's register info is also added, though I need to revisit that to complete some of the field format settings and specific value sets. I will be returning to each existing device in turn and adding all known register info to round out the current set of devices.

Some of you have wanted code in a different format, say, for PIC MCUs or MSP430s, not just Ardunios. One of the things that will ultimately be possible from this rich register information is--quite literally--to automatically generate new libraries using different code conventions. There will still be some manual effort to polish them up, of course, but the tedious work of creating #defines for every register, bitfield, value, etc. will be automatically done for you. I am hopeful that this will really help out with new devices.

That's it for now.

[Reply #65 on:]

Keenly watching this work Jeff.
I'm surprised at the price of the MPU-6050, only $15 ... excellent!

[Reply #66 on:]

Do you gents have a complete listing for ADS1113/4/5 Arduino code. Greg