育才学习网1.plc接收CAN总线上的信息,程序怎么写
plc接收CAN总线上的信息，可以配置成CANopen基本协议进行9针口程序编写。
CAN协议用于汽车中各种不同元件之间的通信，以此取代昂贵而笨重的配电线束。该协议的健壮性使其用途延伸到其他自动化和工业应用。
CAN协议的特性包括完整性的串行数据通讯、提供实时支持、传输速率高达1Mb/s、同时具有11位的寻址以及检错能力。
CAN总线使用串行数据传输方式，可以1Mb/s的速率在40m的双绞线上运行，也可以使用光缆连接，而且在这种总线上总线协议支持多主控制器。
扩展资料：
CAN协议总线的工作原理：
CAN与I2C总线的许多细节很类似，但也有一些明显的区别。当CAN总线上的一个节点（站）发送数据时，它以报文形式广播给网络中所有节点。对每个节点来说，无论数据是否是发给自己的，都对其进行接收。
每组报文开头的11位字符为标识符，定义了报文的优先级，这种报文格式称为面向内容的编址方案。
在同一系统中标识符是唯一的，不可能有两个站发送具有相同标识符的报文。当几个站同时竞争总线读取时，这种配置十分重要。
参考资料来源：百度百科—可编程逻辑控制器 （可编程控制器件）
参考资料来源：百度百科—CAN总线协议
2.can控制器驱动程序怎么写
CAN总线控制器用于实现CAN协议和基础数据链路层，以及用于产生一个CAN帧传送的二进制流模式，位在这个过程中馅，添加CRC校验，应答检测操作；接收的二进制码流被解析和接收收发器在此过程相比，比特填充来执行CRC校验操作。此外，需要冲突的判断，错误处理等多项任务。
CAN收发器（有时也被称为驱动程序）是在CAN总线的物理层，对于一个二进制码流转换为差分信号传输，差分信号被转换为接收到的二进制码流。
在CAN总线都是必要的。
3.STM32HAL库写CAN通信程序最近遇到了难题,有谁有具体例子不
别人写的你参考一下：半年前接触STM32，刚开始MCU用的32F1，库用的标准外设库3.5，写过一些简单的东西。
再后来发现ST还有一个软件叫做STM32CUBEMX，可以自动的生成初始化程序，对于我这个32新手来说无疑是天降福音！终于不用为繁琐的配置而苦恼了（其实就是自己对各项配置不熟，而且没有自己积累的程序可以CtrlC+CtrlV）。虽然CUBE用的是ST新出的HAL库，与以前的标准外设库完全不兼容，甚至基本的I/O操作都变了，会让习惯了标准外设库的人很苦恼。
但是我对标准外设库也不是很熟，而且CUBE的界面化设计真的让配置工程变得很方便，再加上它还有一个类似于FPGA的引脚分配界面，让资源分配，PCB布局布线也方便了不少，于是我选择了用CUBE，用HAL库。很早就开始的写32的朋友有不少，他们也试过HAL库，可最后无一例外都选择了继续使用标准外设库。
他们表示完全不习惯HAL库，另外HAL库不太好，毕竟是自动生成的配置，没有自己手动配置的来得熟悉来得透彻，谁知道软件是怎么给你配置的工程。另外CUBE就是给那些不会写32的人用的（ST的官方的说法似乎也是HAL是为了方便做嵌入式相关且对底层不熟的人设计的，但想不通他为何要把两个库做得不兼容）。
前面一直在画PCB，调PCB，做机械之类的，没有写程序。最近又开始写32，现在用的MCU是32F4，库是HAL/F4库1.6.0。
可是我发现我连GPIO的上拉输出都实现不了，无论如何I/O始终默认输出低电平（操作I/O可以实现电平跳变），这个问题我昨天查了一天，从库到最底层的寄存器都看了，可没发现什么问题。周围用HAL库的就我一个。
有些无奈了，难道HAL库真有什么问题吗？如果真有这么明显的问题，ST官方肯定早就发现了。已经下好了标准外设库，打算换标准外设库，工程从头到尾都自己配置，这样出了问题也更方便找。
可是我始终有一点想不明白，既然ST官方在推HAL库，那肯定也有他的道理，我们也应该勇于接受新事物，为何身边的朋友却都不愿意接纳HAL库。
转载请注明出处育才学习网 » can通信程序怎么写