FreeEMS Issues - Tunix
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000472TunixGeneral Featurespublic2011-12-07 15:382012-04-07 12:25
ReporterFred 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusnewResolutionopen 
PlatformAllOSAllOS VersionAll
Product Version0.9.24-SNAPSHOT 
Target VersionFutureFixed in Version 
FirmwareVersion
Summary0000472: Provide Get Data/Store Data Per Page
DescriptionOn each tab, at least, or more granularly, provided a way to refresh data from the ecu, and burn data to the ecu ONLY for what you're looking at.

Additionally, once 0000261 is implemented provided a get from flash and/or reset to whatever is in flash function so that mal-adjusted things that are in ram can be discarded without manually doing it or a reset/reinit that affects everything being performed.

In MegaSquirt where settings for one thing are spread across many pages, this will likely require a map of what is in the current view/tab to be stored such that it can be updated/pulled from at will.

Finally, as a first step, it would be better if the current buttons were renamed to:

"Get All Data" and "Burn All Data" or something else as short and meaningful.

I'm writing this now because I nearly filed a bug report on the table having colour refresh timing still in it, but it was just that i pulled back the entire ecu contents in order to refresh one table (thereby blowing away valid changes in other tables not yet burned in the process, which is bad...) and it was therefore slow.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files

Notes
(0000944)
dandruczyk   
2011-12-08 03:43   
Nope, not going to be done, end of story and here's why:

Each tab is extremely likely to have data on it from MULTIPLE LOCATION ID's (or pages in the case of MS), and having to break out which ones and which data areas, and which can be read in subsets and which cannot is NOT WORTH THE HASSLE, and offers next to ZERO positive value, and only serves to confuse.

Megatune used to have this sort of behavior (it sucked ass), and it forced each window to ONLY allow controls from a single page (location ID), and got people into the very bad habit, of clicking fetch, changing somethign nad burn over and over again, which cal lead to premature flash failure, as well as a very clunky user experience..

Marking as low/no priority, as there's no compelling reason of value based in reality for this
(0000946)
Fred   
2011-12-08 13:19   
Leaving assigned to no-one such that someone else can pick up the task if they feel the urge. Resetting to open for same reason. See IRC for more info.
(0000947)
Fred   
2011-12-08 13:22   
"Megatune used to have this sort of behavior (it sucked ass), and it forced each window to ONLY allow controls from a single page (location ID), and got people into the very bad habit, of clicking fetch, changing somethign nad burn over and over again, which cal lead to premature flash failure, as well as a very clunky user experience.." = Flawed implementation.
(0001092)
dandruczyk   
2012-01-02 21:04   
The only way to accomplish what you want is to limit the controls on a active page/tab to be all from the same page or location ID. That ruins the UI experience and severely limits the usability, or expoenentially increases complexity of data management and leads to much more bugs and much harder resolution of such bugs.
(0001412)
dandruczyk   
2012-04-07 12:25   
If you returned something in the datalog stream indicating which location ID's were stale it would be far easier. i.e. Set a flag (burn needed/outstanding data, etc), and the tuning software could then do a sweep comparing flash to ram per location to determine what is not current. Right now, you don't do that, which causes the problem if the tuning software/host computer/e5tc were to die, and reconnect it would NOT have any idea that things were out of sync (no flags from ECU), and it would put hte onus on hte tuning software to figure it out. In the case of other ECU's it is NOT POSSIBLE to read he flash and ram states independently, hence what you original wanted in a previous not was never able to be created. a FLAG in the serial stream is the nicest way to give the tuning end a heads up, its also useful in a datalog scenario as a historical marker as to when burns occur (the flag will flip state then, when all locations match), and that can be used to correlate if burns disturb other runtime actions (wheel decode for example)