A fully featured CAN bus tranciever on an FPGA

[shaiko]

I want to implement a CAN bus tranciever VHDL core.
From those of you that have done it before - what is the best source to get information about the CAN protocol ?
Also, is CAN a synchronous protocol (is there a transmitted clock line like with SPI/I2C or it's more of a UART type) ?

 

[bigdogguru]

The following text covers the specification quite well:

Embedded Networking with CAN and CANopen


Microchip offers a few webinars and appnotes on the CAN bus specification:

**broken link removed**

AN228 - A CAN Physical Layer Discussion


The following websites offer CAN bus related material:

CANbus Website




BigDog

 

[FvM]

In usual terms, CAN transceiver refers to the interface chip, e.g. MCP2551. It's also needed when using a CAN controller as FPGA core. Controller cores are available e.g. from opencores.org. If using it for a commercial product, you would need to pay license fees to Bosch.

The asynchronous nature of CAN is obvious when looking at the interface hardware, I think.

 

[shaiko]

Sorry FvM - I meant CAN Controller (or MAC) not the CAN PHY...
By the way, do you know of any microcontrollers that have both the CAN MAC and PHY integrated in them ?

 

[FvM]

The CAN transceiver is required to tolerate high voltage at the CANH and CANL bus terminals. HV BJT or CMOS processes are needed to implement this feature, it's not possible with usual 3.3 or 5V high density processes.

 

[shaiko]

FvM,
I'm trying to understand the vast acceptance of CANbus with high reliability applications - despite the fact of being aynchronous.

Would you agree that an asynchronous protocol will always be less realiable then a synchronous one and always have a higher BER?

 

[FvM]

CAN bus has been designed for a specific application field, communication of distributed controller nodes in automotive and automation. I don't see how synchronous protocols should work in this situation.

 

[shaiko]

I don't see how synchronous protocols should work in this situation.

Why not ?
Same as SPI/I2C do...

 

[FvM]

Which application are you considering? If I2C or SPI or suitable for your application, you should use it. They are definitely not an option for typical CAN applications.

SPI and I2C are board level interface protocols that won't be used on a system level, e.g. across a truck or a large machine. Some aspects are noise imunity, short circuit persistence, robust collision handling.