VC6的年代已经过去很久了，学校毕业出道就开始撸MFC...从MFC还算是由一些情感记忆的，毕竟是以前吃饭的家伙。
N年后，重新拾起VC。好家伙，一看版本居然都VS2019了（还有更高的版本，只是我不想当小白鼠）。果断社区版装上，嗯嗯，还是熟悉的问道，代码智能提示依旧还是那么的垃圾，这很微软。
当初的MFC只是单纯的多字节编码，管丫的什么，统统GBK。
如今的MFC默认给你开启UNICODE，默认给你开启优化。这里就产生了两个大坑：
1、坑一，默认Unicode

第一次编译出来跑一跑，第一眼看上去：“哎呀握艹，MFC居然变漂亮了，不是以前那样子了”。换了层皮之后，就掉进Unicode的大坑了
CString msg;
msg.format ...我靠，为毛线有错误？以前都是这样 format 的啊，靠着VisualStudio“弓虽大白勺智能提示”，原来改名成Format了.....wo艹，怎么还有错误，再次靠着弓虽大的提示功能，原来是要 _T() ...老人不会玩新版本的MFC了。
因为功能需要，创建了一个Pipe，从控制台捕获输出

我尼玛，从这里开始爬坑。解释一下为什么有坑：
a).中文环境，win7以前，默认GBK。从win10开始，这货居然Unicode了
b).还是gbk问题，MFC认为控制台输出的时gbk，所以在win11下，并启用了Unicode的情况下，他会自作聪明的把控制台pipe输出的内容悄咪咪的来了个转码，gbk->utf8
所以，最开始的时候，我把从pipe抓到的内容，来个utf8 -> gbk 之后变成了火星文。不转也是火星文。What the f**k?百思不得其解。最后是在一次偶然中，pipe返回值只有一个汉字+一个字母，长度居然为6 ......突然醒悟。
把编码手工还原一下 utf8 -> gbk ，我滴个乖乖，这样才对。

2、坑二，代码优化
我特么的各种断点调试呢，变量窗口各种给我“变量已优化”...好烦。关掉关掉，不然没法调试。

记录一下。新版本，新玩法，老人out了。

国内两大摄像头厂商“大华”、“海康威视”，旗下摄像头均支持ONVIF，但是两个厂家对ONVIF的理解有一定的相差。最近在做机器人视觉的时候，选型的过程中才有了4款摄像头（大华、海康各两款）。
记录一下开发过程中遇到的坑：
两家都支持SOAP的WS-Username Token和Digest鉴权，但是...（坑来了），大华在进行WS-Username Token鉴权时，会严格检查created域，当客户端与IPC的时间跨度相差比较大时，大华这边直接“401 Unauthorized”。相比之下海康可以顺利通过。这里就形成了一个隐形的死循环问题：由于摄像头刚刚初始化并上电，时间是错误，那么在进行下一步操作前，得先同步时间...问题就在这里，时间不对，要同步时间 => 要同步时间，就得访问设置时间的SOAP接口 => 要调用SOAP，就要鉴权 => 时间不对，鉴权失败......

MMP，折腾了1个星期，10+天没更新，上周末突然发现校时的SOAP接口Digest方式鉴权时可以通过的。于是只好曲线救G。
用 Digest 鉴权同步时间，其他接口继续使用 WS-Username Token

最近才知道一个让我哭笑不得的事情：在广东人眼中，广东以外的省，统统都是北方......
某个在广东的前同事最近向我咨询，如何改进GPS/北斗定位设备的数据质量，如何提高超载监控设备的数据精准度。顺便palapala吐槽了一堆市面上现有的某两大知名品牌车载终端的数据质量（我啥都没说，懂的都懂）。
拉了个网络会议，邀请了某通的算法工程师，大致了解了一下情况：
1、目前国五和国六排放的工程车，终端数据都要遵循JT808国标
2、定位数据偶尔发生漂移，少则几百米，多则几十公里
3、车子的承重数据波形图，瞬时漂移多达1000KG以上，距离90%的精确要求相差甚远

分析了问题的原因：
1、安装的时候，既为了省事，也为了防破坏，GPS天线都是跟终端用扎带捆绑在一起，塞到副驾驶位的工具箱里面。这样就导致了GPS接收数据的不稳定性。查看了轨迹图，漂移较严重的时候，大多在周边有高楼的情况下。某些特殊位置（地图上没有名字的区域），信号失真，这个应该是安全考虑，附近区域做了特殊防护措施。
2、承重数据，当前的算法居然是利用JT808的手刹信号作为标定点...让我哭笑不得。司机的驾驶习惯、终端的数据延迟等因素，都会导致手刹信号不可靠。还有一些特殊场景：诸如修路的时候，搅拌车边走边卸料，这就不可能去拉手刹。

解决办法：
1、把天线外露，放置到驾驶楼的顶部
2、采用卡尔曼滤波算法，核心思想：预测+估值，计算出合理的数值区间，让波动收敛在可控范围内。

改进意见是提了，但愿这个问题尽快得到解决。

ARM漫天飞的年代，没必要还在坚守古老的C89了。谭浩强教授的C语言教程都升级多少个版本了，嵌入式行业还在抱着古董级的东西不放......上一篇文章，贴了AHT20传感器的示例，所以干脆一不做二不休，顺便把最近写的INA226传感器的Python版代码也公布了。

说明一下：

1. INA226不贵，某宝上随便搜搜就知道，是德州仪器的
2. 这个SOC是I2C协议，兼容SMBUS，所以可以直接用Python的smbus2组件
3. 如果你怕Python工作不稳定，那么我告诉你：你想多了，我这里在工业环境下照样好好的。实在不放心，那就systemd托管起来

不废话，上图：

嵌入式开发，动不动就是C，千篇一律的C，甚至好多都特么的还是古老的ANSI89版的标准。
大学里的C语言基础教程都升级了，这嵌入式行业就这么不思进取么？
看看奥松官方的DEMO，还是用的GPIO作为示例，我也是醉了。
最近的项目刚好用到了这款传感器，都啥年代了，ARM遍地都是......所以决定，在条件允许的前提下，抛弃古老的C语言，尝试着用Python3.x来实现一下传感器数据的读取。
话不多说，上图（要抄作业的自己照着图敲一遍，别老想着Ctrl+C & Ctrl+V，这样不会有进步的）