I’m pulling my hair out trying to get i2c12 to work. I have the exact same code (with the obvious exception of hardware.i2c12 in lieu of hardware.i2c89. I’ve tried two different devices. They both work on ports 8 & 9, but neither works on ports 1& 2.
Is there any difference in i2c addressing between i2c12 and i2c89?
AM2315 from Adafruit. I’ve had success with the board in the past, but always used i2c89.
I’m wondering if the “tighter coupling” between 1 & 2 is causing issues. I have these clocked at 100 KHZ, but also tried at 10 KHZ without success. In the past, I’ve used 100 KHZ successfully. I’ve also just tested 10KHZ on 8 & 9 and it works just fine.
Also, I’m using 10K pull-up resistors on all 4 ports. I’m wondering if I should lower the ones one ports 1 & 2 to 4.7K. I had really hoped to be able to use both pairs of ports for i2c, but may have to settle for just using 8 & 9. The issue with the AM2315 is that it has a hard coded address, so I can only attach one of these to an i2c port.
As recommended, I wake up the device and then write to it to request data. On the wake-up write, I get a return code of -2, which seems to be the norm even on 8 & 9. When I do the write to request the data I’m looking for, I get a return code of -3 for 1 & 2, whereas I get a 0 for 8 & 9. With 1 & 2, reply is always null. As stated above the following code works with 8 & 9 (with the obvious i2c change). I sure hope I’m just being dull about some triviality!
server.log("reading ports 1&2"); dummy = hardware.i2c12.write(Am2315Addr,"\\x00"); //Needed to wake up the bus server.log("wake up return: "+dummy); dummy = hardware.i2c12.write(Am2315Addr,"\\x03\\x00\\x04");//Request data server.log("request data write return: "+dummy); imp.sleep(0.15); //give it a moment to work reply<-hardware.i2c12.read(Am2315Addr,"\\x03",6); //Read 6 bytes starting at x03 server.log("reply: "+phex(reply));
Sorry @smittytone, perhaps I misunderstood your question. I’m using an April board that I got through Adafruit.
Are you getting anything out of pin1 and pin2? Try turning on LEDs.
Peter
Unfortunately, no LEDs here at the office. I’ll have to grab some at home and give that a test tomorrow. FWIW, I did connect a simple thermistor circuit to both ports and they’re reading it just fine, so I know the ports aren’t “dead”.
So…I found an optically isolated control relay that has a LED to show output status! I connected it, but see no change when on the CL line. I believe I see a brief dimming when it’s on the DA line and the imp tries to write to the sensor. NOTE – the CL and DA are pulled to 3.3 via a 10K, so I see them “ON” all of the time unless they’re pulled low by the imp. Based upon log data, I also believe the LED might influence the circuit enough to disrupt communications (it seemed to foul i2c89 when connected).
At 10KHZ, it’s really a challenge to see anything and I don’t have a scope.
Also, I simply wired the isolated control relay to the two ports to confirm the imp is able to output and both ports 1 and 2 can output.
I, again, swapped sensors to confirm the sensor that was attached to ports 1 & 2 still works and it does just fine connected to 8 & 9.
It sounds as if you might be experiencing a known pin 1 imp/socket hardware intermittency … you can read more about this at the following links …
http://forums.electricimp.com/discussion/2218/dead-pin-1/p1
http://forums.electricimp.com/discussion/1038/sparkfun-breakout-can-never-get-response-from-pin-1/p1
I’ve dismissed this, @LarryJ, due to the fact that the port still functions as a digital input and a digital output without any problems. If the intermittency pertains or is more susceptible with something like i2c, please advise. Thanks for the feedback. I’m feeling quite stranded on this one.
I have ordered a new April (green like all the others I’ve used) breakout board. Unfortunately, I’ve soldered the April to my own PCB to keep the size as small as possible. The downside is that I can’t simply change the April board. I’ll have to populate another PCB at least minimally to test another board. Alternatively and probably more wisely, would be to simply breadboard it to see what happens.
I stripped my device code down to about 12 lines and I get the same results – i2c12 never works and i2c89 always works. I’ve checked the PCB about 1000 times visually and with a DVM and can’t see any board issues. It’s a very simple board.
Ah, gotcha … I was hoping it might be something simple for you, but sounds like you’ve likely covered that base already. I’m not aware of something unusual related to this intermittency and I2C (but my experience has been just using the pin in a static mode … not using I2C). I can note however the pin1 thing can be quite intermittent … and very frustrating. I’ve had a circuit work for hours, then just stop, then work again later, etc. I was eventually able to attribute the root cause to this mechanical problem, as others have also.
Hopefully someone will be able to shed some light on it for you … will be interesting to learn the resolution on this one.
I appreciate the interest and thoughts. I’m really stymied, but feel stalled until I get delivery of another green April board. I’ve swapped cards without any change in results. I resoldered every connection on my PCB even though it checks out perfectly with a DVM and is a simple circuit (pin pulled to 3.3 via a 10K). So far…one of life’s mysteries.
Green April’s also didn’t show the pin1 issue in general (it was only certain types of socket, eg the one sparkfun used, that showed it).
Really not sure what it could be. No known issues with i2c12. So if you configure pin1 as digital out (with the 10k pullup) you read near zero volts on that pin? (just checking that it’s not a high impedance connection somehow).
So here’s some additional data:
I purchased a new green April board from Adafruit.
I purchased a new imp card.
I set up the circuit on a breadboard with 10K resistors pulling 1, 2, 8 & 9 to 3.3vdc (to eliminate any issue with my PCB).
I’m testing with 2 different AM2315 devices
Both work every time on 8 & 9
Neither works ever on 1 & 2. It always returns a -2 to the write calls
I have confirmed (via an LED) that I can write out of both 1 & 2.
Unless I’m missing something, there has to be some difference with the April and/or the imp card that makes it incompatible with the AM2315 on 1 & 2. Right?
Perhaps I should try a device other than the AM2315, but the packaging is idea for our applications
Any suggestions would be greatly appreciated!!!
What voltage is the AM2315 being run at? Is it the unit in this thread: http://forums.adafruit.com/viewtopic.php?f=22&t=48133 ? The imp is not designed to cope with 5V I2C replies.
Peter
Yes, that’s the unit. I had “assumed” that since the pin was pulled to 3.3Vdc with a resistor and the output as I understood it functioned by pulling the output to ground, that it would work, as it has for months on pins 8 & 9. Perhaps 1 & 2 are simply different enough that it’s not as tolerant. I had hoped it was simply an error on my part, but not of this nature! 
Perhaps I’ll need to hunt for another temperature-humidity sensor that’s similar in accuracy and use it. Any suggestions for a proven device?
Ah no you’re right, I2C is meant to be open-drain. You could find out, I suppose, if you had access to an oscilloscope.
Peter
No scope here.
For now, I’ll just use pins 8 & 9 and we’ll use multiple devices when we need multiple humidity readings. Not ideal, but I’ll stop investing time on this issue.
By the way, Peter, thank you for pointing out the error of my ways. Evidently, the AM2315 will not work reliably with the imp, so I’m going to try the HIH-6130. It seems to have performed well for others and is nearly as accurate.