FRAM COMPONENT

[max.tisc]

HELLO
I wanted to ask if you could create a component for FRAM-type memories, which have the advantage of being very fast at up to 3.4 MHz on the bus and, above all, can withstand trillions of read and write cycles. It's an inexpensive component from the MB85RC series, available in various sizes: 256k, 512k, 1M, and 2M in I2C. They're also pin-to-pin compatible with the older 24Cxx ones.
Thanks

[mnfisher]

There's also a SPI version - running at up to 50MHz - look very neat, and should be fairly easy to get running...

Martin

[max.tisc]

Could you make both versions? The ones found on a well-known Chinese site already mounted on a board are in I2C.

[mnfisher]

Ordered a handful of the Chinese boards - i didn't check the datasheets but if the only change of the interface used them it should be possibly to use either bus with minimal code - always good to keep the interface as 'thin' as possible (data is sent/received in as few places as poss) - one issue is that most MCUs maybe don't support i2c faster than 100kbaud?

Martin

[max.tisc]

I already have the 256k I2c if you write something I can test them, the spi are more expensive and rare

[mnfisher]

This is the idea I have (note that it is very unlikely to work - as I haven't any hardware to test on)

I've loosely based this on a '24' based project I did on Arduino that allowed multiple memory chips to be attached (set the address with a0..a2) -
so in properties - there is number of devices (1..4) and base address (I guess this will usually be 0x50 - but it doesn't have to be, range is 0x50..0x53) - the address must increment by 1 when it moves to the next device (if using multiple devices). There is also device capacity (in bytes)- and this must be the same for all the devices.

There are 'write' and 'read' macros that take the address to write/read to/from, address of the data to write/read (we need to use a line of C to get this) and length - these are intended for 'internal' use, with interface macros to take more 'usual' arguments (WriteIntArray / WriteLongArray etc).
This slightly convoluted way of doing things makes writing (and reading) different data types very easy (and is quicker/uses less memory than converting the data to a byte array before calling i2c::TransactionWrite()) - just get the address of the variable, the size and call write - it automatically handles chip boundaries (although at present doesn't loop back to 0) - I've added a WriteByteArray, WriteString and ReadByteArray.

The question - this might lead to some difficulties when converting to a component - is there a 'correct' way to get the full macro 'name'?

There is no image / simulation as yet - any ideas on this?

Martin

[BenR]

I've bought a couple of modules too, they should hopefully land this side of christmas.

[max.tisc]

Is there already a component that I can upload to the FC10 component folder for testing?

[mnfisher]

I don't think so. Did you try my code - above. There is a 50:50 chance that it works (or doesn't ) but it would interesting to know if anything happens - especially if you can watch what is happening on a logic analyser?

Martin