Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
December 10, 2016, 12:07:31 00:07


Login with username, password and session length


Pages: [1]
Print
Author Topic: QUESTION: PIC18 ECAN without transceiver?  (Read 995 times)
0 Members and 1 Guest are viewing this topic.
electrojit
Active Member
***
Offline Offline

Posts: 168

Thank You
-Given: 181
-Receive: 267


« on: July 21, 2014, 06:47:11 18:47 »

Hello dear board members,

I am working on small learning project to understand how ECAN works on PIC18 controller. I tried cross connecting the Rx and Tx lines of two controllers and wrote simple code to transmit and receive few messages.

But it is not working out. I don't have debugger and canalyzer so can not actually debug it. But on scope it shows that one controller keeps on repeating the message few times and goes to Busoff.

Based on this behavior I assume that this method of directly connecting the two CAN controllers without transceiver might not work as it might not generate the ACK bit.

But not sure if I am right.

So any one on the board have such experience or more insight into using such setup?

Regards,
electrojit
Logged
Tupperware
Newbie
*
Offline Offline

Posts: 15

Thank You
-Given: 13
-Receive: 24


« Reply #1 on: July 21, 2014, 08:15:39 20:15 »

Can't say I have ever tried what you are attempting, but pretty sure it won't work Wink.  I would guess for the same reason that you suggested, no nodes can acknowledge the transmission so the CAN controller retries and eventually goes into Bus-off.

Have you had a look at the MCP2551 application note (http://ww1.microchip.com/downloads/en/AppNotes/00228a.pdf)?  That gives a pretty good explanation of what the physical layer is doing.
Logged
mike_au
Newbie
*
Offline Offline

Posts: 22

Thank You
-Given: 5
-Receive: 5


« Reply #2 on: July 22, 2014, 10:33:20 10:33 »

While I'm sure microchip would say it is entirely unsupported, it seems like it should work. There is nothing particularly special about the ACK bit, if the main message can be transmitted directly between uC's  there is no reason the ACK can't be (and I can't see why the message wouldn't work).
Logged
pickit2
Moderator
Hero Member
*****
Offline Offline

Posts: 3816

Thank You
-Given: 567
-Receive: 2049


There is no evidence that I muted SoNsIvRi


« Reply #3 on: July 22, 2014, 11:15:40 11:15 »

you show no code.
you can set a controller to keep repeating a message without ever going into bus-off.

even without a transceiver you could use another input to detect ACK.
Logged

Note: If you have no posts other than, I want or reporting a dead link Then you can't complain If I remove your post So Stop Leeching
Tupperware
Newbie
*
Offline Offline

Posts: 15

Thank You
-Given: 13
-Receive: 24


« Reply #4 on: July 22, 2014, 09:58:28 21:58 »

The CAN transceiver is converting your Tx/Rx serial data into CAN_H (High) and CAN_L (Low) differential signals.  The bus has two states "Dominant" and "Recessive". Every node receiving an accurate message overwrites this recessive bit in the original transmitted message with a dominant bit, thereby acknowledging it.  The CAN controller receives its own transmitted message as well as messages from other nodes, if it sees that no one acknowledged its transmission (ack slot is still recessive) an internal counter is incremented, the message is retransmitted and so on until a threshold is reached and the controller transitions to bus off...no more messages are transmitted until the CPU resets the error counter.

Unless you can detect the ack slot in the tx stream and write a dominant bit into the rx serial stream the controller will always go to bus off.

This is outside the realms of code since the functionality is hard coded into the CAN controller peripheral.

« Last Edit: July 22, 2014, 10:02:26 22:02 by Tupperware » Logged
Parmin
Hero Member
*****
Offline Offline

Posts: 544

Thank You
-Given: 357
-Receive: 126


Very Wise (and grouchy) Old Man


« Reply #5 on: July 23, 2014, 12:24:50 00:24 »

I have used 18F25K80 with the internal hardware CAN.
No problem.
Logged

If I have said something that offends you, please let me know, so I can say it again later.
mike_au
Newbie
*
Offline Offline

Posts: 22

Thank You
-Given: 5
-Receive: 5


« Reply #6 on: July 23, 2014, 03:41:22 03:41 »

you can set a controller to keep repeating a message without ever going into bus-off.
You can clear the errors to get it to keep transmitting, but the controller will still consider the messages to have failed.

even without a transceiver you could use another input to detect ACK.
But you can't then feed that knowledge back into the CAN controller.

I have used 18F25K80 with the internal hardware CAN.
No problem.
Without a transceiver?

You say you are seeing the message being sent out with a scope, how good is your capture? can you actually see it transmitting the full frame? or are you just seeing that the output is doing something? You probably need to feed the uC tx pin back into its own rx as well as the rx on the other uC. The CAN controller monitors the bus, when it transmits a dominant and doesn't see a change on its rx pin it probably assumes a bus fault.


EDIT: It looks like this will do the trick http://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf
« Last Edit: July 23, 2014, 03:43:36 03:43 by mike_au » Logged
Tupperware
Newbie
*
Offline Offline

Posts: 15

Thank You
-Given: 13
-Receive: 24


« Reply #7 on: July 23, 2014, 08:47:24 08:47 »

EDIT: It looks like this will do the trick http://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf

Looks like a reasonable solution for using CAN over short distances.  Doesn't help electrojit much though as he will still need another node to ACK his transmissions.  Maybe another PIC18 wired as that link suggested will be the easiest method for your testing?
Logged
pickit2
Moderator
Hero Member
*****
Offline Offline

Posts: 3816

Thank You
-Given: 567
-Receive: 2049


There is no evidence that I muted SoNsIvRi


« Reply #8 on: July 23, 2014, 09:19:50 09:19 »

well everyone can use the can protocol to implement a system that works in a similar way, but then it is not can.
you would find it almost imposable to change or add to as needs change.

Remember the RS protocol, you could not even have a single cable that you connect two items together, with so many standard pin-outs, not to count the number plugs & sockets.
In a piece of kit we used at my place of work we had the transceiver in the 9pin shell, that did not follow the standard wiring, just a way to tie in the customer to their system. 

As an exercise to use the can or ecan protocol without transceivers is just that, in the real world you do need to follow the way it works, and use transceivers.
Logged

Note: If you have no posts other than, I want or reporting a dead link Then you can't complain If I remove your post So Stop Leeching
mike_au
Newbie
*
Offline Offline

Posts: 22

Thank You
-Given: 5
-Receive: 5


« Reply #9 on: July 23, 2014, 10:32:56 10:32 »

Doesn't help electrojit much though as he will still need another node to ACK his transmissions.  Maybe another PIC18 wired as that link suggested will be the easiest method for your testing?

He's got two:

I tried cross connecting the Rx and Tx lines of two controllers
Logged
Tupperware
Newbie
*
Offline Offline

Posts: 15

Thank You
-Given: 13
-Receive: 24


« Reply #10 on: July 23, 2014, 01:54:01 13:54 »

He's got two:

Quite correct...I missed that bit! I thought the was feeding Tx to Rx on the same PIC. Thanks.
Logged
electrojit
Active Member
***
Offline Offline

Posts: 168

Thank You
-Given: 181
-Receive: 267


« Reply #11 on: July 23, 2014, 05:19:17 17:19 »

Thank you all for your answers...

I am able to see the full message on the scope. And I consulted the local Microchip support engineer, he said this scheme will not work due to missing ACK. And as per CAN specs - the node will keep on repeating the message - it will go into Error Passive mode but will never go to bus off mode.

I tried the ECAN Loop back mode with only one controller (no external pins) and I was able to test the Tx and Rx logic as well as the packing unpacking logic.

If some one needs the code can share soon after some comments and touchup as its in very bad shape Sad btw I used the Microchip ECAN.c and ECAN.h files in application.

I read the siemens application already and then tried to use the same circuit and also tried to keep the TX pin as tristate as mentioned in the stackoverflow but no luck till now... I might be doing something wrong... will work more on this weekend and keep you updated...
http://electronics.stackexchange.com/questions/30564/is-a-can-enabled-microcontroller-sufficient-to-drive-a-can-bus

Thank you once again all... for taking participation in the discussion... happy to see so many people working and sharing the knowledge...

Regards,
electrojit
Logged
mike_au
Newbie
*
Offline Offline

Posts: 22

Thank You
-Given: 5
-Receive: 5


« Reply #12 on: July 24, 2014, 02:23:05 02:23 »

I don't see why he says the ACK would be missing, either you can communicate between devices like this or you can't; if you can, then the ACK will be transmitted in the same way as any other bit, if you can't then the ACK is the least of your worries.
Logged
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC