Future Tuning Software Architectural Wish List (lower level)

Free Open Source Software project discussion forum. Post your Free Open Source software projects here!
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: Future Tuning Software Architectural Wish List (lower level)

Post by dandruczyk »

Fred wrote:Before I start, I'd like to say this : We want to keep as much stuff out of the ECU as possible while retaining as much information inside the ECU as possible. What I mean by that is that if it can be done in the tuning tool, it should be done in the tuning tool unless that impacts functionality on the ECU side in a negative way. This keeps max resources available for doing real things.
mtx_man wrote:If the ECU can provide INFO to the tuning SW regarding ports and capabilities. I can make it work.
The ECU should certainly tell you what the current state of the table looks like.
i.e. lets say a command to retrieve the list of "global" pins, capabilities, module,module_pin

Rough idea of returned data:
uint16,uint32,uint16,uint16, uchar[16]
global_pin,capabilities_mask,module_num,mod_pin, global_pin_name
Yes, something just like this. I have to question the value of using up space on the chip to store names for the pins though. The tuning tool is already going to need to know about all the variables and how to access them etc etc, what is a simple 1:1 table of index:name going to hurt? It seems to me, not much?
The ECU should be able to interrogate all devices on all busses to generate that table.
Much like I'm not a fan of autotune and AMC and EGO correction, I don't think something like this should be automated. I think it should be setup explicitly. Such external devices will be strictly for advanced users anyway, so I don't see there being a need to make it overly simple for them at the expense of extra code and complexity on the ECU side.
This allows for 65535 "global" pins, 32 possible capabilities per pin, 65535 possible modules, 65535 max "pins" per module.
Sure, in terms of index it does, but the table on the ECU will have to have a finite limit of slots anyway, and at the end of the day, there are only so many features to pass off to external devices before you don't even have to drive the car anymore :-) A reasonable table size might be 256 entries? that's between 2 and 3 times the chips pin count which is already 3x the ms2's pin count. I think that should be fairly sufficient. We aren't trying to be a MOTEC here :-) In any case, the table size will be determined by a particular version anyway as some might not have room for such a large one with all the extra features they want to add in etc.
If the ECU has engouh RAM,FLASH it would be ideal to be able to set that table in the code with an additional textual field, allowing the pin to be named from the tuning SW side, thus if anotehr tunig sw loads it it can present that info to the user. IT's nicer than having a hardcoded table with all of the supposedly "thoguht up possibilities" with a bucnh of generic_1, generic_2 and so on's.
True, and there may be, certainly it doesn't need to be nailed down now. User assigned names could be stored in the tuning tools config pretty easily too. Switching tuning tools is a fairly significant thing anyway, and setup of pinouts is something you only do at initial setup or when you make a change to the system. Not something you reference each time you crack open the tool like VE or Advance. I'm tending to look at it like this though :

In terms of a pin, you only care about A what it is hooked up to externally which you need the Freescale name for B what it can do which the bitmask tells you. Calling it "pwm boost" when if you have pwm boost assigned to it, you should be able to display that without having it explicitly named to that seems frivolous to me.
Thus the tuning SW can run a command to get the table, and then present the data however is needed (i.e. sort by capability, then by pin number, or textual name, etc. Thus allowing the user to define new pins in the appropriate groups and assigning names to then for easier reference. In terms of using those pins, we'd have towork out a way to genericize the I/O in the firmware to make it modular so things aren't as "hardcoded" as they are now. i.e defien a mask of "used pins" and create various prioritized handlers for each active pin. (some handlers are more intensiv,e i.e. pwm vs simple digital I/O ), not sure how crazy u wana go wit hthe firmware though as this can be rather tricky todo and make it run as u want.
Yeah, I can see it being tricky for sure. It will definitely require a lot of thought to implement.

The more we discuss it, the closer to knowing how to do it we will get though :-)

Thank you for your input! Very much appreciated.

Fred.

I am trying to aim for by having the textual names stored in the ECU to prevent the tuning software from needing to have FIRMWARE SPECIFIC extraneous config files that will get out of control esp as submodules are added. By storeing that info inside the cpu (serial EEProm anyone?) all the tuning SW has to do is ask for it from the ecu, instead fo download a list of numbers and compare to a local file that may be incomplete.

my ideas up above for 65536 ports was a "high estimate"m, nad 256 is better. also the 32 bits of capability flags coule be easily knocked to 16 bits. but I prefer to not require the tuning SW to have a special ioport config file to be required based on the firmware version on the ecu. (this is similar to the MT msq's being dependant on the specifc megatune .ini which is a bad idea in my opinion.)
Post Reply