t vago's MPGuino workspace thread, continued

[FlashStopFall]

I know this isn't a tech support forum, but I couldn't figure out this compilation problem. Would it be better to post this as an issue on github?

I would love to solve this, if you know what the problem is, or could point me toward how to solve it myself. Thanks!

I tried enabling useChryslerMAPCorrection, but compilation failed with the error:

In file included from /home/ian/Arduino/mpguino_tav/mpguino_tav.ino:438:0:

/home/ian/Arduino/mpguino_tav/trip_measurement.h:438:52: error: 'tPressureChannel' was not declared in this scope
((mpMAPpressureIdx - mpMAPpressureIdx) << 8 ) | (tPressureChannel) // Pressures
/home/ian/Arduino/mpguino_tav/trip_measurement.h:439:53: error: 'tPressureChannel' was not declared in this scope

,((mpBaroPressureIdx - mpMAPpressureIdx) << 8 ) | (tPressureChannel)

/home/ian/Arduino/mpguino_tav/trip_measurement.h:440:53: error: 'tPressureChannel' was not declared in this scope
,((mpFuelPressureIdx - mpMAPpressureIdx) << 8 ) | (tPressureChannel)

/home/ian/Arduino/mpguino_tav/trip_measurement.h:441:52: error: 'tPressureChannel' was not declared in this scope
,((mpInjPressureIdx - mpMAPpressureIdx) << 8 ) | (tPressureChannel)

/home/ian/Arduino/mpguino_tav/feature_datalogging.ino: In function 'void idleProcess()':
/home/ian/Arduino/mpguino_tav/feature_datalogging.ino:528:20: error: 'prgmCalculateMAPpressure' was not declared in this scope
/home/ian/Arduino/mpguino_tav/feature_datalogging.ino:528:20: note: suggested alternative: 'prgmCalculateSpeed'
/home/ian/Arduino/mpguino_tav/feature_datalogging.ino:539:20: error: 'prgmCalculateBaroPressure' was not declared in this scope
/home/ian/Arduino/mpguino_tav/feature_datalogging.ino:539:20: note: suggested alternative: 'prgmCalculateBingoFuel'

exit status 1

Compilation error: 'tPressureChannel' was not declared in this scope

I messed around with it but was unable to make any progress. I'm using MPGuino v1.95tav 2023-Aug-14 with a legacy MPGuino setup.

useChryslerBaroSensor compiles without errors.

I also have an issue where instant mpg only shows up half the time while moving; it switches back to gal/h the other half of the time. My speed always shows up correctly, and the average mpg continues working.

[FlashStopFall]

So, the serial logging function output every 0.5 seconds. Is there a way to make this faster (i.e every 0.2 seconds, or even every 0.1)?

[FlashStopFall]

Found the last version where useChryslerMAPCorrection worked. It is commit "a50af8e". You can find it on github by going to "commits" and scrolling to Jun 3, 2023. Or by cloning the repo, and then doing "git checkout a50af8e". This is in case anyone else wants to try out Chrysler MAP Correction, obviously t_vago, you know where all that is.

[FlashStopFall]

I fixed useChryslerMapCorrection. All I did was move the code that changed in the broken version back to how it was before. I created a pull request for the latest version, available here (https://github.com/FlashStopFall/MPG...rMapCorrection) if you would like to use it. t_vago, I hope you are doing well, and I hope the pull request is satisfactory!

[t vago]

Okay... been busy these past two years, but again am supporting my version of MPGuino!

FlashStopFall, I looked at your fix for useChryslerMapCorrection, and implemented a more modular fix that I tested on my IDE as working.

I also fixed another user's reported bug, and ensured that EEPROM.h matches filename case.

Latest development - I went through the code and fixed all pointer references to all SWEET64 programs for the AtMega2560, as there was a possibility that they would get pushed outside of assumed program space if the code and selected options would become big enough for that to happen. I also added the ability to write bytes into a dedicated RAM buffer from the debug monitor, copy existing flash-resident SWEET64 routines into this RAM, and the ability for MPGuino to run any SWEET64 program so entered into the RAM buffer, as one of its built-in functions. This means that an existing SWEET64 program can be worked on, in real-time, to troubleshoot any bugs.

I still need to add some more items to this new feature. Namely, the ability to enter the SWEET64 instructions and their arguments (operand bytes), and have the monitor automatically convert those into bytecode that SWEET64 can actually run. Also, the ability to output these RAM programs into a form that can be directly pasted into the source file. This will immensely improve the ability to develop new SWEET64 programs.

After that, I will further development to allow my MPGuino to support TFT displays. It already supports Bluetooth, and can interface using a suitable bluetooth module with the MPGuino Blue app currently available on Google Play or on abbalooga's website, http://abbalooga.com

[t vago]

Okay, I added the ability to enter the SWEET64 instructions and their arguments (operand bytes), and have the debug monitor automatically convert those into bytecode that SWEET64 can actually run. Also, I added the ability to output these RAM programs into a form that can be directly pasted into the source file. This will immensely improve the ability to develop new SWEET64 programs.

Added also a user manual and a developer manual, and updated the readme.

[t vago]

Updated the debug monitor to display more status information, and wrote a regression package to externally test SWEET64 opcodes for proper behavior. Caught a really subtle bug in the square root function by doing this, too.

Now working on finally supporting Abbalooga's AtMega2560 touch screen and TFT display. Got to where I can perform touch calibration, draw simple shapes, and rotate the output screen in 90 degree increments. Also began work on the parameter editor TFT displays, and got an actual numeric touchpad working, as well as drop-down menus for those parameters which are either on-off or only have a few enumerated values

[freebeard]

Not an area of interest to me, but thanks for keeping the old homestead in your thoughts. It's been quiet around here lately.