I2C Comm with Digital Compass HMC6352

[skimask]

I'm fairly you don't have the I2C command syntax's correct.
Double check the PBP manual and see what you come up with.

[jihlein]

Skimask,

The manual shows the addr parameter as option. Since this isn't an EEPROM, and from looking at the HMC6352 data sheet, I figured that the commands should be sent as data arguements.

I can try sending what I'm calling cmd as the address argument:

I2CWRITE SDA, SCL, $42, [cmd, addr], nowrite

becomes

I2CWRITE, SDA, SCL, $42, cmd, [addr], nowrite

later today. It does seem like my write commands are somewhat working, however. If I change the commands to write and read RAM rather than just read EEPROM, I can see the RAM data change with the read command, it's just off by 1/2.

Looking at how the module responds to commands, I'm not sure how I would restructure the I2CREAD command. Maybe it needs a dummy addr argument??

At the moment I can't tell if the issue is on the write or the read side, but since I've tried to read known values from EEPROM and they are off by 1/2, I tend to think the read side is where my problem lies. I'm wondering if it's a data type issue, although the documentation says the data will be transmitted in bytes.

Thanks,

John

[skimask]

The manual shows the addr parameter as option. Since this isn't an EEPROM, and from looking at the HMC6352 data sheet, I figured that the commands should be sent as data arguements.

Yep, I got that.
But I still don't think they're right for what you want.
And is the module getting the 70uSec delay it requires after requesting the data from the eeprom?

[JD123]

Values that come in as 1/2 what they should have been shifted right one bit. You are loosing the LSB somewhere? I don't know the in's and out's of exactly what PBP does when shifting in I2C, but it might be that PBP is expecting one more bit. Does that compass send out 8 bits... or does it send out 7? Maybe it's sending out 9?

Anywho, it's a byte shifted right... some where, some how.

Does this from the datsheet have anything to do with your problem?

"Negative binary values will be in two’s complement form"

[skimask]

Values that come in as 1/2 what they should have been shifted right one bit.

Or maybe...
North 360 / 2 = 180 South ..... 1/2 the value
Are those values always exactly 1/2? Or are they just close to 1/2...

[jihlein]

It sure does look like a byte shift. For reading EEPROM/RAM locations, I believe it is just sending back an 8 bit byte. If you choose to read raw magnetometer data rather than computed heading, that's where the 2's complement comes into play. I haven't got that far yet, and FWIW, plan to read computed heading. Thought it would be a good simple test to just try to read an write some simple values to the unit before trying to take measurements....

The delay I put in is consdierbaly longer than the delays mentioned in the data sheet. From my understanding og the I2C protocol, the extra wait time should not be a factor. Whether or not it "bugs" the compass processing I can't see. Can reduce the wait time to the recommended 70 usecs and see if that changes anything.

If else fails, I'll take it to work and watch the transaction on a digital storage scope and see what's occuring.

[jihlein]

The values are exactly half.

Got a couple of quick posts here -

Haven't tried taking measurements yet, figured if I can't write and read simple bytes correctly, I wouldn't be able to set the operating mode and read data correctly. Baby steps.

When reading out a computed heading, it's a 2 byte read. The combined value will be 0 to 3599.

[jihlein]

Success!

The code as written works fine if you add the following define at the beginning:

Define I2C_HOLD 1

I added this line, made the delays the appropriate times, and could read EEPROM correctly.

Took the next step and could write RAM and read it back correctly.

Finally, put the device in standby mode, commanded it to compute heading, and all works as it should.

On to the control law (the "easy" part!!)

John