EEPROM write time = what?

[Pommie]

I'm trying to find the maximum time a write to EEPROM could take. I've checked the datasheets and searched the Microchip website to no avail.

I have written some code to measure the time and for a 16F876A it appears to be 4.5mS. This only allows about 200 writes per second which seems very slow. It appears to be independent of clock speed.

The reason I ask is because I have a project which involves transferring a file from a PC via hyperterminal to the pic and then to EEPROM. I had it running at 19200 baud and my fifo overflowed . I now have it at 9600 baud and have the EEPROM writes on an interrupt so I can process the next line while the last line is being stored. My worry, is that the maximum time could be anything as the datasheet states that it is temp and chip Dependant and to check the AC characteristics which are blank.

I could drop the speed down to 4800 but I'd rather not if I can find reassuring timing figures.

So, does anyone have any idea where I might find this info?

Mike.

 

[eblc1388]

Your measurement is well on the spot. The specific EEPROM location needs to be erased first before written to so that would account for the relatively long timing.

The actual timing data is hidden inside the DC characteristic of the datasheet. The timing seems to be independent of the MCU clock speed but I remembered some "overclockers" mentioned data error with EEPROM write at 24MHz or higher clock speed on a 20MHz PIC.

 

[manish12]

It is not possible to you send the file from pc to mc and than eeprom.
because hyper terminal send the data continues to the serial port.
mc and memory req. some time.
I was make similer project stand alone eeprom copier as well as pc dump ability for 4kb - 16kb eeprom.
best way to do this ,is that make small c/vb prog for sending byte by byte data from file if possible use ack.

 

[Pommie]

Your measurement is well on the spot. The specific EEPROM location needs to be erased first before written to so that would account for the relatively long timing.

The actual timing data is hidden inside the DC characteristic of the datasheet. The timing seems to be independent of the MCU clock speed but I remembered some "overclockers" mentioned data error with EEPROM write at 24MHz or higher clock speed on a 20MHz PIC.

Thanks, I missed that in the datasheet.

Looks like I will have to drop down to 4800 baud as the worst case is 8mS.

I thought I had found a way around the problem when I realised that writing to flash only took 4mS to write 4*14bit words, almost 8 times faster than EEPROM. However, the processor stops during this 4mS and so I would loose RS232 data unless I drop the speed to 2400.

Mike.

 

[Pommie]

It is not possible to you send the file from pc to mc and than eeprom.
because hyper terminal send the data continues to the serial port.
mc and memory req. some time.
I was make similer project stand alone eeprom copier as well as pc dump ability for 4kb - 16kb eeprom.
best way to do this ,is that make small c/vb prog for sending byte by byte data from file if possible use ack.

I would normally write a VB app for doing this. However, with this particular program, I want it to be fully configurable without any installed programs, so hyperterminal at 4800 baud it is.

I could pad the file out with comments between each record to give the EEPROM time to write but, you can guarantee some knowledgeable person would delete the pad lines.

Mike.

 

[eblc1388]

If you can afford some spare SRAM in the PIC, then a circular buffer using Bank2+Bank3 GPR for incoming serial data might be a solution.

 

[Nigel Goodwin]

One solution would be to write more than one byte at a time, a 'sequential write', a 24C04 writes up to 8 bytes at a time, and only takes the same amount of time as writing a single byte. While the write is completing you can read the next collection of bytes into a buffer, ready for the next transfer.

This has the obvious advantage of speed, which is always good.

Another solution is to cure the problem at RS232 level - handshaking - the PC is already equipped for it, you just need to write PIC code to implement it at that end. However, this wouldn't be as fast.

 

[Pommie]

If you can afford some spare SRAM in the PIC, then a circular buffer using Bank2+Bank3 GPR for incoming serial data might be a solution.

I already have a 32 byte fifo for RS232 receive + a 40 byte line buffer that gets fed from the fifo + a 7 byte record buffer that gets fed from the line buffer + a 32 byte fifo for echoing back. I also can't start compressing a record until the previous record has been written as I use flash based lookup tables in the compression routines which get corrupted by the interrupt based EEPROM write.

Having said that, I just checked and I have all of bank 2 free so I could implement an 80 byte circular buffer for writing the eeprom. I would still have the EEPROM/Flash conflict but I should be able to work around that.

That should at least allow me to stay at 9600 baud.

Thanks for the suggestion.

Mike.

 

[Pommie]

One solution would be to write more than one byte at a time, a 'sequential write', a 24C04 writes up to 8 bytes at a time, and only takes the same amount of time as writing a single byte. While the write is completing you can read the next collection of bytes into a buffer, ready for the next transfer.

I don't really want to add any more hardware.

Another solution is to cure the problem at RS232 level - handshaking - the PC is already equipped for it, you just need to write PIC code to implement it at that end. However, this wouldn't be as fast.

This could be the solution. It would actually be faster than my current solution which is to slow everything down to a pace where the slowest operation is possible.

Mike.

 

[Nigel Goodwin]

I don't really want to add any more hardware.

Sorry, I thought you were writing to an external EEPROM - there's not really a lot of internal EEPROM to write to.

 

[gramo]

I never thought of this until today, but just incase anyone wants some source code on how to clock the average EEPROM write / average USART byte output time, this is how I did it;

The output on the LCD is;

Write: xxxxx uS
Serial: xxxxx uS

Write is the average time in uS per EEPROM write, and Serial is the average time per uS for a byte of data to be sent (can be calculated, but just found it handy to throw in aswell to compare for real life values)

Device 16F84A	' Define what device your using

XTAL = 16	' Set the Osc speed

Symbol GIE = INTCON.7
Symbol TMR = INTCON.5
Symbol TMR_0 = INTCON.2

Dim uS as Word
Dim mS as Word
Dim S as Word
Dim X as Byte
Dim Count1 as Word
Dim Average as DWord
Dim Temp_DW as DWord

LCD_DTPIN = PORTB.4	
LCD_RSPIN = PORTB.2
LCD_ENPIN = PORTB.3
LCD_INTERFACE = 4
LCD_LINES = 2
LCD_TYPE = 0
		 
ON_INTERRUPT Interrupt_Sub

INTCON = %00100000
Option_Reg = %00000000
					
Delayms	150
Cls

Count1 = 0

Main:

	 S = 0
	 mS = 0
	 uS = 0
	 TMR0 = 0	 
	 GIE = 1
	 
	 For X = 0 To 63
		 EWrite X, [X]
	 Next 
	 GIE = 0
	 
	 Average = uS 
	 Temp_DW = mS
	 Temp_DW = Temp_DW * 1000
	 Average = Average + Temp_DW
	 Temp_DW = S * 1000000
	 Average = Average + Temp_DW
	 Average = Average / 63 
	 Print at 1,1, "Write:  ", DEC5 Average, " uS"

	 
	 S = 0
	 mS = 0
	 uS = 0
	 TMR0 = 0	 
	 GIE = 1	 
	 
	 Repeat
	 	   SEROUT PORTA.0 , 84 , [X]	
	 	   Count1 = Count1 + 1		   
	 Until S = 3
	 
	 Average = Count1
	 Average = 3000000 / Average
	 
	 Print At 2,1, "Serial: ", Dec5 Average, " uS"
	 Count1 = 0 

	 Goto Main

Interrupt_Sub:

	Context Save

	If TMR_0 = 1 Then
	   TMR_0 = 0
	   uS = uS + 128
	   If uS >= 1000 Then
	   	  uS = uS - 1000
	  	  mS = mS + 1
		  If mS >= 1000 Then 
		  	 mS = mS - 1000
			 S = S + 1
		  EndIf
	   EndIf
	EndIf
			  
	GIE = 1
	
	CONTEXT RESTORE

 

[gramo]

For my 16F84A with the above program, its sits on 3.442ms per EEPROM write and 2.240ms per USART byte output

 

[gramo]

Looking at those figures, you would need to use a micro controller with built in USART, and use the 2 byte buffer on 2400 baud (4.48ms per byte), as the speed of the write will not allow sufficient time to write a value and recieve the next...

 

[Pommie]

Looking at those figures, you would need to use a micro controller with built in USART, and use the 2 byte buffer on 2400 baud (4.48ms per byte), as the speed of the write will not allow sufficient time to write a value and recieve the next...

So, I'm doing pretty good to be receiving at 9600 baud and managing to store it in EEPROM. Just goes to show why all those buffers are needed.

Mike.

 

[Pommie]

Gramo,

I was curious why you got a shorter time than I did for EEPROM writes. Can't see why it 25% shorter but did notice you are writing 68 byte when there are only 64!

Mike.

 

[gramo]

Good pickup! i'll modify that (miss read for RAM), it still maintains 3.4ms