Shop OBEX P1 Docs P2 Docs Learn Events
Processing Speed versus Data through put — Parallax Forums

Processing Speed versus Data through put

TJHJTJHJ Posts: 243
edited 2008-12-15 03:45 in Propeller 1
Does anyone know how to figure out how much data processing you need per MIP( maybe). Specifically how fast data would need to be fed from an e-prom to the prop in order for it to directly process from the eprom, versus loading to the ram 1st. Maybe a data transfer rate per cog?

Here is what I am thinking, With a boat loader, It would be possible to process directly from the e-prom, bypassing the 32k limit. The ram could be used as just that, ram, for variables, ect. Similar to how a PIC tends to work. I can never do very much with video because the video buffer takes up 24k right off the bat. So if I was reading the commands from the e-prom then I could have a full 32k of program or more, and not be limited by the video buffer. Even go to higher resolutions. The interesting idea is that because cog's have direct access to IO lines, they could be running their own programs from their own e-prom, and using their 2k ( Minus the loader) for independent ram, and still have access to the common ram.

This is all dependent on being able to read the eprom fast enough, which off the top of my head I have no idea if that is possible as things are laid out now.

TJ

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2008-12-14 21:21
    It all depends ...

    I2C EEPROMs like those used for the boot loader work up to about 1MHz clock. They are serial, so they require an address at the beginning of a transfer, typically a total of 4 bytes including device select codes which comes out to about 36 bits. Each byte read after that takes about 9 bits. That's 100000 bytes per second maximum. Writing of course takes much longer since it's flash EEPROM.

    There are serial memories that use the SPI protocol and require 3 I/O pins, two of which can be shared with other SPI devices. These can use a clock up to 20MHz, require a 3 byte opcode/address initiation to a read, then require only 8 bits per byte to do the read transfer. Writes take a 4th byte and, for flash, take longer to complete.

    You'll have to decide whether this is fast enough for your needs. The SPI memories are about 20 times slower than hub RAM and the I2C memories are 25 times slower than the SPI memories.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2008-12-14 22:06
    You can also get parallel flash memories (such as this one), which can be accessed much faster. However, without some sort of address/data multiplexing scheme, you would use up most of the Propeller's pins interfacing to one of them.

    -Phil

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    'Just a few PropSTICK Kit bare PCBs left!
  • kwinnkwinn Posts: 8,697
    edited 2008-12-15 03:45
    Phil is correct. If you used Prop pins for address and data bits you would use up most of the pins ( 18 address, 8 data, 3 control bits). If you used serial to parallel shift registers you would need 8 pins to shift addresses out and data in/out. If the address register can also be incremented by a pin a new address would only need to be shifted out when a jump is encountered in the code.
    Since most programs execute several instructions before a jump the next address and byte of data can be accessed very quickly most of the time. If the Flash/Eeprom contained bytecode instructions for the prop to interpret and execute the time required to do so would probably be as long or longer than the time required for the data to be shifted in.
    I think the Prop would be an excellent choice for this application. With multiple cogs you could use one cog for fetching the bytecodes and one or more cogs for executing them.
Sign In or Register to comment.