General I2C advice

[prstein]

Hello Malcom,

Consider using F-RAM.

It's very fast writing (compared to EEPROM) but otherwise works about the same way. I believe they claim unlimited writes (or nearly so). I've used the SPI versions with good success.

Best Regards,
Paul

[aberco]

Looks sweet, I 'll evaluate those F-RAM from Ramtron too, thanks for the info.

[malc-c]

Guys, thanks for the advice and suggestions. Farnel seem to stock FM24C512 and I guess at £12 it's not bad when you consider the read/writes are claimed to be in excess of 10 billion !!

I'll also look at dropping the sample rate down, but when the room is cold and a heater should fail, the temperature in the reptile enclosures can drop quite a bit in a several minutes. IF the sample rate was a lot less, any graph from the resulting data would be a bit basic

[HenrikOlsson]

Hi Malcolm,
The 24x512 has 512kbit worth of storage space, that's 65535 bytes.
Counting the number of bytes in your "packet":

29 09 2010 19:45 234 236 240 242

I get 14 bytes (because the last four values CAN be higher than 255, right?).
So 65535/14/60/24 = 3.25 days. So, in short, you won't be able to fit your seven days worth of data doing it that way.

Storing the date and time at startup only (and when it wraps around) will basically save you 6 bytes per record. If you know you are recording once per minute there's really no need to save save the time - every time. That's still not enough to get 7 days into a 24x512 though.

Well, just something to think about.

/Henrik.

[aberco]

If you record time + date with your sample, it is not necessary to take equally spaced samples. you could sample at a slow rate, but when there's some big variations measured, increase the sample rate.

Or as HenrikOlsson said save memory by storing only the fist time/date tag, but then you have to keep the same sample rate. This is the solution I'm implementing currently in my USB temperature logging jumpdrive.

Here is the table I generated, considering an header of 40 bytes in EEPROM, followed by individual 12bits temperature samples (I use a TMP100 sensor which output celsius values at 11bits + sign).

[malc-c]

Guys, once again, thanks for the heads up with regards to the amount of data I could store. I guess the only options I have is to reduce the sample rate down, or, if 512 will store 3 and a half days, then 1024 would hold around a weeks worth....

I have one of these home weather station



http://www.foshk.com/Weather_Professional/WH1080.htm

Not sure what memory it has, but it sends temperature, wind speed, wind direction, rain fall, air pressure and humidity readings at least every 5 min and can store two weeks worth before roll over !

Does increasing the size of the memory have other problems when used with PICs?

If used on the same pins that the RTC (DS1307) is connected to what would be the ideal address to use, and do I use the IC2WRITE / IC2READ to send / retrieve data ?

[aberco]

RTC and EEPROM can share the same I2C bus, and they have their own address (check the datasheet). A0/A1/A2 allows you to put more EEPROM on the same bus, but it won't conflict with the RTC (MSB part of the address is hard-coded in the device, and LSB part can be set up by user depending of the device).

You could also use an SD-card as your storage medium. It is a bit more complicated to use, especially if you want a FAT system (check on this forum there's some examples).

I would go with I2C EEPROM, but storing data in binary rather than ASCII.