Mantis - ISSUES

0000063: People still using MegaSquirt

Please fix ASAP

0000103: Improve UI for realtime data

Currently it is hard to scan across a row and see the relevant value for a variable...

Also the white column is a bit hideous

0000104: Add datalog sample rate display

datalog packets/second

0000076: Add ability to cell by cell tune tables to memory dump tab

This one should be pretty easy too :-)

You'll need to source the location id from the same drop down.

Then you need three numeric text entry fields :

RPM index
Load index
Value

The three new packet types are :

/* Main table manipulation */
#define adjustMainTableCell 100
#define adjustMainTableRPMAxis 102
#define adjustMainTableLoadAxis 104

The first one has 8 bytes of payload in the form of 4 unsigned shorts.

location id, rpm index, load index, cell value

The second is :

location id, rpm index, rpm value

And the third :

location id, load index, load value

This will form the foundation of tuning into the future :-)

Should be easy as pie to do as well :-) Mean while Aaron can fix those bugs ;-)

0000079: Real time vars display for basic datalog packet

create a tab with name and value pairs of fields in fixed locations. The values can be updated by a back ground process that reads fresh data, and the names will be static from code or config at start up.

Something like the temp and resistance fields here :

http://i260.photobucket.com/albums/ii15/diyefi/FreeTherm/RealScreenShot.png [^]

Only name on left and value on right might be better?

0000098: Protocol Unit Test Framework

Old bugs are coming back, and it's getting hard to test specific packets/combinations.

We need some sort of test framework where binary strings can be supplied and the apps output can be compared to what is expected.

Also the possibility of speed testing.

0000058: Yellow Reset Button

I would like to be able to reset the device into the firmware out of the serial monitor.

Discussion on the forum required. Will update with more info when that occurs.

0000067: Scroll Events Ignored In Main Tab

As the title says :-) I scroll, it doesn't move.

0000046: Debug Message Console

Parse debug packets and create something to display them sequentially perhaps with a time stamp, one per line. Dumping to the console the app is running from is acceptable too. Or both configurable.

0000060: Serial Comms Funnies Cause Hard Freeze

A while ago I noticed that I could connect both cute comm and this to the serial port at the same time. This is unusual in itself and probably related as most apps lock the device for exclusive use by default. Today I had cutecom listening and tuner talking which was fine. Then I disconnected cutecom and sent another packet and it locked up solid using lots of cpu.

0000062: Port Control Screen And Packets

Obviously I need to write the firmware side for this too, but it would be immensely useful to be able to configure the IO from a dedicated tab in the GUI.

I think the format should be:

send (full state for all pins)
receive (full state for all pins)

At start up the GUI should query the device to find out the current state. Or perhaps it could be on a user config basis?

The tab in question will need a sub section for each port and a set of columns or rows or check boxs for the bits in each control register. There should be some sort of LED indicator for each pin to show the actual state received after the update is made. I guess it should be sent on a per click/adjustment basis in real time. There could/should be another LED saying that the state of the pin and the settings don't match.

This will be enormously useful in understanding the hardware better as it will enable me to test various theories without soldering new stuff up.

You won't be able to do much with it until I provide the details or what you should be able to control and how the packets should look, but have a think about it. it might be a case of just writing large blocks of registers with memcpy on my end, or maybe i will need to be more explicit.

This is a good task for me on the train so look for some results later this week. This of course relies on the comms reception working properly, so that takes priority for sure.

I've been working on the pin out stuff tonight, but it is tough going. it would be nice if I could configure things on the fly to test out some theories.

This type of packet could be used to implement various control strategies on the PC side where it is easier to write complex code and then migrate them to the firmware when well tested and debuged. Stuff like PID idle and what have you could all start life on the PC side using this interface.

In the long term it could be a very valuable debug tool when there are hardware and wiring issues etc. Well worth doing in my opinion. Quite easy too bar laying out the gui.

0000059: Create Interrogation Routine

http://www.diyefi.org/forum/viewtopic.php?f=43&t=500 [^]

The program needs to be able to determine what it is connecting to and not corrupt the SM or a MS if they are present. It also needs to be able to determine which versions of each are present on the far end of the cable and load the appropriate code for them at that time.

0000057: Full Screen Mode For Use On Small Screens

It would be nice if it could do a true full screen mode and claim every pixel for itself. This would be most useful on a little screen like the EEE which a lot of people may use to tune with.

Just a thought :-) You did say to put it all in here.

0000056: Give It the DIYEFI Logo :-)

Here is the .ico file for the website, gimp can turn it into a png or whatever you want.

http://www.diyefi.org/favicon.ico [^]

I just realised that it has no display icon and in the EEE it comes up with the ugly red X logo as default.

No big deal, perhaps you want your own logo there, or the FreeEMS one when Rob designs it :-)

http://i260.photobucket.com/albums/ii15/diyefi/FreeEMS-Tuner/stillBadOnEEE.png [^]

0000055: Good Default Min Sizes For Components And Windows

Certain things like columns and what have you should have appropriate default and min sizes to display cleanly. You shouldn't be able to make the window size smaller than those figures, at least not without a scroll bar.

I think it should default to cleanly displaying all the components visibly.

Feel free to reject if you disagree :-)

I'm just trying to get to a place where I just git pull and make no adjustments each time I run it... could save me a few seconds here and there :-)

Screeny : http://i260.photobucket.com/albums/ii15/diyefi/FreeEMS-Tuner/stillBadOnEEE.png [^]

0000051: Investigate And Maybe Create A Parser For MTX Gauge Definitions

Open source means leveraging other peoples work :-)

It would be really cool/nice if we could use the same gauge definitions as MTX uses and therefore the designer that comes with it too. It may be that this is not practical at all, however it is a very nice feature and compatibility with them would be good to have :-)

See the latest MTX for examples and code on how they are used internal to that app.

0000050: Datalog Parsing Based On Config

Soon datalog packets will be available for parsing and displaying. This is core functionality to the tuning app. The data sent in the complex log will be configurable on the EMS side. The basic structure will be something like :

* A meta mask - where each bit indicates that a block of data is sent or not sent
* Sub masks - where each bit indicates that a particular field is sent or not

Which byte/short/long gets parsed into which internal value for display and logging is dependent on these masks.

Additionally, the user may want the ability to further filter these into a subset log for easier viewing and lower storage space while retaining a full log elsewhere, this is just a wild idea though :-)

I think the datalog files should be MS/MLV compatible for easy up front tooling. Later we can create an app to parse our logs (and ms ones) ourselves at which point the format *could* be changed.

Reliant on this parsing is general display of these values in bar graphs and on gauges.

0000047: Error Code To Description Config/Mapping And Display

When an error code is received the number should be used to look up a description string to display in a dialog or console of some sort. Internal counters that display how many of each type are recorded would be good too.

0000044: Make It Version Aware

Make it query the interface version to choose which config to use/code to run etc and query the firmware version to be able to display it for the user. These are key to multi version support and a good user experience.

0000037: Ability To Select From Multiple Serial Devices

A menu selection for the serial device to use would be a nice low priority feature to have.

0000035: Document protocol plugin interface

Please please.

Part of this will also be GUI element dependencies

0000034: Document comms plugin interface

Please please :)

0000033: Document coding conventions

Document please, probably base it on the python coding standards

0000022: The Ability To Load New Firmware

It might be nice in the future for the same gui to support upgrades as well.

See http://freeems.aaronb.info/tracker/view.php?id=21 [^] for more info.

Additional nice things an integrated version *could* do are move settings between releases in an automated or semi automated way.

Things that could move quite safely between releases (probably) include :

Main tuning tables
Thermistor tables

Definitely low priority on this, but something to think about :-)

0000064: Allow Option To Not Blow Away Log On Restart

It would be nice if the history was a bit longer than the 15 seconds since the last launch ;-)

Either rotating logs or just append and append with maybe a shutdown line to break it up or something?

Your call :-)