How We Organise Our Project Files

There are many different ways to organise your source code and many different opinions on the best method! We have chosen the following as a very good approach that is widely used, well suited to both small and large projects and simple to follow.

Each .c source code file has a matching .h header file. All function and memory definitions are made in the header file. The .c source code file only contains functions. The header file is separated into distinct sections to make it easy to find things you are looking for. The function and data memory definition sections are split up to allow the defining of local (this source code file only) and global (all source code files that include this header file) functions and variables. To use a function or variable from another .c source code file simply include the .h header file.

Variable types BYTE, WORD, SIGNED_WORD, DWORD, SIGNED_DWORD are used to allow easy compatibility with other compilers. A WORD is 16 bits and a DWORD is 32 bits. Our projects include a ‘main.h’ global header file which is included in every .c source code file. This file contains the typedef statements mapping these variable types to the compiler specific types. You may prefer to use an alternative method in which case you should modify as required. Our main.h header file also includes project wide global defines.

This is much easier to see in use than to try and explain and a quick look through one of the included sample projects will show you by example.

Please also refer to the resources section of the embedded-code.com web site for additional documentation which may be useful to you.

Modifying Our Project Files

We may issue new versions of our source code files from time to time due to improved functionality, bug fixes, additional device / compiler support, etc. Where possible you should try not to modify our source codes files and instead call the driver functions from other files in your application. Where you need to alter the source code it is a good idea to consider marking areas you have changed with some form of comment marker so that if you need to use an upgraded driver file its as easy as possible to upgrade and still include all of the additions and changes that you have made.

Move The Main Driver Files To Your Project Directory

The following files are the main driver files which you need to copy to your main project directory:

mem-ffs.c -The FAT16/32 file system driver functions

mem-ffs.h

mem-mmcsd.c – The lower level MMC / SD card driver functions

mem-mmcsd.h

Move The Generic Global Defines File To You Project Directory

The generic global file is located in each driver sample project directory. Select the most suitable sample project based on the compiler used and copy the following file to your main project directory:

main.h The embedded-code.com generic global file:

Check Driver Definitions

Check the definitions in each of the following files to see if any need to be adjusted for the microcontroller / processor you are using, and your hardware connections:-

mem-ffs.h

mem-mmcsd.h

Check the definitions in the following file and adjust if necessary for your compiler:-

main.h

Timers

You will need to provide some form of timer for the driver. Typically this can be done in your applications general heartbeat timer if you have one. Do the following every 10mS:-

	//----- FAT FILING SYSTEM DRIVER TIMER -----
	if (ffs_10ms_timer)
		ffs_10ms_timer--;

If you do not have a matching timer then using a time base that is slightly greater than 10mS is fine. Note that the timer must be interrupt based as it is used to provide timeout protection in some of the driver functions.

SPI Port Setup

The SPI interface needs to function in the following way:-

Clock is low in idle bus state

Data is valid on the rising edge of the clock. Data is outputted on the falling edge of the clock.

The speed of the SPI bus is set using 3 separate defines in mem-mmcsd.h. It needs to be between 100KHz and 400KHz when initialising a new card, and up to 20MHz or 25MHz for MMC or SD cards once initialised.

N.B. If your device does not have an SPI port, or if you suspect you may be experiencing issues with your devices SPI peripheral (e.g. due to a silicon bug), a bit based SPI interface is available using the included files mem-spi.c and mem-spi.h in your project. See the mem-spi.h header file for details.

Application Requirements

In each .c file of your application that will use the driver functions include the ‘mem-ffs.h’ file.

You will need to periodically call the drivers background processing function. Typically this can be done as part of your applications main loop. This function looks to see if a MMC or SD card has been inserted or removed and updates the driver appropriately. Add the following call:-

	//----- PROCESS FAT FILING SYSTEM -----

	ffs_process();

Please see the:

‘Signal Noise Issues With MMC & SD Memory Cards (& Clocked Devices In General)

page in the resources area of our web site for details of a common PCB level problem experienced when using MMC and SD memory cards.