wire library endTransmission() still not working with Due

I have read the posts about endTransmission() returning non-zero on successful transmits. This was supposed to have been fixed in Arduino 1.5.7.
I am testing this with a tinyRTC board. My I2C scanner which relies upon wire.endTransmission() returns 2 (NACK) for the RTC address (0x68).
However, if I use the RTCdue library which does not use wire, I can access and read the RTC.
My conclusion is that wire is still not fixed for the due.

Any help? I make extensive use of I2C and could do with a working wire library for the Due.

I discovered that RTClib assumes connection to the second I2C port on the Due, without giving the option as to which port you are connected to. Once I sorted that out, it all works as expected.

#ifdef AVR
#include <avr/pgmspace.h>
#define WIRE Wire
#else
#define PROGMEM
#define pgm_read_byte(addr) (*(const unsigned char *)(addr))
#define WIRE Wire // Wire1 --- You have to change Wire1 to Wire to use the standard I2C port on the Due
#endif

My first forum post, so Noob grace is humbly appreciated...

Thought I would attach to this exising post started by Gutzy

I'm trying to get an OV7670 camera (no FIFO) module working with my Due, and I just need to read the configuration and change a couple registers in the camera over the I2C interface. Everything else is working pretty well thanks to help from this forum.

I have the latest MAC OSX version 1.5.8 Arduino software, which should have issues with the Wire library fixed (or so I've read), but cannot after many hours even read a byte from the camera with my Due.

According to the camera datasheet, it's SIO-D (ie. SDA) line is compatible with the Due SDA1 - pin 70, meaning direct connection at 3.3V is perfect, and the SIO-D runs tri-state so setting pinMode(70, INPUT) disables the Due internal pull-up on that pin. I have SCL1-pin 71 set as OUTPUT, and I've tried a range of resistors between the SCL1 and SIO-C pins (from none to 1K). I have a scope on the SCL1 pin, but it shows the pin high and never cycling low when I run the code.

Of course without sending any clock pulses to the camera when I call the read routine (below), I get what I expect - only zeros (camera reset should restore defaults which are mostly NOT zero).

So it looks like the Wire library is failing to cause my poor Due to assert a clock signal, but still returning true on an available byte from SDA1.

Am I doing something wrong here, or are the most basic Wire functions just not available to work on the Due yet?

// CODE SAMPLE //

volatile byte regData = 0;
byte device = 0x43; // need to shift right 1 bit for a 7-bit address. 0x43 is READ for OV7670
byte regaddrx;

Wire1.begin;
// Configure camera by modifying registers via the SCCB, first read them...
for(regaddrx = 0x01; regaddrx < 0x7F; regaddrx++) { // max address for 7-bit is 0x7F
Serial.print(regaddrx, HEX);
Serial.print(":");
regData = ReadReg((device>>1), (regaddrx>>1));
Serial.print(regData, HEX);
Serial.print(", ");
}

...
byte ReadReg (byte addr, byte regAddr) {
Wire1.beginTransmission(addr);
Wire1.write(regAddr); // Register address to read
Wire1.endTransmission(); // Terminate request
Wire1.requestFrom(int(addr), 1); // Read a byte
while(!Wire1.available()) { }; // Wait for receipt
return(Wire1.read()); // Get result
}

Hi - I can't add anything to your specific post - although I have a feeling that the camera needs a clock signal to do anything.

Project number 2 on my list is to get the same camera working on a Due - I was attempting to generate the clock myself from the Due - but failed - however I have seen reference to someone who has managed to get high signal rates from a Due (up to 84 Mhz!).

In that I abandoned this approach I lashed out on a adafruit signal generator breakout.

As I said that is project # 2

Project 1 however is a re-write (using some existing code) of the wire library for the Due.

If it all works it should do the following.

Multi-master with ARB loss detection.
Repeated start.
General call handling
A call to allow a stop to be sent (for when repeated start is used and you don't send any more data.
Allow a Due to work happily as a slave (Receive, request) and as a master (send, requestfrom)

I am about to start the initial round of testing now (unfortunately the last 2 nights I have had to do some of my day job from home due to 'issues').

As soon as I get something that I have tested to MY satisfaction, I will post it.

Stan

Stan,

Thanks. I do have the XCLK generated using a 74LS624 VCO chip - I run the clock about 8Mhz cause I don't need a high frame rate. When I said " Everything else is working pretty well" I was alluding to the fact that I can sync on the VSYNC, HREF, and PCLK just fine, but I need to turn off the Free-run PCLK to keep from missing pixels at the beginning of each HREF. I'll probably need to fiddle with some other camera settings too, so getting the I2C working is high priority now to finish up.

I couldn't get a good XCLK signal from the Due either. I assumed when I bought it that it would have an OSC out, but not.
I found that even with 84M speed there aren't a lot of cycles to spare with the PCLK cycling every .0625 usec. So I'm reading REG_PIOD_PDSR to detect VSYNC/HREF transitions (much faster than digitalRead, don't waste your time), and attaching an interrupt to my PCLK pin so I never fall behind on sampling pixels, however this is why I need to turn off the PCLK free-run in the camera, so it gets gated by HREF highs. I'm pretty sure this will solve my issue, and will post some code once I get there.

Anyway, I appreciate you guys who write all the underlying code. I'm a Sys-Eng type myself and always struggle with the coding details (better at reviewing and catching errors than writing it myself:-).

If you meanwhile have a way to bit-bang the I2C interface while working on the Due Wire library, could you maybe send me a chunk of code to do that? Otherwise I'll have to wait for the Wire update, or try to use a second board to update camera registers, and all I have is an UNO R3+ which is 5V and I don't want to mess with converting levels if I can help it.

Thanks again.

Finally got a chance to get some code done.

I now have a Due i2c library that handles multi-master quite nicely thank you.

My test bed is a Due and a Mega (i2c going thru a level converter).

Both boards can successfully.....

Issue a wire.begin with an address

Transmit
receive
request
respond

quite happily.

Occasionally the bus locks up - and this is primarily because I have not put the ARB conflict code in the Due (I have no idea if ARB conflict code is in the mega.......

The other piece of code I want to put in is the handling of a GC broadcast (but theoretically this should not be too hard :frowning: )

The good thing is that is a drop in library - no changes to other base arduino code.

Nearly there

Stan

Hey Stan,

Finally got back, (couldnt find the thread for some time) and I went ahead and implemented the I2C to my camera with my UNO R3+ and a nice level converter chip (adafruit/757 4-bit Level converter works sweet!).

So how did your Wire library project turn out? Is it done? Are you going to submit it into the next release if not there already?

At some point I would really like to remove the "extra board" and configure the camera directly with my DUE, but without a working wire library I have no other options.

I'm seeing nothing new about Due/wire in the forums. I see the latest release is still 1.5.8, but perhaps the nightly build versions have your new library ???
Please let me know if it is available, and THANK YOU in advance.

Glenn