How fast can data be read from the standard EEPROM

potatohead

Found on most propeller boards, such as Demoboard, etc..?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

Bill Henning

Depending on eeprom chip, one of:

400khz scl, approx. 40kb/sec if reading in bursts
1MHz scl, approx. 100kb/sec if reading in bursts

potatohead said...
Found on most propeller boards, such as Demoboard, etc..?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system

Mike Green

These EEPROMs are designed for a clock speed of about 400KHz. Each byte takes 9 clocks and you have to send a device select code plus an address before you can do anything else. Once you've done that, you can transfer lots of bytes at 9 clocks per byte. For single byte transfers, you're talking about just under 40 clocks (10 KByte/sec). If you're transferring larger blocks, you amortize the select and address bytes over the whole block. 100 bytes averages out to about 10 clocks per byte or 40 KByte/sec.

With writes, you're limited to the EEPROM page size (often 64 bytes) and there's a several millisecond overhead time for the write operation to finish.

Some EEPROMs will work up to 1MHz.

jazzed

I assume you mean uncached [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM

Kye

I get 2515 Bytes per second in spin. I don't think you can go faster without unrolled loops.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

potatohead

It's a video related question (as most of mine are).

I've been building some sample displays to show off what the Parallax drivers can do, and along the way, just thinking of different techniques to get more out of a Prop.

Video displays are composed of static elements and dynamic ones. Well, if the static bits could be fetched from storage, and layered with the dynamic ones, very considerable savings could be realized in terms of the memory buffer requirements. With most of our drivers to date, this is of limited use as they are either linear, or require complex timing to build interesting displays, or they are limited to some purpose, such as a game, or text, etc...

So my thought was to queue some stuff up during the blanking time, then fetch the rest as the display is building. Some of that comes from the HUB, some from a blanking buffer, and the rest potentially from storage. The EEPROM is just there, as is the SD card, and other devices I don't have yet.

I don't know much (yet) about fast reads from either one, and I thought the EEPROM might be quickest, and everybody basically has one [noparse]:)[/noparse]

Jazzed, I don't know what you mean about cached. I would use PASM, and arrange for a buffer, where an initial burst of data happens, then while the buffer is being drained, get other reads done within limits, repeat for each frame of the display.

Honestly, one could be kind of wasteful given a large storage device, and data could be arranged for sequential use too.

The Parallax drivers are nice, in that they exhibit a very high degree of on screen flexibility screen buffer memory wise. That's sort of what triggered the question.

Is there a link to the fast EEPROM code? I read somewhere that somebody was getting data from SD quickly too. Not sure where either is to be found right now.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

Beau Schwabe

potatohead,

Would the memory need to be contiguous in one EEPROM? Could it be read in parallel interleaved across more than one EEPROM to effectively increase the overall throughput?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Bill Henning

potatohead,

The color burst signal for NTSC video is 3.579...MHz

That means that if you want to do a byte per pixel, even if you don't need to leave time to update the display, you need to read data at a minimum data rate of ~3.6MB/sec ... which is about two orders of magnitude more than EEPROM can do.

If you want to be able to plot points, draw lines, etc. you need roughly twice the bandwidth.

So for realistic NTSC graphics, you need approx. 7.2 megabytes per second - which is 57.6 megabits per second, ignoring the address etc overhead.

For four color graphics per pixel, cut above data rates by a factor of four.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system

potatohead

Yes. I don't think that matters, but for pin cost.

The basic structure for this to work would be tiles stored in the EEPROM, up to 128 byte chunks, because that's what the Parallax tiles are. Could be as small as 8 byte chunks too, for 8x8 drivers.

The other structure would be the scan line, which would be a strip of data.

The scanline is kind of big, and isn't as flexible, and more or less needs to be streamed out of the devices. The tiles could be read as needed, buffered, and shared on the screen for a very high degree of re-use, depending on the display content.

@Bill, yep. Was just working on schemes... [noparse]:([/noparse]

Seems to me, the tile would have to be fetched a line at a time, that's going to be costly, leading to the scan line, or some other thing that approaches streaming... Probably the devices are not fast enough to do any real good, but perhaps load in a color map. I need to do some more thinking about how things can be structured, and what kinds of displays would result.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!

Post Edited (potatohead) : 7/11/2010 11:53:32 PM GMT

jazzed

potatohead said...
Jazzed, I don't know what you mean about cached. I would use PASM, and arrange for a buffer, where an initial burst of data happens, then while the buffer is being drained, get other reads done within limits, repeat for each frame of the display.

I posted an EEPROM cache driver in another thread earlier today: Look here for Spin32_EECACHE.zip. It is designed to support instruction caching.

At present the cache supports 128 N byte chunks (N=16,32,64) but could be modified to use N (64,32,16...) 128 byte chunks. The cache manager is in PASM and has a 2 long interface so that a pre-fetch can be started while doing other things. In the JVM I use the same idea except it is within in the VM interpreter COG. The cache is essentially a lossy hash table where collisions are not resolved.

The cache interface is byte, word, long, and *special*. All interfaces will cause a buffer load if necessary, and can be reworked if necessary to suit your burst application. The special interface stores a COG size buffer to your destination rather than cache.

Keep in mind the driver was not designed with your application in mind and would be quite slow with the current command/poll interface, but it could be easily adapted. With a small change to the interface to load without polling for ready, you could render from a given buffer at whatever rate you like after your pre-fetch.

I found that EEPROM can be read reliably faster than it can be written.

Cheers,
--Steve

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM