LSM303 register interface compatibility ...

[Ozone]

I recently began working on an driver software for a magnetometer application, which is intended to support both the LSM303 (the LSM303DLHC, to be exact), and the HMC5883L from Honeywell.

And I didn't fail to notice that both devices have identical I2C addresses and identical values for the identification register values (IRA, IRB and IRC).

My question would be, is this intentional ?

Not that it is of utmost importance to me, I found another way to distinguish between both. The HMC5883 has no accelerometer part, and when I can write into a RW accelerometer config register and read the same value back, I deal with a LSM303, else with a HMC5883.

[Andrew Neil]

---

@Ozone wrote:

My question would be, is this intentional ?

---

More likely accidental, I should think.

They are devices from two different manufacturers - I doubt the designers from either company go around checking all competitor's parts ...

[Ozone]

> They are devices from two different manufacturers - I doubt the designers from either company go around checking all competitor's parts ...

That got me wondering.
And not only the I2C adress and ID register values are the same, the internal addresses of those registers as well.
Meaning, you send a I2C read request with the same register offset, and get identical answers from both devices.

I think this is no coincidence, one wanted to be compatible with the other, I guess.
Although I don't expect a full disclosure here ...

[Andrew Neil]

So are any/all of the other registers compatible, too?

[Ozone]

LSM303 :

And HMC5883L:

The LSM303 has an additional accelerometer, and those registers are located at higher addresses.
The magnetometer section of both is so far identical - although some parameters are not, it seems.
At least the maximal update rate of the magnetometer data is different (200Hz vs. 75Hz).

I suppose someone licensed someone else's IP here, and integrated it into his own device.
Keeping all ID data identical seems strange to me, though.