MPGuino shield: Fork? V2?

[bobski]

Originally Posted by msc

Of course this would be a pointless exercise that adds two chips unless the second interrupt is put to good use.

I like to think the VSS is "good use", though I suppose it could be moved over to the new interrupt expander setup. Keeping the VSS and injector(s) on interrupts lets the non-time-critical code (such as variable calculations, display rendering, button handling and whatever else people come up with) run amok without affecting the accuracy of those core measurements.

Originally Posted by msc

Since you are working on a general re-rendering of the concept you might try and add DPFI support. It would be a significant contribution and you would be a hero to a number of people with throttle body injection.

I'll see what I can do.

Originally Posted by msc

Adding support for a second injector would require a second set of injector calibration values and summing the output of both injectors for total fuel flow.

Yeah, the software side seems pretty easy: A check-what-changed code snippet that triggers the appropriate chunk(s) of code in the interrupt. I've pretty much already written the chunk(s), I would just need a few additional variables to differentiate the two injectors.

Originally Posted by msc

On another topic. If you want to really keep the inductive kick of the injector away from the MCU you can give the input side of the opto it's own ground wire back to near where you pick up the injector signal, presumably at the ECU.

Yeah, I thought about that. The ground line you get on the Arduino's headers is uninterrupted back to the negative external power terminal, which would presumably be connected to a ground wire near the ECU. A second wire might help with noise rejection (not really a problem afaik), but I don't think the shared ground is going to cause problems protection-wise.

[bobski]

I thought of an alternative circuit design for the interrupt expander last night. Each input would have 1 bit of a D-latch and an XOR gate. The data input to the latch would be the signal you want to watch, and the latched output would go to one of the XOR inputs. The other XOR input would be the raw signal. That way, the XOR would go true any time the input doesn't match the data in the latch, which would trigger the interrupt. When the interrupt gets triggered, part of the routine would clock the D-latch which would make the data and input match up again. That would make the XOR go false and clear the interrupt signal until the input changes again. It's still two chips, but those two chips could serve multiple inputs. A 74HC86 quad XOR and a 74HC373 octal D-latch costs about a dollar together and would serve 4 inputs. Add another XOR chip and it would serve eight (if there were enough free pins on the Arduino).
After looking around a bit, I found some IO expanders use this same setup to drive their interrupt outputs. Using a single-chip IO expander would be nice, but they're all serial interfaced which is probably too time consuming for an interrupt routine.

[bobski]

Current code, as posted in the Release Two Workspace (/Fork name TBD) thead:
http://dl.dropbox.com/u/9882625/MPGshield_0.3.pde

[bobski]

I had been busy with school, so not much progress, but here's the current state of things:

http://www.youtube.com/watch?v=6JS2qwB39S8

[FalconFour]

Holy... frickin'... lover of Jesus. WOW. That is one SERIOUS pro setup you've got there in that video. Yikes. Makes me feel kinda insignificant here with my most elaborate logic device being my Arduino (programming it to decode whatever logic I need to read), and my most elaborate analog device being my $50 kit digital oscilloscope based on an ATmega64. My breadboard setup is a modded Radio Shack Electronics Learning Lab (modded with an LCD, internally wired to 14 breadboard rows)... that's why I'm leaving all the monitoring and calculation code in MPGuino alone in V2, because I don't have the equipment to test any changes to that part! =P Heck, I'm even having trouble figuring out how I can test the data display routines outside the car if all I can show is "0"

So are you planning on building a new "device" for MPGuino (the hardware side, that is), or just working on software?

[bobski]

Eheh... Thanks. NKC has had a deal on the two (DS1052E and DG1022) for some time now, so I convinced my parents to pick up the bill as a graduation present. I've been wanting a decent oscilloscope since I was like 10 or 11 years old. But yeah, I had one of those same oscilloscope kits before this (128x64 display, 3 switches, 7 pushbuttons, PCB front and rear panels). I pretty much learned surface-mount soldering on that kit. It's affordable and decent as a basic scope if you have nothing else, but you can do so much more with a decent commercial bench scope.
Yes, I'm building new hardware. The above hardware is very similar to the MPGuino, but I wouldn't say it's "for MPGuino". Now that the basic framework is laid out, I'm leaning toward a design with a graphic display. Code-wise, it's pretty much just a matter of including the glcd library and writing the code to draw the display pages. Hardware-wise, graphic LCDs that are compatible with the glcd lib take up way more IO lines than character displays, so a mega-style Arduino board is probably a necessity. There are serial-controlled graphic displays out there, but it seems that would require pretty heavy modification of glcd, which is beyond my present abilities.