MPGuino shield: Fork? V2?

[dcb]

I don't know what liberties you are taking with the schematic or the code, but mpguino vss was designed to use a change interrupt on pin 23 which triggers on both a rise and fall. I point a finger at your lack of understanding how it was designed/works

I'm sure you will complain about it though, and have some suggestions for "improvement", at which point I will have to explain that both the edge detection interrupts are being used to distinguish the rising and falling edge of the injector pulse.

Damn newbies. Be a good engineer and look at the schematic and the code and the atmega datasheet please and don't be surprised that making random changes to the code or circuit can break things. There is no hardware OR code ivory tower on this project, they work as a unit. If yours isn't working right, there is only one direction to point.
source data sheet

[bobski]

Originally Posted by dcb

I don't know what liberties you are taking with the schematic or the code [...] please and don't be surprised that making random changes to the code or circuit can break things.

I'm starting from scratch on both counts. I've borrowed a few hardware design elements, but the code is all new as far as the MPGuino project is concerned.
Unlike the MPGuino, I'm using one interrupt input for the injector signal with the interrupt being called when the signal changes (rising or falling edge). The interrupt code then checks whether the pin is high (just hit a rising edge) or low (just hit a falling edge) and executes the appropriate chunk of code to start or complete the pulse width measurement (adding the measurement to the total dispensed if completing), and/or calculate the period of the pulse cycle. Those two bits of data let you calculate total fuel dispensed, engine speed and duty cycle of the injectors (instantaneous flow rate).
The second interrupt input is dedicated to the VSS and only triggers on rising edges. It's code is a good bit simpler, calculating the time period since the last rising edge (used for instantaneous speed) and incrementing the VSS pulse count.

My latest code, now calculating trip and instantaneous MPG:
http://dl.dropbox.com/u/9882625/MPGshield_0.2.pde

[edit]scratch that. trip MPG is just sitting at zero. :/
probably some stupid programming bug.[/edit]
[edit2]fixed.[/edit2]

[dcb]

Originally Posted by bobski

I'm starting from scratch...I'm using one interrupt input for the injector signal with the interrupt being called when the signal changes (rising or falling edge). The interrupt code then checks whether the pin is high (just hit a rising edge) or low (just hit a falling edge)...

Just FYI, I had problems with that approach, and decided that using separate rising and falling interrupts was the most accurate way to monitor the injector pulse. The vss can count x2, not a problem. You are throwing a lot of well tested and considered code/hardware on the floor.

So I guess I will wish you luck at this point Just don't complain and point fingers please.

[bobski]

Originally Posted by dcb

You are throwing a lot of well tested and considered code/hardware on the floor.

Code that I know nothing about, have met nothing but frustration when trying to read and therefor can't easily work on.

[toc]

Originally Posted by dcb

Just FYI, I had problems with that approach

Could you elaborate what the problems were?
Is it the "CHANGE" interrupt wasn't available in the arduino at the time?
Time spent determining if it was an up or down change?

Your implementation is widely tested and obviously works well.

[dcb]

I am hoping to bow out of this discussion at my first opportunity, as the code/design makes perfect sense to me already and I don't see the need to go rearranging everything nor do I have the time/inclination to discuss it, or re-live it, here is a FREE working example, what more could you ask? Don't break it then blame it is all I ask.

It could be doing a read in an interrupt was part of the problem, I don't know for sure. It wasn't reliable though. Having a tight interrupt routine on rising and one on falling seemed to fix it. Interrupts need to be tight, signals can bounce a bit, etc.

[bobski]

Originally Posted by dcb

signals can bounce a bit

Speaking of signals, I noticed an entertaining side effect of the zener setup: it acts like a floating input when disconnected from the car. If I hold the hookup wire in one hand, it registers a 52.8 MPH speed (with associated odometer crawl). Using my other hand as an antenna, I can get much higher values by reaching toward various electronic devices. For instance, the LED cabinet lights I use at my desk register speeds in excess of 3 miles per second. If I touch my (grounded) computer case, it drops to zero. A 1M ohm pulldown resistor in parallel the the zener seems to fix it. I suppose most cars already have a pulldown in place so it's a non-issue. It's kind of handy for desktop testing actually.

[dcb]

note R6 in the schematic above, only a problem for reed switch vss. Hall effect don't float nor do real injector signals.

[FalconFour]

FWIW, I just saw this topic after I posted my feeble attempt at re-railing this Arduino project back into its Arduino roots... http://ecomodder.com/forum/showthrea...ace-16556.html - not meaning to step on hard-working dcb's toes here, but I mean, come on, thousands if not hundreds of thousands more capable, productive, and eager people have Arduino platforms on their desks than have Atmel AVR "core" systems... and the current code (as well as all my mods to it) have worked and run just fine in the Arduino IDE... plus, my prebuilt MPGuino has been running on a stock Arduino bootloader ever since I applied my first "mod" to the MPGuino code (had to flash the bootloader first to get it to take the upload). It's just project-suicide to keep forcing it further and further away from the Arduino platform, which in my experience is perfectly rock-stable and very well standardized compared to free-wheeling and non-standard raw AVR code. Maybe you had a bad chip? I dunno, but I think the project would be much more active and accessible (as opposed to 1/2 a forum page of posts a month) if more people with Arduinos could contribute...

[bobski]

Glad to see I'm not the only one that's been thinking about this.
I'll try to get a schematic of my current hardware drawn up this week. It's nothing particularly impressive, but should be a good starting point for discussion, further development and revision.
My code works fine on IDE 0021, uses standard libraries, has basic functionality at this point and should be easy to adapt to different hardware designs. Using different size displays, multiple displays and even graphic LCDs (which I just started playing with yesterday, after picking up a couple of $10 128x64 units) should be a simple matter of writing info pages that make full use of them.
The problem with typical graphic LCDs or more than one character display being the number of IO pins they demand. Serial interfaces can cut down the pin count, or one can go the opposite route and use a board with more IO pins - an Arduino Mega. AFAIK, the code should work fine on any Arduino compatible board at this point.