View previous topic :: View next topic |
Author |
Message |
valemike Guest
|
CAN - use PIC's integrated CAN vs MCP2515/2510? |
Posted: Wed Aug 25, 2004 7:54 am |
|
|
For those of you who have implemented CAN, and especially running at high speeds (e.g. 1Mbps), did you guys use the standalone MCP2510 or the PIC's internal CAN module?
I see that you would only need to talk to the standalone CAN module via SPI and would thus avoid having long traces carrying high speed data going to the edge of the board to the CAN connector.
I guess what i ask is - Am I going to have EMI issues if my PIC is in the middle of the board, and i have long lines carrying 1Mbps to the other side? If so, how do i fix this? 4-layer board? run the CAN lines on inside layers? |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Aug 25, 2004 12:15 pm |
|
|
We have used both types here. We used the MCP2510 with a Zilog
processor. It was a 6 layer board, I think. I'm sure that the SPI bus
was the least source of EMI on that board. I think I ran the traces on
the top layer.
We use 4-layer boards (or more) typically, and I put 1806 size ferrite
beads on most external signal connectors (RS-232, audio, etc.).
I put 3312 size beads on the power and ground traces coming from the
DC power input connector. Then it has no problem passing the FCC tests.
These are small to medium size boards, typically powered by
a "wall-wart" power supply, or some other DC power supply. |
|
|
Yashu
Joined: 08 Oct 2003 Posts: 26
|
|
Posted: Wed Aug 25, 2004 5:13 pm |
|
|
I've used both topologies... 18F8720 with MCP2510
& standalone 18F458 & standalone 18F458/18F8680 combo
App is automotive @ 500K
standalone 18F458 is 2 layer with decent ground pour and CAN Tx/Rx runs of about 2".
18F8720 w/MCP2510 is 4 layer with SCI Tx/Rx runs @ 4MBit/s of about 3"
combo design is 6 layer with CAN Tx/Rx runs of about 6"
All FR4 62mil thick... 8mil trace on 2 layer...6mil trace on multi-layers... top -or- bottom layer runs
no problems on any
passed FCC conducted emissions no sweat
also, combo design has 802.11b intentional radiator which also passed easily |
|
|
Douglas Richard
Joined: 08 Sep 2003 Posts: 49 Location: Concord NH
|
|
Posted: Thu Aug 26, 2004 6:10 am |
|
|
Stay away from the 2510. errata sheet is a mile long. If you have to use the 2515 but try to use a pic with CAN on board. For me the SPI connection was just too slow. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Aug 26, 2004 8:35 am |
|
|
Quote: | Stay away from the 2510. errata sheet is a mile long. |
That's true. At the time we did our design, the MCP2515 was just
coming out and wasn't available for purchase. I did read the whole
errata sheet for the MCP2510 and at least in our application, it looked
like we would be OK. We haven't received any complaints back from
the customer. So I think it can be used in a simple CAN application.
But I'm ready to change out the chips if they ever call with a problem. |
|
|
valemike Guest
|
FCC? |
Posted: Thu Aug 26, 2004 9:31 am |
|
|
What? CAN applications need FCC certification
I thought a mere UL approval was all I needed, and even that is optional. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1909
|
Re: FCC? |
Posted: Wed Jun 01, 2005 11:49 am |
|
|
valemike wrote: | What? CAN applications need FCC certification
I thought a mere UL approval was all I needed, and even that is optional. |
Can anyone confirm or deny this? Thanks in advance. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
|
newguy
Joined: 24 Jun 2004 Posts: 1909
|
|
Posted: Wed Jun 01, 2005 12:19 pm |
|
|
Thanks for the link, but I'm developing a "box", with a PIC in it, running at 4 MHz for an automotive application. Does it need to be tested for EMI as well? I think I already know the answer, but the link you provided didn't expressly spell out automotive apps. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Jun 01, 2005 4:44 pm |
|
|
I'm not an authority on FCC regulations, but if you look at the
Part 15 documents at the link below, section 15.103 lists Exempted
Devices. It says that devices used in automobiles are exempt from the
specific technical standards (which I presume means Class A and B).
http://www.access.gpo.gov/nara/cfr/waisidx_04/47cfr15_04.html
You need to read it and decide for youself. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1909
|
|
Posted: Wed Jun 01, 2005 4:59 pm |
|
|
Thanks! |
|
|
mike holeton Guest
|
|
Posted: Wed Jun 01, 2005 10:24 pm |
|
|
Here's the low down on automotive EMC.
There are NO SAE or other specs the devices have comply to in the USA.
The reasoning to date is that if a device produces excessive emissions, then the consumer will not use or demand a fix. This practice has worked well for all automotive apps.
Now to the nuts and bolts of the decussion. Automotive suppliers and OEMs all use J1939 spec'd communication which requires a baud rate of 250KHz. If you are using some kind of pripority communication with CAN, then you can not communicate with the engines, transmissions, ABS, etc.
I do test all my devices on my MUX system for suceptability and emissions, just because I don't want problems in the field and in some of my applications for the military, I must comply to MIL SPEC 461. I use SAE SPEC J1113 for emmisons testing. CE tesing is not required for automotive use. |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1909
|
|
Posted: Thu Jun 02, 2005 12:18 am |
|
|
Mike,
Thank you very much! FYI, my app doesn't have anything to do with communicating with the vehicle's own systems. I just want to use CAN because it's so immune to interference, ESD, you name it. Nice to know I don't have to send it for EMI testing.
Not that I'd design it poorly so that it would radiate in the first place.....
|
|
|
Guest
|
What's wrong with priority messaging? |
Posted: Thu Jun 02, 2005 12:25 am |
|
|
Quote: | If you are using some kind of pripority communication with CAN, then you can not communicate with the engines, transmissions, ABS, etc. |
Mike,
Why does priority communication prevents the communication to these components? Is there a fundamental prohibition, or is it just a standard? I would think, if the alert/alarm/failure signals are assigned higher priorities, the system should be able to handle the failure modes.
Cheers,
Nick |
|
|
mike holeton Guest
|
|
Posted: Thu Jun 02, 2005 10:04 am |
|
|
I'm sorry for the spelling error. I meant to say that if you are using a special or non spec basic communication on the data link.
Most of the time, if you don't have specific PGN, the other components won't recognize your messages. I have gotten around this issue by pretending to be one of the other components. Using there PGN's. Not a good practice, but it works as long as you are sure of the messaging scheme and what could happen if the data would mess up something else.
There's much more detail to the above, but I think you get the point.
Best Regards,
Mike |
|
|
|