|Anonymous | Login | Signup for a new account||2019-01-20 04:45 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000258||Tunix||General Features||public||2011-09-09 09:43||2011-10-23 18:53|
|Target Version||1.0.0||Fixed in Version|
|Summary||0000258: Add Support For Dynamic Loading Of Profiles|
|Description||Because MTX has always worked on an effectively hard coded basis against particular firmwares it has some behaviours which are incompatible with something resembling megasquirt ini/msq style initialisation. This is a design choice that was and is in many ways a good one.|
The game plan for FreeEMS is to design a file format and data set that can fully describe what the user has access to, in which ways, and do it all dynamically from an ECU or with a file provided, worst case. In such a case, the file would be dynamically chosen along with a data/tune file, or as part of a data/tune file. This would happen at application launch, or possibly even to switch from one system to another while running without needing to restart the app.
One symptom that is currently showing up because of the dynamic vs static init arrangement is inability to load saved ecu files offline for freeems. This is because the freeems memory structure is live queried from the running device and the device is not available for that when doing an offline mode load.
My proposed short term fix for that, if we bother with a short term fix (could be a good step towards a final solution?) is to save whatever memory structure data is retrieved from the freeems device in the .ecu file with the data. That way the same structure information could be pulled back out of the ecu file and used to allocate memory for the tune.
Clearly Tunix isn't my app, so I don't know enough about it to be more detailed and the above speculative solutions and descriptions could be flawed or utterly wrong.
When we do get full dynamic data description working, Tunix will need to store that description along with the data when saving the ecu contents to a file. This seems like a good first step.
|Tags||No tags attached.|
|YOU need to get the dynamic data description stuff started before I can do anything whatsoever|
|suspended until fred moves on his end for the supposed "dynamic config"...|
|What about for all of the other firmwares that you support? They won't be providing you with a nice clean interface and the behaviour should probably be consistent. Thoughts?|
All the other firmwares supported have profiles that define ALL ECU capability and memory layout. FreeEMS doesn't yet have this, as yours is a completely different design where the "config" is supposedly planned to be READ from the ecu and loaded to setup the tuning software. Thus it is impossible to do an offline mode since this data doesn't exist for the tuning software to configure itself to. (i.e. catch-22). If/when the downloadable-from-the-ecu config is created, the tuning software would have the option of loading a previously cached profile, thus allowing offline mode after at least ONE live connection.
Thus blocked until such time.
|The "live from ECU" thing is only a maybe at this stage. Even if it goes ahead, you will still need to A be able to load the same info from a file selected by the user from some "ecu configs" dir and B save the retrieved data in the same format to be reloaded at a later date and C that format needs to be human readable. Perhaps a good start would be to change the ECU dump format to xml or json or yaml or whatever and put some readability into it?|
|I mean: Right now you pull all of that data from files for the others, why not create a second mechanism for that data that can pull it back out of memory and dump it into another format? All of the datamap.in stuff could then be loaded, dumped and converted. Have a think about this, it might help distil out what the FreeEMs data structure needs to look like too.|
The ecu config as it currently sites is human readable to the extent that it's not a binary (its .ini), and I chose NOT to encode the datamap.ini stuff into it for several reasons:
1. it locks it to megatunix which isn't good for cross-tuning-sw-ability
2. It only encodes half of the story, the datamap's real purpose is to supplant weaknesses in the gui design tools (glade) that don't allow me to bind data to controls in a way that megatunix leverages.
There are too many variables and too many unknowns to come up with a good or viable solution at this time. There needs to be conditions set to limit the set from infinite to something finite (and doable).
|Copyright © 2000 - 2011 MantisBT Group|