Dave's unofficial TODO list from his favorite nitpicker

MegaTunix is a cross-platform tuning application written and maintained by David J. Andruczyk. Discuss all things MTX here!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Dave's unofficial TODO list from his favorite nitpicker

Post by Fred »

Eye for an eye, tooth for a tooth.

You wouldn't believe this, but as I started typing that sentence the lyric played over the radio in time with my typing. If I were superstitious I'd think it meant something. The song was "bad company, i wont deny, bad company, till the day i die" etc. google lyrics, i don't know who it's by.

OK:

Code: Select all

FreeAir:~ fred$ megatunix 
Xlib:  extension "RANDR" missing on display "/tmp/launch-tHP5nz/org.x:0".
?̪?
(megatunix:53962): Gtk-CRITICAL **: gtk_entry_set_text: assertion `text != NULL' failed

(megatunix:53962): Gtk-CRITICAL **: gtk_entry_set_text: assertion `text != NULL' failed

(megatunix:53962): GLib-CRITICAL **: g_thread_join: assertion `thread' failed
That was the first run, but it just exited cleanly. I think I chose FreeEMS and offline for that.

Code: Select all

FreeAir:~ fred$ megatunix 
Xlib:  extension "RANDR" missing on display "/tmp/launch-tHP5nz/org.x:0".

(megatunix:54157): Gtk-WARNING **: Unable to find default local directory monitor type

(megatunix:54157): Gtk-WARNING **: Unable to find default local directory monitor type
Segmentation fault
That was after connecting, jizzing my pants about freeems being displayed in mtx, choosing to try to log stuff, being unable to find either the logs or binary logs, and quitting, i think i chose to save a copy of settings when it did it, which may be why, as you probably have NO datamaps and it probably got a java null pointer and crapped out about then. IE, unfinished business. If so, sweet, if not, I'll rebiuld with debug and try again.

Yep, thats when it happened alright. And, I found the logs! :-) Gufi now has a copy and has rewritten his java log viewer. Go him! :-)

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!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Dave's unofficial TODO list from his favorite nitpicker

Post by Fred »

Actual PW seems to align with effectivepw, is that your terminology for "time fuel is flowing" ? I forget who suggested the rename of my var to effective pw, but it wasn't my idea, and I do like it :-)

Actual is a bit ambiguous IMO as the actual electrical PW is IDT longer than the effective fuel flow PW. Just being fussy here. You may disagree.

I see various issues with scaling etc. I'll have a crack at updating the headers to reflect reality, IIRC the lambda one has an out by one error on it anyway. The ranges don't really belong in the firmware, though. If you take the min and max values for the variable and scale/offset/translate those the same way then you've got a fair starting point for your min and max. Let me see what I can do, I'll post again when it's sorted or I know more.

One thing I can say now, is that you can remove all the delta stuff from display in the short term as none of it is calculated yet. Also, assume that vars are unsigned shorts or in your terms _U16_ if you have no other info. I just realised that those derivative ones are correct to be signed. RPM isn't, though. I forget if RPM is even correctly calculated, it may not be. I think min/max for rpm are 0 and 32767.5 though your average engine will come in under 8k or so, but you know that.

From the "Runtime Vars" and "Runtime Data" (why not the same name?) you should remove:

mat - no code yet
ego2 - no code yet
iap - no code yet, and secondary accessory code var anyway, possibly will remove it and let features calc it from raw on their own as it is fairly niche.
mafraw - no code yet
dmap - no code yet
dtps - no code yet
drpm - no code yet
ddrpm - no code yet
airflow - intermediate debug value
densitynfuel - ditto

There is no such variable as CLT in FreeEMS there is only CHT, it's not a coolant temperature, its a head termperature or indication of that by coolant. MegaJizz doesn't make this distinction and fails to handle air cooled temp ranges. We do. That needs fixing. EDIT, this is correct in the "sliders" view, just not the secondary window with values.

base pw is pw before engine temp enrich and transient correction
effective pw is the pw after those corrections, ie, the desired fuel flow pw
ref pw is the pw that is used unless cylinders get trimmed etc. its ref because anything that needs to know pw should use this.

scaling/offset wise:

IAT/CHT seem to be good, but in raw internal EMS units of degrees Kelvin. Probably best to subtract 272.15 from those figures for display in deg C or some other conversion for deg F. I can read it as is, though, so no biggy.
MAP seems correct, i have a syringe attached to a real sensor and can play with it.
In Runtime Data the clock is sp3 and in Runtime Vars its clock, should these match? if not, why not? curious. It seems bad to have different nomenclature for the same things.
PW values seem reasonable. I'd have to check against raw values to verify, but they seem good.
TPS reads 0 so I need a jimstim to try it out.
BRV seems close, but need to check against jimstim.

None of the fields have units displayed. I think they should, you may disagree, or it could just be that its only temporarily done and they're not in yet. Just noting all things i see.

Hard resets field doesn't seem to count resets, not those from the buttons which I verified do work, nor from the button on the device.

If you want to display some of your existing MS bit flags/lights/etcs you could provide translated services from other data for them. EG warmup, if temp is lower than the part of the curve that has the minimum correction value then it's warming up. The firmware will never tell you "it's warming up" because that information is dynamic and irrelevant and controlled by a curve by the user and always applied as it applies to overheating situations to to cool the engine with a rich mixture.

other flags you will definitely have are

engine cycle sync (cop/seq/full sync)
engine revolution sync (wasted/semi/half sync)
per cylinder sync (dizzy/batch/min sync)

maybe something for "receiving engine position information" as that will be required for the fuel pump to be on.
After start enrichment
maybe flags for the non continuous transient enrichment types (map, tps), maybe

Serial port sniffing, any chance of regex style stuff rather than a fixed set? This would make sense for linux and windows, but would really come into its own on the mac where they have those weird names... mine differs from yours, perhaps you could include mine in the default set? :-) /dev/cu.usbserial-A1003NmB

The binary packets would be better with time stamps of some sort on them, either US style year.mm.dd backward dates (for good sorting) or just a lowsy currentTimeInMillis() value or something. That way they wont get over written constantly. and you can pin them back to specific times.

I don't like the MS style version/revision field names. The firmware version field isn't a signature, its a version, named and numbered and unique. The revision number and textual version ones are a combined thing not seperate and are the version of the interface not the firmware. 3000 firmwares could share an identical interface. It says "detected firmware: FreeEMS 0.0.0" which is wrong, you detected firmware "FreeEMS Vanilla 0.1.2 SNAPSHOT" using interface version "0.0.0 IFreeEMS Vanilla". though the format of the interface stuff is up in the air so dont spend too much/any time on it.

I see that you query the location ID list as part of interrogation, nice! :-)

However, I can't hold my mouse over the text window with that stuff in it on the general tab without a HUGE popup tool tip thingy obscuring the view of near everything. Longer delay or ability to turn them off please? Maybe it exists? RTFM is an acceptable answer to anything here :-)

Hitting select all in the datalog caused a crash, then didn't and went slow, then just clicking a few caused a crash.

Intuitivity: realtime mode radiobutton lines up with select file and start reading rt vars buttons, playback mode lines up with select variables and stop reading rt vars. My mind said to me "select vars for playback, but wheres the thing to select them for realtime view, and its on and doesnt do anything, " also, hitting start reading produces an "already started" warning in red, shouldn't the button be greyed out? Ditto for stop when its not running.

OK, I've tested everything FreeEMS related that I can think of for now, and you know what, I don't care much about most of it, for now, just getting more stuff implemented, we can polish and fine tune names and conversoins and shlt later, but it'd be nice to get some xml structure happening and some xml xsd checking going on and some basic stuff like a single table tunable and loaded from xml, etc. IE, ignore all of above if it helps achieve the end goal faster.

Do you regret saying "you haven't used it' yet? :-) You bet your arse that I'll flood you with feedback like no one else does once I actually start using it. I'm worse than the others too, because I can see what is possible, am fussy and tuned into details and I'm a demanding motherfcuker of a user too!! :-)

Keep up the awesome work! :-)

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!
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: Dave's unofficial TODO list from his favorite nitpicker

Post by dandruczyk »

Fred wrote: Hard resets field doesn't seem to count resets, not those from the buttons which I verified do work, nor from the button on the device.
Need clock to be set it stone before i can set this up...
Fred wrote: If you want to display some of your existing MS bit flags/lights/etcs you could provide translated services from other data for them. EG warmup, if temp is lower than the part of the curve that has the minimum correction value then it's warming up. The firmware will never tell you "it's warming up" because that information is dynamic and irrelevant and controlled by a curve by the user and always applied as it applies to overheating situations to to cool the engine with a rich mixture.
Nope, not gonna happen, not going to put in a special case for this. warmup means ETE will be modified which means you have enough info to set a bit or not....
Fred wrote: other flags you will definitely have are

engine cycle sync (cop/seq/full sync)
engine revolution sync (wasted/semi/half sync)
per cylinder sync (dizzy/batch/min sync)

maybe something for "receiving engine position information" as that will be required for the fuel pump to be on.
After start enrichment
maybe flags for the non continuous transient enrichment types (map, tps), maybe
No docs on these that I've seen anywhere, I take it your musing and haven't done these yet....
Fred wrote: Serial port sniffing, any chance of regex style stuff rather than a fixed set? This would make sense for linux and windows, but would really come into its own on the mac where they have those weird names... mine differs from yours, perhaps you could include mine in the default set? :-) /dev/cu.usbserial-A1003NmB
Use the "Locate Port" button and follow the instructions. NOTE OS-X serial port usb drivers are notoriously buggy, and typically provide two devices, a .cu... an a .tty.... ususally one works, but Mtx has no way to know beforehand.
Fred wrote: The binary packets would be better with time stamps of some sort on them, either US style year.mm.dd backward dates (for good sorting) or just a lowsy currentTimeInMillis() value or something. That way they wont get over written constantly. and you can pin them back to specific times.
Nope, then it breaks it from being a pure serial stream. Mtx's ascii datalogs (CSV/TSV) add in a high res counter (hr_clock) with usec resolution...
Fred wrote: I don't like the MS style version/revision field names. The firmware version field isn't a signature, its a version, named and numbered and unique. The revision number and textual version ones are a combined thing not seperate and are the version of the interface not the firmware. 3000 firmwares could share an identical interface. It says "detected firmware: FreeEMS 0.0.0" which is wrong, you detected firmware "FreeEMS Vanilla 0.1.2 SNAPSHOT" using interface version "0.0.0 IFreeEMS Vanilla". though the format of the interface stuff is up in the air so dont spend too much/any time on it.
The problem is you did a BAD no-no. you stuffed in an integer and string together, which completely breaks string processing, as the 0's look like "nul's" to any string parsing functions and causes all sorts of problems. You didn't provide any direction as to what you wanted and now you piss and moan its not to your liking, sheesh!.

Fred wrote: I see that you query the location ID list as part of interrogation, nice! :-)

However, I can't hold my mouse over the text window with that stuff in it on the general tab without a HUGE popup tool tip thingy obscuring the view of near everything. Longer delay or ability to turn them off please? Maybe it exists? RTFM is an acceptable answer to anything here :-)
General tab, uncheck tooltips.
Fred wrote: Hitting select all in the datalog caused a crash, then didn't and went slow, then just clicking a few caused a crash.
Can't replicate, u sure this is a datalog or the crappy logviewer? if logviewer, I don't care much as that'll be ripped out and replaced with something else soon enough. catch it with GDB on a debug-symbol build (./configure --enable-debug ; make clean ; make)
Fred wrote: Intuitivity: realtime mode radiobutton lines up with select file and start reading rt vars buttons, playback mode lines up with select variables and stop reading rt vars. My mind said to me "select vars for playback, but wheres the thing to select them for realtime view, and its on and doesnt do anything, " also, hitting start reading produces an "already started" warning in red, shouldn't the button be greyed out? Ditto for stop when its not running.

OK, I've tested everything FreeEMS related that I can think of for now, and you know what, I don't care much about most of it, for now, just getting more stuff implemented, we can polish and fine tune names and conversoins and shlt later, but it'd be nice to get some xml structure happening and some xml xsd checking going on and some basic stuff like a single table tunable and loaded from xml, etc. IE, ignore all of above if it helps achieve the end goal faster.

Do you regret saying "you haven't used it' yet? :-) You bet your arse that I'll flood you with feedback like no one else does once I actually start using it. I'm worse than the others too, because I can see what is possible, am fussy and tuned into details and I'm a demanding motherfcuker of a user too!! :-)

Keep up the awesome work! :-)

Fred.
Feedback is fine as long as it includes DEBUG TRACES (in case of crashes) along with context on how to duplicate the crash. (I did this, then this, then this and i can always make it crash here!) Constructive criticism is important and welcomed, even if it hurts my feelings. (i suggest doing X instead of Y and here's a good ass reason why), vs "This is wrong and thats wrong..."
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Dave's unofficial TODO list from his favorite nitpicker

Post by Fred »

mtx_man wrote:
Fred wrote: Hard resets field doesn't seem to count resets, not those from the buttons which I verified do work, nor from the button on the device.
Need clock to be set it stone before i can set this up...
Why can't/don't you do it like MLV does it with just looking for sequential counters and read the SP5 var instead of the SP3 one. If var = last var+1 (and account for overflow somehow) sweet, otherwise count reset. In MLV it shows up as a red line from the log. Very simple, very effective. I don't even understand what you mean about clocks and set in stone ness. What has a clock got to do with resets?

Fred wrote: If you want to display some of your existing MS bit flags/lights/etcs you could provide translated services from other data for them. EG warmup, if temp is lower than the part of the curve that has the minimum correction value then it's warming up. The firmware will never tell you "it's warming up" because that information is dynamic and irrelevant and controlled by a curve by the user and always applied as it applies to overheating situations to to cool the engine with a rich mixture.
Nope, not gonna happen, not going to put in a special case for this. warmup means ETE will be modified which means you have enough info to set a bit or not....
I don't think it's a good idea, which is why my sentence started with "If YOU want to". I will not insert code to set bits based on complex conditions that can be visually determined on an external system, of dealt with in that much-higher-resource environment. Again, to repeat, ETE var is *always* modified. It is not a "no, or yes and how much" it is ONLY a "how much" where how much can be 0 - lots. Thus no such bit exists. I agree with your not creating fake bits, but there will be quite a few bit fields that MS has that we won't just by design/the way it works.
Fred wrote: other flags you will definitely have are

engine cycle sync (cop/seq/full sync)
engine revolution sync (wasted/semi/half sync)
per cylinder sync (dizzy/batch/min sync)

maybe something for "receiving engine position information" as that will be required for the fuel pump to be on.
After start enrichment
maybe flags for the non continuous transient enrichment types (map, tps), maybe
No docs on these that I've seen anywhere, I take it your musing and haven't done these yet....
Some yes, some no, they're documented in headers like everything else, and inserted in sp4 as agreed/stated in IRC discussions and commit logs.
Fred wrote: Serial port sniffing, any chance of regex style stuff rather than a fixed set? This would make sense for linux and windows, but would really come into its own on the mac where they have those weird names... mine differs from yours, perhaps you could include mine in the default set? :-) /dev/cu.usbserial-A1003NmB
Use the "Locate Port" button and follow the instructions. NOTE OS-X serial port usb drivers are notoriously buggy, and typically provide two devices, a .cu... an a .tty.... ususally one works, but Mtx has no way to know beforehand.
I have some general feedback on some of the behaviours of MTX including this. At some point I'll get around to documenting them for you.
Fred wrote: The binary stream log files would be better with time stamps of some sort on them, either US style year.mm.dd backward dates (for good sorting) or just a lowsy currentTimeInMillis() value or something. That way they wont get over written constantly. and you can pin them back to specific times.
Nope, then it breaks it from being a pure serial stream. Mtx's ascii datalogs (CSV/TSV) add in a high res counter (hr_clock) with usec resolution...
I was unclear, see bold section for correction, sorry!
Fred wrote: I don't like the MS style version/revision field names. The firmware version field isn't a signature, its a version, named and numbered and unique. The revision number and textual version ones are a combined thing not seperate and are the version of the interface not the firmware. 3000 firmwares could share an identical interface. It says "detected firmware: FreeEMS 0.0.0" which is wrong, you detected firmware "FreeEMS Vanilla 0.1.2 SNAPSHOT" using interface version "0.0.0 IFreeEMS Vanilla". though the format of the interface stuff is up in the air so dont spend too much/any time on it.
The problem is you did a BAD no-no. you stuffed in an integer and string together, which completely breaks string processing, as the 0's look like "nul's" to any string parsing functions and causes all sorts of problems. You didn't provide any direction as to what you wanted and now you piss and moan its not to your liking, sheesh!.
Yes, I know it sucks, and needs fixing. Instead of putting up with the bullshit, you could have said "can you temporarily remove the integers from this so I can parse it as a string like the firmware version because the zero bytes screw that up" and I'd probably have gone "yep, fine" as it needs major semantics change anyway. Or, maybe it doesn't after all the data service stuff. We'll see. Would you like that change now? If so, I'll happily do it. I don't want to do it and break you, though. Whatever you want, and it's only temporary anyway, but "just a string" is probably a longer term solution than the hack I had there before.
Fred wrote: I see that you query the location ID list as part of interrogation, nice! :-)

However, I can't hold my mouse over the text window with that stuff in it on the general tab without a HUGE popup tool tip thingy obscuring the view of near everything. Longer delay or ability to turn them off please? Maybe it exists? RTFM is an acceptable answer to anything here :-)
General tab, uncheck tooltips.
Thank you! :-)
Fred wrote: Hitting select all in the datalog caused a crash, then didn't and went slow, then just clicking a few caused a crash.
Can't replicate, u sure this is a datalog or the crappy logviewer? if logviewer, I don't care much as that'll be ripped out and replaced with something else soon enough. catch it with GDB on a debug-symbol build (./configure --enable-debug ; make clean ; make)
logviewer, I think! Sorry for being unclear again. I can still test for you if you want, otherwise we can forget about it for now? Possibly better to test as it could be wider than just the viewer?
Feedback is fine as long as it includes DEBUG TRACES (in case of crashes) along with context on how to duplicate the crash. (I did this, then this, then this and i can always make it crash here!) Constructive criticism is important and welcomed, even if it hurts my feelings. (i suggest doing X instead of Y and here's a good ass reason why), vs "This is wrong and thats wrong..."
That is what I try to do, I hope I succeeded.

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!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Dave's unofficial TODO list from his favorite nitpicker

Post by Fred »

Log viewer:

select all, no prob, close, no prob, lots of things appear but are unreadable (just too many) in the window, no prob, reopen chooser, try to deselect hr_clock, gdb trips:

Code: Select all

(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) n
Program not restarted.
(gdb) continue
Continuing.
Xlib:  extension "RANDR" missing on display "/tmp/launch-tHP5nz/org.x:0".
Reading symbols for shared libraries . done
Reading symbols for shared libraries .. done
Reading symbols for shared libraries . done
megatunix(1882,0x7fff707f4ca0) malloc: *** error for object 0x1020d0008: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted.
0x00007fff84201616 in __kill ()
(gdb) backtrace
#0  0x00007fff84201616 in __kill ()
#1  0x00007fff842a1cca in abort ()
#2  0x00007fff841b96f5 in free ()
#3  0x000000010002918a in populate_viewer () at logviewer_gui.c:429
#4  0x0000000100028c00 in view_value_set (widget=0x102990340, data=0x0) at logviewer_gui.c:307
#5  0x00000001010c48d2 in g_closure_invoke ()
#6  0x00000001010da23b in signal_emit_unlocked_R ()
#7  0x00000001010dbc64 in g_signal_emit_valist ()
#8  0x00000001010dc034 in g_signal_emit ()
#9  0x00000001006bf5d0 in gtk_toggle_button_clicked ()
#10 0x00000001010c48d2 in g_closure_invoke ()
#11 0x00000001010d9f0e in signal_emit_unlocked_R ()
#12 0x00000001010dbc64 in g_signal_emit_valist ()
#13 0x00000001010dc034 in g_signal_emit ()
#14 0x00000001006bf325 in gtk_toggle_button_released ()
#15 0x00000001010c48d2 in g_closure_invoke ()
#16 0x00000001010d9f0e in signal_emit_unlocked_R ()
#17 0x00000001010dbc64 in g_signal_emit_valist ()
#18 0x00000001010dc034 in g_signal_emit ()
#19 0x000000010054f215 in gtk_button_button_release ()
#20 0x00000001005feb1f in _gtk_marshal_BOOLEAN__BOXED ()
#21 0x00000001010c48d2 in g_closure_invoke ()
#22 0x00000001010da3bc in signal_emit_unlocked_R ()
#23 0x00000001010db936 in g_signal_emit_valist ()
#24 0x00000001010dc034 in g_signal_emit ()
#25 0x000000010071619e in gtk_widget_event_internal ()
#26 0x00000001005f7637 in gtk_propagate_event ()
#27 0x00000001005f8906 in gtk_main_do_event ()
#28 0x0000000100a10594 in gdk_event_dispatch ()
#29 0x00000001011478f9 in g_main_context_dispatch ()
#30 0x000000010114af91 in g_main_context_iterate ()
#31 0x000000010114b2a5 in g_main_loop_run ()
#32 0x00000001005f8ce0 in gtk_main ()
#33 0x000000010002e4cb in main (argc=1, argv=0x7fff5fbff940) at main.c:148
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!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Dave's unofficial TODO list from his favorite nitpicker

Post by Fred »

And the one you care about, which looks to be just as I suspected.

Code: Select all

(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Breakpoint 2 at 0x10002e008: file main.c, line 55.
Starting program: /usr/local/bin/megatunix 
Reading symbols for shared libraries .. done

Breakpoint 2, main (argc=1, argv=0x7fff5fbff940) at main.c:55
55		Serial_Params *serial_params = NULL;
(gdb) continue
Continuing.
Xlib:  extension "RANDR" missing on display "/tmp/launch-tHP5nz/org.x:0".

(megatunix:1889): Gtk-WARNING **: Unable to find default local directory monitor type

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x0000000000000000 in ?? ()
(gdb) backtrace
#0  0x0000000000000000 in ?? ()
#1  0x00000001000201a0 in prompt_to_save () at gui_handlers.c:1491
#2  0x000000010001c085 in leave (widget=0x1018c72d0, data=0x0) at gui_handlers.c:116
#3  0x00000001010c48d2 in g_closure_invoke ()
#4  0x00000001010da23b in signal_emit_unlocked_R ()
#5  0x00000001010dbc64 in g_signal_emit_valist ()
#6  0x00000001010dc034 in g_signal_emit ()
#7  0x0000000100719770 in gtk_widget_activate ()
#8  0x000000010060ce90 in gtk_menu_shell_activate_item ()
#9  0x000000010060e89d in gtk_menu_shell_button_release ()
#10 0x00000001005feb1f in _gtk_marshal_BOOLEAN__BOXED ()
#11 0x00000001010c48d2 in g_closure_invoke ()
#12 0x00000001010da3bc in signal_emit_unlocked_R ()
#13 0x00000001010db936 in g_signal_emit_valist ()
#14 0x00000001010dc034 in g_signal_emit ()
#15 0x000000010071619e in gtk_widget_event_internal ()
#16 0x00000001005f7637 in gtk_propagate_event ()
#17 0x00000001005f8906 in gtk_main_do_event ()
#18 0x0000000100a10594 in gdk_event_dispatch ()
#19 0x00000001011478f9 in g_main_context_dispatch ()
#20 0x000000010114af91 in g_main_context_iterate ()
#21 0x000000010114b2a5 in g_main_loop_run ()
#22 0x00000001005f8ce0 in gtk_main ()
#23 0x000000010002e4cb in main (argc=1, argv=0x7fff5fbff940) at main.c:148
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!
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: Dave's unofficial TODO list from his favorite nitpicker

Post by dandruczyk »

Fred wrote:
mtx_man wrote:
Fred wrote: Hard resets field doesn't seem to count resets, not those from the buttons which I verified do work, nor from the button on the device.
Need clock to be set it stone before i can set this up...
Why can't/don't you do it like MLV does it with just looking for sequential counters and read the SP5 var instead of the SP3 one. If var = last var+1 (and account for overflow somehow) sweet, otherwise count reset. In MLV it shows up as a red line from the log. Very simple, very effective. I don't even understand what you mean about clocks and set in stone ness. What has a clock got to do with resets?
A discrepancy in the clock is what mtx uses to know if a ecu reset has occurred, If the clock vari is goingto be moved around, I am NOT going to enable that until you get it fixed some some datalog variable. each time you move it I'd need to alter the RealtimeMap file, and I don't like playing "chase fred and his propensity to change things". I'd rather wait until that api has stabilized.
Fred wrote:
Fred wrote: If you want to display some of your existing MS bit flags/lights/etcs you could provide translated services from other data for them. EG warmup, if temp is lower than the part of the curve that has the minimum correction value then it's warming up. The firmware will never tell you "it's warming up" because that information is dynamic and irrelevant and controlled by a curve by the user and always applied as it applies to overheating situations to to cool the engine with a rich mixture.
Nope, not gonna happen, not going to put in a special case for this. warmup means ETE will be modified which means you have enough info to set a bit or not....
I don't think it's a good idea, which is why my sentence started with "If YOU want to". I will not insert code to set bits based on complex conditions that can be visually determined on an external system, of dealt with in that much-higher-resource environment. Again, to repeat, ETE var is *always* modified. It is not a "no, or yes and how much" it is ONLY a "how much" where how much can be 0 - lots. Thus no such bit exists. I agree with your not creating fake bits, but there will be quite a few bit fields that MS has that we won't just by design/the way it works.
I'm not going to put in one-off conditional checks. (IF X is > blah and y is less than barf an the moon is in the right position, and so on and so forth). Basically, in the FW if ETE is not zero, a "warmup" flag should be raised, if 0, then it should be withdrawn.. You can even go further and have different bits for WHY ETE is enabled. (i.e. CHT, CLT, MAT, IAT, not enough time since start, etc...) Having that in the tuning software means its a special case for each and every one, which is not going to happen. the ECU should tell the tuning software. "Hey I'm in warmup enrich", the tuning software SHOULD NOT have to infer and guess (with some arbritrary, prone to change as the firmware evolves conditions) "is it in warmup or not, I'm not sure...."
Fred wrote:
Fred wrote: other flags you will definitely have are

engine cycle sync (cop/seq/full sync)
engine revolution sync (wasted/semi/half sync)
per cylinder sync (dizzy/batch/min sync)

maybe something for "receiving engine position information" as that will be required for the fuel pump to be on.
After start enrichment
maybe flags for the non continuous transient enrichment types (map, tps), maybe
No docs on these that I've seen anywhere, I take it your musing and haven't done these yet....
Some yes, some no, they're documented in headers like everything else, and inserted in sp4 as agreed/stated in IRC discussions and commit logs.
Document it externally, or via doxygen. There should be a webpage documenting ALL INFO that the tuning software will need, without tuning software authors needing to go hand dig through headers and sourcecode to figure it out. i.e. ONE PLACE to go, updated preferrably on an automated fashion, so you don't need to be bothered with it.
Fred wrote:
Fred wrote: Serial port sniffing, any chance of regex style stuff rather than a fixed set? This would make sense for linux and windows, but would really come into its own on the mac where they have those weird names... mine differs from yours, perhaps you could include mine in the default set? :-) /dev/cu.usbserial-A1003NmB
Use the "Locate Port" button and follow the instructions. NOTE OS-X serial port usb drivers are notoriously buggy, and typically provide two devices, a .cu... an a .tty.... ususally one works, but Mtx has no way to know beforehand.
I have some general feedback on some of the behaviours of MTX including this. At some point I'll get around to documenting them for you.
Fred wrote: The binary stream log files would be better with time stamps of some sort on them, either US style year.mm.dd backward dates (for good sorting) or just a lowsy currentTimeInMillis() value or something. That way they wont get over written constantly. and you can pin them back to specific times.
Nope, then it breaks it from being a pure serial stream. Mtx's ascii datalogs (CSV/TSV) add in a high res counter (hr_clock) with usec resolution...
I was unclear, see bold section for correction, sorry!
The stream log files are the RAW input and output streams. I am NOT molesting them with additional information which will break their parsability via the tool you have as well as other tools in development.
Fred wrote:
Fred wrote: I don't like the MS style version/revision field names. The firmware version field isn't a signature, its a version, named and numbered and unique. The revision number and textual version ones are a combined thing not seperate and are the version of the interface not the firmware. 3000 firmwares could share an identical interface. It says "detected firmware: FreeEMS 0.0.0" which is wrong, you detected firmware "FreeEMS Vanilla 0.1.2 SNAPSHOT" using interface version "0.0.0 IFreeEMS Vanilla". though the format of the interface stuff is up in the air so dont spend too much/any time on it.
The problem is you did a BAD no-no. you stuffed in an integer and string together, which completely breaks string processing, as the 0's look like "nul's" to any string parsing functions and causes all sorts of problems. You didn't provide any direction as to what you wanted and now you piss and moan its not to your liking, sheesh!.
Yes, I know it sucks, and needs fixing. Instead of putting up with the [shizzle], you could have said "can you temporarily remove the integers from this so I can parse it as a string like the firmware version because the zero bytes screw that up" and I'd probably have gone "yep, fine" as it needs major semantics change anyway. Or, maybe it doesn't after all the data service stuff. We'll see. Would you like that change now? If so, I'll happily do it. I don't want to do it and break you, though. Whatever you want, and it's only temporary anyway, but "just a string" is probably a longer term solution than the hack I had there before.
I already worked around it, filling in the gui as I saw fit, You provided NO info as to how you want it to look in the gui. and the information on firmware and interface version is vague at best, and provides no information on the version number (i see its 3 levels but does describe why there are 3 levels and what the difference mean, i.e. 0.0.0 vs 0.0.1 vs 0.1.0 vs 1.0.0 and so on.
Fred wrote:
Fred wrote: I see that you query the location ID list as part of interrogation, nice! :-)

However, I can't hold my mouse over the text window with that stuff in it on the general tab without a HUGE popup tool tip thingy obscuring the view of near everything. Longer delay or ability to turn them off please? Maybe it exists? RTFM is an acceptable answer to anything here :-)
General tab, uncheck tooltips.
Thank you! :-)
Fred wrote: Hitting select all in the datalog caused a crash, then didn't and went slow, then just clicking a few caused a crash.
Can't replicate, u sure this is a datalog or the crappy logviewer? if logviewer, I don't care much as that'll be ripped out and replaced with something else soon enough. catch it with GDB on a debug-symbol build (./configure --enable-debug ; make clean ; make)
logviewer, I think! Sorry for being unclear again. I can still test for you if you want, otherwise we can forget about it for now? Possibly better to test as it could be wider than just the viewer?
Don't worry about the logviewer, its a steaming buggy POS to be replaced at some point when i can find some sanity and clarity..
Fred wrote:
Feedback is fine as long as it includes DEBUG TRACES (in case of crashes) along with context on how to duplicate the crash. (I did this, then this, then this and i can always make it crash here!) Constructive criticism is important and welcomed, even if it hurts my feelings. (i suggest doing X instead of Y and here's a good ass reason why), vs "This is wrong and thats wrong..."
That is what I try to do, I hope I succeeded.

Fred.
I don't see any debug traces....
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: Dave's unofficial TODO list from his favorite nitpicker

Post by dandruczyk »

Fred wrote:And the one you care about, which looks to be just as I suspected.

Code: Select all

(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Breakpoint 2 at 0x10002e008: file main.c, line 55.
Starting program: /usr/local/bin/megatunix 
Reading symbols for shared libraries .. done

Breakpoint 2, main (argc=1, argv=0x7fff5fbff940) at main.c:55
55		Serial_Params *serial_params = NULL;
(gdb) continue
Continuing.
Xlib:  extension "RANDR" missing on display "/tmp/launch-tHP5nz/org.x:0".

(megatunix:1889): Gtk-WARNING **: Unable to find default local directory monitor type

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x0000000000000000 in ?? ()
(gdb) backtrace
#0  0x0000000000000000 in ?? ()
#1  0x00000001000201a0 in prompt_to_save () at gui_handlers.c:1491
#2  0x000000010001c085 in leave (widget=0x1018c72d0, data=0x0) at gui_handlers.c:116
#3  0x00000001010c48d2 in g_closure_invoke ()
#4  0x00000001010da23b in signal_emit_unlocked_R ()
#5  0x00000001010dbc64 in g_signal_emit_valist ()
#6  0x00000001010dc034 in g_signal_emit ()
#7  0x0000000100719770 in gtk_widget_activate ()
#8  0x000000010060ce90 in gtk_menu_shell_activate_item ()
#9  0x000000010060e89d in gtk_menu_shell_button_release ()
#10 0x00000001005feb1f in _gtk_marshal_BOOLEAN__BOXED ()
#11 0x00000001010c48d2 in g_closure_invoke ()
#12 0x00000001010da3bc in signal_emit_unlocked_R ()
#13 0x00000001010db936 in g_signal_emit_valist ()
#14 0x00000001010dc034 in g_signal_emit ()
#15 0x000000010071619e in gtk_widget_event_internal ()
#16 0x00000001005f7637 in gtk_propagate_event ()
#17 0x00000001005f8906 in gtk_main_do_event ()
#18 0x0000000100a10594 in gdk_event_dispatch ()
#19 0x00000001011478f9 in g_main_context_dispatch ()
#20 0x000000010114af91 in g_main_context_iterate ()
#21 0x000000010114b2a5 in g_main_loop_run ()
#22 0x00000001005f8ce0 in gtk_main ()
#23 0x000000010002e4cb in main (argc=1, argv=0x7fff5fbff940) at main.c:148

there's no context leading up to this supposed crash, i.e. WHAT WERE YOU DOING??

"Unable to find default local directory monitor type" is an OS-X GTK warning that can be ignored. AFAIK its a bug in the toolkit and not in Mtx.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Dave's unofficial TODO list from his favorite nitpicker

Post by Fred »

Everything is working spiffingly, but I'd like to see some usability changes, copy/paste from IRC :

[17:21] <puma_numero_uno> djandruczyk: that mtx whinging is about to start :-) something i heard marcos complaining about too. incescant dialog boxes. particularly the "i've unplugged the cable" one, i fucking know in the first place, but ok, pop it up once, after that, leave it down as i already hit OK and I definitely know by now.
[17:22] <puma_numero_uno> what would be even better would be if it said "go offline" or "retry" or "just wait till i tell you to try again bastard" or "try periodically, and work when it connects and dont bother me again till then, or not even then"
[17:23] <puma_numero_uno> it'd be great to be able to turn off the exit ones too. "are you sure you want to quit" - yes, yes and never ask me again, no - should be the options there :-)
[17:23] == `CHR1S [~chris@c-71-206-192-128.hsd1.pa.comcast.net] has quit [Ping timeout: 250 seconds]
[17:24] <puma_numero_uno> and the saving stuff, the internal datalog one, i never asked for such a log, so either save it without teling me, or dont save it unless i ask you to,
[17:24] <puma_numero_uno> the last one is "do you want to save your settings" well, how about "yes, yes, and remember my decision, no, no and remember my decision"
[17:25] <puma_numero_uno> a few changes in those areas and you could keep the same functionality for those that like it, and the rest of us can ditch it in favour of faster use and less annoying popups
[17:25] <puma_numero_uno> disclaimer, this hasn't been well thought through, but there is some good stuff here, and I'm sure many others would agree with at least some of it, plus none of it removes the option to retain the same behaviour.
[17:25] <puma_numero_uno> posting all this to your thread :-)

Pretty please? :-)
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!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Dave's unofficial TODO list from his favorite nitpicker

Post by Fred »

When logging, and you send a hard reset, you get a bunch of all zero log entries, this could easily be a firmware thing, just all zero until something gets done, and you are asking N times before that, Thoughts? Probably my fault/issue/feature/design. I might work on that if it is, but could also be your requests getting ignored and you just filling out zeros? Just taking a stab in the dark on this one. Not a big deal no matter what anyway.

Dave, i get segfaults when its trying to interrogate sometimes. I haven't done a trace, no, but you can probably make it happen if you try enough? I had other things to say too, like how do i make it always choose freeems (or ms2 for the vast majority of users) and just try that straight away when launching without asking? And can we get the "save internal data" to not seg fault and just exit even if it doesnt save? And logs end up empty if you remove the device out from under mtx before you close them. I noticed more stuff, but it's late, and I just sorted out the decoder stuff and need to pack my things. So no further detail at this time.

Also, something to think about, when you do a hard reset, you end up with heaps of streamed packets flying at you which you had previously turned off. Just a thought.

Keen for:

Stability, usability, faster logging/stream logging, in that order, if you care what i want, which you probably don't really :-)

I'll start wanting other things sometime after sunday, but I understand how busy you are, so...

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!
Post Reply