Wangwangmj的博客

这两个如果不注意，可能调试起来很麻烦，我比较喜欢第二个，常用的不知道是哪个，QtQuick.controls有delegate和background可以自己调节背景，并且在下面的大框架的计算中需要把这个高给去掉，top也需要放在这个bottom下面，类似xxx.top:menuBar.bottom。最近在项目中用户感到qml的Menubar,不是很熟悉这个框架，这个menuBar在qml中是有两处的，在使用的时候不要两个都import进来了。

强制替换路径，不建议像我这么写，最好使用qt的qrc，但是我尝试了一下，我的工程里做不到。// iconPath.append("/resource/启动图标1.png");// 添加正确的资源路径，exe不显示图标。iconPath.append("/resource/启动图标1.ico");不知道为什么不能使用相对路径只能使用绝对路径，只好强制找文件。

只使用delete并未在_customPlot中删除对象，必须使用_customPlot->removeItem(line);，使用之后不要再调用delete，否则会导致崩溃。// 清空时间标签容器。// 清理旧的时间标签。// 清理旧的网格线。

修改cmakelist.txt中与项目相关名称，删除build文件夹中的内容，重新打开项目运行。

4.64M的W25QXXX的擦除时间在Freertos操作系统下需要至少两分半(实际测试下来有长有短，可能是因为其他任务没挂起，因为是实时系统，测试下来擦除对数据输出没什么影响就没有加挂起操作，加上用户体验感也不会很好)，所以网上的驱动对于擦除时间的设置100s可能是不够的，会导致擦除失败，擦除失败会导致初始化失败，硬件初始化失败最好也暴露出来，写失败的原因要么地址不对要么初始化没成功，针对内部flash有些写失败可能是字节没对齐，外部目前没遇到过要求按照字节对齐的情况。

1.如果想用消息队列替代全局变量，在多个地方使用这个全局变量时，等待消息队列不能用xQueueReceive，这个函数会在使用后将消息队列中的数据删除，使用xQueuePeek,这个函数只会复制消息队列中的消息并不会删除消息队列中的参数，所以如果在接收完这个队列的时候如果要再次向这个队列发消息的情况下不建议使用这种方式。3.操作系统的vportfree和pvportmalloc一定要对应起来，切记不要使用成free，否则会造成严重的内存泄漏问题，如果这个函数一直运行的话甚至会导致死机。

1.进入断言原因：多条数据的解析以\r
为结尾，断言中有对指针为空的判断以及指针指向空间为空的判断，数据不完整的表现为指针指向空间为空，因为指针为char*,但是数据缺失结束符'\0'陷入死循环原因：在没有加入断言之前，处理多条数据以\r
作为结尾，如果没找到\r
返回-1，然后指针移到未处理的位置，如果数据缺失的情况下会一直进入循环然后指针前移。现象：使用DMA接收数据时接收数据不完整导致后面的数据无法正常解析陷入死循环或者直接进入断言。实际并非接收数据不完整，空间内有脏数据没有清空。

4.检查串口一初始化在最前面，确实有可能没有来得及创建一些资源，那么在中断中做一些条件判断，如果信号量创建成功那么句柄一定不为NULL,所以使用空闲中断的时候在加一个条件判断一下句柄是不是为NULL。5.空闲中断在一上电也有可能触发错误中断，因为接收了一个满的数据触发了ORE中断，错误处理中断中重新打开DMA接收即可，使用HAL库没有进行其他操作也没问题，比如将数据寄存器中的数据读出来。2.查找空闲中断中的逻辑，在空闲中断中做了两件事，发信号量，发队列。背景：使用DMA+空闲中断，上电会触发一次空闲中断。

换成 QSPI+W25Q512，以为速度可以更快，但是一旦分频低于8依旧无法写入。2.使用W25Q512保存日志的时候发现，上电全部擦除以后第一次写入无法正常写入，第二次可以正常写入，查找以为是默认低电平的原因，改正后依旧不行。1.有个下电保存参数的需求，采用的是PVD+W25Q256,使用SPI,正常情况下SPI速率配的分频是四分配，未在下电的时候测试，可以正常读写。检查当前驱动，并没有擦除逻辑，不擦直接写虽然可以写入数据，但是有部分数据会乱，换成了先读取进行擦除判断再写入，测试成功。

擦除内部flash的时候影响到了串口3的接收，在擦除之前使用HAL_UART_AbortReceive(&huart3);关闭串口三的串口接收，在写入完毕 使用HAL_UART_Receive_DMA(&huart3,...,...），解决问题。stm32h743程序运行过程中，有指令保存数据到内部flash，在执行操作的时候，影响到了另一个串口接收数据。打印发现，另一个任务的DMA接收只能接收一个字节，接收的第一个字节是正确的，后面的字节丢失。在存内部flash的过程中，有关闭中断，挂起其他任务的操作。

两个任务，一个任务初始化一个结构体数组，一个任务从内部flash读取数据赋值到结构体数组中，结构体数组用来配置输出，但是配置输出异常，打印发现前面的数据被覆盖，内部flash在没有数据写入的情况下读出的数据是0xFF，怀疑是读取和初始化的时间冲突的问题。怀疑是任务大小不够，检查最开始出问题的堆栈大小，将栈大小调大没有用，事实上，全局变量是通过指针的方式调用的，并不是将整个赋值到任务的栈空间上，所以和任务的大小没有关系。怀疑是读取两个参数顺序不对，先读取的大的缓冲区再读取小的缓存区解决问题。