完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
电子发烧友论坛|
你好,我们正在搞一个项目,需要连接两个pic18f45k80。现在我们正试图用两个pic18进行测试设置,其中一个只传输简单数据,另一个只接收数据。这个想法是,两张图片将颠倒一个LED的当前状态,因此当他们收到一条消息时,他们应该同步闪烁。但是,我们还没有达到那个程度。我认为我们已经为发送方和接收方都配置了正确的软件配置。我们设置了发送方的CANTX被校正为接收方的CANRX。我已经看到发送节点正在尝试发送,但我认为接收方不会向发送方确认至少一个节点正在监听。该范围显示发送器的TX线在几毫秒内被拉到零。之后线路很高,接着是15个非常短的零点。我想知道这个没有CAN收发器的硬件设置是否可能。我也想知道,如果没有看到我们的源代码,您是否有任何建议或提示。预先感谢
|
|
相关推荐
17个回答
|
|
|
你可能需要收发器。一个想法-但我不是舒尔是否工作:配置TX引脚作为两个设备上的开路漏,并连接一个上拉复位器。在每个PIC连接TX引脚到RX引脚。然后连接一个设备的TX/RX到第二设备的TX / RX。
|
|
|
|
|
|
为了扩展一下Weydert的想法……如果CANTX引脚是开路漏极,你可以把所有的TX/RX线绑在一起,然后加上一个上拉线。否则,如果CANTX信号是推挽信号,你必须用一个二极管隔离它,这样它只能把总线拉低。可以使用EGIST位来实现这一点。根据描述,在ENDRHI=0的情况下,CANTX管脚在隐形时是三态的。通常使用收发信机时,我必须设置这个位=1,这样CANTX管脚在隐形时将驱动VDD。否则,线路浮动,收发信机有问题。
|
|
|
|
|
|
Weydert是正确的。我以前用另一个制造商的MCU做过这件事。然而,当这些MCU配置为CAN时,我们不能将它们配置为开漏极,因此我们需要在两个MCU的CAN-TX和CAN-RX引脚(朝向CAN-TX引脚的阴极)之间添加阻塞二极管。然后将CAN-RX线与上拉电阻连接到VDD。
|
|
|
|
|
|
如果您正在以低速(<100Kbps)工作,并使用缺省的PORTB CANTX/CANRX引脚,那么您甚至可能能够使用内部PORTB上拉来逃避。我会试着打开两端的所有引脚,虽然我不知道使用CAN外围设备是否会覆盖TX引脚上拉功能。如果你想要更高的速度,那么我肯定会添加一个外部上拉。
|
|
|
|
|
|
为什么要使用这个应用程序?如果你在两个CPU之间进行通信,似乎是多余的。CAN对于许多CPU共享同一两条线路径的多处理器应用来说是非常好的,但是对于两个CPU系统,UART或SPI可能是更好的选择。
|
|
|
|
|
|
谢谢大家的回复。我改变了CiCON.EndRI位为零,并添加外部拉升到TX RX和RX TX通道。结果是一样的。但是,CuleGe也在努力,我们现在把MCP2551添加到设计中。然而,我们现在只有一个,所以我们在发射器侧连接它。但是它承认,或者是传播者在回应一个确认,或者PIC以某种方式回应它自己的信息。现在我们可以看到实际数据:D。现在我们看到实际数据,我们可能可以计算出其余的数据(我希望)。我们认为,如果没有收发器,使用两个节点会更容易。但这似乎要困难得多。CAN收发信机似乎使事情变得容易多了。承担这么多事情感觉很不专业,为此我深表歉意。我也为我的语法道歉,谢谢你们的帮助!
|
|
|
|
|
|
在添加收发信机之前,您是否尝试将所有CANTX/CANRX管脚连接在一起,以便它是单个线总线,或者您是否具有单独的CANTX->CANRX,反之亦然。
|
|
|
|
|
|
你好,杰瑞,我试过分开的CANTX->CANRX。“每个CAN外围设备都需要能够“看到它传输的内容”,因此单线连接。“这现在很有意义。”我们仍在苦苦攻读CAN芯片,但我可以在今晚不使用TigCIEVS的情况下进行测试。谢谢你的输入。现在我们的范围与发送者的TX和收件人的TX有关。我们可以在发送图片的tx处看到正在发送的数据,也可以同步地在接收图片的TX处看到短零。我们还在接收端和发送端都有错误。所以我们还没有完成。我想我们最终可以完成。如果你有初学者错误的提示,任何帮助都会被接受。谢谢!
|
|
|
|
|
|
以前你提到只有一个收发器…如果你还在尝试的话,那效果就不太好。一旦你使用了一台,你就会想要两端的收发信机,把它们连接成“合适的”CAN总线。而且,当使用收发信机时,你会发现设置CIOCON.ENDRHI位=1工作得更好。虽然大多数收发器芯片在TXD输入端有一个内部上拉,但我已经观察到,有时它太弱了,不能以更快的速度工作。
|
|
|
|
|
|
你好,杰瑞,谢谢你的回复。对不起,我试着同时做太多的事情。现在我们有2个可转换芯片。在其他地方的软件中似乎有很多错误,所以我们将集中在第一个…我将在这里更新,如果我们取得了更大的进步;)CIOCON.EndRI位:它是高的设置与2 CAN TrimeVists。我们在没有转机的情况下完成了测试。
|
|
|
|
|
|
我们认为先尝试回环模式工作是个好主意。我创建了一个名为“voidinter.PIR5_ISR(void)”的中断,但是看起来事件被触发了,即使PIR5全部为零。是否有一个地方可以查看所有预定义的中断向量?我已经在网上看到了一个提到GLD文件的帖子,但是在里面我看不到它们。我也没有搜索编译器的文件夹。有人知道我能在哪里找到中断向量吗?
|
|
|
|
|
|
我们已经成功地接收到回送模式发送的消息。然而,数据在RX缓冲器1中呈现,而不是在缓冲器0中。操作模式为2(扩展FIFO模式)。此外,我们看到缓冲区0的溢出位,但在该缓冲区中没有数据。有人能解释这种行为吗?所以现在我们的图片工作在环回模式,我们认为我们可以改变为正常操作,看看我们能否接收到除了发送部分以外的与发送器相同的代码的消息。我们可以看到图片试图发送,但是消息发送请求位仍然很高,并且图片一直试图发送消息。在接收器的TX上,我们观察到高电平状态,脉冲与传输PIC的传输同步为零。这个脉冲在CAN高CAN低电平上是不可见的。这就是我不理解的部分。数据表表明,当另一个节点正在发送(情况就是这样)时,mcp2551不会将canbus的主状态改变为隐状态。但是接收节点想要发送一个应答。为了查看发射机是否真的希望看到这个确认,我们在接收图片上连接了TX线(在那里可以看到确认),并将其直接连接到发送图片的RX。理论是,在发送的PIC上可以看到确认,并确认有人收到了消息。当我们在调试时尝试这个时,我们看到发送pic清除了发送请求位,并设置“消息成功发送中断”(TX0IF或其他)。现在,发送节点认为数据是成功发送到接收节点的。然而,在接收节点上没有接收到数据和错误。所以现在我们回到了开头。TL;DR,当接收图片的TX线上存在确认位时,接收侧的mcp2551不应该在can总线上设置隐性状态吗,或者发送侧的MCP2551是否已经解决了这个问题?如果是第二种情况,那么如果接收节点无论如何不应该放在总线上,那么为什么在发送pic上与发送的数据同步地脉冲一个短零点呢?现在我的大脑真的崩溃了,感觉就像我们尝试了一切。我真的希望这儿有人能解释我们观察到的行为。提前感谢!我希望你不要介意我没有使用真实的注册名。我现在在火车上,现在没有手上所有的注册名。
|
|
|
|
|
|
再次问好,我们已经成功地发送和接收2个PIC的数据而没有收发器。我们连接所有的RX和TX的一起,它的工作!谢谢杰瑞的想法,把所有的RX和TX连接在一起。我们甚至不需要增加一个外部的拉起,清除EndRI位。不幸的是,当我们尝试通过CAN收发器发送消息时,仍然存在问题。我认为如果我们没有正确连接MCP2551是有意义的,因为我们可以证明我们的软件可以工作。我认为这个主题现在可以关闭了,因为主题已经回答了。谢谢大家的帮助!
|
|
|
|
|
|
嗨,MCP2551是一个相当古老的设备…看看MCP2561或62,甚至更好的ATA65 61(CAN FD准备)问候
|
|
|
|
|
|
大家好,我们还实现了与两个CAN收发器的通信。问题是MCP2551的部分缺陷。显然,一个同学把它炸毁了,把它作为工作芯片送给我们。谢谢大家的帮助!RISC,谢谢你的建议!我已经知道微芯片不推荐MCP2551用于较新的设计,但是CAN收发器的选择并不取决于我们。我会记下来的。谢谢大家。
|
|
|
|
|
|
也可以用单与门在同一板上桥接两个CAN设备。以及TX信号,并将它们反馈给两个RX信号。有一个关于无收发器的应用笔记可以在什么地方,但我没有读是4年左右…
|
|
|
|
|
|
“铁法”
|
|
|
|
|
只有小组成员才能发言,加入小组>>
MPLAB X IDE V6.25版本怎么对bootloader和应用程序进行烧录
475 浏览 0 评论
5794 浏览 9 评论
2334 浏览 8 评论
2224 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比?
3530 浏览 3 评论
1124浏览 1评论
有偿咨询,关于MPLAB X IPE烧录PIC32MX所遇到的问题
1098浏览 1评论
我是Microchip 的代理商,有PIC16F1829T-I/SS 技术问题可以咨询我,微信:A-chip-Ti
873浏览 1评论
MPLAB X IDE V6.25版本怎么对bootloader和应用程序进行烧录
475浏览 0评论
/9
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2025-12-2 10:56 , Processed in 1.216832 second(s), Total 106, Slave 89 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191

淘帖
4039