关于MP3软解码例程的Fatfs问题

catlanhui

有几个疑惑请教下各位。
1，在字库函数中，有如下语句，翻遍整个程序，其实并没有使用卷1，该处字库使用的还是卷0的通道。
    f_mount(1, &myfs[0]);
    myres = f_open(&myfsrc , "0:mp3player/HZLIB.bin", FA_OPEN_EXISTING | FA_READ);

2，在play_run()函数里，FIRE有下面注释，按FIRE的说法，如果字库mount(0)的话会出错，跟我上面的理解的卷0的通道似乎又有矛盾，还有就是继续mount(0)为什么会出错。
           /* 注册工作区，原sd卡字库也使用了f_mount而且mount(0)但文件系统指针不同,
           继续mount在0盘符的话会出错，我把sd卡GetGBKCode_from_sd函数中的f_mount注册到了1        */               
           f_mount(0, &fs);

3，其实还是对文件系统了解不清楚，在什么情况下我们才会使用几个卷，因为这在FF.H是可以配的，而且在Fire的该例程中，其实还用了卷3，估计是验证用的，如下。我用f_mount(0,&FATFS)，使用不同的FATFS系统文件感觉跟用f_mount(1,&FATFS1)，f_mount(2,&FATFS2)，f_mount(3,&FATFS3)结果没什么差别啊。
     f_mount(3, &bmpfs[0]);

flyleaf

0 1 2 3那是跟底层驱动配置有关的，使用的卷不同，那在底层最终实际调用的函数也不一样。
至于你说的用123到正确可能是驱动里没有区分，0123都当成sd卡的驱动

catlanhui

感谢flyleaf的回复。
我的理解是：f_mount(vol,fatfs *fs)，vol是卷标，类似WINDOWS下的盘符,C,D,E,F。
                                                   fs是空间，比如U盘就是一个空间，插上电脑，显示一个盘符，就是f_mount这个动作。
                                                   fs在全局是个全局结构，即使后面f_mount(vol,NULL),申请的fs结构依然存在。
                                                   而FIRE的程序，尽管程序用了卷标0，1，3（3我基本肯定是没用的，即这个语句  f_mount(3, &bmpfs[0])），但其实最终功能上一直是卷0作为提供给用户操作的接口。而且在图片显示使用的空间其实是f_mount(1, &myfs[0])，或者 f_mount(0, &fs)中的一个。
请诸位回复我的理解是否正确。
谢谢。