QUESTION: PIC18 ECAN without transceiver?

[electrojit]

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

[Tupperware]

Can't say I have ever tried what you are attempting, but pretty sure it won't work .  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.

[mike_au]

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).

[pickit2]

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.

[Tupperware]

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.

[Parmin]

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

[mike_au]

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

[Tupperware]

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?

[pickit2]

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.

[mike_au]

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

[Tupperware]

He's got two:

Quite correct...I missed that bit! I thought the was feeding Tx to Rx on the same PIC. Thanks.

[electrojit]

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 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

[mike_au]

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.