小灰笔记

在批量数据更新的时候，可以通过工具进行标定数据的地址偏移，将地址偏移到FLASH区间或者通过刷写的上位机进行地址的偏移转换。其中，FLASH的指针表可以固定在FLASH中，RAM的指针表可以用于标定的切换或者依然索引FLASH原始数据。页面切换的效率大大提升。这种方式，需要进行标定的参数存储在Flash中，以全局量的形式呈现，不进行额外的RAM分配。再加上MCU支持分页的映射，因此整个标定数据可以拆分成若干标定的子页面，根据标定的需求使能FLASH到RAM的映射，能够在很多使用场景下降低标定RAM的使用。

使用dbc文件建模完成CAN通讯是一种比较高效的开发模式，不过在建模的过程中dbc文件中描述的数据需要自己去定义。出于示例的简单，只定义了8位和16位的数据。完成一个M脚本，脚本会通过对MATLAB Workspace中的数据模板进行拷贝修改完成数据定义。运行后，Workspace中已经生成dbc中的数据定义，只需要把这些数据保存成mat文件即可保存使用。在MATLAB的Workspace中定义8位以及16位的数据定义模板，然后执行M文件。后续，提供使用这个示例中的dbc文件进行建模的方法。

全部学习汇总： https://github.com/GreyZhang/J1939_basic 前面大概看了J1939的请求报文，其实就是请求一个PGN的信息。今天，把手里的例程基本梳理了一下。感觉大概调试了一下，基本上看明白了大概的用法。只是，例程似乎只是用于基础功能的演示，并没有严格遵循相应PGN的定义。 这里，先大概了解一下发送机转速PGN。 其实，这个是已经在文档中定义过了的PGN。如果，实际的应用肯定得按照这个来。...

全部学习汇总： https://github.com/GreyZhang/J1939_basic 这次来小结一下请求报文的发送，因为响应部分暂时有一点点模糊没看明白，还需要补充一点文档信息。 关于请求报文，我参考了恒润的一份PPT中的一页，这个在很多文库能够看得到。具体部分据图如下： 从这份PPT中的信息看，其实请求报文还是很简单的一个东西。至少，请求的动作还是很简单的。这是一个固定的报文格式，填充一个PGN的信息即可。而请求...

全部学习汇总： https://github.com/GreyZhang/J1939_basic 在J1939的协议栈中存在一个队列的收发机制，其中接收队列的实现之前在做ISR的部分代码分析的时候已经看过接口上的交互。对于这个队列实现，其实应该有一个具体的实现机制。 关于队列的机制，在学习数据结构的时候接触过队列的实现，这个基本上是基于链表来实现的。但是，链表的实现是需要基于内存的动态分配来实现的。在嵌入式系统中，尤其是涉及到高实时性和可靠性相关的系...

全部学习汇总： https://github.com/GreyZhang/J1939_basic 之前研究Arduino的时候，看过了Arduino开源社区中别人对ECAN使用的时候使用了队列的收发。全都是软件实现，没有使用硬件的模式。手里的这套J1939的代码也有这么一个类似的功能。 接下来，看看手里这套代码的处理。 关键代码都在注释上面，其实，下面的部分也已经不在同一个代码块。正好这个函数还剩下这么一点没做分析，一起给标注...

全部学习汇总： https://github.com/GreyZhang/J1939_basic 之前，大概分析了J1939_ISR，要想明确弄清楚J1939的收发的机理需要继续分析两个CAN的收发接口。这里，先尝试分析一下CAN消息的接收功能。 首先需要注意的是，这个函数用了static，因此使用的范围会有一些限制。通常是不会出一个文件，尤其是其在C文件中定义的。后面的代码，出现了好几重的预处理，目前我的emacs配置下需要层层查看。万不得已，...

全部学习汇总： https://github.com/GreyZhang/J1939_basic 经过之前的几次代码分析，基本上知道了广播多帧报文的实现是一个什么过程了。也基本上知道了命令地址实现的基本流程和方法了。 我现在接触的3份J1939的代码例程中，有一份是使用POLL模式，而最近的两份代码则是使用的中断模式。虽然，大概的功能已经分析过了，但是中断ISR还是没有看过究竟是如何用的。而这部分应该是这份代码在不同平台上移植的关键。...

全部学习笔记汇总： https://github.com/GreyZhang/J1939_basic 前面了解了一下广播多帧报文的实现分析，当时发送了一个0xFED8（65240）PGN的信息。但是，这种数据的组包顺序以及规则没有弄清楚。 我没有系统阅读过全部的J1939的资料，因此直接借助了网络资源。找到了一份文件，对此的解释如下： 这一组报文的发送必须是通过BAM来实现，因此这是之前我们看到的功能的实现原因。之前的报文发送...

全部学习汇总： https://github.com/GreyZhang/J1939_basic 借助一个简单的例子来看一下J1939广播多帧报文的发送实现。为什么不叫多帧报文而叫广播多帧报文呢？因为在J1939中存在两种多帧报文的发送模式，一个是广播另外一个是点对点的。而两个流程是不同的。 上面的这个流程图就是J1939的广播多帧报文的实现，这个是我从Vector的一份文件中截取出来的。从上面可以看得出，大概的流程是先发送一帧TP.CM_BAM...

全部学习汇总： https://github.com/GreyZhang/J1939_basic 前面做了一个地址声明初始化的功能分析，但是这个动作触发之后还应该有一个确认的过程。其中，声明不成功的处理还是容易的，因为会直接收到一条报文。如果是声明成功的话，需要等到一定的时间，在相应时间内没有冲突报文则可以取得相应的地址。 这是超时处理确认的处理，关键点还是在上面的这个状态的变化。需要确认这个状态是否被清零了，因为在初始化的时候这个状态是置位的。...

全部学习汇总： https://github.com/GreyZhang/J1939_basic J1939地址声明的接口功能之前基本上分析过了，这一次看看在整个我看到的例程中这个接口究竟是如何使用的。毕竟，这个接口还是有两种不同的使用模式的。 这个接口在整个工程里面被调用的次数不是很多，我搜索了全部的工程如下： 最前面两个还有最后两个是没有必要关注的，这都是生成的文件或者辅助的工程文件。H文件中的就是一个声明，也不需要看。接...

全部学习汇总： https://github.com/GreyZhang/J1939_basic 前面看了一个初始化的接口，发现其实跟协议栈相关的更多的还是最后的一个队地址声明接口的调用。 这个函数是一个静态函数。 通过这个简单的细节就可以知道，这个是一个协议栈内部的一个功能，也就是跟协议栈的协议实现有着很大的关联度。好在，看了一下这个函数的代码量之后让我舒了一口气。这个函数的实现代码量还是很小的。...

全部学习汇总： https://github.com/GreyZhang/J1939_basic看了一下我手中的这一份J1939的代码其实代码量不大，看起来我可以直接做一个详细的代码分析。这个就是初始化的第一个接口，今天就完成这个接口的分析。 其实这个主要是一些状态和设备的信息初始化，在不同平台有一些工作可能可以通过其他的方式来实现。 当前我看的软件中，上面的设计可能有一些啰嗦。不过，上面这个考虑到了不同传入参数的处理。 这些其实还是CAN驱...

全部学习汇总： https://github.com/GreyZhang/J1939_basic 上次做了地址声明的部分分析，当时出现了一份报文交互记录。当时只注意了源地址和目标地址，没有注意到数据场。今天没事儿的时候突然间脑子里想起了这么一回事儿，当时的数据场到底是一个什么信息呢？ 我找到了前面的报文记录： 首先，在Vector的一份文档中有如下的描述。 如果地址声明的时候出现了地址冲突，名字具有更高...

全部的学习汇总： https://github.com/GreyZhang/J1939_basic 之前测试用的两个板子，测试的过程中为了区分增加了一个定义：板子定义为A（地址0x80），B的地址为0x81。 现在，我手里的B板子已经进行了一次地址声明且测试过了。现在，尝试做一下测试，修改A板的程序让它的地址也设置为0x81，这样等我的A板上电运行进行地址声明的时候应该会出现冲突。 简单的修改如下： 软件修...

全部的学习汇总： https://github.com/GreyZhang/J1939_basic 前面做了官方例程的测试，两个板子能够通过按键分别控制对方的LED的亮灭。现在，做一个简单的修改： 把目标地址改成130，也就是0x82。这样，通过这个板子按键的时候，将会发送报文到目标地址0x82。姑且把这个板子定义为A（地址0x80），B的地址为0x81。 修改之后，做了两个测试。第一个是使用A的按键触发请求，结果B的灯本次没...

全部学习汇总： https://github.com/GreyZhang/J1939_basic 如果看到细微之处，CAN通信似乎从来都不是那么简单。尤其是到了协议栈的环节，万千变化最后还得回归到枯燥的文档，的确是不容易啃透。我自己尝试了多次J1939的学习，但是大部分都是处于理论性的材料学习，而这种学习基本上也是看完后面的前面的就会忘记。 正好手头有两个PIC18Fxxxx的开发板，虽然MCU的型号不同但是至少是架构一致而且全都带有一个ECAN模块...

全部学习汇总： https://github.com/GreyZhang/PIC18F 看了一个CAN接收的例程，本来还打算做一个最终的调试，把我之前的部分CAN代码也一起放进来。后来想想，不能够一直凌乱下去。先做个简单的分析，后面创建一个工程开始全新的功能调试了。 代码的排版等格式我大概用工具进行了一个处理，现在勉强有更好一点的可读性了。 加了一部分我修改过的代码了，不过不打算继续调试了。不过，还是增加了一个我之前修改过的一...

再次回顾之前的小项目：https://github.com/GreyZhang/printf_via_CAN 前面增加的Arduino例子可以看得出最后的版本工作是没问题的，但是这个是不是就是最好的呢？其实不然。为什么呢？printf的核心映射实现是putc的接口，在这个模块中我们改成了另一个名称。这个功能实现的是一个字符的操作，那么如何实现一个字节到CAN的多字节转换呢？在这里，我们引入的其实是一个队列的机制。 在之前的代码中，队列机制其实是实现了...

之前做了一个小项目，通过CAN通信实现printf的功能。在实现方案中，我给出了底层发送以及上位机解析的简单方案。相关的链接可以查看： https://github.com/GreyZhang/printf_via_CAN 但是，底层给了简单的代码没有可以直接用于演示测试的例子。因此，在此把这个部分功能直接移植到Arduino上，用以做一下相应功能的展示。自然，Arduino本身不需要这个功能，毕竟它有便捷的串口通信。 这次的移植，全部的工程代码可以...

这是我很早就需要补上的一课，工作因素，之前的代码基本能够满足要求，因此这方面也就一直没关注。看起来，工作还是不能太忙了，太忙了总会阻碍一个人的进步。时至今日，我依然感激曾经北京三年打酱油的日子，不加班让我有大量的时间可以去自我提升。 本来，在工作之中补上这个落下的功课是最好的。好巧不巧，还是到了我自己的自我学习过程中。而我这次的学习，竟然也有点返璞归真，没有采用工作中那么复杂的MCU，而是直接基于Arduino和一个扩展板。说白了，其实是基于MCP2515的CAN芯片。...

之前的版本其实在一定程度上有一定可用度了，但是，缺点在于换个波特率就需要重新烧写程序。这个比较令人恼火，使用不是很便捷。 其实，要做一个波特率切换也不是很麻烦，而且C++在字符串等处理上比C容易不少。这样，还是增加一下相应的功能。 常用的波特率250kps、500kps、1000kps，暂时在软件中支持这么多。增加代码如下：void loop(void){ if (Serial.available() > 0) { ...

之前，在基于CAN实现的printf中提到了几个改进之处。具体的描述参考：https://blog.youkuaiyun.com/grey_csdn/article/details/107732595 关于数据场中8个字节的充分利用，如果是进行Arduino相关的实现比较简单。为什么呢？这个不同于XCP、UDS等复杂的协议栈还需要对报文进行解析，这里需要的只是按照字节顺序逐个输出即可。自然，对应的printf的实现自然也应该按照这种方式来实现。不过，如果原来的printf功能不做升...

其实，上大学的时候觉得嵌入式或许不是很难。虽然是一个软硬结合的东西，但是大部分的内容都是可以在电脑上看到的。当然，这是那个时候的一个初级的认识。那时候接触的开卡板种类很有限，而大多数的平台都有现成的开发环境，基本还都支持串口打印的功能。加上那时候正好看到了一个故事，说ken老爷子的软件调试只需要一个printf即可。自己想了下，确实也是，不清楚的东西就printf一下呗！ 工作之后从事嵌入式让我有点傻眼了，因为printf没了！我们设计的控制器上甚至连串口都没有，如何print...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 近段时间计划学习S32K144，CAN相关的东西基本上都是驱动类的，但是如果要进入到工程阶段就得需要搭载部分协议栈。 一般来说，各种协议栈都是商用的，价格也都不便宜。不过，现在网络上也有一些可以用于学习的一些资料或者软件库文件。多少能够让我们学到一些基础的东西，...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 这算是计划之外的一份学习总结，本来打算错误能够触发捕获到就结束这一项学习。不过，看了一下SDK的代码之后我发现其实这里还有一个小技巧值得去看看。这个技巧就是快速判断出buserr、busoff之类的错误是否发生了。 之前做PowerPC的驱动开发，习惯了半导体提...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 继续S32K144的学习，今天来看看CAN的错误诊断。关于这部分，如果要做到产品化的一些指标其实需要一些其他的东西。比如，BUSOFF的快慢恢复模式等。我这里看的仅仅是驱动实现的可能性，因此仅仅是看看使用这个芯片的时候这个如何提供基础的功能信息而不去做这部分的实现。...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 以前的学习笔记写起来，都有一种整理测试记录或者调试记录的感觉。我觉得其实这样虽然简明扼要，但是总是少了一种生活的味道。或许，以后把我的学习笔记写得更加生活化一点会更有意思。至于学习中的几个要点，只要是笔记的内容够短总能快速提取出来。 今天的学习笔记说起来有一点点...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 继续S32K144的学习，昨天稍微深入学习测试了一下FIFO的接收模式，使用的是中断接收的方式，最终感觉让我打开了一扇新的学习大门。原来这个CAN的收发不仅实现容易，而且功能十分强大。 昨天调试FIFO接收功能的时候，使用的是中断模式。今天尝试一下DMA模式下的...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 继续S32K144的学习，还是进一步深入CAN相关的知识细节。这一次学习小结一下CAN的几个回调函数，因为这个会关系到接下来我对几个协议栈相关知识的探索。不仅如此，整个CAN驱动是协议栈实现的基础，在学习协议栈之前肯定得有一个深入的掌握。 今天需要看看CAN的接...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 最初看文档的时候，几种不同的FORMAT以及掩码把我看糊涂了。 先看看三种不同的format，其实这个还是好理解的。这三种format，决定了filter的作用。如果是选择A的话，那么就是所有ID的bit都是100%匹配的。如果是选择B或者C，那么只有一部分...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 继续S32K144的学习，这次来看看CAN的FIFO接收模式。FIFO的功能是使用多个buffer级联，组成一个队列的方式实现队列的报文接收。使用FIFO，可以让驱动软件设计更加简洁。同时，FIFO在接收的能力上也是很强的，可以让我们在后期软件处理上有更多的设计尝试。...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 继续S32K144的学习，今天做一个简单一些的尝试，修改CAN的波特率。看了前面的CAN的简单实现，我感觉这个应该很容易。 常见的CAN的波特率配置有三种，250K、500K以及1000K。在使用的时候，一般分别对应的场景需求有J1939、UDS以及BootLo...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 继续S32K144的学习探索，这次看看CAN默认配置获取功能。这个函数之前在看文档的时候是看到过的，但是一直没在意。主要原因可能是因为我并不是很清楚这个接口可以做什么用。难道是用于反初始化之类的操作？ 看着相应的信息，其实也是很熟悉，这部分我们打开S32DS...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 前一阵子花了太多的时间来学习lisp，暂且稍微换一下相应的步伐。继续S32K144的学习，今天来看看CAN的接收初步。简单起见，我直接使用SDK进行测试。 注意到文档中的几个关键点： 为了能够使用CAN的驱动，首先得调用这个初始化的函数。这部分我们...

这部分功能我关注的很少，我用到的CAN协议中的因子都是在消息传完之后自己增加。这样，我用到的Simulink仅仅是一个最简单的翻译功能。       有一阵子我觉得带有factor和bias的信号使用Simulink实现就是第一个定标的实现，后来我发现无论我怎么进行定标信息的修正始终出现数据类型的不匹配。直到有一天，随手拽了一个强制数据类型转换的模块实现了代码生成。从代码中，我发现其实定标信息