重新组织了文件的防止

README.md

@@ -103,7 +103,6 @@
       // 接收的回调函数,用于解析接收到的数据
       void (*can_module_callback)(struct _ *); // callback needs an instance to tell among registered ones
   } CANInstance;
-  #pragma pack()
   ```
   
   
@@ -111,13 +110,11 @@
 ## BSP层(Board Sopport Package)
 
 - TODO：
-  1. 增加SPI和I^2^C的BSP模组以便支持IST384磁力计和Oled显示屏等。
-  1. 增加和module层的deteck_task配合的蜂鸣器和led闪烁配置。
 - 主要功能：实现映射功能。
   - 在本框架中，BSP层与cube高度耦合，对该层的修改可能需要使用cube重新生成工程（主要是外设的配置，通信速度，时钟频率和分频数等）。该层也是唯一允许直接出现stm32HAL库函数的代码层，**在非BSP层编写代码时，如需使用HAL_...函数，请思考是否有同功能的BSP_...函数**。不过，由于ST的HAL已经对硬件进行较高的抽象（如以handle_xxx的方式描述一个硬件外设或功能引脚），因此更换开发板需要修改的内容极少。
   - 最简单的(如gpio)仅是对HAL库函数的封装。较为复杂的则会进行一定程度的处理(如can)
 - 补充与修改：某款主控对应的BSP层应保持相同，当认为该层可能缺少部分功能或有错误时，请联系组长确认后解决并更新整个框架，**请勿自行修改**。
-- 代码移植：BSP层也是在不同系列、型号的stm32间执行代码移植时主要需要关注的代码层。向功能更强系列移植一般只需要重配cube并重新组织BSP层的映射关系，而向功能较少的系列移植还需要去掉其不支持的功能。修改BSP后一般不需要对其他两层进行修改。
+- 代码移植：BSP层也是在不同系列、型号的stm32间执行代码移植时主要需要关注的代码层。向功能更强系列移植一般只需要重配cube并重新组织BSP层的映射关系，而向功能较少的系列移植还需要去掉其不支持的功能。如果仅是对同一型号的开发板进行HAL初始化配置的修改，则BSP层**不需要**变动。
 - 子文件与文件夹：
   - bsp.c/h：该层核心文件，其中.h被include至main.c中，以实现整个代码层的初始化。include了该层所有模块的.h并调用各模块的初始化函数。**注意**，有些外设如串口和CAN不需要在bsp.c中进行模块层的初始化，他们会在module层生成实例（即C语言中的结构体）并注册到bsp层时自动进行初始化。以此达到提高运行速度避免未使用的模块被加载的问题。
   - bsp_xxx.c/h：每一个成对的.c/h对应一种外设，当上面两个代码层需要使用某个外设时，这里的文件就是对应的交互接口。
@@ -128,7 +125,6 @@
 - TODO：
 
   1. 增加模块离线/错误检测模块（官方例程中的`deteck_task`）。
-  2. 增加超级电容模块
   3. 增加步进电机模块
   4. 增加裁判系统多机通信、UI绘制模块
   5. 增加舵机模块
@@ -138,7 +134,7 @@
 
 - 子文件与子文件夹
 
-  - **注意，module层没有也不需要进行同意初始化**。app层的应用会包含一些模块，因此由app来调用各个模块的init或register函数，只有当一个module被app实例化，这个模块才会存在。
+  - **注意，module层没有也不需要进行统一初始化**。app层的应用会包含一些模块，因此由app来调用各个模块的init或register函数，只有当一个module被app实例化，这个模块才会存在。
 
     > 命名为init()的初始化一般来说是开发板的独占资源，即有且只有一个这样的模块，无法拥有多个实例，如板载陀螺仪、LED、按键等。命名为register()的模块则可以拥有多个，比如电机。