Post by thread:eeprom or sram ?

Reading some of the recent threads about eeprom and some other fancy memory having limited R/W capability. Its almost certainly been done, but... why not use a PIC emulating an I2C EEPROM, perhaps running faster than the 400Khz I2Cclockrate, with cmos SRAM and battery backup or even conventional lo-volt eeprom like the AM29F040 ?. OK, there is the space needed for two or more chips and the battery but there would be almost no limit to memory storage capability depending on the peripheral hardware to multiplex/buffer/page or whatever, the address and data lines between PIC and SRAM, or am I missing something here?. While not trivial, the code in the PIC should be quite easy for the guru's here to whip-up in 2 mins or so ;-). anything from 1K to 4 googlebyte I2C pseudo EEPROM which could have auto- increment, block move, block compare etc .whatever you want. Perhaps a silicon disk-drive in a 5pin DIN plug, or is this what the 'smart cards' do?. just a thought.. Mike W -- Life is dark and empty for the PIC developer without VirtualBreadboard go look at it... http://www.virtualbreadboard.com

> While not trivial, the code in the PIC should be quite easy for the > guru's here to whip-up in 2 mins or so ;-). anything from 1K to 4 > googlebyte I2C pseudo EEPROM which could have auto- > increment, block move, block compare etc .whatever you want. No reason why it couldn't be done with standard I2C protocols, just faster. And no bus capacitance or pull-up gotchas. Enough RAM in an F84 to have a simulated 64-byte page write. With a 20MHz PIC, 100ns SRAM read/write you'd probably do 10x the I2C max speed. Although .... an F84 would be fairly well dedicated to the task if say portb is used for data/address and porta was used for I2C i/o and control lines such as CE, WE, OE, and latches. A big SRAM like a 4Mb needs d0-d7 and a0-a18. That's a lot of latches, assuming you want random access and not just always sequential R/W from $0000 up. Maybe shift registers would do for addressing or LE, OE or CP. 74HC373's + 74HC138 ? Would you be able to create enough control lines without sacrificing too much speed ? Might not be overly important if the real goal is data manipulation.

> No reason why it couldn't be done with standard I2C protocols, just > faster. And no bus capacitance or pull-up gotchas. Enough RAM in > an F84 to have a simulated 64-byte page write. With a 20MHz > PIC, 100ns SRAM read/write you'd probably do 10x the I2C max > speed. Although .... an F84 would be fairly well dedicated to the > task if say portb is used for data/address and porta was used for > I2C i/o and control lines such as CE, WE, OE, and latches. A big > SRAM like a 4Mb needs d0-d7 and a0-a18. That's a lot of latches, > assuming you want random access and not just always sequential > R/W from $0000 up. Maybe shift registers would do for addressing > or LE, OE or CP. 74HC373's + 74HC138 ? Would you be able to > create enough control lines without sacrificing too much speed ? I think it is not a wise idea to receive data serially, and then store it by serially shifting adr+data bus states. Using a CPLD and implementing an direct SPI <-> SRAM bus (or possibly DRAM for that matter) will be faster and use less components.

> > I think it is not a wise idea to receive data serially, and then > > store it by serially shifting adr+data bus states. > > Why's that ? Because it's slow. The master that talks serially to the PIC can just as well directly talk to the shift registers that the PIC would talk to afterwards.

> > > I think it is not a wise idea to receive data serially, and then > > > store it by serially shifting adr+data bus states. > > > > Why's that ? > > Because it's slow. The master that talks serially to the PIC can > just as well directly talk to the shift registers that the PIC would > talk to afterwards. Fair enough. I did make a comment about whether speed would be sacrificed for ease. I believe the original ball being kicked around was whether blocks of parallel SRAM could be made I2C-friendly (for block selection) by using a PIC as translator or by having PIC- based drivers using I2C protocols but at higher speed, ie not involve proprietary I2C devices limited to 400kHz. Are there I2C shift registers ? he asked lazily. If so, would these not also be 400kHz ?

Performing a quick guesstimation, seems an arrangement with a pic controlling a shift-register clocking in the address and data bits to an SRAM would be able to keep up with slow i2c speeds? That method ought be just as fast as i2c SEEPROM eh? In fact--think Ill just have to try it out to see! ok..jef > Fair enough. I did make a comment about whether speed would be > sacrificed for ease. I believe the original ball being kicked around > was whether blocks of parallel SRAM could be made I2C-friendly > (for block selection) by using a PIC as translator or by having PIC- > based drivers using I2C protocols but at higher speed, ie not involve > proprietary I2C devices limited to 400kHz. Are there I2C shift registers ? > he asked lazily. If so, would these not also be 400kHz ? > Jeffrey D. Spears University of Michigan College of Engineering ``Double-E, can't spell gEEk without it!'' -Captain Gerald M. Bloomfield II, USMC (my brother)