µC/FS Architecture

Owned by Former user (Deleted)
Last updated: Dec 25, 2020 by WES Admin
3 min read

 µC/FS was written from the ground up to be modular and easy to adapt to different CPUs (Central Processing Units), RTOSs (Real-Time Operating Systems), storage media and compilers. Figure - µC/FS Architecture  shows a simplified block diagram of the different µC/FS modules and their relationships. 

Notice that all of the µC/FS files start with ‘fs_’. This convention allows you to quickly identify which files belong to µC/FS. Also note that all functions and global variables start with ‘FS’, and all macros and #defines start with ‘FS_’.

Figure - µC/FS Architecture

Architecture Components

µC/FS consists of a set of modular software components. It also requires a few external components (provided with the release) be compiled into the application and a few configuration and BSP files be adapted to the application.

Your Application

Your application needs to provide configuration information to µC/FS in the form of one C header file named fs_cfg.h.

Some of the configuration data in fs_cfg.h consist of specifying whether certain features will be present. For example, LFN support, volume cache and file buffering are all enabled or disabled in this file. In all, there are about 30 #define to set. However, most of these can be set to their default values.

µC/Lib (Libraries)

Because µC/FS is designed to be used in safety critical applications, all ‘standard’ library functions like strcpy(), memset(), etc., have been re-written to follow the same quality as the rest of the file system software.

POSIX API Layer

Your application interfaces to µC/FS using the well-known stdio.h API (Application Programming Interface). Alternately, you can use µC/FS’s own file and directory interface functions. Basically, POSIX API layer is a layer of software that converts POSIX file access calls to µC/FS file access calls.

FS Layer

This layer contains most of the CPU-, RTOS- and compiler-independent code for µC/FS. There are three categories of files in this section:

  1. File system object-specific files:
    • Devices (fs_dev.*)
    • Directories (fs_dir.*)
    • Entries (fs_entry.*)
    • Files (fs_file.*)
    • Partitions (fs_partition.*)
    • Volumes (fs_vol.*)
  2. Support files:
    • Buffer management (fs_buf.*)
    • Cache management (fs_cache.*)
    • Counter management (fs_ctr.h)
    • File system driver (fs_sys.*)
    • Unicode encoding support (fs_unicode.*)
    • Utility functions (fs_util.*)
  3. Miscellaneous header files:
    • Master µC/FS header file (fs.h)
    • Error codes (fs_err.h)
    • Aggregate header file (fs_inc.h)
    • Miscellaneous data types (fs_type.h)
    • Miscellaneous definitions (fs_def.h)
    • Configuration definitions (fs_cfg_fs.h)

File System Driver Layer

The file system driver layer understands the organization of a particular file system type, such as FAT. The current version of µC/FS only supports FAT file systems. fs_fat*.* contains the file system driver which should be used for FAT12/FAT16/FAT32 disks with or without Long File Name (LFN) support.

Device Driver Layer

Device drivers (or just drivers) are low-level functions that translate logical block operations into physical I/O operations on storage device controlled by the device drivers. There is one driver type for each type of storage device: SD/MMC card, NAND flash, NOR flash, etc.

Device drivers hide all details about the storage device (e.g., the size of the physical block (or, on magnetic disk, the sector), whether physical blocks/pages must be erased before they can be overwritten) from the higher layers in the file system, and therefore from the application as well.

The vendor of the file system may provide generic drivers.

Vendors of boards and board support packages may provide drivers for specific evaluation boards.

µC/CPU

µC/FS can work with either an 8, 16, 32 or even 64-bit CPU, but needs to have information about the CPU you are using. The µC-CPU layer defines such things as the C data type corresponding to 16-bit and 32-bit variables, whether the CPU is little- or big-endian and, how interrupts are disabled and enabled on the CPU, etc.

CPU specific files are found in the …\uC-CPU directory and, in order to adapt µC/FS to a different CPU, you would need to either modify the cpu*.* files or, create new ones based on the ones supplied in the uC-CPU directory. In general, it’s much easier to modify existing files because you have a better chance of not forgetting anything.

RTOS Layer

µC/FS does not require an RTOS. However, if µC/FS is used with an RTOS, a set of functions must be implemented to prevent simultaneous access of devices and core µC/FS structures by multiple tasks.

µC/FS is provided with a no-RTOS (which contains just empty functions), a μC/OS-II and a µC/OS-III interface. If you use a different RTOS, you can use the fs_os.* for µC/OS-II as a template to interface to the RTOS of your choice.