DAPLink 源码解读

DAPLink 的 Webusb 部分涉及以下几主要个文件

1. Vfs_manager.c   stream_opne ,stream_werite ,strem_close，usb接口
2. file_stream.c     open ,write ,close操作
3. virtual_fs.c     fat16虚拟系统
4. vs_user.c       虚拟磁盘文件创建，文件命令处理
5. flash_decoder.c  bin,hex 文件解析、烧写编程
6. target_flash.c    flash 编程
7. swd_host.c      swd接口、驱动

vfs_manager.c 是webusb 文件处理的最高层文件

   此文件对上接口主要有四个函数

Void usbd_msc_init(void)        在usbd_msc.c中调用

Void usbd_msc_read_sect( )      在usbd_msc.c中调用

Void usbd_msc_write_sect(void)   在usbd_msc.c中调用

Void vfs_mngr_periodic(void)     在main.c中调用

从文件名就可以看出几个接口函数的主要功能，初始化，读扇区，写扇区，以及周期定时处理函数

这个文件中还有两个重要函数：

文件变动回调函数 static void file_change_handler()  和 文件数据回调函数 static void file_data_handler()。

文件变动回调函数file_change_handler()在初始化函数usbd_msc_init(void) 中被设置为回调：

usbd_msc_init(void) –> build_filesystem() -> vfs_set_file_change_callback(file_change_handler)

回调是在函数 msc_write_sect(void)中产生的，其中文件数据回调函数vfs_mngr_periodic(void)被直接调用：

void usbd_msc_write_sect(uint32_t sector, uint8_t *buf, uint32_t num_of_sectors)

{

 …

    file_data_handler(sector, buf, num_of_sectors);  <----------------- 直接调用

}

需要注意在函数usbd_msc_write_sect()中，对函数file_change_handler()的回调早于对file_data_handler()的调用。

而文件变动回调函数的回调的路径如下：

usbd_msc_write_sect()  –>  vfs_write()( virtual_fs.c ) -> virtual_media[i].write_cb ->

write_dir() -> file_change_cb(  VFS_FILE_CREATED、VFS_FILE_CHANGED、VFS_FILE_DELETED  )

注意最后调用的file_change_cb 函数句柄，就是指向 file_change_handler() 函数的（在初始化时设置的）。

从回调参数（VFS_FILE_CREATED、VFS_FILE_CHANGED、VFS_FILE_DELETED）中可以看出，文件变动调用是在三个情况下回调的：

1.文件名发送变动，调用类型参数是VFS_FILE_CREATED

2.文件内容变动，调用类型参数是 VFS_FILE_CHANGED

3.文件删除时调用，调用类型参数是VFS_FILE_DELETED

从上面分析可以看出两个回调函数的作用如下：

1.文件变动回调函数file_change_handler()

当新文件出现时被调用，当文件删除时被调用，当文件数据写入是被调用

2.文件数据变动回调函数file_data_handler()

文件数据写入时总是会调用此函数。

在此函数中会直接检查每一组写入数据，确定是否是bin或hex 文件数据，如果是就直接调用打开传输流函数transfer_stream_open(), 启动数据传输。

因此，对于bin 和hex 文件传输时，系统并不检查文件名后缀，而是直接检查数据格式是否满足bin和hex 格式要求来决定是否传输（烧写或编程）。

对于无法从文件数据内容判断出文件格式的文件，就只能通过文件名来判断是否是我们需要传输(烧写或编程)的文件。

从道理上讲，通过文件名判断文件类型来决定是否是传输文件应该比通过文件内容判断更加简单，但是在这里却不是如此，这是因为我们并不拥有fat文件系统（这个系统在电脑端），我们知道的只是扇区的读和写操作，因此想要知道存储了哪些文件，就必须自己建一个虚拟的文件系统来还原文件系统，再通过虚拟的文件系统来比对新增、删除、修改的文件后再调用回调函数。

virtual_fs.c文件就是为实现此目的而设立的一个虚拟文件系统。这个文件系统虚拟并保存了磁盘的 mbr、fat1、fat2、root_dir 四个部分，文件内容的数据部分并没有保存。

此系统是虚拟了fat16磁盘系统。关于fat16磁盘系统的格式定义需要自己脑补了，这里不做详述。

要想改造DAPLink 的 webusb 部分，就必须深入理解两部分内容：

1. virtual_fs.c 虚拟文件系统

还原文件系统的目录部分，数据部分就是需要得到的内容，是需要进一步处理的数据，比如烧写、存储等，我们这里是想做的是将得到数据写入MicroPython 的文件系统中并执行。

1. vfs_manager.c 虚拟管理

完成对流数据的打开、传输、关闭等操作，这些宏观操作回传递到file_stream.c 中执行响应的 open 、write、close 函数，实现对传输数据的编程、保存等处理。

Virtual_fa.c 源码解读

Vfs_read, vfs_write 是提供给 Vfs_manager.c的数据处理接口。通过这两个函数对扇区进行读写，我们重点关注写操作。

每一次扇区的写操作都会调用vfs_write 函数，由于USB接口的写接口都是直接对扇区写，此外并没有对所写内容的信息，因此要区分所写内容就只能通过查找扇区号分布的的区域和虚拟磁盘记录来判断扇区数据 --- 是目录数据？是某文件数据？。

virtual_media[16]是有16个单元的虚拟磁盘结构，磁盘单元结构是一个数组，结构如下

typedef struct virtual_media {

    vfs_read_cb_t read_cb;

    vfs_write_cb_t write_cb;

    uint32_t length;

} virtual_media_t;

结构中定义了对次区域的读和写操作read_cb 、 write_cb ，还有一个此区域的总长度length --- 字节数。

一个结构对应一个磁盘区域，对于fat16系统，此结构对应的区域顺序如下：

mbr   ---  mbr 区域

fat1   ---  磁盘分区表1

fat2   ---  磁盘分区表2

dir    ---  文件目录区0 ~ 13 ,最大13个文件，新增文件目录就在这里增加

记录此区域的数量单元是virtual_media_idx ，因此virtual_media[ i] 中i从 0 - virtual_media_idx-1  就遍历了整个磁盘区域，根据比较每个区域的范围，查找出写入扇区所属的区域后，调用virtual_media[i].write_cb（）函数，write_cb()函数在不同的区域对应不同的函数，在mbr区中write_cb对应着write_none，read_cb()对应着 read_mbr()函数，fat1,fat2区域对应着read_fat和write_none，而目录区则对应着read_dir和write_dir函数，其中write_dir函数是我们解读的重点。

Write_dir是写文件目录操作函数，调用此函数就意味着此次写入扇区是对目录扇区操作。

计算目录起始编号和范围start_index、start_index，开始遍历每一个目录，并比较数据，如果数据

完全相同，则继续比较下一个目录数据，若找到不同数据的目录了后，再比较文件名是否相同，相同则用VFS_FILE_CREATED参数调用file_change_cb（）函数，若文件名第一个字符是0xe5,则用 参数调用VFS_FILE_DELETED调用file_change_cb（）函数，初以上两个条件外，则用参数VFS_FILE_CHANGED调用file_change_cb（）函数。

这里函数file_change_cb（）就对应着本片开头提及的回调函数file_change_handler()，

在函数file_change_handler()中继续处理写目录的数据。

目录写函数read_dir()中代码更短，逻辑比较简单，自己解读，我就不再分析。

如果过对文件目录操作还有不太清楚的地方，也可以参照文件创建函数vfs_create_file()，这是在虚拟文件系统中创建一个文件，里有对目录文件的增加修改等操作，可以帮助理解虚拟文件系统。

这个文件中其余的函数都是辅助函数，代码较短，解读比较容易，自己解读，不再唠叨了。