前两天定位一个嵌入式应用的死机问题，过程极为复杂，首先用jlink抓core文件，然后用trace32恢复现场，最后发现是idle线程的任务栈被踩了，但是没法确定是谁踩了这个内存，理论上，靠死机dump也是能恢复出来哪一个操作产生的这个现象，但极为复杂，需要通过SP去恢复其他线程的任务栈，也就是踩内存产生的实际，通常恢复出来都是被踩的任务栈，最后还是得依靠打印日志，走查代码查出来问题；最终，发现异

经过好几个平迁移DW1000的折磨，总结一下。一、速率对DW1000的影响主要有两个：1、MCU的运行速率；从STM32、nrf、gm技术、sifli等MCU，总结经验是，MCU的运行主频只要高于48MHZ，少打印串口log，以及少用memcpy等耗时操作，对dw1000的操作是不会存在性能瓶颈的。2、SPI通信速率；SPI速率主要是SPI主频，官方代码中port_set_dw1000_slowr

这个类似低代码平台的大屏制作工具，对于不会复杂前端开发，特别是做UI的同学来说，就可以直接做设计，然后拖拖拽拽的给实现了，不仅节省了前端同学的开发工作量，也节省了人力成本，开玩笑的说，前端同学的饭碗可能有影响了。

必须点赞，正点原子的资料是相当齐全的！

老李从方舱出来的那天，就下定了决心，从公司辞职，然后回老家养猪！

1、基站配置进入升级模式2、基站通过串口接收ota数据，然后通过UWB广播消息发送给标签，然后标签升级；标签和基站之间的应答

DW1000跟MCU之间是通过SPI读写完成数据交互，如果SPI数据读写有延迟，对基站吞吐量的影响是很大的，最近一次，分析标签完成一次测距时间太长的问题，就找到了SPI读写过程中的问题，当然也有选用MCU自身主频低的因素在里面；

使用ffmpeg实现一个播放器？是不是没什么新意，不过一直使用ffmpeg程序，还没有用ffmpeg代码接口实现播放器，并且还需要使用linux的alsa接口播放出声音，所以做出来还是觉得有点意思；

LINUX外接TM1650键盘，由于TM1650不是一个标准的I2C接口，只能通过操作GPIO方式模拟I2C通信；问题1:通过linux的文件读写gpio方式，支持us级别的控制；几个报错处理：1、开始通过文件方式操作export文件，发现总是失败；[failed]gpio_export path:/sys/class/gpio/gpio145open error: Permission deni

一个需求，需要实现拷贝一个本地文件到共享文件夹的功能，思路是先开启网络共享文件夹的访问，然后执行拷贝命令；开启网络共享文件夹的免密码访问，需要在cmd.exe命令窗口，使用net use命令，如：net use \\192.168.21.102 "password" /user:"test"另外，执行cmd.exe，通常方法是使用system调用或者wine