Downloading and uploading to I2C EEPROM...

G

Grogster

Senior Member
Hi there everyone. :)

I have a project that I am likely to tinker with over the Christmas break, which involves storing quite a bit of data on an EEPROM running on the I2C bus. This data will be a combination of raw data that the PICAXE can read and write when needed, but 75% of the memory-map will be ASCII text messages which the PICAXE can read out of the chip and show on the LCD when needed for various things - it's a way of saving program space on the PICAXE itself, as lots of text messages can gobble up all your program space. :p

My main concern at this point is, uploading and downloading the data from the EEPROM to the PC and back.

Reading would be relatively straightforward - setup a routine which when selected(there will be LCD and button control) simply transmits the entire memory map one byte at a time, serially to the computer running some terminal software, then save the terminal session - done. :)

However, what if I wanted to write back the computer file to the EEPROM?

You might say that you can reverse the above, but you can't as page-errors and overflows have to be controlled when writing large amounts of data to EEPROM.

Does anyone here have any pointers on the best way to get a download from a computer into the EEPROM chip?

I was thinking of making use of CTS and RTS on the serial port, using PICAXE IO pins, which SHOULD control the data flow to the EEPROM via the PICAXE, allowing the PICAXE to control the writing speed to the EEPROM and prevent page-errors - correct?

I might be slightly off track with my understanding of things, so please feel free to offer pointers and suggestions.

I am currently reading my way through the 24LC256 EEPROM chip manual.
This EEPROM supports page writing, with a 64-byte page length, so I have to be able to control writes at no more then 64-byte pages at a time.

...back to the reading...
 
Last edited:
In the past, I have just written a PICAXE BASIC program to hold the data and load that into the PICAXE and run same to write the data into the EEPROMs. Works well if you do not need to change the EEPROM data frequently.

You can write quite large blocks of data, it is just a case of observing the 64 byte boundaries for page writes.

You can see some examples of my past programs to write bulk data to 24LC256 EEPROMS in this thread. See post 14 and others:
http://www.picaxeforum.co.uk/showthread.php?t=10014&highlight=A55*&page=2
 
Cheers - will read that thread. :)

When you mention "Respect 64-byte page boundries":

Do you have to send 0x00 as data to con-encide with the page boundry, or just send 0x00 as a word to tell the EEPROM you have finished sending data?

...at which point, it then needs a little time to actually write those bytes internally.

EDIT: Ahhh - I think I understand.

Write dummy bytes to fill up the page(in your case, 0x00), then a pause to allow the EEPROM to write that data internally, then you can write the next page - correct?

I think I understand that right...
 
Last edited:
Some notes that may help you:
1. It is not necessary to completely fill every byte on a page of 64 bytes but there is a need to ensure that when writing a group of bytes, you do not flow over a page boundary as the address pointer will revert back to the start of the current page and overwrite previous bytes at lower address lcoations.

2. There must be a pause of at least 5 ms after every page write to EEPROM whether that is a few bytes or an entire page.
 
Ahhh - so therefore, lets say I wrote only 10 bytes.

1) Write the bytes to the EEPROM
2) Wait at least 5ms to allow the EPPROM to commit those bytes to memory

So, in other words, I DON'T HAVE TO PAD OUT THE DATA TO 64 BYTES THEN PAUSE, I just have to make sure that I don't exceed 64 bytes in any one write command, or more then 64 bytes in multiple write commands, without a pause.

Correct?

I think I have it now... :)
 
If you write 10 bytes at a time then your first steps are right
1. write ten bytes
2. pause

But after six consecutive writes if your address keeps advancing, you have now written from address 0 to 59 (a total of 60 bytes).
Then the page limit comes in at this point when you try to write beyond address 63.

In the next lot of 10 bytes,
byte 1 will be written to address 60
byte 2 to address 61
byte 3 to address 62
byte 4 to address 64 (not at the page boundary)
byte 5 to be written to address 0 as the address rolls over within the current page.

If you can do page writes on lots of 2, 4, 8, 16, 32, 64 bytes then there is not generally a problem.

But with other groupings such as 5 bytes (as often used for fonts) or 10 bytes as you suggest then you have to make sure that you do not try and cross the page boundary within a single write command.
 
Thanks for your help. :)

I guess at this point, I need to breadboard an experiment and do some writing tests to see what happens.

If you write the aforementioned 10 bytes, so long as you have a pause before you write any more, should that not cure the issue?

However, I think I grasp it - the important thing is that you don't exceed the page boundry during ANY write. Avoid that, and everything should be OK.
 
Thing of it as writing in a notepad of paper. Each WriteI2c / HI2cOut puts a sentence on the page you're looking at.

The sentence can start anywhere on the page can be from one character to however many fit on the page. After each of those commands, a write of one sentence, you need to wait for the ink to dry.

If you are writing a sentence on the last line of the page, and you reach the end of the page, you cannot turn the page, but have to continue writing from the first character of the first line of the same page.

If while writing you reach the end of the last line, the end of the page, you can stop, pause, let the ink dry, then turn to the next page.
 
Didn't you used to be able to get EEPROM programmers?

A ZIF socket with an interface to a computer COM port, and you could not only program PIC chips, but also the common EEPROM chips too, by downloading to the chip from a file on your PC.

Anyone know anything about these, and where I could get/make one?

It would be exceedingly helpful, if I could pre-program the EEPROM then just plug it in for the PICAXE to use it...
 
Grogster said:
Didn't you used to be able to get EEPROM programmers?
Click to expand...

No, you couldn't.
You could get UV erraseable EPROM programmers.
(for the pedantics, some were capable of loading data into byte wide EEPROM)

If you are going to use the 'classic' byte-wide EPROMs then get a programmer and wire up an entire PICAXE port to the data bus and two ports to the address bus.

Alternatively, wire two PICAXE I/O lines to an I2C EEPROM and download data to it.
 
Last edited:
Grogster said:
Didn't you used to be able to get EEPROM programmers?

A ZIF socket with an interface to a computer COM port, and you could not only program PIC chips, but also the common EEPROM chips too, by downloading to the chip from a file...
Click to expand...

Yes, altronics and Jaycar sell a Pic programmer that can program
24Cxx series EEPROMs but not the 24LC series
 
Downloading and uploading to I2C EEPROM

You might also look at Ponyprog - it has support for reading and writing I2C eeproms using a simple hardware programmer that you can either build or buy. Ponyprog is a nice software and hardware solution that can program a lot of devices. The website is HTTP://www.lancos.com/prog.html.

Rick
 
rhaseman said:
You might also look at Ponyprog - it has support for reading and writing I2C eeproms using a simple hardware programmer that you can either build or buy. Ponyprog is a nice software and hardware solution that can program a lot of devices. The website is HTTP://www.lancos.com/prog.html.

Rick
Click to expand...

You still need a hardware programmer such as that I mentioned in post 14.
Ponyprog is then in itself still limited to the 24Cxxx series EEproms and not the 24LCxxx series


Still considerably easier for small quantities to program via the Picaxe chip
 
Last edited:
Please excuse a complete noob at this, but may I ask for some advice?

I am designing a circuit where a PicAxe-20M2 needs to talk to an EEPROM (24C65-I/SM) over I2C. In total, there are 13 variables that need to be read and written, each consisting of a 16-bit integer. A schematic of the circuit is available here.
I have no experience with C or assembler, and it's been some 30 years since I wrote any BASIC.
 
The PICAXE manuals are great ... you'll want to focus on Manual #2 which has all the commands and such ...

1: Start small ... get your 20M2 running a blink sketch to get you back into the groove of using BASIC
2: Write a program that stores a single byte to the I2C EEPROM
3: Write a program that reads-back the EEPROM
4: Modify your program to store a WORD (2-bytes) to EEPROM
5: Run your read-back program and make sure it works ...
6: Write your program to store 13 WORDS to EEPROM!
 
You might like to look at this thread
E

Thread '16 caratteri'

Ciao a tutti
Vi espongo il mio problema che ho gia' parzialmente risolto in un recente forum.
Allego programmi di scrittura e lettura per EEPROM 24LC256 che mi sembrano a posto ma il risultato di
lettura non e' quello sperato.
Spiegazione:
La scrittura viene fatta con 16 caratteri per ogni pagina di 64 caratteri.
La lettura avviene per ogni pagina leggendo i 16 caratteri scritti.
Se scrivo solo 4 righe (16*4=64 che coincidenza!) il risultato e' corretto, se invece scrivo 5 righe c'e'
sovrapposizione di caratteri non voluta (pur considerando la paginia di 64 caratteri)
Per ottenere il...
(admittedly it's in Italian) which does reads and writes via I2C to EEPROM.
It doesn't need much modification to read and write pairs of bytes (i.e. 16 bits or one word)
 
You must log in or register to reply here.
Back
Top