广播测试小工具支持的功能：1、MIC广播喊话；2、组播播放音乐；      IP单播播放音乐；3、SIP客户端；     来电自动接听；4、通过广播地址搜索广播设备；代码基于DUILIB实现的界面；

windows版本ffmpeg的功能需求：1、解码mp3文件；2、解码h264;x264编译：x264-master.tar/x264-master$ ./configure --prefix=${PWD}/install --host=i686-w64-mingw32 --enable-shared  --extra-ldflags=-Wl,--output-def=libx264.d

看最近的访问搜索关键字，大部分都是通过WVP-GB28181关键字搜索过来的，原来调到一半，就去干别的事情了，趁着年前比较空闲，重新捡起来，发现还比较顺利的调通了取流，记录下过程。

原来在HW的时候，特别欣赏几个喜欢做小工具的同事，不但个人绩效好，还提升了团队的工作效率。

rv1106模块或者开发板，系统：支持buildroot或者ubuntu两种Linux系统；硬件上，支持：摄像头MICAudio+功放0.5T算力64M、128M或者256M RAM可以外挂SD卡

实现一个通过ADC采样电压值，每次采样5次，去掉一个最大值，一个最小值后，取剩下三次的平均值。//取5次adc，去掉最大值，去掉最小值，取平均值 #define BATT_LVL_COUNT  5 static int batt_lvl_history[BATT_LVL_COUNT] = {0}; static&nbs

朋友有多年的Linux实战培训经验，录制了好些Linux学习视频，分享给有需要的同学！链接：bilibili小站

前两天定位一个嵌入式应用的死机问题，过程极为复杂，首先用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的同学来说，就可以直接做设计，然后拖拖拽拽的给实现了，不仅节省了前端同学的开发工作量，也节省了人力成本，开玩笑的说，前端同学的饭碗可能有影响了。