Fast External Memory

[prstein]

prstein, What is the frequency you are updating this ram histogram?

Dave Purola,
N8NTA

Dave,

The timing for pulses coming in is random, but it might be as high as a few thousand per second all totaled up.

Paul

[Art]

Is it a bad idea to use two of the pics you say are capable of maintaining one of the arrays?
I would think an 8 bit parallel interface between them could be that fast.
Definitely faster than SPI or I2C could do it.

[Demon]

I'm not familiar with the F-RAM products. I just use chips like the AT24C1024 when I need external ram.

Sorry, I can't comment on speeds and interfacing right now, I'm still too rusty (been out of the loop too long). But you might want to take a look at those, they are common and cheap.

I'm just throwing this out in case it actually is helpful to you.


Features
• Low-voltage Operation
– 2.7 (VCC = 2.7V to 5.5V)
• Internally Organized 131,072 x 8
• 2-wire Serial Interface
• Schmitt Triggers, Filtered Inputs for Noise Suppression
• Bi-directional Data Transfer Protocol
• 400 kHz (2.7V) and 1 MHz (5V) Clock Rate
• Write Protect Pin for Hardware and Software Data Protection
• 256-byte Page Write Mode (Partial Page Writes Allowed)
• Random and Sequential Read Modes
• Self-timed Write Cycle (5 ms Typical)
• High Reliability
– Endurance: 100,000 Write Cycles/Page
– Data Retention: 40 Years
• 8-lead PDIP, 8-lead EIAJ SOIC, 8-lead LAP and 8-ball dBGATM Packages
Description
The AT24C1024 provides 1,048,576 bits of serial electrically erasable and programmable
read only memory (EEPROM) organized as 131,072 words of 8 bits each. The
device’s cascadable feature allows up to 2 devices to share a common 2-wire bus.
The device is optimized for use in many industrial and commercial applications where
low-power and low-voltage operation are essential. The devices are available in
space-saving 8-lead PDIP, 8-lead EIAJ SOIC, 8-lead Leadless Array (LAP), and 8-ball
dBGA packages. In addition, the entire family is available in 2.7V (2.7V to 5.5V)
versions.

[prstein]

Art,

Not a bad idea, but that's a lot of pins (and capability) going to waste. I went and actually tested some code and I can't *quite* fit an array of 1024 LONGs, but I can break it down and get 1024 24-bit values.

This discussion started me looking around, and I'm thinking of picking up a few of these to try: http://search.digikey.com/scripts/Dk...=800-1433-5-ND

Robert,

Thanks for the input, but that device looks way too slow.

Best Regards,
Paul

[rmteo]

Which PIC are you using? To use that static RAM, you will need one with an External Memory Bus - typically an 80-pin TQFP device.

[prstein]

Which PIC are you using? To use that static RAM, you will need one with an External Memory Bus - typically an 80-pin TQFP device.

Which PIC is yet to be decided. I work a lot with the 18F452 currently. I'm not opposed to using a larger PIC, but 40 pins ought to cover everything. I didn't think I needed to use an explicit memory bus, I presumed that I could just control the the interface directly. I suppose there would be speed disadvantages, though.

Best Regards,
Paul

[aratti]

I need to keep track of two large arrays (1024 elements) of LONGs in a two-channel pulse height analyzer. As each value comes in I need to increment that element by one. For example, if ADC1 returns a value of 258 I need to get the value of MyLongArray[258] and add 1 to it.

I wonder why you need a long variable for this application? Once that an array has reached a count of 255 (one byte) statistically your pattern is not going to change much till when your long will overflow.

I am currently doing this by streaming the data out to a PC and letting the PC do the work of storing and updating the array. I'd like to move this into a self-contained board instead.

Surely you are doing the transfer via serial port, I don't see why a serial eeprom shouldn't be able to cope with the PC baud rate.

Al.

[prstein]

I wonder why you need a long variable for this application? Once that an array has reached a count of 255 (one byte) statistically your pattern is not going to change much till when your long will overflow.

I wish! On the front end is a radiation detector. Features within the array (or spectrum, if you will) become better defined with larger accumulations, and the statistics of the measurement do improve. Your right that a long variable is probably overkill, but a word variable is certainly too small. I've been working with 512-element arrays of 24-bit values (a word and a byte) and that is probably enough, but more is better right?

Surely you are doing the transfer via serial port, I don't see why a serial eeprom shouldn't be able to cope with the PC baud rate.
Al.

If it were just sending the data one way, as it does to the PC, you'd be correct. With serial memory the value at the location must be read, incremented, then re-written. I timed it out a couple of weeks ago and it was horrendously slow (relatively speaking) using I2CREAD and I2CWRITE.

Best Regards,
Paul

P.S. I manged not to say "don't call me Shirley." 8^)

[languer]

The 18F452 should have plenty of memory; and all the banks can be accessed linearly.

For 1024 x 32-bit (long) words; a 32K serial EEPROM (e.g. 25AA320) would do. They can be clocked up to 10MHz (all in the HW SPI) which should be more than needed.

If you strictly need RAM (not long-term storage) then a serial RAM (e.g. 23A640) should do. Again SPI interface at speeds up to 20MHz.

I still think you should have more than enough storage on an 18F452.

[Demon]

...

Robert,

Thanks for the input, but that device looks way too slow.

Best Regards,
Paul

You can use page writes with the AT24C1024, could that help?

Features
• ...
• 256-byte Page Write Mode (Partial Page Writes Allowed)
• ...

[Art]

If eight pins is too much you could use a 4 bit interface.
Still much faster than any I2C or serial EEPROM, particularly when you
have to wait 10ms after a write cycle.

If you read a value and then update that value, you are supposed to wait 10ms right there.

No reason why the pic acting as a RAM chip couldn't perform other tasks until
it is interrupted,
as long as there's enough RAM left in both chips to run the program as well.

I'm sure I've asked about external RAM on this board before (or on the old picbasic list).
It would be nice to have a fast pic compatible RAM chip, as well as an FPU
(another thing I've asked about).
I'm sad that the pic32 chips don't even have an FPU (something I expected).

[languer]

Not to keep beating the same drum ...

I suggest you look at something like the 23A640. You can do sequential reads and sequential writes. And all this over SPI. At 10MHz (and four lines - max), a 32-bit transfer is 3.2uS (that should be pretty fast).

From datasheet:

If operating in Sequential mode, the data stored in the memory at the next address can be read sequentially by continuing to provide clock pulses. The internal Address Pointer is automatically incremented to the next higher address after each byte of data is shifted out. When the highest address is reached (1FFFh), the address counter rolls over to address 0000h, allowing the read cycle to be continued indefinitely.

If operating in Sequential mode, after the initial data byte is shifted in, additional bytes can be clocked into the device. The internal Address Pointer is automatically incremented. When the Address Pointer reaches the highest address (1FFFh), the address counter rolls over to (0000h). This allows the operation to continue indefinitely, however, previous data will be overwritten.

This, or something similar, should fit your needs.

[prstein]

If eight pins is too much you could use a 4 bit interface.
Still much faster than any I2C or serial EEPROM, particularly when you
have to wait 10ms after a write cycle.

If you read a value and then update that value, you are supposed to wait 10ms right there.

No reason why the pic acting as a RAM chip couldn't perform other tasks until
it is interrupted,
as long as there's enough RAM left in both chips to run the program as well.

I'm sure I've asked about external RAM on this board before (or on the old picbasic list).
It would be nice to have a fast pic compatible RAM chip, as well as an FPU
(another thing I've asked about).
I'm sad that the pic32 chips don't even have an FPU (something I expected).

Hi Art,

I think the hardware SPI port might do it. I'm going to try these: http://www.mouser.com/ProductDetail/...1pcR43MBP1g%3d. I don't care so much that they're non-volatile but they are much faster at writing than standard EEPROM.

Best,
Paul