General I2C advice

[malc-c]

Hi,

I have a project which currently uses READ to write data to the PICs memory on programming and as part of the option to store changed values of variables etc and time and date from a DC1307 RTC.

The RTC used I2C to communicate with the PIC. I would also like to use an External Serial EPROM to store date, time (HR:MIN), and the contents of four word variables (three digits), something like 290920101945234236240242 (29 09 2010 19:45 234 236 240 242 for 29th Sept 2010, 19 hrs 45 min, temperature1 temperature2 etc). This could be updated every minutes (1440 records per 24 hours)

I would also like the data to be rolling, ie if it's possible to store 7 days worth of data, it would overwrite day 1 on the 8th day.

I've not used EPROMS before and would welcome suggestions on suitable chip to use and how to correctly address it, given that I'm already writing to the PICs memory and reading data from the RTC module. I would also like the cntents cleared once it's been downloaded to a PC application. So for example once the PC receives the last bit of data it sends a character via HSERIN that then makes the PBP code clear the contents of the external eprom

[Jerson]

Hi Malcolm

First, a little warning about EEPROMs - updating it once a minute could run it out pretty quick. You can do the math. Assume a standard eeprom has 1,000,000 write cycles. Now, this is spread over a block worth (64 bytes in some) even if you write a single byte. Soon, you will realize that your eeprom can last at best 2 years if you use the block write mode.

I suggest you consider a larger write interval assuming nothing changes very drastically in a temperature chamber over a period of a minute.

As for the EEPROM, you could go with any of the 24C series. You might be able to fit a lot into a 24C256 or 24C512 and if you need to go further, 24C1024

Regards

[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.