Refactor API proposal

[RobTillaart]

in #82 a proposal is made to improve the API

  bool readADC(int &value)
Which returns false in case of errors and true as well as value when all is
Ok.

Users can then do
   if(readADC(value))
      handle value
   else
      handle error

• check for the whole API to apply this pattern
• update all examples
• Improving the error's to include possible I2C errors.
• New API can be implemented while keeping the old interface - optionally as depreciated.

An alternative could be

  int readADC(int &value)

return 0 if OK or the error code, so it does not need to be fetched with getError()

[deKees687]

Perhaps most users are not interested in error handling. They just want results in the easiest way possible. For those users it is handy to keep readADC() that returns the adc value. Changing this function will break API and cause annoyance to existing users so I would keep that interface.

The longer timeout is no problem because that will never result in extra delays as long as all is OK. And it does not need any changes in user code anyway.

The alternative readADC(&Value)
return 0 if OK, errorcode when error:
This would make user code a little more complicated. It is no longer possible to put the call in an if() statement as you would want to preserve the error code. And you still need to call getError() if you want to clear the internal error code. So you get code like:

int Value;
int Rc = readADC(Value);
if(Rc == ADS1X15_OK )
   Handle value
else 
   Handle Error

So at the end, I would keep the interface as-is. Don't break user code. And update the examples to show how to use the API in the easy way and how to use it in a proper error-handling way.