Storing thousandths of 8-digits codes --> SRAM --> Arduino

Is the eight digit code in decimal? If so, you can convert to hex and save each code in four bytes. That cuts the storage in half.

Arduino has 8kbytes of RAM. Even packed in hex, 2 digits/byte, the data needs about 300 kbytes. He's bought a VW Beetle and wonders how to squeeze the fifth elephant in.

So you need 280K bytes.

So you need 280K bytes. You can get 1M (128K x 8) volatile or NV SRAM from Microchip, so you'd need three of them. One SPI (3 lines) plus 2 or 3 chip select lines.

--sp

Add an SPI serial flash?

The mega has 256 KB of serial flash, which is really pitiful. Serial flash is cheap.

The largest 8 decimal number (99,999,999) fits nicely into 27 bits. Storing 70,000 of those require 1,890,000 bits or 231 kiB, so some external memory would be needed.

Thank you guys for reply's .

It's non decimal number ( so something like 12345678 ). I was thinking on choosing one of these:

But I would go with 512KB version because maybe we will need to upgrade the project with additional codes...

So, SRAM or NVSRAM ?

GM

Careful that the unit is Kbit not Kbyte!

I would use something like this:

Bye Jack

that would be how I would go about it. The only gotcha *might* be the access speed if you need to constantly get a large set of them for calcualtations.

If the data is static and not totally random, why not data compress it when storing and then decompress on the way out?

"LZJB" looks small...

What kind of access speed do you need? How often do you change the codes?

You can use a long which is 4 bytes. Or store it in BCD, also 4 bytes.

You would need 5 of them to store 70,000 * 4 bytes.

If you want the data be preserved over a power-off, you need a non-volatile one.

Careful with the capacity 512 kB is not the same as 512 kb, (byte bit).

Simple RAM will require lots of address bits (20) and parallel bits (4 or more) which is a bad match for a controller chip (no fast external bus, just ports). Could you use an SD card? This works with serial data and control, so it takes some time but only a few pins. That's the well-trod path.

One might also consider a FIFO; it's not necessary to give it an address input, just wiggle the lines whenever you have a new byte for it. First-in-first-out is memory storage, but it's not random access memory.

Is there any pattern in the data - for example, are the values sorted? If so, you might be able to reduce the number of bits required before applying (for example) LZO compression:

Clifford Heath.

Are these 8 *decimal* digits, with any value in [00000000,99999999] possible?

How are they accessed? Randomly? In some particular order? Sorted by value? I.e., how are you *using* them?

How are the values distributed in the domain? Are duplicates possible? Are values "clustered" (i.e., are compression algorithms practical)?

How quickly do you need to be able to identify each of the values in the memory? Are you asking:

- "Is XXXXXX present in this memory?" or:

- "What are all of the values present in the memory?" or:

- "Where (in some sense of order) is XXXXXX in this memory?"

Do the values need to be alterable "at run time"? Or, are they canned "at compile time"? Are they "consumed" at run time (i.e., accessed and then effectively erased? possibly being replaced by a new set?)?