Re: [Gumstix-users] i2c with Heart Rate Monitor Interface questions

[Marc H. <mhu...@lo...>]

which OP jumpers did you install? You may have misinterpruted the address strapping. For addr 91 I'd expect to see OP3 and OP6 installed plus OP0 installed for I2c MODE.

----------------------------------------

From: "Turley, Kimberly" <kim...@ni...>
Sent: Thursday, August 06, 2009 11:30 AM
To: "gum...@li..." <gum...@li...>
Subject: [Gumstix-users] i2c with Heart Rate Monitor Interface questions 

Hi!   
  
I'm working on a physiological monitoring system using an Overo Air with a Summit expansion board and some sensors (a Heart Rate Monitor Interface (HRMI) from SparkFun  http://danjuliodesigns.com/sparkfun/hrmi_assets/hrmi.pdf and a 1-Wire Temperature Sensor also from SparkFun), and I am, unfortunately, way out of my depth, so I apologize in advance for what will probably be pretty dumb questions and poor use of terminology.  The advice on this list has already been hugely helpful to me, but I've finally hit a dead-end trying to configure the i2c connection to the HRMI board. 
  
I've managed to get i2c-tools successful installed, and I am booting from the image I compiled (image version 2.6.30-r39) on a MicroSDHC card.  I've connected the hardware as instructed using the SCL and SDA communication channels from the HRMI board to the SCL and SDA connections on Overo's i2c-3 bus.  The HRMI board is configured in i2c mode with an address of 91 (0x5b) and has an external 4.5V power supply.  As per the post in the I2C Overo Test thread, I did not add additional pull-up resistors to SCL and SDA:  
  
(" The  Summit  board does not have  I2C  pull-ups. But the  Overo  board does   
have pull-ups (4k7 ohm). R20 and R21 are the resistors on the Overo.")    
  
But I am really unclear if I have understood this correctly, and I was unclear from the documentation in the manual above whether level shifting is required between these two connections. 
  
Now I'm trying to read from the i2c-3 device using i2c-tools.  I ran the i2cdetect -l, which listed the i2c-3 and i2c-1 devices, but when I ran i2cdetect -r 3 I got: 
root@overo:~#  i2cdetect  -y -r 3   
      0  1  2  3  4  5  6   7  8  9   a  b  c   d  e  f 
00:            -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --  
  
So clearly it is able to detect that a device is there (when I run this command while the HDMI board is unpowered, the connection times out instead of returning the above chart), but I am unable to write to or read from the device, which I assume has something to do with the address is not being found. 
  
And at this point I really don't know how to go about testing the device - beyond i2cdump, which returns: 
root@overo:~#  i2cdump 3 0x5b  
      0    1    2   3  4   5   6   7   8   9   a   b   c   d   e   f       0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX 
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX 
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX 
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX 
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX 
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX 
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX  
80:  XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX   
90:  XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX   
a0:  XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX   
b0:  XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX   
c0:  XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX   
d0:  XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX   
e0:  XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX   
f0:   XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX      XXXXXXXXXXXXXXX   
  
Actually, it will return that no matter what address I put in, so long as the HRMI is powered on. 
  
Can anyone point me in the right direction for how to go about addressing these issues (To summarize:  
1. Is level-shifting required?  
2. What is the command format to address inquiries to the HRMI?  
3. Can you make any other recommendations to me about how to go about debugging this? 
)? 
  
Thank you so much for any help you can offer! 
  
-Kim