| View previous topic :: View next topic |
| Author |
Message |
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
| Question about CAN bus |
 Posted: Thu May 15, 2014 6:55 am |
 |
|
Greetings! I want to make 2 pcbs (master and slave), communicating with CAN interface. I want to use PIC18F2550 and MCP2551.
First: what is the communication interface of MCP2551 on the side of the controller?! In the datasheet are used TXD and RXD as designators. Isn`t this UART(RS232)? I sought a few samples in this forum where I2C is used.
Second: Which library do I have to use?! can-mcp251x?! Is my MCP2551 compatible with this?
Thanks! |
|
 |
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Thu May 15, 2014 7:31 am |
|
|
Hi,
The MCP2551 implements the 'physical layer' of the CAN bus, ie. the physical connection of the CAN transceiver to the CAN bus. Unless you have a PIC with built in CAN support (the 18F2550 does not!), then you'll need a CAN Bus Controller IC, such as the MCP2515, to actually manage the CAN Bus protocol. This chip communicates with the PIC host via SPI. This CAN Bus Controller is intended to be used with can-mcp251x.
If you want a simple CAN Bus interface, with MCP2551 and MCP2515, I can recommend this product from Mikroelectronica:
5V CAN 'Click' board: http://www.mikroe.com/click/can-spi-5v/
John |
|
|
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
|
| Posted: Thu May 15, 2014 8:29 am |
|
|
OK. If I take for example PIC18F25K80. The datasheet says it has CAN interface. So in this case I have to add MCP2551 or it can work without it?!
Which library do I have to use?!
Thanks! |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1911
|
|
| Posted: Thu May 15, 2014 8:48 am |
|
|
A PIC + MCP2551 is all you need to form a complete CAN node. You cannot connect two CAN capable PICs together directly without a MCP2551 (or equivalent) CAN bus driver IC. You will also require two bus termination resistors, 120R each.
The CCS driver to use is "can-18xxx8.c"/"can-18xxx8.h". |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19569
|
|
| Posted: Thu May 15, 2014 9:06 am |
|
|
I have to ask. If you are only using two devices, why use CAN?. The whole point of CAN is for multiple device communications over relatively short distances, but with a reasonable high level of error handling. Fundamentally designed for cars.
Now key to understanding is that CAN is both a physical layer description, and a protocol. So it is like talking about Modbus ASCII over RS485. Here the 'RS485' is the physical layer description (tells you what signals are used on the wires), and the 'Modbus ASCII' part says what protocol to use.
On CAN, the physical layer is similar to RS485. In fact the early testing was done using RS485 chips!... Then you add the protocol. The protocol is the 'heart' of CAN, with message validation, error detection and arbitration, and also all the specifications concerning how data is framed and timed. Because this is a complex protocol, with accurate timings required, a CAN protocol hardware engine is really always needed. This handles identifying the incoming frames using filters, and does a lot of the responses automatically.
The module in the 25K80, has both this hardware engine, and the physical layer drivers present. No other chips needed (but bus termination required).
There are two fundamental CAN modules present in PIC's. The simpler 'CAN' module, and the ECAN module. You can use either driver. Once gives just the CAN functionality, the second the extended features from the ECAN module. The big improvement is the addition of the DeviceNet protocol handling, and some operations are significantly quicker, but the code is larger. ECAN leaps to a big advantage, when the bus gets very busy.
Have fun.... |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1911
|
|
| Posted: Thu May 15, 2014 9:54 am |
|
|
| Ttelmah wrote: | | The module in the 25K80, has both this hardware engine, and the physical layer drivers present. No other chips needed (but bus termination required). |
?
I must not understand. By "physical layer drivers" I take that to mean what would be functionally equivalent to a MCP2551 IC. I can find no reference in the 25K80's data sheet to such a thing. |
|
|
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
|
| Posted: Thu May 15, 2014 10:00 am |
|
|
I need a serial interface for industrial invironment. I need to work on high distance. The cabels could be 50m long. I saught one solution done with CAN bus, so I decided to use the same. What`s your proposal?
Thanks! |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Thu May 15, 2014 10:07 am |
|
|
| Quote: | | By "physical layer drivers" I take that to mean what would be functionally equivalent to a MCP2551 IC. I can find no reference in the 25K80's data sheet to such a thing. |
Yes, the PIC18f25K80, and the others in its family, all require a MCP2551 or similar.
As far as I know, there is no PIC which has the CAN bus drivers/level interface built in though plenty now have the CAN or ECAN CAN engine built in as a peripheral.
Microchip are pushing users toward the MCP2561 and the MCP2562, which I am using successfully in my new designs.
Apparently a properly terminated CAN bus, can be run at 500kbps at 100m. In vehicles bus length easily reaches ten or more metres even in cars, and in trucks 50m doesn't sound impossible. CAN is good for high noise environments, such as industrial. I use it in RF power amplifiers, where its impossible to totally stop RF getting onto the bus. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1911
|
|
| Posted: Thu May 15, 2014 10:16 am |
|
|
Thanks. Glad I'm not going crazy!
| RF_Developer wrote: | | Apparently a properly terminated CAN bus, can be run at 500kbps at 100m. In vehicles bus length easily reaches ten or more metres even in cars, and in trucks 50m doesn't sound impossible. |
My company runs a CAN bus @250kbps with a mess of a layout (definitely not linear), and a 65' (approx. 20m) run bundled together with 4 welding leads and 4 welding grounds. Each lead can carry anywhere from 130A to ~275A and approx. 20V. No big issues other than our very bad layout. 500kbps @ 100m sounds completely reasonable as long as the layout is linear. |
|
|
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
|
| Posted: Thu May 15, 2014 10:19 am |
|
|
Ok! I really don`t like this interface for my goals. It seems very complicated and I`m forced to use very big microcontrollers, which are not really necessary. What else is suitable?! Maybe RS485?! The microcontrollers on the line will be up to 12, but in the common situation they will be only 2!
And the communication will be simple. Maybe an address and a command.
Thanks! |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19569
|
|
| Posted: Thu May 15, 2014 10:43 am |
|
|
RS485, is an ideal hardware interface.
Then you have to decide on the protocol.
Big question:
Whether this is a single master bus, or requires multi masters?. |
|
|
stoyanoff
Joined: 20 Jul 2011
Posts: 375
|
|
| Posted: Thu May 15, 2014 10:45 am |
|
|
| Single master! |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Fri May 16, 2014 4:48 am |
|
|
| stoyanoff wrote: | | Ok! I really don`t like this interface for my goals. It seems very complicated and I`m forced to use very big microcontrollers, which are not really necessary. What else is suitable?! Maybe RS485?! |
Here my collected experience of CAN and RS485 on PICS. I have used both: the last project had BOTH, CAN for internal comms, RS485 for external.
Both require an external interface/level shifter IC. Both are capable of running at similar bit rates. Both need external terminating resistors, but with CAN the equivalent of RS485's bias resistors are built in to the CAN interface driver IC.
CAN:
General: message based broadcast network. No masters or slaves, and all messages can go to any node that wants to listen to them.
Pros:
Low firmware overhead - the chip does all the protocol work.
Easy to use for most applications with CCS supplied driver.
Buffered - CAN hardware stores a few transmit and receive messages for a short time until firmware can deal with them.
High integrity - rejects a lot of noise and interference.
Robust - CAN can work with CANL grounded or CANH connected to a supply rail! It can cope with several volts common mode differences between nodes, a good common ground is not required. Granted, add in an unhealthy dose of RF and comms gets dodgy, but really CAN can cope with a lot of abuse.
Hot-pluggable - you can add an remove nodes at any time without bricking the bus. We use this all the time to connect our diagnostic PC GUI to running RF amplifiers.
Well defined - no need to reinvent the wheel by making up your own protocol. Its all done for you by firmware and interoperability with other people's kit is easy. Its got CDMA, CRC, retires, bus contention, ID arbitration, etc. built in.
Reasonable bus capacity - straight CAN can run comfortably at up to around 40% bus capacity (100kbps gives roughly 1000 messages per second, of which you could expect to get 400 through).
Cons:
Message based - many people have trouble getting their heads around this and want to send messages to particular nodes: CAN simply doesn't work like that.
Overhead - the CAN protocol is complex and has considerable overhead, meaning only a part of the available bus bandwidth is available for data.
Low message data length - CAN can only transmit eight bytes in a message. No more.
Out of order transmission - CAN is message based, a bit like TCP/IP datagrams, and there's no concept of a virtual circuit. Messages may not be received in the order in which the sending firmware gave them to the transmit hardware. Sending long data requires some in data sequencing information, like a packet count.
Learning curve: CAN isn't like many other PIC comms links, and that means it takes time to suss it out.
Difficult to do command & request sequences - as its not master-slave it can be tricky to associate replies with commands/requests. The message passing paradigm is not well suited to such sequential processes.
RS485:
General: async serial based half-duplex comms medium.
Pros:
Uses familiar interfaces - it just needs a serial port which all PICs have: no need for "fancy" CAN capable PICs.
Point to point and multi-drop - easy to connect many nodes together.
Copes with a fair bit of noise - but nowhere near as much as CAN.
Can be multi-master - but only with a suitable protocol implementation in firmware.
Cons:
Not very robust - just shorting either data line to ground will most likely blow the transmitting part of one driver. I've blown up three FDTI USB-RS485 cables on one project that way :-(
No defined protocol - you have to provide one in firmware. Modbus is common and works quite well, but as can be seen from reading this forum, Modbus implementation is not always straightforward.
Point to point - inflexible architecture, not always well suited to modern comms needs.
Needs more and more complex firmware support - often takes more time to develop firmware than the equivalent CAN implementation.
Personally I now prefer CAN as my default internal-to-system comms needs. My latest project, a "Smartcable" amplifier controller uses CAN with the PICs on boards fitted in the backshell of connectors. I'll use RS485 again if I have to, but I prefer the robustness and ease of use of the well-specified standards compliant CAN bus. Other folks mileage may well vary, and other will have their own list of good and bad things about CAN and RS485. |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1911
|
|
| Posted: Fri May 16, 2014 9:02 am |
|
|
| RF_Developer wrote: | | Message based - many people have trouble getting their heads around this and want to send messages to particular nodes: CAN simply doesn't work like that. |
Yes & no. It can work like that if you want it to - all you have to do is put things like sender, recipient, etc into the message ID:
| Code: | // message ID:
// xxxx xxxx xxx xxxx xxxxxxxxxxxxxx
// | | | | |
// | | | | -- message ID
// | | | -- step # (for multibyte transfers)
// | | -- message purpose
// | -- destination
// -- sender
// for locations (# shifts)
#define FROM 25
#define DEST 21
#define PURP 18
#define MULTI_STEP 14
#define SENDER_MASK 0x1e000000
#define RECIP_MASK 0x01e00000
#define PURP_MASK 0x001c0000
#define STEP_MASK 0x0003c000
#define MESSAGE_MASK 0x00003fff |
Each node then has a unique ID and you then really only need two CAN filters, one for messages directed at THIS NODE, and another for messages directed at ALL NODES. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Wed May 21, 2014 10:14 am |
|
|
| Quote: |
Each node then has a unique ID and you then really only need two CAN filters, one for messages directed at THIS NODE, and another for messages directed at ALL NODES. |
Yes, I use a similar addressing scheme to have targeted messages and broadcast messages, using a filter for each. That though is a higher level added on top of the physical layer. I tend to use more broadcast messages than addressed ones in my applications.
CAN itself has all messages going to all nodes, that's "how it works". RS485 does too in a sense, but with RS485 all acknowledgements and the like have to be implemented by user protocol in firmware, whereas with CAN its done by hardware. The "getting head round bit" is at the physical layer. Its up the user to software/hardware filter and to decide how to deal with allocate/filter/interpret messages as required in the application. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
