View Single Post
Old 01-02-2011, 07:19 PM   #1 (permalink)
DJBecker
EcoModding Apprentice
 
Join Date: Nov 2010
Location: Annapolis
Posts: 159
Thanks: 0
Thanked 32 Times in 27 Posts
Interest in CAN and OBD-2 support for Cougar?

I'm wondering if there is interest in adding CAN reporting and configuration to the Cougar controller.

Why? CAN provides a standard interface for reporting and diagnosis. All new cars in the U.S. are required to use CAN for their OBD-2 diagnostic interface. You can use standard OBD-2 tools, like the ScanGauge, to report what is going on with the controller or have a digital instrument panel.


When I wrote the support for the MCP2515 CAN controller on our motor controller I took care to make it nominally compatible with the Cougar firmware and hardware.

The added hardware would be a small board containing the MCP2515, a CAN transceiver (typically a MCP2551), two resistors, and likely a crystal with two capacitors. All parts are available in through-hole versions, so a standard protoboard may be used. The component cost is under $5, with the protoboard and mounting likely costing a bit more than that.

The connection to the Cougar would be through the 6 pin ISP programming connector, with one (ugly) extra connection to the processor -- the MCP2515 needs a standard SPI port, with a directly controlled chip select line.

Our hardware actually uses two additional connections: an 8MHz clock generated by an AVR timer output so that we don't need a crystal, and an interrupt line. Using a dedicated crystal for the CAN controller avoids the need for the first line. and my firmware can poll the chip rather than rely on an interrupt. (The hardware interrupt is required for low-power sleep operation, but the Cougar hardware isn't set up for that anyway.)

My software initializes the chip, responds to OBD-2 requests that make sense for an EV, and has hooks to read and set most of the same parameters that the serial port interaction can do. I believe that the only modification needed to the Cougar firmware is a function call in the main polling loop.

If someone is interested enough to lay out a circuit board, I have some ideas on a few no-extra-cost features it should have: a pass-through for the ISP signals, jumpered CAN termination, bringing a few of the controller pins out to a header (they can be used for general-purpose I/O or status LEDs), sleep control for the transceiver and jumpers for optionally using an isolating transceiver.


Last edited by DJBecker; 01-02-2011 at 09:43 PM..
  Reply With Quote