[bsp/stm32] 将spi DMA传输更改为阻塞线程方式
拉取/合并请求描述:(PR description)
[ 本提交是受到了pull-5582的启发,以更加通用的方式,添加了spi DMA传输的阻塞线程方法。 ]
以下的内容不应该在提交PR时的message修改,修改下述message,PR会被直接关闭。请在提交PR后,浏览器查看PR并对以下检查项逐项check,没问题后逐条在页面上打钩。 The following content must not be changed in the submitted PR message. Otherwise, the PR will be closed immediately. After submitted PR, please use a web browser to visit PR, and check items one by one, and ticked them if no problem.
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
- [ ] 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
- [ ] 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo
代码质量 Code Quality:
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
- [ ] 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
- [ ] 代码风格正确,包括缩进空格,命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
- [ ] 没有垃圾代码,代码尽量精简,不包含
#if 0代码,不包含已经被注释了的代码 All redundant code is removed and cleaned up - [ ] 所有变更均有原因及合理的,并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
- [ ] 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
- [ ] 本拉取/合并请求代码是高质量的 Code in this PR is of high quality
- [ ] 本拉取/合并使用formatting等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification
我感觉这个完成量放在stm32驱动的结构体里更好一点。因为如果放在spi框架里的话,spi就会依赖完成量了,但其实spi框架并不一定要依赖完成量。放到下面这个位置更好一点

我感觉这个完成量放在stm32驱动的结构体里更好一点。因为如果放在spi框架里的话,spi就会依赖完成量了,但其实spi框架并不一定要依赖完成量。放到下面这个位置更好一点
spi框架或者其他的硬件驱动框架,提供一个统一的,可以阻塞线程的方式,供下层驱动使用是不是更加统一,避免使用事件、信号量等方式产生混乱
我同意郭老师的观点,这个应该放在驱动里边,因为你放在设备框架上的话,实际上这个成员变量被没有实际有效的被设备框架所使用。
是否采用阻塞的方式其实是数据传输的一部分,这个应该是底层bsp驱动全权负责的。
是否采用阻塞的方式其实是数据传输的一部分,这个应该是底层bsp驱动全权负责的。
既然你和郭老师都认为放到底层好,那我更改下
嗯嗯好的 感谢