FRAM
[System Modules]

Files
file	fram.h
	FRAM Module for reading and writing from and to the FRAM.

---

Detailed Description

This describes some routines provided for using the Ramtron FM25256/FM25640. These routines provide basic storage and retrieval of data, and also a modified version of the fsee file system is provided which has write support.

Basic FRAM I/O

I developed the basic FRAM interface routines first. These provide the basic capability of reading and writing arbitrarily sized chunks of data to the FRAM at a specific location. They work somewhat like memcpy().

If you use the FRAM routines, you must call FRAMInit() once prior to use. This sets up the SPI parameters and IO pin directions.

As-is, the code supports hardware SPI relevant for the SBC65EC. If for some reason you need a software SPI, there is an option on line 28 of FRAM.c which will cause a software implementation to be used. Also, the particular io pins are configured in the subsequent section if you are using a non-standard connection. Lastly, the clock speed may be changed at line 53. For the slower FM25640 you will need SPI_FOSC_16, and for the faster FM25656 the default of SPI_FOSC_4 will work.

There are some additional sequential read and write routines. These were provided to ease porting of the file system and probably are of limited use otherwise. They leave the read or write transaction open so that multiple calls may be made to sequential addresses. There is a caveat that FRAMEndWrite()/FRAMEndRead() must be called before relinquishing control back to the system because the ethernet controller shares the same IO pins. This is a little different than is with EE since those pins are dedicated.

fsFRAM File System

Thinking it would be useful to someone, I made a modified version of fsee.h, .c that implement the fsys interface via the FRAM io routines. Additionally, I provided implementation for the filePutByte() routine so that writing is possible. Writing continues from the current file position until end-of-file is reached.

Testing

I used the out-of-box Modtronix web server as a development platform for testing. Strictly for testing purposes I modified the web server to only use the FRAM file system, not EE. This made it easy for me to exercise all the code. In real life you probably wouldn't want to do this as EE is perfectly fine for serving web pages.

For testing I created a page experi.htm. This page is rewritten periodically and updated with the current tick count. This allowed me to easily see that file writing was working (in real life you would use cgi variables -- it was only a test).

Some modifications were made to the project to coax it into using fsFRAM instead of fsee. The most interesting changes were made in mxwebsrvr.c, which is where the 'test suite' is executed. Modifications in that file include:

• Including appropriate headers
• performing needed initialization calls
• reading and writing test data on a periodic basis (once every 32 sec)

Modifications can be found by searching for the comment marker HHH.

Known Limitations

The sequential read and write methods in "fram.h" work fine, but you must complete the operation with FRAMEndRead/Write before relinquishing control to other tasks. This is because the IO pins are shared with other devices.

The embedded file system on which fsee (and hence fsFRAM) are based is very simple, and several limitations are imposed by it's design:

• There is not a facility for dynamically allocating additional space for files after an image is built. This means you will need to anticipate the file size before hand. Do not compress it (or you will change it's real size of course).
• You cannot create new files
• You cannot delete old files
• You cannot append to the end of a file

Despite it's limitations, fsee is fine for an embedded file system. I might implement a new file system with dynamic allocation, though it seems a bit much considering there is only 8-32k space to manage anyway.