Config errors - A better strategy?

[Reverant]

Not sure if this belongs strictly on the MS3 development forum, as it could apply to the MS2 and TunerStudio.

I've had countless instances where customers find themselves stranded due to configuration errors.

This usually happens on settings that don't prompt for a restart. So the user may change a setting, not see a side effect until he restarts, maybe next morning where he has no laptop - boom.

A better strategy would involve the use of TunerStudio: On connect, fetch a list of available and used pins/ports on the Megasquirt. Then simply gray out the used ports in the menus, or leave them out of the list if the widget doesn't support greyed out items (not recommended - users may be confused as to why ports are missing). Of course there is always the issue of other settings that cause a config error - such as requesting VVT on an ignition mode that doesn't support VVT. These could be handled in the .ini, for example grey out the VVT menus if a non-VVT wheel is selected, and also disable the VVT. Users should be presented with a message saying:

"Selecting 4G63 will also cause the following changes:
1) No. VVTs: Off
2) ....
.
.
.
N) ....

Really select 4G63?"

Obviously, this requires careful planning to setup a generic framework that could catch/contain all the cases required.

In addition, it would be nice if we could actively reject any attempts to save changes that cause a conflict. I understand that this is technically more difficult than the first solution. This solution would be easier on the MS3, not easy at all on the MS2. However, this strategy can help if a non-TS source (CAN or serial device?) accidentally tries to assign a wrong pin/port/setting somewhere.

Thoughts?

[racingmini_mtl]

The conflicts and other error causes are tested once inside the ECU when the CPU is initializing. So having this done at another time would mean heavy processing each and every time a setting is written. So I doubt this could realistically be done without impacting the ECU operation. Having TS do something would likely require a lot of work from the developers on both the ECU and TS sides.

It might be better to somehow force the users to do a simple power cycle.

... this strategy can help if a non-TS source (CAN or serial device?) accidentally tries to assign a wrong pin/port/setting somewhere...

Have you actually seen that happen? If an external device actually changes settings and creates a conflict then it's not an MS issue. It could be an issue if a CAN device broadcasting data creates a conflict but that's still doubtful that this should be seen as an MS issue which would warrant major work.

Jean

[Reverant]

The conflicts and other error causes are tested once inside the ECU when the CPU is initializing. So having this done at another time would mean heavy processing each and every time a setting is written.

I disagree, in that a check every time a ram change is about to happen isn't something that happens frequently. It's not a part of main loop or in a timed interrupt so the CPU isn't taxed unless a RAM change is pushed. I mean, is the flash burning on the MS2 on a running engine (change a single setting; burn stumble) something that is more welcome? No, it is a necessary evil which we learned to live with.

Maybe we can add exceptions for known tables that can't create a conflict (ie VE tables and such) and which have a very high probability of being messed with with a high frequency (ie during VE Analyze Live, or when tuner maps in real time).