含光左卫的工作笔记集

现代嵌入式芯片的的一些名词解释和图例。包括BGA，QFP这类典型封装，DIP这类已经不太常用的封装未提及。

一组更方便地读取json格式配置文件的辅助函数，可以输入以分隔符"\\"分隔的路径，然后直接读取到叶子节点，如果叶子节点是字符串格式，可以直接读取字符串的内容。

gcc 环境调用python相关的配置和互操作提示。

一个传感器生成的两段数据，从第5个字段开始，是一些精度为8us的时间锚点（我的时钟没有让它采得太密）。据自然 S16溢出。它的物理意义是电机内的七个扇叶转过的时间，扇叶不是等间距的，它的反应速度足以测量出7个扇叶间距的细微差别，重复性很好。你可以对比两组数据，和同一组数据，两组数据的转速不同。

一次代码优化实战

随着采样深度的加密，FFT能识别到更高的谐波，但是如果你的示波器档位不变，你的频谱的粒度，那种分辨率是固定的。如果一个信号的周期是3.125Hz....那么，你仅仅能觉察到在频谱上在2Hz和4Hz的谱线上，会有一个峰值。这无法满足测量要求。

电机的输入电压和电流波形上叠加的有高频信号，在进行计算前，如果需要求得有效值，则必须进行整周期判定。这里提供了一个Matlab函数可以做这个事情，它会把U/I信号中的一个完整的周期相关采样数据摘出来，存储为独立的文件。需要三个数据通道——电压、电流、转子转速，另外的一个额外参数是电机的极对数，实际处理时用到了一些简化处理，如果发现最终输出的不是一个完整周期，可以调整特定的门限值。

从海思Hisi3531公板替换掉了音频芯片tlv320aic31，转换为wm8978，针对这个改动修改了音量调节功能。代码修改涉及三处地方：.ko的驱动部分；中间层；和应用程序。音量调节功能，使用ioctl机制来实现。

Step2.对照原理图确定LED显示所涉及的管脚定义，因为不必完全点亮LED，所以，仅选择了8段LED的三位,驱动LED似乎需要一个锁存器EN使管脚，再加上LED地址脚，合计五个管脚。编译环境：xc8-v2.41-full-install-windows-x64-installer.exe。Step4.3 编译，补齐缺失的函数（该函数中需要将具体的IO管脚操作与程序的功能合并在一起）Step1.确定芯片的振荡器，查阅芯片手册，对比原理图，最终确认，可以使用内部振荡器。

注意右下角那个Auto Import Hex + Write Device.按钮。在第一次连接到板子后，这个按钮就会激活，点击后，这个PicKit3 Programmer会利用windows自身的文件修改感知功能，侦听对应的.hex是否被改写，一旦文件的modify time被刷新。它就会自动启动加载.hex，并完成烧写动作。

表达式计算 - 逆波兰式转换及运算示例自定义表达式运算中，涉及到三个步骤： 1.关键字析取 2.中序表达式转逆波兰表达式 3.逆波兰表达式运算。 本实现基于C#，可生成对象化的中序表达式和逆波兰表达式，可处理函数，并有规范的函数运算扩展示例。

在编写与设备相关的代码时，有时候需要将部分状态信息展示给用户。状态信息有时候其基本结构并非固定，而是需要通过某种方式读取配置信息，自动生成。基于代码快速生成的需要，这部分状态信息通常会是一些文本信息。并且这些信息在向最终用户展示时，需要支持自刷新。这里展示了一种不涉及图形界面的信息展示技术。它直接以静态html文件为载体。利用html本身的自刷新功能，不断周期性自动加载.

注意：本文的内容无法保证绝对精确，后续可能会做改动，只是自己的笔记。这里的资料均源自数据手册本身。PIC18系列单片机的参考时钟可以选择三个基础时钟源：时钟源分为两个是为了适应高低功耗模式。内部时钟源有三个主振荡器，分别提供HF16M， MF500K和LF31.25K的频率。内部时钟可最高提供16M的时钟。使用外部时钟时，针对主时钟，可以引入一个4x PLL。在查看既有开发板的原理图，想要弄懂的相关的时钟配置时，首先需要查看芯片时钟管脚。芯片的管脚定义在PIN表格中。

针对某个问题的算法生成后，会有一个标定参数的过程。如果这个过程在台式机上进行，大多没有什么障碍，因为你可以在高级语言库里找到完备的矩阵算法库。但是对于单片机环境，本身字长可能只有8位，16位，此时的算法不得不考虑算法中的误差传递，不是非常容易处理。注意，有时候需要对函数体进行指导性的脚本展开，而不能直接代入一些matlab已经验算出的实参。因为芯片库直接有double的支持和math.h库的支持，所以它就仅仅是上面的这种。最终生成的C代码可以直接在嵌入式芯片的编译环境直接使用。确定输出的芯片类型。

MHz级别的单片机，对应uS的间隔，它的运算速度与人工的速度相似，它此时仅能完成有限条数的指令。要特别留神，你只能依据自动计数的定时器，你绝不可以通过中断来数时间间隔。对于单片机，要特别注意采样间隔。这个采样间隔不仅仅是mcc提示你的采样间隔。你还需要考虑到单片机本身的运算极限。你遇到了编译器的优化极限。对我而言，从o0->o2，问题解决。关于手工进行adc采样。关于手工进行adc采样。

所有的软件开发人员都会在他的职业历程中设计一个串行口收发单元。这里展示了一个 基于串行口的协议封装实现。大家可以对比一下自己的实现看看。首先需要对整个软件的结构进行拆分。理论上它应当至少分割为三个大的部分： 1.通讯层。处理bit流的传递。 2.数据帧层。处理frame的析取和打包。 3.应用层。处理各个独立的数据帧。并提供更上层的信息通道。通讯层最先构建，并可进行独立测试。它又按照内部的逻

extern "C" void *malloc(unsigned nbyte) {    static int* begin = (int *)Image$$RW$$Limit;                                //堆首地址     static int* end = (int *)(HEAPEND);                       

//将r中第base位至第base+len-1位赋值 value#define SET_BIT(r, base, len, value) / do{ / int i; / int mask = 0; / int tgt = (r); / for(i=0; i<(len); ++i) / { / tgt &= ~(1<<(

//--------------------------------------------------------------------------- // 模块:          环形缓冲区类 TFengRingBuf // 版本号:        V0.2 // 编写人:        Twicave(twicave@yahoo.com.cn) // // 简

//--------------------------------------------------------------------------- // 模块:          环形缓冲区类 TFengRingBuf // 版本号:        V0.3 // 编写人:        Twicave(twicave@yahoo.com.cn) // // 简

//将r中第base位至第base+len-1位赋值 value#define SET_BIT(r, base, len, value) / do{ / int i; / int mask = 0; / for(i=0; i<len; ++i) / { / r &= ~(1<<(base+i)); / ma

//观察因为Cache未命中引起的程序执行速度变化 //  传入参数, int型缓冲区指针，大小必须大于2*64*256 bytes //  里面的几个常量的值源自ARM920T的Cache结构 void cache_miss_control(int *buf){    long tm;            //起始时间     long total;      

//将r中第base位至第base+len-1位赋值 value#define SET_BIT(r, base, len, value) / do{ / int i; / int mask = 0; / for(i=0; i<(len); ++i) / { / (r) &= ~(1<<((base)+i)); /

因为这两个函数是C库函数，对他的稳定性产生怀疑似乎没有来由。但是先请看一段代码：#include #include #include static jmp_buf jmpbuf_1;int g_a = 0;void test(int index, int *local_val){ g_a = 1111; *local_val = 2222; longjmp(jmpbuf_1,index);}int main(int argc, c

//---------------------------------------------------------------------------// 模块:          环形缓冲区类 TFengRingBuf// 版本号:        V0.31// 编写人:        Twicave(twicave@yahoo.com.cn)//// 简要说明:      实现了环形缓冲区

//目的：企图定位ARM-Linux下程序运行速度缓慢的原因。 //  TYPE, 缓冲区的操作类型（比较同样的运算规模下int8, int16, int32的执行速度差异） // //  buf, 一个大小为SIZE*2(Bytes)的缓冲区 //  SIZE, 实际进行操作的缓冲区的尺寸(Bytes)（比较运算规模线性增长时，执行速度是否线性下降） //  SPAN

 //////////////////////////////////////////////////////////////////////////////// //main dfm %start   dfm_main::Init%class   LogicMainForm%header  MainFormLogic.h////////////////

485的发送规则是：0起始位一个，1停止位一个，连续发送时，以起始位0打头，紧跟字符MSB的8个bits，中间用一个停止位1和一个起始位0隔开。然后是下一个字符的数据区。

1.可以选择那些理论上不可能有偏差的特殊波特率：比如，上图给出的64M晶振下，10417的波特率，是准的，64M可以被10417波特率下的单字节发送所需时间整除。在采用64MHz的时候，波特率设置为115200波特率，会出现-3.55%的偏差。这个偏差如果不校准，发送时会偏得越来越厉害。2.打开芯片一侧的波特率自校准功能。

一个从流中进行指令匹配的代码。嵌入式项目可使用。

IIC调试时遇到的一些故障，及排错过程。

震荡器因为芯片内部已经预置，一旦决定使用外部震荡器，要么是为了协同工作的目的，要么就是为了获得更高端的采样精度。所以，一般会使用晶振。晶振在使用时，PIC单片机提供了三种模式：LP,XT,HS，这三种模式对应了三种不同的增益级别，在AN849中，介绍的很清晰。它依据晶振的频率，LP->XT->HS频率越来越高。

一起485 YModem协议的解析故障，及其处理。

一个嵌入式芯片的运行错误，调试及排错过程。。。Step by Step

PIC18芯片手册 DataRam 部分笔记

一个完整的Bootloader系统实例：包含升级文件的确定。升级文件的解析，直到和底层指令Flash烧写函数挂接的整个逻辑。我们假定升级文件是以流的模式传递的。为了避免更多的依赖，直接对.hex文件本身做解析。

因为这个仿真器不是原厂的，因为粗略试过，无法在集成调试环境中仿真。我一直只做程序烧写器用，最近因为在调485通讯，没有多余的调试串口，而485又是个半双工设备，发送和接收会相互影响，极难调试。今天终于把这个问题搞定了。最关键的一篇文章在这里：

bootloader写成后，需要处理传送过来的.Hex，或者等价的文件的烧录。MicroChip官方并未给出一个.Hex转为.Bin的处理策略。在它的Bootloader代码中，我们可以大致看到它的实现机制，它定义了一组命令。上位机在处理升级时，与Bootloader要通过这组指令进行信息传递。这是一个交互式的协议。如果我们抛开这个交互协议，希望自己处理升级过程，那么，需要对.Hex文件本身进行处理。然后才能让bootloader解析。

Ymodem协议的交互过程，可以通过安装串口监听工具（比如BusHound之类）使用支持Ymodem的客户端软件，监听得到。基本通讯过程如下：发送端设定好要发送的文件列表，进入YModem等待发送状态接收端发送"C"，告知已准备好，提请发送。发送端发送首帧，帧头01 00 ff，01标志这是一个传输起始帧，且长度为128字节。不过注意一个数据帧帧头3个字节，帧尾还有2个字节的CRC，实际是128+5字节。注意帧头非Word对齐，编码时可能要注意。首帧中包含有文件名称，大小，时间戳信息。...

注意：下列描述是在PIC单片机上启用Bootloader的一个相关知识的近似完备集。所有需要了解的，与bootloader与用户态程序交互的理论知识都已给出。包含内存组织，跳转，中断等必备功能的描述。