wdfk-prog
> ### Describe problem solved by the proposed feature > 现在的adc驱动无法使用 常见的adc+dma方式读取数据 是否可以考虑用类似如下的结构体来支持多通道采样呢 > > struct adc_sequence { > uint32_t channels; /* 通道掩码，可同时启用多个通道 */ > int16_t *buffer; /* 存储转换结果的缓冲区 */...
https://github.com/RT-Thread/rt-thread/blob/fabe5646ab94d1b104d12ec27b8767232f53eab7/bsp/stm32/libraries/HAL_Drivers/drivers/drv_hard_i2c.c#L203 - 这里可以加一个断言判断是否空指针 https://github.com/RT-Thread/rt-thread/blob/fabe5646ab94d1b104d12ec27b8767232f53eab7/bsp/stm32/libraries/HAL_Drivers/drivers/drv_hard_i2c.c#L367 https://github.com/RT-Thread/rt-thread/blob/fabe5646ab94d1b104d12ec27b8767232f53eab7/bsp/stm32/libraries/HAL_Drivers/drivers/drv_hard_i2c.c#L392 - 这个格式好像没对齐,可以帮忙对齐一下
1. ffunicode.c的同步不正确,修改量非常大,实际上仅有一点点改动量 2. 这几个commit中有对于ffconf.h的异常改动,但是最后一个commit有做还原,这几个commit合并为一个就好了. 3. 对这个pr的修改进行合并测试后没有问题,可以正常创建目录,文件,删除文件,查看文件 4. ffunicode.c的改动应该有问题的,没有进行尝试.使用的都是默认的UTF-8的格式 5. 仅对dfs_v1进行review并测试.dfs_v2没有做这些操作 6. `ff_cre_syncobj`等函数是为了 旧版 API (R0.14b 及更早版本)设计的;新的版本 (R0.15 及之后版本)仅使用ff_mutex_create;所以应该可以用宏隔开区分. 7. ff_mutex_create的创建格式应该可以与ff_cre_syncobj类似
> @wdfk-prog 还请帮忙review下，特别是 ffunicode.c 的情况： > > ffunicode.c: The large change (~15,593 to ~10,908 lines) is legitimate - R0.16 upstream optimized Unicode conversion tables, significantly reducing file size. This is...
> > > @wdfk-prog 还请帮忙review下，特别是 ffunicode.c 的情况： > > > ffunicode.c: The large change (~15,593 to ~10,908 lines) is legitimate - R0.16 upstream optimized Unicode conversion tables, significantly reducing file...
- 手上没有可以用dfs_v2的板子,还没做支持,欢迎pr