Fal (flash wait action layer) under WinCE)

Fal (flash wait action layer) under WinCE)
Today, my colleague turned out the drive of NAND Flash and asked me why I couldn't compile the DLL. When I saw that there was a problem with oak \ block \ msflashfmd, I will study it by the way.
We will analyze it with the sosocode in this directory. The fasld directory is to generate Lib, first look at the source file in the following:
Targetname = fasld_lib
Targettype = library
Winceoem = 1
Wincetargetfile0 = $ (_ commonoakroot) \ Lib \ $ (_ cpuindpath) \ fasld. Def
Supported des =... \;... \ Inc
Cdefines = $ (cdefines)-dread_from_registry
Sources =... \ FMD. cpp
The above compilation definition is not described.
Check the export function list in the fasld. Def file:
Library fasld
Exports
Dsk_init
Dsk_deinit
Dsk_open
Dsk_close
Dsk_read
Dsk_write
Dsk_seek
Dsk_iocontrol
Dsk_powerdown
Dsk_powerup
The original FMD (The Flash Media driver) is also a block-driven interface. Let's take a look at FMD. Interface functions in CPP
Dsk_init
Fmd_deinit
FMD _ open
FMD _ close
FMD _ read
FMD _ write
FMD _ seek
FMD _ iocontrol
FMD _ powerdown
FMD _ powerup
Suddenly a little depressed. Don't worry. Let's take a look at msdn and find typedef struct _ fmdinterface {DWORD cbsize;
Pfn_init pinit;
Pfn_deinit pdeinit;
Pfn_getinfo pgetinfo;
Pfn_getinfoex pgetinfoex;
Pfn_getblockstatus pgetblockstatus;
Pfn_setblockstatus psetblockstatus;
Pfn_readsector preadsector;
Pfn_writesector pwritesector;
Pfn_eraseblock peraseblock;
Pfn_powerup ppowerup;
Pfn_getphyssectoraddr pgetphyssectoraddr;
} Fmdinterface, * pfmdinterface;
More importantly, the following information is obtained:
When building your driver, verify that your driver links to the FAL. Lib Link Library.
The original fasld and FAL. LIB can be linked together to generate what we want. Haha, there is basically some idea to achieve this step, the original FMD. CPP defines a bunch of fmd_xxxxxx to meet the callback requirements of the fmdinterface interface. Here, someone may ask me what I did in FAL, and I also want to know what I did in FAL. I searched in Google and found the following information:
Because wince implements the wear-leveling (wear balancing) mechanism for reading and writing FAT file systems, fat tables and so on are often written
Areas are evenly written in different areas of flash by the FAL layer algorithm of wince, instead of repeatedly flushing at the same location. However
The wear-leveling algorithm is not made public by Microsoft, so it is difficult to simulate the same mechanism.
Desperate, it seems that Ms really hurt a lot of programmers. Here we can only go to FMD. CPP implements the driver interface. To generate the DLL at the end, you may need to modify the source file, for example:
Targetname = fasld
Targettype = dynlink
Releasetype = Platform
Dllentry = dllmain
Winceoem = 1
Supported des =... \;... \ Inc
Targetlibs = $ (_ commonoakroot) \ Lib \ $ (_ cpuindpath) \ FAL. Lib \
$ (_ Commonsdkroot) \ Lib \ $ (_ cpuindpath) \ coredll. Lib \
$ (_ Commonoakroot) \ Lib \ $ (_ cpuindpath) \ ceddk. Lib
Cdefines = $ (cdefines)-dread_from_registry
Sources =... \ FMD. cpp \

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/gooogleman/archive/2008/11/19/3335766.aspx