355_通过CAN通信实现printf

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

       工作之后从事嵌入式让我有点傻眼了，因为printf没了！我们设计的控制器上甚至连串口都没有，如何printf呢？然而，那时候开始接触高端的调试器以及标定协议。瞬间感觉一个printf在这些东西的面前都不值一提！然而，随着时间的推进，我自己基于兴趣以及职业需要的驱动接触了更多的嵌入式平台，尤其是汽车电子的嵌入式平台。这些平台在实际的产品中一般来说就是没有串口的，而且相应的调试器价格确实是有点昂贵。这时候，我又有点怀念曾经的printf了。

       有一个词语叫做“开卷有益”，的确是。翻一本旧的老书的时候，再次看到了printf的介绍，其实这个功能本身的设计是不依赖于任何通信方式的，如果我们是STDOUT，那么就是PC上标准的命令行显示；如果是串口，那就是串口打印；如果是其他的方式，自然也可以。这样一看，说起来很容易啊，最起码汽车电子基本都少不了CAN，这个一定可以。当然，我可以实现简易的GPIO的打印也能够实现速度更快的SPI打印。不过，嵌入式的软件实现容易，我还是缺少一个东西的，那就是一个上位机，用来把我打印的东西翻译出来。这样，其实有一个CAN卡的驱动，相应的功能实现就容易多了。其实，这个功能之前我已经自己尝试做过了。但是，我感觉这有点重复造轮子的感觉，因为这方面很多成熟的工具都是基于串口的。既然如此，那么何不实现一个基础的CAN转串口？

       我找到了一个简单的方案，使用Arduino + MCP2515，之前自己做的小测试还在这里： https://blog.csdn.net/grey_csdn/article/details/101712390

       这样，一个简单的设计就有了：还是用上面的这一套，我通过我自己开发中的控制器或者板子给2515发送基于CAN的printf信息，传到Arduino之后做一个串口打印即可。整个硬件实用过程也非常简单，因为Arduino只需要一根USB线即可。关于printf的实现，之前也有一个实际测试的学习记录在此：https://blog.csdn.net/grey_csdn/article/details/105311915

       那么如何实现一个简单的上位机显示呢？这里先放一部分我自己测试的Arduino代码参考：

//——————————————————————————————————————————————————————————————————————————————
CANMessage frame;
char putc_char;void loop()
{
#if DEBUG_MODEframe.id = 0x77;frame.len = 8;frame.ext = false;frame.rtr = false;frame.idx = 0x0;if (can.tryToSend(frame)){Serial.println(counter++);}delay(100);
#endifif (can.available()){can.receive(frame);if (0x77 == frame.id){memcpy(&putc_char, frame.data, 1);Serial.print(putc_char);}}
}


       其实，核心代码就是一个接收判断并打印。本来也就没有太多的功能，而且，上面其实还带了一部分我自己的测试代码，预处理部分甚至在实用中都可以去掉。

       接下来，看看基础的效果吧！

       功能实现还是很容易的，而这个基本上也可以满足一个小型工程开发的大部分调试需要了。那么，这个设计是否足够好了呢？没有！两个因素：1，CAN的数据场只用了1/8，因此效率不高； 2，CAN的发送我采用的是1ms发送一帧，虽然足够快了但是依然没有实现最高的性能。以上两点，还是有改进之处的，后面针对第一点，我还会再做一个简单的修正。其实蛮容易，但是懒！主要是这样对我来说也够用了！（捂脸表情）