OBD MPGuino gauge

[jmilk]

Originally Posted by dcb

Easy cowboy Elm has been decided for 1.0, it is universal, easy to implement, and being through hole it is very "kit"able. We are going to work on the price AFTER getting something out there.

for the post elm obd version, we hope to be as low cost as possible, but have not abandoned the arduino platform yet. ishiyakazuo is looking into a software only (duino + a couple transistors) ISO implementation. Maybe you want to sort out the bare bones CAN details? It would be good if there is a bare minimum through hole couple transistors software only CAN version as well, as far as price and assembly go.

Agreed. Elm is a good starting point. I'll probably skip 1.0 myself.

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.

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.

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.

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.

[dcb]

Originally Posted by jmilk

I don't think a 16 Mhz 168 is fast enough to handle 500kbs...

The elm runs at 4.00 mhz.

[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.

[ishiyakazuo]

Originally Posted by dcb

The elm runs at 4.00 mhz.

Actually, it has a 4x PLL in it, so it could also be running at 16MHz...
But also worth noting is that the PIC that the ELM uses (PIC16F2x80) has hardware PWM and CAN as well, so CPU speed may be a non-issue (it's just shuffling data between the serial port and hardware peripherals, with the exception of VPW, which isn't too difficult due to its very broad definition of "10.4kbps" (it could be significantly more or less, depending on how good your bit timings are).

[dcb]

Originally Posted by ishiyakazuo

No one was ever suggesting we should implement CAN in software

I was, just putting it out there

[ishiyakazuo]

Originally Posted by dcb

I was, just putting it out there

Oh, sorry, missed that.
Yeah, probably not a good idea, for the reasons jmilk detailed. If the chip doesn't have a CAN hardware block, it's probably nigh impossible to do with anything cheap (you could write it in straight ASM, and maybe have a shot with a 50MHz ARM7, but at that point you've already blown past the cost of a dedicated CAN part).

[jmilk]

Originally Posted by ishiyakazuo

But also worth noting is that the PIC that the ELM uses (PIC16F2x80) has hardware PWM and CAN as well, so CPU speed may be a non-issue

18F2480, right? Hardware CAN... that'll do it. And it's also my problem with ELM... they're re-selling a $5 chip for $30. That's a $25 license fee for what amounts to bit-shuffling software that shields a tad of the complexity of the underlying bus... and you're pretty much stuck with the firmware, because they don't provide upgrades.

Originally Posted by ishiyakazuo

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.

There's no appreciable difference in power-consumption for flash memory based on capacity. IIRC, flash only actively powers the page currently read-from/written-to, so page count is immaterial. RAM's different, but too small to matter here. Clock speed and operating voltage are just about proportional to power-consumption, however -- even so, I don't think the maximum consumption of fully clocked AT90 (0.15W at 5V/16MHz) would matter in the grand scheme of things (the LCD uses 10x that); and an ATmega328P uses even less... theoretically, it's 0.05W at 5V/20MHz).

[Magister]

Note also that you must be CAN compliant to plug something on your CAN bus, unfortunatly the AtMega is not qualified for C&S CAN Conformance like the AT90CAN.

Also the ELM327/Arduino can be used as a "scantool" interface and be used with dozens of software running on laptop/palm/etc. using a simple 3-wires null modem cable.

The ELM327 v1.3 can easily retrieve 30-80 PIDs per second, which is more than enough. And it implements the basic ISO/VPW/PWM protocol but also the CAN protocol 11 bit and 29 bit, 250k, 500k, header filtering, etc

I agree the solution can move to the AT90CAN** for a 2.0 version, but it needs a PCB and all.

BTW we also use the MC 2551 with the ELM327.
For the code we actually use less than 10k for ISO, my ELM proto is about 12k, we still have space to play with.

[ishiyakazuo]

Originally Posted by jmilk

There's no appreciable difference in power-consumption for flash memory based on capacity. IIRC, flash only actively powers the page currently read-from/written-to, so page count is immaterial. RAM's different, but too small to matter here. Clock speed and operating voltage are just about proportional to power-consumption, however -- even so, I don't think the maximum consumption of fully clocked AT90 (0.15W at 5V/16MHz) would matter in the grand scheme of things (the LCD uses 10x that); and an ATmega328P uses even less... theoretically, it's 0.05W at 5V/20MHz).

Like I said, you'd have to be absolutely nuts to worry about the difference in power usage of the extra flash I think as size increases, the controller is slightly more complex, which adds a VERY miniscule amount to the power usage (we're talking uW here). It was basically meant to be a joke.

The ATmega328P would use less, but then you have to use the extra Microchip part, which might even things up a bit.

I didn't look at the LCD power ratings, but do backlights use that much still? I guess 1.5W isn't that bad when hooked up to a car battery, but I'm a little surprised -- I just wrapped a project a few months back with an ARM7 @ 48MHz with USB, an FPGA and a 2x16 LCD (non-backlit) and the entire setup amounted to about 1W off of a +5v supply.

[ishiyakazuo]

Originally Posted by dcb

FYI, if you are in a hurry, the currently recommended display is made by newhaven display in elgin. I've asked nicely and they have let me stop in to pick up a couple models. You can get everything else from ratshack.

I was looking on Mouser for some other things and noticed this:
Alternate LCD?
It's the same display but with only one set of interface holes.
They also have this one which is the same thing but a little smaller (nice if fitting in your project box is tight).
This other one is yet cheaper but the connector is on the side (in my opinion, the most awkward).
I'm thinking when I lay out my Altoiduino board for this project, I'll try to put the LCD connectors on both the top and bottom so you can use either, and if there's extra space, I'll throw the side connector on too, but routing a handful of pins to two places is bad enough -- 3 is a real pain.