t vago's MPGuino workspace thread, continued

[t vago]

Did some more modifications to my code to make it more modular. One side effect is that my code now supports 20x4 LCD displays with ease. It also supports any TWI LCD 16x2, 20x2, or 20x4 display.

[t vago]

Performed substantial re-write to menu code to support 20x4 screens, among other things. Rearranged menu items to strengthen menu-based feature selection.

Finished refactoring dragrace / accel test code, and discovered that it didn't work as of several years ago. Dragrace / accel test debugged and works now.

Minor refinements to debug terminal code.

Now starting to refactor existing coastdown test code.

[t vago]

Coastdown testing is again put on hold for now - trying to figure out the best way ahead to actually do the calculations

In the meantime, I have started efforts to allow my code to run on the MPGuino Colour Touch.

So far, I have Bluetooth support incorporated and almost completely debugged. My code is now able to transmit to an Android smartphone using the MPGuinoBlue app found on Google Play. No word on iPhone compatibility, since I do not think there is currently an iPhone app written for the Colour Touch.

The only hiccup remaining for my code's Bluetooth support is that the smartphone screen will occasionally stop updating after a parameter is changed, and will not start updating again until the settings menu is accessed.

https://www.youtube.com/watch?v=ZPqg6iU29Tw

[t vago]

A little more testing suggests that my hiccup described above is happening when MPGuino is processing signals simulating high speeds and high RPMs.

Since i don't expect people to do a lot of configuration changes while speeding down the highway, i am going to give solving this hiccup a low priority.

[t vago]

Yah, it's been a while since I last updated this...

Mainly, I've been enhancing the debug monitor portion of my code, and that has enabled me to discover a number of previously undetectable bugs within my code that had been there for years. Stuff like, tank average vehicle speed going wonky after 500 miles traveled, or fuel cost causing excessively high speeds and fuel consumption rates, or CPU utilitization being artificially reported low. Also pushed more global variables into arrays - this enables visibility to the developer via the debug monitor, and also uncovered a few more very subtle bugs.

Now I am in the process of modifying the signal simulator part of the debug monitor to simulate a peak/hold injector signal, which will in turn allow me to modify the fuel injector monitor code to properly detect and process a peak/hold injector signal. I will use as a base that peak/hold injector code first develped here and incorporated into both meelis11's and abbalooga's code.

[t vago]

Got the fuel injector simulator to spit out an approximation of a frequency modulated peak and hold signal, as can be seen below. The yellow waveform is the base fuel injector signal that MPGuino initially generates as a reference, and the blue waveform is the peak/hold output. However, the hold portion appears to be itself delayed, very likely due to MPGuino capturing these pulses itself.



See, the fuel injector and VSS simulators both generate signals that are supposed to be reasonable approximations of what MPGuino would actually see from a running, moving vehicle. As soon as MPGuino switches the edge of a given simulator waveform signal, it will actually handle that signal change via the interrupts that it would normally use. This is very useful for refining and troubleshooting the signal capture interrupt code. However, it can also introduce delays, especially on lower-level interrupts. The VSS and fuel injection signal capture interrupts are two of the highest priority interrupts within MPGuino - they will always have higher priority over any other interrupts being used. The simulators use the timer1 overflow interrupt, which is also use for LCD delay generation, and of course they have a lower priority on the interrupt hierarchy. So, when the timer1-based simulator generates the waveform, the higher priority interrupt will immediately take over once the timer1 overflow interrupt code ends.

And this is likely why the hold portion of the simulated peak/hold fuel injector signal is missing a few spikes.

On the plus side, my MPGuino code could already somewhat handle frequency modulated peak/hold signals. The code can correctly read the number of fuel injector pulses and can therefore calculate engine speed. However, it currently cannot accurately measure the length of the peak/hold signal... That will be the next trick I teach it.

[t vago]

My code now supports frequency modulated peak/hold fuel injection.

What's more - my code automatically detects whether the fuel injection signal is peak/hold or saturated, so there is no need to modify any stored parameter setting.

[FlashStopFall]

Happy to see you are still updating this occasionally!

I'm currently breadboarding the legacy MPGuino setup with the hopes of making a small prototyping board, and maybe even making some PCB's.

Is there a way to display the characters on the display upside down from the default? As in, the display is upside down in my current configuration. I haven't been able to figure it out myself yet. :-)

[t vago]

Originally Posted by FlashStopFall

Happy to see you are still updating this occasionally!

I'm currently breadboarding the legacy MPGuino setup with the hopes of making a small prototyping board, and maybe even making some PCB's.

Is there a way to display the characters on the display upside down from the default? As in, the display is upside down in my current configuration. I haven't been able to figure it out myself yet. :-)

If I understand you correctly, your LCD display would be oriented upside down. If that is the case, it is not possible to modify the code to have the characters displayed upside down. You would have to somehow re-orient your setup to have the LCD display right-side up.

This is because the various LCD character bitmaps (for the digits 0 through 9, letters, etc) are hardcoded into the LCD display itself, and the bitmaps only support a right-side-up display. There are only 8 total programmable characters in the LCD display, and they are currently being used by my MPGuino code to display graphs and to do the spiffy trip labels.

Here is a graphic showing a typical LCD display character bitmap.

[FlashStopFall]

Originally Posted by t vago

If I understand you correctly, your LCD display would be oriented upside down. If that is the case, it is not possible to modify the code to have the characters displayed upside down. You would have to somehow re-orient your setup to have the LCD display right-side up.

This is because the various LCD character bitmaps (for the digits 0 through 9, letters, etc) are hardcoded into the LCD display itself, and the bitmaps only support a right-side-up display. There are only 8 total programmable characters in the LCD display, and they are currently being used by my MPGuino code to display graphs and to do the spiffy trip labels.

Here is a graphic showing a typical LCD display character bitmap.

Of course, I should have known that, I read the datasheet... Thanks!