Jump to content
I2Cdevlib Forums

RYIP

Members
  • Posts

    4
  • Joined

  • Last visited

Recent Profile Visitors

862 profile views

RYIP's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. http://www.varesano.net/files/FreeIMU-20121122_1126.zip FreeIMU uses your i2cdevlib. However, he introduces a bit for SPI. I agree with your point about this is called "i2cdevlib" after all. So, I think the approach taken in freeIMU is not elegant. On the other hand, I think each of the devices, e.g. ADXL will need to take a bit during the instantiation to specify whether it is sitting on SPI or I2C. And to be truly flexible, which SPI (if the corresponding CS) and which I2C (e.g. Wire vs Wire1). But as you pointed out, it is not a trivial change.
  2. I think the function names are unnecessarily misleading. Anyway, to allow burst writes to a I2C slave, the "beginTransmission" is like setting up the buffer on AVR. Then the subsequent "writes" places transactions on the write buffer (not talking to the I2C slave yet). And the "endTransmission" actually opens up the flood gate to allow the transactions to go down to the I2C slave. However, in the case of burst read, "requestFrom" already includes the device ID as well as the number of bytes to read. As such, once it sees this request, AVR (or SAM) can already initiated the transaction to the slave. The extra "beginTransmission" and "endTransmission" surrounding the "requestFrom" merely flush out the write buffer AFTER the read transaction (since the flushing of write buffer is initiated by "endTransmission"). Uno (1.0.5) and Due (1.5.2) behave differently when you flush a empty write buffer. Uno merely sends out one write transaction with the device ID. But then Due sends out a write transactionb with the device ID followed by a write transaction with the address. Personally, I think the Due way is the more "correct" way.
  3. Looking at 1.0.5 Arduino docs on Wire library, I think the proper way for reads are: beginTransmission(devID) write(addr) endTransmission requestFrom(addr, count) while (Wire.available()) { data = Wire.read() } There's no need for beginTransmission before the requestFrom. Also, there is no need for endTransmission. In the current I2Cdev.cpp, by placing the extra beginTransmission you just added an extra entry to the write buffer. When you issue the endTransmission (which is AFTER requestFrom), you are generating a new write transaction with ONLY the devID. In fact, the current code behaves differently for Due and Uno. For the Due code, not only generate an extra unneeded writing of the devID, if also writes an unneeded address.
  4. If I want to use i2cdevlib for Wire1 for Arduino 1.5.2 for Arduino Due, what should I do? Since Due supports TWO I2C interfaces, and Wire1 is the one next AREF. Also, I notice that as part of Fabio's library, someone enhanced the I2Cdevlib to include SPI as well which is sort of nice. Would you consider including that as part of the trunk? Thanks for the excellent work on this. Makes my life so much easier.
×
×
  • Create New...