View unanswered posts | View active topics It is currently Wed May 23, 2018 11:55 am



Reply to topic  [ 21 posts ]  Go to page 1, 2, 3  Next
Future Tuning Software Architectural Wish List (lower level) 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15123
Location: Home sweet home!
I've renamed this thread and created a new one for user stuff.

Issues in this thread include :

  • method for supporting multiple firmware versions in the same tool
  • method for storing/saving/restoring/extracting a tune from a particular version and cross version compatibility.

I can add more topics to that list as they come up.

Currently we have glade/mtx vs. visC/mt discussions going on. A new different tool is on the cards for the future, how it is designed/built will likely be shaped somewhat by this thread.

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Thu May 22, 2008 7:54 am
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Sat Feb 23, 2008 8:58 pm
Posts: 387
What I want to see is a quick and easy way to change the interface with the ECU, the menus in the GUI, and the format of the log file. Nothing should be hardcoded and require a recompile.

I must say that I like the Megatune ini (for the items mentioned above) except for the few hardcoded items but I've been using for a while so I'm biased.

Jean


Thu May 22, 2008 4:06 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15123
Location: Home sweet home!
jbelanger wrote:
Nothing should be hardcoded and require a recompile.


Why? I can understand you wanting to configure things like log files etc, but menu design and code interface stuff just ends up a giant mess in the ini.

If the tool is in an open source language as compilable on mac, linux, win with free tools then anyone needing to change something can do it painlessly. The only people who should need to change things are developers anyway. I would like the code to be clean enough that I can dive in and quickly adapt the latest version to my latest firmware, but beyond that I'm not sure it should be all in a HUGE config file. Look at the support nightmare that those ini files are for the ms crew. MTX doesn't seem to suffer from such issues. The occasional bug crops up and Dave fixes it pretty quickly.

The issue with hard coded stuff in MT is that it really is hard coded and you need visual studio to fix it.

With MTX the code is modular for the interface etc such that you plug in the bits you need and it works.

Provided that it is fairly simple to add/remove/change stuff, why must it be plain text?

So, to summarise, I agree that it should be extensible and flexible, but not that it should be in plain text where mind numb users can get hold of it and mess it up.

Perhaps it is possible to do "ini" style setup in a more efficient clean way? This seems to me to be much like the generic wheel decoder situation. It would be nice to have custom interface types and gauges etc and doing this with just config is near impossible.

This is certainly worth discussing as MT and MTX are poles apart in this respect. My gut feeling is that MTX has it right. MT was built to prototype and does that well, BUT at the same time you could code up a simple interface in the time taken to figure out and change an ini file to do the same at which point a MTX type setup could potentially be just as good at prototyping as an MT one, but without various hassles.

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Thu May 22, 2008 4:27 pm
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Sat Feb 23, 2008 8:58 pm
Posts: 387
I think that part of the support problem is that the user base is many times larger with MT than MTX and that there's a million options due to the firmware trying to do everything in a single version. And MTX never had support for MS2 until very recently (I don't know if it even works fully now). I actually never even tried MTX for that reason.

I agree that the MT ini file is not the best but I can add a new variable in the firmware and be able to edit it in MT with 2 lines in the ini file (well maybe 3 because I would change the signature text). And if I want to log some new variable, it's 2 more lines. That as painless as it gets, in my mind. I don't want to have to maintain another dev environment for the tuning sw if I don't have to, especially if I'm working on multiple computers and with multiple firmware versions. And I'd want to be able to make my changes with any simple text editor.

So, I'm willing to be convinced that it should be done differently but I will probably need a lot of arguments to sway me. I guess I'm getting old and entrenched in my ways. :)

Jean


Thu May 22, 2008 5:43 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15123
Location: Home sweet home!
It's you, IT'S YOU!! Busted! :-p

Quote:
I agree that the MT ini file is not the best but I can add a new variable in the firmware and be able to edit it in MT with 2 lines in the ini file (well maybe 3 because I would change the signature text).

Changing the interface and leaving the RevNum the same! tsk tsk (or am I confused?) After you do this and post for help, how do I know for sure you haven't broken it yourself? I think there should be an entry level, a bar you have to cross over to be able to do such things. If you can't manage them, don't touch the stuff :-) Seriously, you shouldn't be touching the ini/interface definition without changing the version. If it's for your private experimentation, sure, but...

Quote:
And if I want to log some new variable, it's 2 more lines. That as painless as it gets, in my mind. I don't want to have to maintain another dev environment for the tuning sw if I don't have to, especially if I'm working on multiple computers and with multiple firmware versions. And I'd want to be able to make my changes with any simple text editor.

Most any language can be edited in VIM etc. I still compile from a term window. You don't necessarily need a full on dev env. Having said that what are you doing messing with code WITHOUT a proper dev env? Why doesn't the code do what you need from it?

viewtopic.php?f=8&t=134 :-)

Quote:
So, I'm willing to be convinced that it should be done differently but I will probably need a lot of arguments to sway me.

Help is on the way.

jbelanger wrote:
I actually never even tried MTX for that reason.

I haven't used it, but I have tried it and do enjoy playing with it meaninglessly. I dislike the way MT works at least as much as I despise the ini/msq setup. I spent a few days figuring that all out. TBH I still have no idea what everything does.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Thu May 22, 2008 5:58 pm
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Sat Feb 23, 2008 8:58 pm
Posts: 387
Fred wrote:
Changing the interface and leaving the RevNum the same! tsk tsk (or am I confused?) After you do this and post for help, how do I know for sure you haven't broken it yourself? I think there should be an entry level, a bar you have to cross over to be able to do such things. If you can't manage them, don't touch the stuff :-) Seriously, you shouldn't be touching the ini/interface definition without changing the version. If it's for your private experimentation, sure, but...

Actually, I do change the RevNum but I don't have to tell MT about it so I only have to change the signature in the ini because the interface changed. If I changed the code but not the interface, I just change RevNum and leave the signature and the ini file alone. This comes back to what I was saying in the other thread.

Fred wrote:
Most any language can be edited in VIM etc. I still compile from a term window. You don't necessarily need a full on dev env. Having said that what are you doing messing with code WITHOUT a proper dev env? Why doesn't the code do what you need from it?

viewtopic.php?f=8&t=134 :-)

I actually use a mix of tools depending on what I'm working on. It's bit messy and not optimized but it works for me. However, that makes me reluctant to add more dev tools if I don't have to but I guess this my own problem.

Fred wrote:
I dislike the way MT works at least as much as I despise the ini/msq setup. I spent a few days figuring that all out. TBH I still have no idea what everything does.

I think this is partly due to the same problem for the whole MS project: there is no spec or doc on any of the code so you basically have to dig in and figure things out. I didn't have too much trouble with this part but it was done incrementally over a long period.


Thu May 22, 2008 6:22 pm
Profile WWW
LQFP112 - Up with the play

Joined: Sun Apr 06, 2008 6:30 pm
Posts: 100
Here's my take.

DISCLAIMER: I'm biased because I'm the MTX author. I also recognize that many of the ways that mtx is/was designed is NOT optimal and should have been done differently.


MTX is designed with 1 primary goal to be USER friendly (not necessarily developer friendly, which is how MT seems to lean). It was also designed to be modular (I failed somewhat in this due to my lack of good programming experience, though it has improved a lot in recent months with ms-2 support working)

MTX Advantages:
- Easier on the Eye
- Easier on the END user
- fairly adaptable
- It has the coolest slickest dashboard/gauges out there (IMHO)

MTX Disadvantages:
- Harder to add new controls to compared to MT (more work involved)
- not as flexible as I'd like
- too monolithic in some areas
- conf files need improvement to be less verbose or converted to something better (XML).

That being said, I don't think it's possible to develop something with the relative simplicity of a megatune ini (they aren't THAT simple, but they are terse where they need to be), and maintain the gui flexibility of megatunix which uses glade to do the graphical layout.

For the most part in megatunix adding support for new firmware does NOT require a recompile EXCEPT in the case where the firmware requires unusual or very special handlers. (for example the TTM code in mtx for the tooth/trigger monitor tab), or things like the accel wizard or warmup wizard.

MegaTunix's conf files are VERY verbose and not super consistent. I WILL probably convert a subset of them to XML (ones that are not well suited to XMLification are the Gui datamaps and main interrogation profiles, however just about all other conf files should be easy as XML (dash and gauges are already XML)

Back/restore formats are a hard issue to solve. (lots of ways to go on this one). megatunix is simple export it as an ascii stream of bytes, making it nearly impossible to exchange it across firmwares, megatune's is complex as a xml-ish file which ismarried to the megatune.ini file that was in use at the time of backup. conversion to another firmware release is not guaranteed unless the namespaces are completely consistent (an they tend to be in many cases),

I chose the "you can't translate backup.restores between FW rev's" over megatune's "you can probably, but it might bork some hidden variable burried who know's where" approach.

_________________
-- David
http://www.megatunix.com
http://megatunix.sourceforge.net


Thu May 22, 2008 11:23 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15123
Location: Home sweet home!
mtx_man wrote:
DISCLAIMER: I'm biased because I'm the MTX author. I also recognize that many of the ways that mtx is/was designed is NOT optimal and should have been done differently.

I don't think you are, you might be stubborn, but it seems to me you are as self critical as you are critical of others. ie. you'll be honest equally in all directions. I appreciate that a lot.

Quote:
MTX is designed with 1 primary goal to be USER friendly (not necessarily developer friendly, which is how MT seems to lean). It was also designed to be modular (I failed somewhat in this due to my lack of good programming experience, though it has improved a lot in recent months with ms-2 support working)

I think that is the right approach too because a user might/probably will be incompetent, whereas the dev should be able to figure it out.

Quote:
That being said, I don't think it's possible to develop something with the relative simplicity of a megatune ini (they aren't THAT simple, but they are terse where they need to be), and maintain the gui flexibility of megatunix which uses glade to do the graphical layout.

That being the key point that I also agree with. This is kinda like our "separate decoders so that they can be optimal in each case" scenario.

Quote:
For the most part in megatunix adding support for new firmware does NOT require a recompile EXCEPT in the case where the firmware requires unusual or very special handlers. (for example the TTM code in mtx for the tooth/trigger monitor tab), or things like the accel wizard or warmup wizard.

I suspected that, but wasn't sure. How are you feeling now Jean?

Quote:
Back/restore formats are a hard issue to solve. (lots of ways to go on this one). megatunix is simple export it as an ascii stream of bytes, making it nearly impossible to exchange it across firmwares, megatune's is complex as a xml-ish file which ismarried to the megatune.ini file that was in use at the time of backup. conversion to another firmware release is not guaranteed unless the namespaces are completely consistent (an they tend to be in many cases),

I chose the "you can't translate backup.restores between FW rev's" over megatune's "you can probably, but it might bork some hidden variable burried who know's where" approach.

I hadn't even considered this at all. I'll have a chew over it and post some thoughts.

I actually intended this to be a from the users perspective thread in terms of what you can click/do/how you do it/features/abilities/etc, but this is good too. I might rename this one and start a new one for the other aspect.

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Fri May 23, 2008 7:11 am
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 15123
Location: Home sweet home!
Bump, changed the title of this and put the original content over here :

viewtopic.php?f=10&t=218

Fred.

_________________
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!


Fri May 23, 2008 9:03 am
Profile WWW
LQFP144 - On Top Of The Game
User avatar

Joined: Sat Feb 23, 2008 8:58 pm
Posts: 387
Fred wrote:
Quote:
For the most part in megatunix adding support for new firmware does NOT require a recompile EXCEPT in the case where the firmware requires unusual or very special handlers. (for example the TTM code in mtx for the tooth/trigger monitor tab), or things like the accel wizard or warmup wizard.

I suspected that, but wasn't sure. How are you feeling now Jean?

That sounds good and I'm glad to hear that. I remember Dave saying so before but since I haven't yet played with MTX, I haven't seen what the conf files look like. And having to recompile for very specific special cases is expected.

I'm glad to have Dave's point of view and comments. And I don't want to criticize but would actually want to benefit from his experience on the fact that it seems to have been quite a job to make MTX MS2 compatible. It would be good if we can avoid this when defining the configuration files (or whatever will be used) and the parsing engine behind for the tuning software. Since it was quite easy to do in MT and the fact that the MS2/extra variable sized tables was also easy to do in MT but not so in MTX, it would also be good if we can have a first hand experience of the potential pitfalls to avoid.

Jean


Fri May 23, 2008 3:39 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 21 posts ]  Go to page 1, 2, 3  Next

Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.