Program Memory Performance

[mikep]

I going to start a new thread on program memory performance. This has been discussed several times but always as a side issue to another thread. Here was the latest dicussion on FRAM memory performance.

I believe it is well-established that FRAM read speed is the same as EEPROM and is mostly limited by the SPI bus speed. However FRAM is faster for writes and essentially does not have a write limit like EEPROM.

My simple testcase does a 1000 writes to program memory using PutEEPROM (reads are done with GetEEPROM). As mentioned by Don the difference becomes apparent at the end of the write cycle or on a page boundary. I found that writing a integer was twice as fast as writing a byte in terms of bytes per second into program memory. Here is a summary of my results so far. The table includes rounding so don't expect the arithimetic to be exact.

Data Size	Read	EEPROM Write	FRAM Write	Flash Write
1 byte	0.09ms (11.3 Kbytes/sec)	2.2ms (460 bytes/sec)	0.2ms (5.2 KBytes/sec)	?
2 bytes	0.09ms	1.1ms	0.1ms	?

I would also like to try external flash memory as I expect that it will also be faster than EEPROM. The only difficulty is that it usually needs 3.3V and therefore entails additional circuitry.

[spamiam]

I am surprised by the relatively slow read speeds of both FRAM and EEPROM.

Since the SPI bus runs at something like 7MHz, I expected peak read speeds of as high as 1M bytes per second (sequential bytes within a page).

Even one tenth of this speed is rather faster then what is seen in the table.

I wonder why this is? I must be badly off-base in my math somewhere.

-Tony

[mikep]

Well it is possible that I did something wrong but I believe most of the "extra" time is taken up by the ZBasic instruction overhead and SPI setup time. Although I did eliminate the loop overhead from my performance numbers, I still include some extra code to calculate the address to write to as well as pushing the 3 parameters needed for the Get/PutEEPROM instruction. Here is the instructions that do the work:

[spamiam]

And I will have to check this again as well. I only recently was doing speed testing of SPI-driven MMC card data transfers. I was getting 1K BYTES per second in pure ZBasic-driven code, and substantially faster than that with the SPI hardware.

I was able to get bit rates approaching the maximum on the SPI hardware until my slow 4000-series logic couldn't deliver the slew rate.

But I got good data transfers and I was transferring 512 byte buffers.

The average speeds were well more than 10x the software speeds, and I was being limited by the logic, not the programming language.

The ZBasic SPI hardware interface is well optimized, and effectively runs at the full potential of the AVR hardware. It does the entire buffer with one command.

I did NOT try to use the SPI hardware for byte-by-byte transfers, as it appears you are doing in your code. This would incur a significant speed penalty for all the ZBasic overhead. Come to think of it, a loop runs at about 10,000 loops per second, doesn't it? Therefore about 10,000 bytes per second might be about the best that byte-by-byte transfers can run.

I have not interfaced with SPI EEPROM nor FRAM, but can you not do sequential reads or writes up to the full page size? I.E. No indexing needs to be done in ZBasic, just send the proper commands, then then use SPICMD() [or GetEEPROM(x,y,512)] to send an entire buffer of data in one ZBasic instruction?

-Tony