xqq27 1d035e1127 提交今日完成内容：led1增加了一些内容在mw_led里。我发现，led部分的内容不应该写在bsp_gpio内，虽然他们都使用了底层的gpio内容，但是他们更多的是关于led的。我觉得可以进一步抽象一下io的切换、读取，但这个也要和其他地方解耦开来，比如led的开与关，和开关量控制的电机的开与关都是操控电平高低的，他们都使用io控制语句，那他们是都同时使用st库的gpio_Setbyte和ResetByte，还是先抽象出一个函数Gpio_High、Gpio_Low，然后其他函数都调他呢？目前先在bsp里面分别写各自作用的函数，如“开灯”“开电机”，然后各自的上一层middleware分别调用各自的板级支持包bsp，这样感觉更独立、更解耦，即便换芯片就统一把所有的bsp改掉就好了。

2025-04-28 23:17:48 +08:00

..

.vscode

提交今日完成内容：led1增加了一些内容在mw_led里。我发现，led部分的内容不应该写在bsp_gpio内，虽然他们都使用了底层的gpio内容，但是他们更多的是关于led的。我觉得可以进一步抽象一下io的切换、读取，但这个也要和其他地方解耦开来，比如led的开与关，和开关量控制的电机的开与关都是操控电平高低的，他们都使用io控制语句，那他们是都同时使用st库的gpio_Setbyte和ResetByte，还是先抽象出一个函数Gpio_High、Gpio_Low，然后其他函数都调他呢？目前先在bsp里面分别写各自作用的函数，如“开灯”“开电机”，然后各自的上一层middleware分别调用各自的板级支持包bsp，这样感觉更独立、更解耦，即便换芯片就统一把所有的bsp改掉就好了。

2025-04-28 23:17:48 +08:00

app

led部分的bsp部分完成，接下来开始写驱动部分

2025-04-28 16:45:44 +08:00

bsp

提交今日完成内容：led1增加了一些内容在mw_led里。我发现，led部分的内容不应该写在bsp_gpio内，虽然他们都使用了底层的gpio内容，但是他们更多的是关于led的。我觉得可以进一步抽象一下io的切换、读取，但这个也要和其他地方解耦开来，比如led的开与关，和开关量控制的电机的开与关都是操控电平高低的，他们都使用io控制语句，那他们是都同时使用st库的gpio_Setbyte和ResetByte，还是先抽象出一个函数Gpio_High、Gpio_Low，然后其他函数都调他呢？目前先在bsp里面分别写各自作用的函数，如“开灯”“开电机”，然后各自的上一层middleware分别调用各自的板级支持包bsp，这样感觉更独立、更解耦，即便换芯片就统一把所有的bsp改掉就好了。

2025-04-28 23:17:48 +08:00

isr

采用了Timer2作为硬件定时器的程序，目前只试了一下基本定时器的定时更新中断功能

2025-01-22 13:22:25 +08:00

library

led部分的bsp部分完成，接下来开始写驱动部分

2025-04-28 16:45:44 +08:00

middleware

提交今日完成内容：led1增加了一些内容在mw_led里。我发现，led部分的内容不应该写在bsp_gpio内，虽然他们都使用了底层的gpio内容，但是他们更多的是关于led的。我觉得可以进一步抽象一下io的切换、读取，但这个也要和其他地方解耦开来，比如led的开与关，和开关量控制的电机的开与关都是操控电平高低的，他们都使用io控制语句，那他们是都同时使用st库的gpio_Setbyte和ResetByte，还是先抽象出一个函数Gpio_High、Gpio_Low，然后其他函数都调他呢？目前先在bsp里面分别写各自作用的函数，如“开灯”“开电机”，然后各自的上一层middleware分别调用各自的板级支持包bsp，这样感觉更独立、更解耦，即便换芯片就统一把所有的bsp改掉就好了。

2025-04-28 23:17:48 +08:00

SmartCarV1.code-workspace

提交最新的可以调试的版本，并整理了一点点蓝牙模块部分

2025-03-17 22:52:44 +08:00