Spare IO And Aux Functionality UIs

[Costa]

Except for MS, the only other ECU I've used is an e420c from Adaptronic.

The configuration software for the e420c ECU is called WARI. You can get a copy to play with, from the web site.

For outputs you first selected the output number. The text in the pull down list tells you the current limit and if they are PWM capable.

Then you choose what the output type. For type RPM we can then set high and low values for the hysteresis. Note PWM check box greyed out because its not available for output 6. Also, the "configure" button is greyed out because there are no other configurations for selected type.

Continued next post.

[Costa]

from previous post.

When you select a standard type like "Fuel Pump" the configure button becomes available.

Pressing "Configure" takes you to the "Special function" page where you can configure these standard functions.

Selecting Inputs is similar the the Aux Out selection. First choose the input number than select the type. Standard types such as the Enrich/retard function are also configured on the "Special function" page, as shown above.

CA

[AbeFM]

Silly long post. Perhaps I should divide it up. This silly forum doesn't do multi-quote so sorry, I did everything in Notepad.

The spare IO memory region will likely have a validator handler like other memory regions have. IE, it won't be possible to misconfigure it. You'll get an error back when you try to save it. It should be straight forward for the UI to prevent you from having the same value assigned to two features, or having the wrong type of pin assigned to a feature, etc. The firmware should reject such configuration outright and not let you save it.

This would be at the UI level, clearly the EMS wouldn't have to do this... But it would be nice to know which combinations are ok. I mean, if I know it could go on any of these three pins, I'd like to know what things are currently on those pins so I can look at reassigning them.

If you want input about how to configure the configurable pins, you should provide a list of pins that can and can't be configured.

I'm not sure I 100% agree with this. Seeing how you'd handle configuring things in the different situations may guide what's worth leaving configurable and what isn't. Ovbiously if it turns out one or two single pins are not configurable, they would just disappear from the framework - without changing the overall approach, nor does it invalidate any work we put in at this early stage.

Examples of inputs to use for rules.
rpm
tps
...
internal temp of ecu
knock event
based on spare input
speed of car , of individual wheel , of rate of steering
...
voltage / amperage
etc ( im sure i left some out )

Ah! The crux of the matter. As I mentioned in my earlier post: You should be able to select "spare" inputs, but also know what they are. So "Pin 79" "equal/more/less/etc" "Value".... But knowing what that function is without having to go to a log-book somewhere to find out.. Would make it very useful!

My question is: Would you define these pins here, or in some stand alone place for DEFINING GPIO? My feeling is yes: You set up pins (in a similar fashion, something telling you what must be banked or not banked, etc). Then in the output configurator you're only setting logic - not what the pins are.
Obviously that implies checks that the datatypes are compatible or at least cast-able.

Code: Select all

# Electric fan control.
# PID controlled, run once a second.
schedule absolute 1000ms {
    name "PID PWM fan control"
    controller pid (
        input CHT,
        output eFan,
        proportional_term fan_control_params.P,
        integral_term fan_control_params.I,
        derivative_term fan_control_params.D,
        setpoint 100,
        active_above 80,
    )

I think this would have to be a bit different - to make it useful. Clearly PID control is going to be something we write in generic terms. Perhaps that's just what you're doing, how you define a function. And it's good to have that stuff under the hood.

But for getting people to run their car... You need to imagine a GUI with appropriate blanks so you CAN auto-generate all this. I agree wholeheartedly on the pointers thing (the root of my unending misundertandings of engine position sensor trigger edge polarity stems from this. As I see it, you just tell it "always use the ____ edge/number/routine" and it uses it, without being slow).

There has to be an acceptance of the fact that not everyone has the same skillset. I know plenty of very talented tuners/designers who can't handle a line of code to save their life. For this to be something anyone can plug into their car and get working, it needs to have a GUI - and figuring out the way to get that GUI to couple to the underlying hardware is the challenge we're all setting ourselves here. Hence my suggestions for defining pins and inputs and outputs... Then setting up fan control would be a simple matter of picking "upper temp, limit 1, limit 2, action case 1, action case 2" as well as "P,I,D, etc"....

Ah, perhaps fred caputred this more succinctly. Still, the idea is to define a 'super case', a few classes of things you want to do. Will it be limiting? Sure. But 1) it's a start, and 2) It'll capture most of what we want.

Basically, you have to work from the assumption that you need to provide enough flexiblity for what is likely to be used - but that people who want to go crazy will write their own code! We're not going to cover EVERY case, and there's no reason to try. Let's put up examples like you did, then figure out how we'd do those.


Basically, if some new CLASS of outputs/behaviors comes up, someone writes another option, with it's logic. Example:

Inputs: (some pull downs)
Cases? (integer)

Case 1:
Control Type: Boolean/PID/????
Conditions: (names - pull downs)
Levels: (Some blanks)
Action Type: (pull down - Digital Output, 1-D PWM output, 2-D PWM, adjust system variable, add line to log)

Case 2:
Condition Type: Boolean/PID/????
....

... case n

If you picked PWM, you'd get a display with a number of ouputs. Basically if you come up with some new set of conditions/realtions... you'd write a new handler. But they shold all be in the same place and work the same way - so you don't end up with MS thing of a bunch of handlers for specific tasks. Basically, look at all of those, and figure out the 5 or 6 classes that they actually have, and write a generic handler for it. So all things handle N variables, you pick how many and move on - instead of having a 2 variable routine an a 3 variable routine and a 5, but no 4 cause no one ever needed it.

Does that even make sense?

Ah, Sim's later post seems to be MUCH closer to what I was thinking...

The EMS will need to expose the following:

Data:
Tables. Fuel and Ignition, enrichments, etc. as well as
generic tables that can be created and used for any purpose.
Tables that the EMS will always have should just exist and be
useable with no initialization.

Traditional variables.

Something that can be used to create objects, or at least
structs.

This almost seems like it would go in the pin definitions place I was talking about earlier. You would define variables - which don't have to have physical relations to anything. Those would need updating/servicing? Once they are created, your IO page could use them - but it's better than defining them in place.

The Scheduler:
Time based events.

Angle based events.

Action based events, eg: a pin goes high. This can be done
by polling using either time or angle based scheduling,
but it would simplify things greatly for the end user if
an abstract way to
poll pins of interest in the background existed. It could probably
be done more efficiently than a bunch of different poll
functions sprinkled into the scheduler. The VM could just
run through a linked list of function pointers once a
cycle rather than scheduling a bunch of different pin (or
event) handlers.

Again, this is something where... You'd need to define it elsewhere. It's a condition. Such and such variable (either angle, time since ____), and in your IO window, you'd say if that is more than/less than/etc. This way you can cleanly concentrate on defining all this elsewhere. Doing it all at once will make a mess for both the UI and wasted information, generating the same variable so many times.

Basically, we need to be streamlined enough that we can only ask for so much before it's worth writing a stand-alone function.

It would be good if there was a way to add to the library (so
an end user could just add a package to get new features).

+1, and the branch could be merged into the main code if it works well.

As for the language itself, it needs to be small, and easy to
parse, while also being clear and easy to use.

Still think this is not only overkill, it won't run well - or at least brings less practical advantage over a well thought out and implimented GUI.

A good GUI lets you both enforce rules and quickly set up ten things. Be fair, you can configure an MS in like 5 minutes. Can you write code, even psuedo code, in a day to do the same? Maybe. Barely. And you'd have to debug it. Why take a performance hit for that 1 in a hundred people? Should be be avaiable? It is. In the source code for the whole project. If you need it, have at it, it's there.

Except for MS, the only other ECU I've used is an e420c from Adaptronic.

The configuration software for the e420c ECU is called WARI. You can get a copy to play with, from the web site.

For outputs you first selected the output number. The text in the pull down list tells you the current limit and if they are PWM capable.

That looks awesome! Of course, you'd STILL need the pin definition page because the hardware is specific to the build. Hopefully the software is broadly applicable. We don't have control over the hardware. So you could use that, but you HAVE to tell it somewhere what you have. For instance, MY inputs will likely be a different format than most people's VR inputs as I have a circuit I like. I might also put (as an example) a giant 20 amp relay on it, or a 10 kv power supply for a display. Just silly stuff to show you might customize that.

I do like the summary list! I imagine some 2-D windows/graphs as in MS. That would work for variable fan speeds or any non-PID control.


I'm not as sure I like the "Configure" tab as it is very limiting! You can only do what they have there - i.e. one output for fuel pump, etc etc. A generic handler would cover a LOT more people. Say you have 16 sequentially opperated fuel pumps. Mine would work great - just define those pins' names, then say "16 outputs", set the values and you're done. It works.
If it can be virtualized/programmed by you shiny happy people, I'd be honored to use it.

[Fred]

Great post, Abe! I've read it all, and it's made me think about a few things.

I like the configure IO first thing, and it somehow needs to be integrated with the injector/ign pin usage stuff too. With that in mind, I DO and WILL be doing config checking at send to ECU time. So when you send the core engine config chunk in for burning it will check the GPIO stuff and refuse if there is something configured on one of the core pins. Then you can go back and fix the core thing first, and then retry (and succeed) at sending the core engine settings again. Or vice versa.

There are two concepts to handle pin wise:

what a port is capable of and setup as
what a pin is setup as

some of those things are related, obviously. Perhaps some sort of inheritance.

From a UI perspective, though, it might be possible to just display a huge list of free pins, and then choose one and have the GUI app setup the IO behind that for you.

Features, either generic or specific, will have a set of prerequisits, perhaps one input digital pin, one analogue input pin and one PWM output pin for XYZ feature. To enable that you'll have to fulfil its pin requests before you can configure it. Same can work for simpler stuff.

While we're here. I'd like to have it such that ANY pin can be PWMed, just by software in a crappier way. That way you don't have to waste GOOD 16 bit or 8 bit HW PWM on stuff that doesn't matter.

Perhaps it would make sense to handle the generic stuff as N generic logic blocks and have M components to each block. It's all going to be flash only, so there is a lot of space to just go and store lots of information. As long as its not hard coded and we can figure out an interface from UI to interpretter/code then we're good.

If we aim for the ultimate in flexibility we can only fall short and make it awesome instead of perfect :-)

BTW, I agree with Abe re the UI vs language thing. I think the language posts have some great content in them, though, and a lot of it is applicable to a UI approach too.

Lots to think about here.

In terms of data in and data out, inputs should be just that, inputs. They should record their information somewhere in the device that is accessible to the other functionality. Thinking about that a second longer, an analogue or digital input pin has its value always readable right in the registers and can be used directly where necessary. Or, they could be buffered such that off meant on, and vice versa, and the output of that transformation was applied to the feature/logic.

Which makes me think about inputs vs logging.

Right now we have a bunch of generic unsigned shorts available to put whatever you want into, via code. This UI/I should probably include a way to tell a variable or input to be logged, and where.

In some cases there are relationships between these different "aspects" but in others there aren't.

The logging could be more generic, and I know how, right now :-) We can have the core logging up front and ALWAYS present with a variable area of custom logging after it which gets populated based on configuration from this stuff. Additionally, we can trim that log to get a higher frequency and only send what we're populating. On top of that, we can have a scratch pad log style that is purely what the user asks for. And this thread has been the inspiration on how to do that. I've been thinking about that for a while.

Great stuff!

One more thing:

We're not going to cover EVERY case, and there's no reason to try.

I think we can all think of a project that did try, and I think I can emphatically say that there is EVERY reason to NOT try :-)

We're missing posts from JD, Cam, XR, and a few others. Once those roll in I might try to summarise the entire thing into a new thread.

Keep it coming, people! :-)

Fred.

[Fred]

A couple of things come to mind here, re MTX:

We need the ability to only burn/send X and not the entire device memory. Not having that is a pretty serious limitation when you consider the interdependencies of this stuff and the fact that you could get a partial write in before being told to get lost due to something later conflicting with somethign earlier. You could end up in the situation where you have to manually undo your UI changes before you can get it to write, which would suck.

Customly configurable logging seems like a winner, and can be done with simple tools and a viewer app, but it would be nice to have MTX handle it too. I guess there is quite a bit of rework required to handle something like that. So that can be a "much later" thing, but it kinda needs to be there. It could work on the basis that when you enable XYZ logging type, you read the configuration for it from flash first (or assume what you already have from app start and interogation/data load is correct) and use that info to parse the incoming stream that you just enabled.

OK, enough from me. Off to bug the missing people :-)

Fred.