Pages: [1]   Go Down
Author Topic: wire library endTransmission() still not working with Due  (Read 252 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 2
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 2
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 1
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
}
Logged

Offline Offline
Newbie
*
Karma: 0
Posts: 35
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Pages: [1]   Go Up
Jump to: