Looking for the best OBD2 option with AVR.

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The company I'm working for uses a 18f2580 pic + mcp2551 transceiver to talk to an OBD2. I'm left with decision to stay with PIC or go AVR. I'm not a huge PIC fan so I'm a bit biased on AVR. I was thinking of using mega328 + STN1110+transceiver . Would I be better off with a AT90CAN128? Anyone have an experience on the matter to share some thoughts? Its not that I need an option but rather I want to brain storm this a bit before I begin.

 

 

 

Last Edited: Wed. Feb 3, 2016 - 08:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've always used the MCP2551 chips even with AVR (ATMEGA328), along with an MCP2515 because I like the way it offloads the can processing from the main chip.

I use a simple SPI interface and have loads of success with them.

 

Thats just my 2p worth. It adds an extra chip, but it's the way I like it.

I've never tried any of the AVRs with built-in can, so can't comment on them.

SpiderKenny
@spiderelectron
www.spider-e.com

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Never heard of the MCP2515, I see it supports time-triggered protocols. Also, from what I gather this is a cheaper option. Looks like the greatest advantage to a built in CAN really comes down to speed.

 

Some thoughts from a Corey, Richard

I dislike SPI.  

If you busy-wait inside the CAN-SPI ISR to do all needed SPI sending and receiving, like polling registers to see which buffer to service, you waste a lot of time, limit your throughput and greatly increase your max interrupt latency.  (Perhaps it would mitigate the pain if you allowed most other kinds of interrupts to pre-empt or "nest inside" such a long busy-wait SPI-CAN ISR.  At least do your busy-wait with interrupts re-enabled.)

I saw a 97-microsecond ISR to service an MCP2515 (40 MHz PowerPC, 10 MHz SPIbus).  
When it looped-back the messages it sent, the ISR took 197 microseconds.  
0.2 milliseconds to receive one CAN packet!

If instead you start each SPI transfer and then use a "SPI complete" interrupt, code can become complex, especially if your CAN controller makes you query a register before reading or reloading a message buffer.    Treat it as a thread or task or state machine.  All to read one packet!

 

Though I'm not sure of our feature speed requirements at this time. I think in our development cost is the higher target.  There is also the ATA6560 vs MCP2551 not sure there is much of an advantage.

 

 

 

 

Last Edited: Thu. Feb 4, 2016 - 09:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One option is the dsPIC33EP/PIC24EP: 70MIPS, CAN driver, DMA support, SPI up to 7Mbps.

 

while(!solution) {patience--;}