Go Down

Topic: Expert Comment Needed on a New I2C Library API (Read 4 times) previous topic - next topic

fat16lib

On getter functions.

I could read the baud rate register to get the speed.

I think the pull-ups could be determined by reading the PORT register.

I already have the state functions and just need to include them in the class wrapper.

pito

#6
Feb 10, 2013, 09:53 am Last Edit: Feb 10, 2013, 09:59 am by pito Reason: 1
Do we need to mess with internal pullups? Those pullups are off the recommended values for i2c, so you need external resistors anyway. And APIs - do you consider to have the same as we have today or shall we ie. rewrite sensors drivers with the new i2c lib?

fat16lib

pito,

I provide the option of internal pull-ups because of this statement in the AVR datasheet.
Quote

Note that the internal pull-ups in the AVR pads can be enabled by setting the PORT bits corresponding to the SCL and SDA pins, as explained in the I/O Port section. The internal pull-ups can in some systems eliminate the need for external ones.

I have run some I2C chips, like a RTC, with only internal pull-ups in past projects with no problems.

I didn't use the Wire style API since I don't want an internal buffer and limited transfer sizes for I2C master.  I am designing for maximum performance with RTOSs.

In my first tests at 100kHz with a DS1307, Wire takes 1084 microseconds to read the seven date time registers.  This library, in a NilRTOS thread, takes 1008 microseconds but the thread sleeps while the ISR does the read and lower priority threads get about 850 microseconds of extra CPU time.

At 400 kHz, the read takes 324 microseconds and lower priority threads get an extra 180 microseconds of CPU time.

I may investigate a Wire style wrapper class with an internal buffer but I don't know if that would be valuable.

pito

#8
Feb 10, 2013, 02:44 pm Last Edit: Feb 10, 2013, 02:54 pm by pito Reason: 1
Quote
The internal pull-ups can in some systems eliminate the need for external ones.

The arduino ecosystem shall be designed robust by default, imho. I would recommend to use the i2c pullups with lower resistor values, ie 2k2-4k7. Most of the users do not possess techniques for debugging such potential hw-related issues.

APIs - so your message is the existing drivers utilizing old wire lib have to be rewritten for the new lib.

fat16lib

Quote

The arduino ecosystem shall be designed robust by default, imho. I would recommend to use the i2c pullups with lower resistor values, ie 2k2-4k7. Most of the users do not possess techniques for debugging such potential hw-related issues.

I agree so the default is no internal pull-ups.  I will add a warning to the documentation for begin().

Simple versions of begin(), like these, do not enable pull-ups.
Code: [Select]

  twi.begin();  // 100 kHz, no pull-ups
  twi.begin(I2C_100KHZ);  // 100 kHz, no pull-ups
  twi.begin(I2C_400KHZ);  // 400 kHz, no pull-ups



Quote

APIs - so your message is the existing drivers utilizing old wire lib have to be rewritten for the new lib.


To repeat, a wrapper to present the Wire API is easy to write.  This may make it easy to use existing drivers by changing the include file from Wire.h to the wrapper include.  I don't want the standard API to be the Wire API because of Wire's limited internal buffering.

Go Up