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

最近移植代码到瑞芯微平台，记录几个问题，代码细节确实是关键！1、C++ 函数 void*返回值没有返回， 触发munmap_chunk:invalid pointer；2、mqtt-paho库，MQTTClient_subscribe主题为空，导致mqtt主动断连，出现lost conn现象；3、void *payload数据直接复制给string，尾巴出现多余字符； int msga

pjsip自带的回声消除处理包括webrtc-aec3，效果不是很理想，切换为webrtc-aec后，确实能明显的感觉到回声被抑制了

一、理解广播地址：专门用于同时向网络中所有工作站进行发送的一个地址叫做广播地址。在使用TCP/IP 协议的网络中，主机标识段host ID 为全1 的IP 地址为广播地址。如果你的IP为：192.168.1.39，子网掩码为：255.255.255.0，则广播地址为：192.168.1.255；如果IP为192.168.1.39，子网掩码为：255.255.255.192，则广播地址为：192.1

广播的业务还是挺好实现的，作为练手项目绝对不错，主要涉及到几个点：1、音频数据采集；2、音频数据编码；3、媒体流组包发送；4、UDP Socket服务器、客户端实现；5、音频抖动缓冲区，及播放器实现；

吞吐量要解决的几个问题：1、标签时隙管理；一种方式：基站主导，官方的TREK1000代码有类似的逻辑；一个标签，比方每2s发送一次P帧，2、多基站测距；A站、B站、C站回复A帧的时间不同，需要做延时发送；具体延时多久，也需要同标签做好时间窗口同步；

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

硬件同事在调研通过PCM音频模块，完成PCM音频流的播放，一共使用了3个模块：1、CJMCU-5102模块：PCM5102为 I2S-DAC 解码器；支持I2S输入；没有参数配置；2、WM8978模块： WM8978为DAC+ADC芯片，除了DAC解码功能，还带了一个MIC录音功能;支持I2S输入；支持I2C配置相关参数；3、VS1053模块：VS1053是音频编解码芯 片，支持：MP3/WMA/

近期的几个问题着实让人头疼，过程也是相当坎坷；1、丢包率硬件的稳定性，软件一样的逻辑，丢包率居高不下，一直在40%以上；还好硬件同事不甩锅，发现硬件PA的问题，重新修改了一版硬件后，确实丢包率下来了好多，还是需要有一般靠谱的伙伴；当然软件这块也做了好多修改，丢包重试；sniffer模式的实现；2、功耗；功耗仪上测试了好几版，抓波形，分析工作时长；分析竞品的工作时长，找到功耗消耗长的原因：第一个：T

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