Marcos' development comments!

Marcos Chaparro's GPL C++/QT tuning application, now supports FreeEMS too!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Marcos' development comments!

Post by Fred »

Yippee, I get to be first :-)

I pulled it down, installed a couple of things, and built it last night :

Image

It took bang on 5 minutes to build, and started up just fine.

There are a couple if issues and comments I have, some of them will be obvious, some you may disagree with, take them or leave them :
  1. That little bit of console error output seen in the terminal in the screen shot what does it mean?
  2. The weird characters/not characters around the 3d table, what are those supposed to be?
  3. It doesn't fit on my EEE's screen!
  4. The gui isn't scalable and the current fixed size limits you to proper laptops
  5. Displaying all that stuff in one window at once seems a bit much
  6. In "data acquisition" i clicked "qviewer" and got a colour picker dialog, that popped up 6 or more times after hitting cancel! cancel should = cancel IMO
  7. If you're planning to support multiple ECU's (Yours, FreeEMS, PIS, MS? etc) then you should probably have some sort of profile loading where it doesn't do or show much till you tell it what you're connected to. Scrub that, I see this in the configuration thing. It just needs more work, and to show appropriate menus for each one, etc. Cool cool.
  8. Are my fonts shit? what does it use? what do I need to install?
  9. FreeEMS menu items do nothing, apparently, ditto pinout in help.
  10. quicktune in tools also doesn't fit on my screen
  11. user interface and security tabs in config have nothing in them
  12. replay gave me a dialog where I chose a log file from data examples and got the following "cannot open file, unknown error" but when i tried to reproduce it, it worked and replayed stuff.
  13. the graph in the top right corner has no label, what is it? put a label on it?
  14. view menu "std arrange" brings up a nitrous control menu, bad naming there!
  15. in your firmware, you seem to have a fixed injector dead time value, that is a pretty extreme compromise, but maybe required on your hardware? MegaSquirt uses a slope too, to create a line correction, but the correct approach is a curve. Consider adding that?
  16. Choosing timing in edit, fuel, causes a segfault. i took a screeny http://stuff.fredcooke.com/ECUmanager.f ... gfault.png , but when i reproduced it, there was none of the other output, so I guess that happened while doing other stuff first.
  17. edit, ignition, ignition table also segfaults
  18. same nitrous menu appears to be available from the edit menu as from the other random place
  19. boost control menu option does nothing
  20. PWM1 and PWM2 also bring up nitrous - is it some kind of accidental default?
  21. open ecu and connect ecu both bring up the ttyusb0 not found error as above somewhere (clearly whatever i did above triggers one of these actions (without asking the user!)) but, connect even though it fails, gets greyed out and disconnect becomes an option. that shouldn't happen. after i hit disconnect, open is greyed out!
  22. firmware upgrade does nothing.
Gasp, that ought to keep you busy!! :-) Breakfast time for me. Now, some of the above could easily be down to my libs and the fact I'm running deb unstable. Just tell me what to upgrade and I'll give it a shot. I also didn't follow your instructions when installing stuff:

Code: Select all

apt-get install qt4-qmake
apt-get install libqt4-dev
Could I be missing something?

Could my gl drivers be broken causing the dodgy stuff on screen and the output in the terminal?

Good to see this underway.

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
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: Marcos' development comments!

Post by nitrousnrg »

yep, those are many of the bad things about ECUmanager.
That little bit of console error output seen in the terminal in the screen shot what does it mean?
The weird characters/not characters around the 3d table, what are those supposed to be?
* both 1 and 2 appeared after an upgrade in my system too. I still don't consider it important, there are critical bugs to fix first. Maybe using a newer version of qwtplot3d the problem may disappear.
It doesn't fit on my EEE's screen!
The gui isn't scalable and the current fixed size limits you to proper laptops
Displaying all that stuff in one window at once seems a bit much
*3, 4, 5, 14: I realized that when I compiled it on a desktop machine... I think it is in the TODO, "a more flexible gui". The idea is to select wich compenents the user want to see, to have a customizable data viewer. Not easy to do, but it worths the effort. I think I saw a qt app that did something like that.
That was going to be the function of View menu ;-)
In "data acquisition" i clicked "qviewer" and got a colour picker dialog, that popped up 6 or more times after hitting cancel! cancel should = cancel IMO
*6 thats because the config file is empty, all the colors are saved in ~/.config/MyEnterprise/ECU manager.conf -I'm gonna change that name right now!-
Providing defaults colors built-in it'll be fixed.
If you're planning to support multiple ECU's (Yours, FreeEMS, PIS, MS? etc) then you should probably have some sort of profile loading where it doesn't do or show much till you tell it what you're connected to. Scrub that, I see this in the configuration thing. It just needs more work, and to show appropriate menus for each one, etc. Cool cool.
*7 Yep, I have to make massive changes to make it flexible enough to support multiple EMS. The communications are mostly solved, it uses another thread dedicated to the comms, i'd like to make it more like a fontend (universal GUI) talking to a backend (device specific). The GUI is what i have to change, for example, the table headers can't be changed.
Are my fonts [shizzle] what does it use? what do I need to install?
*8, no idea what are you talking abut

Most of the unimplemented menus do nothing or open the nitrous thing, I did it just to don't forget to write that code (boost ctrl, pwm, etc), but that development goes along with the microcontroller code. I must grey those instead of connecting random things.

Another huge usabilty problem is that it needs to be connected to the EMS to do some things -like playbacks-. Here, I use /dev/ttyUSB0 to connect mine, it is configurable in Tools->configure manager/communications

As you can see, its a little worse than "rough in the edges", but everything is fixable. The only thing in which I have no clue is about compiling the 3d surface under windows.

Thanks for your huge support Fred :-)
Marcos
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Marcos' development comments!

Post by Fred »

Good work :-)

Another issue :

Now the qviewer comes up, and i can resize it. If i resize it very small, it goes into an infinite loop.

http://stuff.fredcooke.com/infiniteLoop.ECUmanager.png

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!
cpuTorture
TO220 - Visibile
Posts: 5
Joined: Tue Apr 20, 2010 5:23 pm

Re: Marcos' development comments!

Post by cpuTorture »

Hi,
Sorry that I missed you on IRC Marco. I was away. Firstly glad to see the software that you have made. It was easy to compile and get going (thanks Fred for the pointer to the pre-reqs) I liked that the interface performs quickly, using a grid style control is a good idea.

I was just having a play with the interface and choose tools->quick tune. Left mouse button down with pointer to the left side of the top graph and dragging with mouse down off the right hand side seems to cause a segfault here. To track this down I turned debugging on, which by default at this stage of your development might be a good idea for ease of tracking such problems.

here is a backtrace of the fault:
QTableWidget: cannot insert an item that is already owned by another QTableWidget

Program received signal SIGSEGV, Segmentation fault.
0x0806ef34 in QTableWidgetItem::setTextAlignment (this=0x8235b50, channel=0, index=12) at /usr/include/qt4/QtGui/qtablewidget.h:138
138 { setData(Qt::TextAlignmentRole, alignment); }
(gdb) bt
#0 0x0806ef34 in QTableWidgetItem::setTextAlignment (this=0x8235b50, channel=0, index=12) at /usr/include/qt4/QtGui/qtablewidget.h:138
#1 qt4application::QuickTuneChange (this=0x8235b50, channel=0, index=12) at qt4applicationEXTRAS.cpp:135
#2 0x080b616b in qt4application::qt_metacall (this=0x8235b50, _c=QMetaObject::InvokeMetaMethod, _id=30, _a=0xbfffe434) at moc_qt4application.cpp:155
#3 0x00f1ac9a in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4
#4 0x00f293d5 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4
#5 0x080b7a6b in QuickTune::QTuneChange (this=0x84a3020, _t1=0, _t2=12) at moc_QuickTune.cpp:91
#6 0x080a4ce0 in QuickTune::MAPvalueChanged (this=0x84a3020, index=12) at QuickTune.cpp:65
#7 0x080b7b1c in QuickTune::qt_metacall (this=0x84a3020, _c=QMetaObject::InvokeMetaMethod, _id=28, _a=0xbfffe588) at moc_QuickTune.cpp:78
#8 0x00f1ac9a in QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) () from /usr/lib/libQtCore.so.4
#9 0x00f293d5 in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4
#10 0x080b6905 in graph2D::valueChanged (this=0x848a0d0, _t1=12) at moc_2Dgraph.cpp:84
#11 0x08064357 in graph2D::mouseMoveEvent (this=0x848a0d0, event=0xbfffeb50) at 2Dgraph.cpp:159
#12 0x004c469a in QWidget::event(QEvent*) () from /usr/lib/libQtGui.so.4
#13 0x004664dc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#14 0x0046d9f7 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#15 0x00f15a3b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4
#16 0x0046c952 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) () from /usr/lib/libQtGui.so.4
#17 0x004f8088 in ?? () from /usr/lib/libQtGui.so.4
#18 0x004f7511 in QApplication::x11ProcessEvent(_XEvent*) () from /usr/lib/libQtGui.so.4
#19 0x0052660a in ?? () from /usr/lib/libQtGui.so.4
#20 0x02b1e5e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#21 0x02b222d8 in ?? () from /lib/libglib-2.0.so.0
#22 0x02b224b8 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#23 0x00f415d5 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#24 0x00526135 in ?? () from /usr/lib/libQtGui.so.4
#25 0x00f14059 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#26 0x00f144aa in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#27 0x00f1869f in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#28 0x00466577 in QApplication::exec() () from /usr/lib/libQtGui.so.4
#29 0x0805d597 in main (argc=1, argv=0xbffff494) at main.cpp:35


Regards
Jay
User avatar
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: Marcos' development comments!

Post by nitrousnrg »

Hi Jay, Fred

Both bugs are fixed, you can resize main window and Qviewer window; and quicktune doesn't hang the app anymore.

Thanks for your bug hunting!
Marcos
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Marcos' development comments!

Post by Fred »

Marcos, congrats on talking to FreeEMS for the first time tonight! :-) I was very excited to see it working!!

http://stuff.fredcooke.com/ECUManagerTa ... stTime.png

And HD video : http://www.youtube.com/watch?v=qZ6mAtnTFXE

Awesome work! I look forward to more! :-)

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: Marcos' development comments!

Post by Fred »

Awesome work moving the libs into /lib, whoever suggested that must have been a legend ;-)

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
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: Marcos' development comments!

Post by nitrousnrg »

Awesome work moving the libs into /lib, whoever suggested that must have been a legend ;-)
LOL
Indeed, the guy is giving me some pretty good advices.

Btw, last commits include the binary, even when I explicitly put bin/ECUmanager in .gitignore.... Watch that out, if it doesn't disappear in my next commit, help me :-)

Thanks Fred!
Marcos
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Marcos' development comments!

Post by Fred »

Ingles lesson:

"good advice" it's singular because advice is not discreet and is continuous :-) IE, a lot of advice is still one chunk of advice even if its on lots of stuff, etc.

Not sure about your bin/ECUManager. If you committed it before the .gitignore then that oculd be the issue... with a clean tree, try git rm bin/ECUManager; git commit

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
nitrousnrg
LQFP144 - On Top Of The Game
Posts: 468
Joined: Tue Jun 24, 2008 5:31 pm

Re: Marcos' development comments!

Post by nitrousnrg »

Ingles lesson:

"good advice" it's singular because advice is not discreet and is continuous :-) IE, a lot of advice is still one chunk of advice even if its on lots of stuff, etc.
So advice means "consejo", as well as "consejos".
Ack :-)
try git rm bin/ECUManager; git commit
Okay, i'll try it later. Not sure what do you mean by "clean tree"...

The app is calculating checksums, so it should be able to send some packets. firmwareRequest, will be the first one to be implemented, then other requests, and finally block memory writings. Let me know if you disagree, you are the firmware guy ;-)
Marcos
Post Reply