| View previous topic :: View next topic |
| Author |
Message |
edhaslam
Joined: 15 Jul 2005
Posts: 89
Location: UK
|
| How to check number of/size of I2C EEPROM chips installed |
 Posted: Thu Sep 22, 2005 5:11 am |
 |
|
Hi all,
I'm currently designing a datalogger that can have a maximum of 8 24LCXXX memory chips installed and I'd like to know if there is a way of checking how many are installed and also the size of chip is installed, when the firmware first loads up. Does anyone have any ideas/code on how to do this?
Cheers,
Ed |
|
 |
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Thu Sep 22, 2005 7:54 am |
|
|
I'm not sure if I'm the best to answer this, but...
I would try a test for "ready". You can find this in some of the drivers included in compiler. Basicly it write the device address and waits for an i2c ack (ackknowlege). If you get it, then you know that chip exisits. If you don't((timer involved here)) then that chip isn't installed. |
|
|
Guest
|
|
| Posted: Thu Sep 22, 2005 11:21 am |
|
|
| treitmey wrote: | I'm not sure if I'm the best to answer this, but...
I would try a test for "ready". You can find this in some of the drivers included in compiler. Basicly it write the device address and waits for an i2c ack (ackknowlege). If you get it, then you know that chip exisits. If you don't((timer involved here)) then that chip isn't installed. |
Thanks, I'll have a look through the data sheet and see what I can find out about this.
Does anyone know if there is a way to find out the size of the device? |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1909
|
|
| Posted: Thu Sep 22, 2005 1:00 pm |
|
|
As far as the size of the EEPROM is concerned, what I'd look at is the chip's response to a memory read from an address "above" its maximum.
My gut feeling is that the MSb would be ignored. Say that you have a 32kbit eeprom - it only recognizes the least significant 12 bits of the 16 bit address (2^12 = 4096 bytes = 32kbits).
Hmm. What I'd do is read, and remember, the data from the first 8 memory addresses (addresses 0 - 7) in the eeprom. This would require 3 address bits. Then try reading from addresses 0x0010 - 0x0017. If these 8 bytes are different from the ones you read from addresses 0-7, then the eeprom has at least 2^4 bytes of memory. Repeat the process for addresses of 0x0020 - 0x0027, 0x0040 - 0x0047, and 0x0080 - 0x0087. When you read back the same data as you did from addresses 0-7, then the address has wrapped, and you know the max size of your eeprom.
For my 32kbit eeprom example, I'd read the same data as from addresses 0 - 7 as soon as I hit an address of 0x1000 - 0x1007 because the 4 MS bits of the address would be ignored by the eeprom, which would interpret 0x1000 as 0x0000.
There are probably quicker ways, but this should give you an idea of how to solve the problem. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Thu Sep 22, 2005 3:01 pm |
|
|
| newguy wrote: | As far as the size of the EEPROM is concerned, what I'd look at is the chip's response to a memory read from an address "above" its maximum.
My gut feeling is that the MSb would be ignored. Say that you have a 32kbit eeprom - it only recognizes the least significant 12 bits of the 16 bit address (2^12 = 4096 bytes = 32kbits).
Hmm. What I'd do is read, and remember, the data from the first 8 memory addresses (addresses 0 - 7) in the eeprom. This would require 3 address bits. Then try reading from addresses 0x0010 - 0x0017. If these 8 bytes are different from the ones you read from addresses 0-7, then the eeprom has at least 2^4 bytes of memory. Repeat the process for addresses of 0x0020 - 0x0027, 0x0040 - 0x0047, and 0x0080 - 0x0087. When you read back the same data as you did from addresses 0-7, then the address has wrapped, and you know the max size of your eeprom.
For my 32kbit eeprom example, I'd read the same data as from addresses 0 - 7 as soon as I hit an address of 0x1000 - 0x1007 because the 4 MS bits of the address would be ignored by the eeprom, which would interpret 0x1000 as 0x0000.
There are probably quicker ways, but this should give you an idea of how to solve the problem. |
An erased EEPROM or one initialised to a constant value will also pass this test. Also, in some of my projects, I deliberately duplicate EEPROM data so that I have current user modified paramters and "as built' paramters to enable the user modified paramaters to be "factory reset". So the above test would fail.
I suggest you read the first location and save it to memory. Call this "reference" Then starting at the next smallest EEPROM size, test the first value at the page boundary (call this "current").
If the value is different then we are still within the EEPROM so repeat the test at the next boundary.
If it is the same as "reference" then you have a potential wrap condition and therefore the previous EEPROM size is a candidate. Write the compliment of the reference value to the first location in EEPROM. Test if the value of current location has changed. If it has changed then a wrap condition has occurred. Restore the original contents of the first location. If a wrap occurred then you have discovered the size of the EEPROM. If not then continue this process upto the maximum possible EEPROM size.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
edhaslam
Joined: 15 Jul 2005
Posts: 89
Location: UK
|
|
| Posted: Fri Sep 23, 2005 1:35 am |
|
|
| Thanks guys, good food for thought there. I'll let you know how I get on... |
|
|
edhaslam
Joined: 15 Jul 2005
Posts: 89
Location: UK
|
|
| Posted: Fri Sep 23, 2005 1:52 am |
|
|
| treitmey wrote: | I'm not sure if I'm the best to answer this, but...
I would try a test for "ready". You can find this in some of the drivers included in compiler. Basicly it write the device address and waits for an i2c ack (ackknowlege). If you get it, then you know that chip exisits. If you don't((timer involved here)) then that chip isn't installed. |
Strangely, the 2401 - 2465 drivers have the following code in them:
| Code: |
BOOLEAN ext_eeprom_ready() {
int1 ack;
i2c_start(); // If the write command is acknowledged,
ack = i2c_write(0xa0); // then the device is ready.
i2c_stop();
return !ack;
}
|
But the 24128 and 24256 don't - which is strange. Is there a reason for this? It looks as though it would possible to add this code into those drivers? |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Fri Sep 23, 2005 7:24 am |
|
|
Don't add code to the driver file. Add the code to your program file. otherwise when you install a new compiler your modified driver file will be overwritten with the new compilers' driver file.
Last edited by treitmey on Fri Sep 23, 2005 7:51 am; edited 1 time in total |
|
|
Mark
Joined: 07 Sep 2003
Posts: 2838
Location: Atlanta, GA
|
|
| Posted: Fri Sep 23, 2005 7:27 am |
|
|
They put it at the end
| Code: |
status=i2c_write(0xa0);
while(status==1)
{
i2c_start();
status=i2c_write(0xa0);
}
|
Not the best way. The code will sit there until the write is complete wasting processor time. It also leaves the bus with a Start condition. Not a good thing when you have multi masters on the bus. |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Fri Sep 23, 2005 7:47 am |
|
|
| Right. In my post(sencond in this list) I put in a blip that says he needs a timer for that check. I didn't want to write the whole thing for him. I just wanted to point him in the right direction. |
|
|
edhaslam
Joined: 15 Jul 2005
Posts: 89
Location: UK
|
|
| Posted: Sat Sep 24, 2005 10:08 am |
|
|
| treitmey wrote: | | Right. In my post(sencond in this list) I put in a blip that says he needs a timer for that check. I didn't want to write the whole thing for him. I just wanted to point him in the right direction. |
Thanks for the shove in the right direction guys. Much appriciated. I think implementing a timeout is definitely the way forward. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
