Serial to Picaxe to EEPROM and back

johnnewyork

New Member
Hi Guys, I'm looking for help with a new project. I'm not a great software coder but I want to learn. I have made a few small projects using the 08m2 PICAXE with small serial I/o. Now I would like to use a Picaxe to received a "file" serially and store it in an EEPROM then later transmitt the saved "file" back out the serial port. My main problem is how to Write to EEPROM with a Serial interface. I would like to receive and transmit at 38400 baud and save a variable sized file of about 20K bytes. I don't need to perform any background serial I/O.

I am familiar enough with For Next loop statements and reading characters from the serrxd but I don't understand how to receive large amount of "data" character and save it in real time.
I have read through a lot of example posted here but I still don't understand. I have a 28x2 and a 20m2 for prototyping and a EEPROM kit.

I believe I need something like this:

code:

code to initiate the transfer
"here"

;for reading the characters
Transfer_to_EEPROM

HI2CSETUP I2CMASTER,%10100000,i2cfast_32,i2cword ;Set-up for eeprom

for b0=0 to 2500 ; read in 20000 characters and save then in the EEPROM
serrxd (b0,b1,b2,b3,b5,b5,b6,b7)
writei2c, 0, (@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc,@ptrinc)
pause 40
next b0

;
code to initiate the transfer
"here"


;for sending the characters
Transfer_to_PC:

for W1=0 to 1023
readi2c W1,(B1)
pause 40
hserout 0,(B1)
next W1

Any help would be appreciated.

thanks john
 

geoff07

Senior Member
You are going to need a serious eeprom to store 20k bytes. I am currently working on a project that writes to a separate eeprom. If the one you use is anything like the one I am using (1k bytes, 25LC080, spi), you are going to have a little more to do. Eeprom is not like ram. The eeprom has write protection to deal with, and also paging. These complicate matters a bit (you will need the eeprom data sheet).

The sequence will be something like:

1 set write enable (chip select, send enable command, chip unselect). The unselect actually executes the command.
2 send the Write command (chip select again, send command, unselect)
3 send the address to write to (2 bytes)
4 send a page of data (16 bytes in my case)
5 wait until the write command has completed (send a status request command and read the response)
step and repeat

Although I am using an spi eeprom the fundamental logic is likely to be the same. The paging means that you have to accumulate bytes in a page buffer and write them as a page or have some complicated logic to manage where the data goes. Fortunately, once written, reading is purely sequential and thus uncomplicated.
 

Goeytex

Senior Member
Whether or not this is practical or even possible with a Picaxe depends upon how fast the data arrives and how fast the Picaxe can move the data from ram to the external EEPROM.

1. Is the incoming data a continuous stream of 20K bytes at 38400 baud?
2. What is the source of the data ?
3. Can it be programmed to pause for a while every 1024 bytes ?
4. Can you add a 16Mhz crystal / resonator to the 28X2 so that it can operate at 64 MHz?

The 28X2 has a 1024 byte serial input buffer (scratchpad) that can receive data in the background. The data can be moved to EEPROM on the fly as long a the buffer is not overrun. The scratchpad can be programmed to be a circular buffer so that all 20K bytes can be continuously received and moved to EEPROM. However how it is implemented or whether it can work at all depends upon your answers to 1, 2, 3 & 4 above.

It think it is safe to say that this is not practical or even possible using serrxd or serin unless you can slow the data down and pause the incoming data as needed s0 that the Picaxe can keep up with the incoming data.

I am not sure if HI2C will interfere with the incoming data using hardware serial background receive, so hopefully Technical or hippy will see this and let us know. If it does conflict then all bets are off.
 

westaust55

Moderator
An EEPROM such as the i2c 24LC256 is 256 kbits = 32 kBytes
Usually you will only write around 8 or 16 bytes to EEPROM at a time.
64 bytes is the largest block for more typical EEPROMs (= page size)
And after each multi byte write there is a need to wait 5ms before the next write.

This along with info already given suggests a need to slow down the serial data from PC to PICAXE.
 
Last edited:

grim_reaper

Senior Member
I agree with all the responses above. My data is nowhere near as big (I use the PICAXE EEPROM rather than an external one), but the principal - and the problems - are the same.
The way I solved the data flow speed problem was to simply write the data from the PC in chunks/pages. So if I want to store all 255 bytes into the EEPROM, I send a packet of data something like "1, 32, x, x, x, x, (plus 28 more x's!)", meaning "Chunk #1" (store at address 1), length is 32 bytes, here they are.
Fixing the length at a known number also allows you to not overrun the scratchpad and use the other half of it for other things.

Hope that helps a bit!
 

hippy

Technical Support
Staff member
If the data is simply thrown at the the PICAXE, at 38400 baud a new character could be arriving at the PICAXE every 260us, and that would likely be too fast for a PICAXE to handle while updating EEPROM at the same time.

Using some other mechanism to send the data a byte or chunk at a time should however work. It might be possible to use XMODEM or a similar protocol or it might require the writing of some PC-side software to support doing it.
 

grim_reaper

Senior Member
Yes hippy, perhaps I should have clarified in my rambling... to do my chunk-at-a-time code, I used a 20X2 and background receive on the HW serial, plus it was only at 19200 baud, so the AXE coped very well.
Also, since I do indeed write PC software, that bit was designed specifically to send a chunk and wait for a positive response from the PICAXE before sending the next one.
 

geoff07

Senior Member
a new character could be arriving at the PICAXE every 260us, and that would likely be too fast
This is what flow control is for. Not used much in these USB days but still simple: either XON/XOFF characters or DSR/CTS signals. Perhaps it can be applied in this case.
 
Top