By the way. I think Werners idea of using a serial EEPROM is an excellent choice for this problem. You can get the little beasts that hold up to 64K bytes (i.e. AT24C512).

A random read to any byte takes approximately 50 clocks on the two-wire interface. A sequential read takes approximately 20 clocks for the first byte.

If the device was programmed with a data set of say 5K strings with an average length 8 bytes it takes about 40K bytes to hold the data itself. An index table to point to where any one of the strings starts takes 5K*2 = 20K bytes. That fits nicely inside a 24C512.

To locate and read out any given average length string will take a random read and a sequential read to access the index table = 70 clocks. Then a random read plus 7 more bytes in sequence to read out the data would take 50+(9*7)+4=110 clocks. Total fetch time for any string is then 180 clocks.

The two wire interface can be clocked at a maximum rate of 1 MHz (1 µsec). This is feasible if you use a hardware assisted I²C interface so a string readout time can be about approximately 180 µsec. If you have to use a bit banged software interface then the readout time would be proportional to this in terms of how fast the net software generated clocking rate can be.

Sounds like a very good solution to me. And as Werner pointed out, the device could be programmed off line and plugged into the target. However a serial download scheme via the UART could be feasible as well.

Michael Karas