Basic I2C and different devices

[MagIO2]

As some might know I like to store PASM drivers in upper part of EEPROM. Now that I have a QS and a Spinneret it is time to store some drivers in their EEPROM as well. But the code I have running since I do this kind of stuff did not work!

In my older setups, a breadboard and a GG board, I used FRAM instead of the EEPROM. It turned out that the FRAMs behave differently.
To read the same location I do the following:
i2c.ReadPage(i2c#BootPin, $a2, $7e00, buf, 512) for the FRAM
i2c.ReadPage(i2c#BootPin, $a0, $fe00, buf, 512) for the EEPROM

I changed my code that's used to handle all the driver stuff. Now it has to be told during initialization which device is attached! But then I need a version of the program per device.

Another possibility would be to loop over all different kind of devices, trying with $a0/$fe00 first and then $a2/$7e00. And here is the question: What can go wrong if I simply try out the devices? What can go wrong then in future with other devices attached? Is there maybe a better way to find out which device is attached?

[Mike Green]

1) The Basic_I2C_Driver generates its select code from two sources ... the explicit one given as the 2nd parameter and the upper bits of the address passed as the 3rd parameter. Each select code occupies 64K in a 512K address space. $a0 occupies $0000 to $FFFF and $a2 occupies $10000 to $1FFFF. You can put $a0 in the 2nd parameter and use addresses from $10000 to $1FFFF and you'll be able to access the FRAM.

2) There's usually no way to determine what's at a particular I2C device code. Some devices like memories use a 2 byte address field. Some devices use a 1 byte address field. Some devices don't use an address field at all. You really have to know what's connected to your I2C bus. If you're just dealing with memories, you're pretty safe. There are ways to see if you have a 32K or 64K EEPROM or FRAM at a particular device select code. Larger memories just behave as multiple devices, each 64K.

[MagIO2]

Thank you Mike!

Hmm ... had to recheck with the datasheet. If I read it right the FRAM actually uses slave address $A0 and memory address $0000-$7FFF and slave address $A2 and memory address $0000-$7FFF. A15 is placed in bit 1 of the Slave Address byte, whereas the MSB of the memory address is a don't care. And it makes sense, as otherwise the FRAM would not work as boot-device. But in other words 64k of the address-space are wasted in these devices. Strange that they did it that way!

Is the A in the slave-address $Ax reserved for memory devices or do the manufacturers of I2C devices simply pick a slave-address on their own will?

[Mike Green]

$Ax for some reason was chosen for memory devices. Other device select codes have been used for other types of devices. Philips, and now NXP, owned the patents on the I2C bus and therefore controlled the assignment of device select codes. Since some or all of these patents have now expired, I don't know how new devices are assigned codes. Since there are a limited number of codes available ($1x-$Fx), I assume they're all allocated.