[ishiyakazuo]

Originally Posted by dcb

Also worth noting that the atmega32 for arduino probably isn't very far off either and it should just be a drop in replacement for the atmega168. I know a few folks have already got it working. It has 2Kram and 32kflash, 1Keprom and is a buck or two more.

I meant to mention going this route, actually.

Originally Posted by jmilk

As far as bare-bones CAN, I'm not convinced it's a good idea. Hardware alone wouldn't just be "a couple of transistors", but rather quite a number of discretes (at least two Zeners, Cs, Rs, probably an op-amp). You'll need to worry about slew-rate, shielding the Arduino from transients and all that good stuff, and -- more importantly -- shield the car's CANbus from the Arduino. Just imagine what might happen if EMI within the Arduino is amplified and makes it to the CANbus, or if a transient melts your termination and shorts the bus... the CAN operates on a shared medium, and might well disable the car if choked.

I think there was a misunderstanding somewhere. We were talking about "a couple of transistors" for the ISO-9141 bus, which is fairly low speed and is basically RS-232 at different levels and at a strange 10400 baud rate.
For CAN, we'd use one of the following hookups:
- ELM 327 with its recommended schematic
- The Microchip parts you proposed
- AT90CAN parts with hardware CAN support

Originally Posted by jmilk

And that's the next point... collision detection, arbitration, bitstuffing and phase-locking are all non-trivial problems that have folks much smarter than us scratching their heads. I don't think a 16 Mhz 168 is fast enough to handle 500kbs... even at 20 MHz you only have 40 cycles per bit to decode what's coming across the wire, and if that's enough, the uP is then fully utilized.

Logically, then, you might be looking for a second uP to handle the UI, and there you are out another $3-$4, along with the discretes... you might as well go with an available and proven solution.

No one was ever suggesting we should implement CAN in software It's hard enough with a dedicated PHY, from what Yoshi said.

Originally Posted by jmilk

Reading ahead (while I'm writing this) it appears ishiyakazuo was going the AT90-route. He is correct on the combined cost of MC+mega**8 solution vs. the AT90. Do keep in mind that the prototyping cost of the MC solution is considerably lower -- breadboard, RBBB, two DIP chips, done. No mussing with adapters or break-out boards. Ditto for reproducibility -- heck, you can wire-wrap this baby or stick it on a proto-shield.

Agreed. Plus it's much quicker to get everyone the same setup.

Originally Posted by jmilk

I don't think we'll need 64K -- a large portion of the 12K-or-so in use now comes from the libraries you linked in. 32K should be plenty to do what you're attempting to accomplish here. I do have two precious ATmega328s here (thanks for the samples), and it's a perfect drop-in replacement for the 168. I'll pull the code and check the baseline this weekend.

BTW, good call on the Altoids tins The custom PCB to populate a la carte is certainly a very well "kit"able option. I'm curious to see how the differential bus compares to, say, an RS485, where many solid interfaces are available.

The only reason I was talking about AT90CAN64 vs AT90CAN32 is because the 64 is less than a buck more, and is more widely available. (And let's face it, extra flash never hurt anyone... unless you're terribly obsessed with power consumption.) I'll also be picking up some ATMega328s.