MPGuino release one workspace

[diesel_john]

The VSS signal from the transmission transducer on my '91 Ford is fairly weak. In fact, a couple months ago, the connector at the trans had gotten oil in it and that was enough to pull down the signal. I don't think i have a wire from the ECU to the speedo because i have a speedo cable too.

[dcb]

Just FYI, the debug screens are accessible via the left right buttons now, as is a "Demo mode" if you press both left and right together once (cycles back and forth through pre-recorded data). So, the data is all there, it is just a matter of presenting it now (and you don't even have to get your hands dirty now). I don't know actually what mpg values it should be, but I'm guessing the end of the array data is 45mpg @ 25mph instant.

The other button combinations are:
middle: brightness
middle+left: Tank Reset
middle+right: Current Reset

The previous patched version debug screen may be out of date, so make sure to use the latest from post 1.

[MetroMPG]

Way to go, dcb. Very cool to watch things unfolding.

I'm going to get in on the fun next week with mine.

[dcb]

Thanks Cap'n

So how do I have 64 bit math on the arduino without the 7k libraries. I can't declare one long long without running out of space. But need to do some accurate multiplying/dividing that would benefit from the extra bits. Does anyone know of any short and sweet 64 bit math routines handy that take less than 7000 bytes?

[dcb]

Well, if I trim down my demo mode so it just uses constant values I can get the 64 bit library to fit (things start breaking before you get to the maximum), so we are officially tight on space and might even need to pare down a couple things, but nobody has to write and debug and integrate any 64 bit math routines for version 1.

Binary sketch size: 14030 bytes (of a 14336 byte maximum)

[awillard69]

That would be reason to evaluate your code and see if there are any optimizations that can be done, any old school tricks to eliminate instructions in the compiled code. May need to dig into the compiler to see if there any optimizations that can be leveraged there.

I'm not sure you will need the 64 bit data, you could get more than .1 variation from a signal (timing, weak/faulty unit, etc), so having resolution beyond one decimal may not be helpful and in this case detrimental to other features desired.

BTW, I just got my *duino and display. So, I'll get to assemble it and do my "Hello World" test. Something to do this weekend!

Also, I was thinking of putting together a simple circuit, something based on a few 555/556 chips to provide a generator for test signals (static injector and VSS pulse trains) to allow bench testing of the code without having to deal with the connect issues. I don't have a scope, so I'll have to rely on just the math for the apparent frequencies and pulse widths. Unless anyone has any other ideas...?

[MetroMPG]

awillard: great - another beta tester signs up!

I believe the list of beta testers/second fiddlers now includes:

larrydag - '95 Honda Accord DX
myself - '98 Pontiac Firefly (Geo Metro)
andrewj - '94 Civic CX
mosier - ??
awillard69 - ??
Mr Clean - ??

And of course our fearless leader:

dcb - 97 saturn s2

Did I miss anyone?

dcb: I wasn't aware of the sketch size limitation. Way to squeak 'er in there.

The size challenge reminds me of the5k.org... which now sadly appears to be defunct. It was a great web site where contests were held to build the best web pages that came in under, you guessed it, 5kb. There was awesomely creative stuff there at one point. I'm sure there are other sites like it out there.

[larrydag]

I had the debug mode on this morning as I drove into work. I pretty much saw the same results. Injector %D would jump around from 0 to 40% approximately. Although it seemed to go to a very large whole number occasionally (23456 maybe)? I don't know if that is a bug or something. The C would just jump to 0.0, 0.1, 0.2. Don't know if that is accurate but sure doesn't look like an rpm. Maybe needs to be multiplied by 10000 in the code.

Nothing with VC. I'm thinking it might be the connection circuit because I definitely get a reading with the multimeter albeit a small one. I don't think the signal goes above 0.4-0.5 Volts. What kind of signal are we supposed to get with the VSS?

[dcb]

The "%D" tells me you don't have the latest and greatest. I would start with the latest code from post 1.

[awillard69]

Originally Posted by dcb

So how do I have 64 bit math on the arduino without the 7k libraries. I can't declare one long long without running out of space. But need to do some accurate multiplying/dividing that would benefit from the extra bits. Does anyone know of any short and sweet 64 bit math routines handy that take less than 7000 bytes?

I couldn't wait for my board to get assembled, so I started playing with the latest code here at work.

I was able to shrink the sketch size from 7464 bytes to 6642 bytes (11% reduction) by just adjusting the data types used. For instance where you have

for( int x = 0; x < 10; x++ )

You can save space by converting it to

for( byte x = 0; x < 10; x++ )

It can be anywhere from 1 to 3 bytes, depending on system. Note: I cannot verify that any changes do not negatively impact the operation of the code itself.

Just changing the various loop control variables from "int" to "byte", I was able to reduce the size quite a bit.

Nextly, removing variables from the global scope has an even greater impact.

For instance, moving

int vsspinstate=0;

into the function where it is used saves 40 bytes! I think that maybe you planned to use it elsewhere, but are not currently. If you don't intend to use it, trim it completely and save the space altogether.

Now that I look deeper into the code, not that I understand everything you build so far, you are using some OO constructs (LCD and trip classes). You may also be adding overhead you don't expect and may gain some significant space by converting to structures and functions. Anecdotal perspective: there is no OO/C++ in the Linux kernel (per Linus) because of the overhead in complexity, size and speed - performance is critical. OO is for the programmer, not the processor/CPU.

Let me know if you want to see my modifications. Since you are up and running, you may be able to evaluate their "properness" better than I can at this point.

It's nice to be more than the sum of our individual parts - together we are stronger.