IIC File system

[mhoneywill]

Hi Mark,

I'd like to know how easy it would be to create an IIC file system, similar to the SPI file system. In my prodduct I have an IIC FRAM chip (fast write times, unlimited writes), and I was thinking of accessing this memory using the uTasker file access commands. I've got the following questions

1. Can you give me some pointers as to which routines, need modifying.

2. The simulator would need modifing to save of the IIC memory on shutdown, and restore it on powerup

3. I have other IIC pheripherals on the same bus, and would still want to be able to support those.

4. It would be nice if the internal Flash, SPI and IIC memory areas were all avalable at the same time, I currently don't have SPI flash so thats not an issue at the moment.

5. In anticipation of supporting other types of non volatile memory like SD cards and USB memory devices, maybe the file access commands need to have an extra parameter that specified which "device / memory area" they are reading from.

Cheers

Martin

[mark]

Hi Martin

Additional memory devices can be added based on their virtual addresses (the SPI FLASH is selected when the access address is higher than the end of internal FLASH, which is always considered as first). Accesses beyond the end of SPI FLASH can be considered as the next memory type, etc.

This means that all routine supporting SPI_FLASH will need to be modified to first check whether the access is in I2C FRAM memory and do hardware specific accesses when the check is true, but allowing the SPI FLASH or internal FLASH access to take over when not.
In the processor driver code the external chip type can be accessed using routines equivalent to eg. spi_flash_lm3s_atmel.h

Saving and reading back the memory content can be added to FileToDisk.c

I see a couple of complications due to the I2C interface:
1) Speed. The max speed is 100k or possibly 400k and so reading is a bit slower
2) Since the I2C interface being used for other devices is interrupt driven and accesses to IIC FRAM (as SPI FLASH) would be required to be 'in-line' this represents another solution.

To improve 1 and solve 2 I would suggest that it remains interrupt driven so that reads and writes can be queued, but the IIC FRAM reads can be configured to go straight to specific memory (the pointer passed with the memory read) rather than via the driver input buffer [much more efficient].
Depending on whether the I2C interface is already busy or not, memory reads may have to be delayed - for which a simple semaphore wait would be useful.

I think that these can all be solved but it is certainly a little more complicated, mainly due to the fact that the interface needs to be shared. I don't envisage real difficulties on the target (also the simple semaphore has been used before) but I haven't been able to work out how the simulator can do the same thing just yet since it is not 'really' interrupt driven...

Regards

Mark

[mark]

Hi Martin

Not focusing on how to realise the suggestion but rather on the background for deciding on such a chip; what advantages does it have over a conventional SPI FLASH?

I have used MRAM with the Freescale M52259 (Kirin3) since the EVB has a 16 bit MRAM: see http://www.utasker.com/forum/index.php?topic=504.0
This is is however connected to an extension memory interface and achieves read / writes at up to 80MHz and, being memory mapped, also program code can be run from it (although a bit slower since it is not full 32 bit in width). Essentially it is equivalent to SRAM which doesn't lose its content when powered down.

In your case you are not utilising the speed of the MRAM (is FRAM the same or is it meant to be slower?) and so are there real benefits in going this way?

Regards

Mark

[mhoneywill]

Hi Mark,

Historically our boards have been layed out for an IIC memory chip rather than a SPI chip. On a new layout we may well include SPI memory chips.

We've used FRAM chips from Ramtron http://www.ramtron.com/products/nonvolatile-memory/serial.aspx they have unlimited writes and have an instant write time. As our configuration info is generally quite small these chips make for a good solution.

I'm thinking I may well modify the utasker IIC memory Driver to allow a pointer to be passed for memory read and write to avoid having to double buffer data.

Cheers

Martin