Spare IO And Aux Functionality UIs

[Fred]

Hello All!

I know there are a few of you here with extensive experience on different platforms using the various tuning software out there. What I want to know is how do they let you choose and configure your spare IO and other generically configurable things. I know motec let you just use random tables with random axis scales to attach to various algorithms. What do the others use? I was inspired by looking at this page about Jean's IO board, it also inspired me to never want to see another jumper again in my life, however for some things, jumpers are necessary, more or less.

I don't just want to know about the awesome ones, I want to know about the mediocre ones and the shit ones too. I want to come to understand spare IO in a way that no one else does and then implement something resembling the ultimate spare IO interface. It'll be needed to some extent fairly soon too, so the timing of this thread is good!

Screen shots earn you bonus points! :-)

Fred.

[dandruczyk]

<wild dream mode>

define classes of pins:
1. low current (1 amp or less) on/off
2. low current (1 amp or less) PWM
3. high current (>1 amp) on/off
4 high current (> 1amp) PWM
5. high precision logic (timing sensitive, i.e. ignition/injection/other)
6. high precision high current (same conditions as #5)

Then define sources
Table (i.e. 1D:pwm percentage based on temperature, 2D pwm percentage based on rpm and load)
State of one or more variables i.e. ((X is > Y) && (A <= B))
Combination of the above

How to accomplish this and provide a usable interface? No idea whatsoever right now
</wild dream mode>

It would help to have some constraints. i.e. how many spare pins are we talking about, what sort of features are planned? i.e. just simple on/off, pwm, high precision?


I would also suggest allowing the capability of DIGITAL inputs (input compare) for things like VSS (vehicle speed), and ABS sensors, as well as PWM andfrequency based sensors (Ford MAF/MAP sensors of various years come to mind). digital inputs like this eliminate a lot of ground issues compared to analog signals, as the data is encoded in either the frequency/pulsewidth or dutycycle, all of which should be measurable/configurable for inputs.

[BenFenner]

Sadly I don't have as much experience with this as I should. Mainly because I'm not really ever "adding" things and either make due with what I'm given, or fear adding as too complicated.

This is my experience with auxiliary outputs. Sorry, no auxiliary input experience yet.

With AEM EMS Series 1, the radiator fan(s) are treated as an auxiliary output as not every car has electrical fans. The auxiliary output configuration window consists of two tabs. The main output tab, and the secondary function tab.



Output - Corresponds to a physical pin on the ECU plug.
Name - I guess you can make a more descriptive name for the pin to make things human readable?
Basic Activation - If the active box is checked, the output is active according to the configuration in this window. What you see is what you get. You cannot add more variables to the list. You get Coolant, Load, RPM, TPS, and Road Spd options only. "Less Than" and "At Least" can be toggled on each. Value can obviously be changed to whatever you wish.
Switched Output Configure - When activated, not only do the conditions above need to be met, but this condition needs to be met as well. This is usually an electrical input on an ECU pin.
Functions - These are even more conditions that need to be met for the output to be applied. (See function tab.) Common situations are provided for such as Radiator Fan high/low temp range as seen in the screen shot. Choosing the VTEC function allows more complicated conditions such as Fuel Added, Ignition Offset, load windows, rpm windows, TPS windows and vehicle speed windows. Other functions provide similarly relevant options.

Keep in mind AEM has a dedicated section for ON/OFF variable valve technologies, boost solenoid control, and nitrous control so you don't have to go to the auxiliary outputs until you're adding secondary fuel pumps, water/meth injection, or other special things.

As for auxiliary inputs... I'm not familiar enough with that to speak on it just yet.

[preludelinux]

Have all outputs highly configurable based on any input you can hook up to the ecu and use many to base rules off of. ( i need to stop thinking about iptables right now )

Examples of inputs to use for rules.

• rpm
  tps
  boost / nos
  iat
  cht
  internal temp of ecu
  knock event
  based on spare input
  oil pressure
  power steering pressure
  speed of car , of individual wheel , of rate of steering
  voltage / amperage
  etc ( im sure i left some out )

Example of configurable outputs.

• Fans
  light
  variable valve timing ( may not get pin assignment but gets configs )
  i believe some awd or lsd systems can be changed on the fly and some power steering systems ~
  Turn off things that dont need to be running
  Gas mileage estimate ( would be neat to do )
  etc

Exmple of configurable inputs

• MAF
  secondary wideband or narrorband

[jharvey]

I seem to recall that most of preludelinux list is on Fred's non configurable list. Last I looked at it, I seem to recall we have a very limited set of items that Fred plans to allow to have some form of configuration.

Please list the non configurable, and potential/common configurable IO, I found your pin out to be confusing.

[preludelinux]

A quick status page showing all pin configuration. Refuses to map pin already in use or prompts user that if you select this pin feature X will be without a pin / disabled. Also would be nice to show pin assignment in drop down menus or not even show assigned pins.

[Fred]

I seem to recall that most of preludelinux list is on Fred's non configurable list. Last I looked at it, I seem to recall we have a very limited set of items that Fred plans to allow to have some form of configuration.

The opposite is true! What are you smoking? I want some! :-)

Core pins are fixed, and used for core functions first, available for other things if not being used for core functions.

All pins are capable of GPIO on/off type behaviour.
Up to 8 pins are capable of PWM use, 4@16bit, 8@8bit, or some combination of those sets.
On a typical setup, perhaps 70 or so spare IO pins of various types will be available.

Various functionalities will be available and have pin feature requirements. PWM idle or PWM boost will require a PWM pin. Vtech or fans will require a GPIO pin. Fancy boost control will require an extra map sensor input called IAP on some random ADC pin. Nitrous might require a user enable input that will therefore require a digital input pin. ETC.

Ben's post has some useful stuff in it, as does Jean's page, and I'm certain there is more good info from others who are yet to post on it's way to us soon.

From Baldur:

[21:12] <@TekniQue> the way that makes the most sense is to have an outputs configurator
[21:13] <@TekniQue> where you can pick a pin and select a function it supports for outputs
[21:13] <@TekniQue> that way there are no conflicts
[21:20] <@TekniQue> or rather
[21:21] <@TekniQue> just have it one fat list of available input/output functions
[21:21] <@TekniQue> where entering each one gets you a dropdown or a dialog showing all the pins that are compatible with that function
[21:21] <@TekniQue> and showing ones not already assigned in colour
[21:22] <@TekniQue> and in the main list, show the functions that have invalid assignations (double assignations) in colour also
[21:50] <@djandruczyk> that sounds interesting
[21:57] <@TekniQue> well, I think it's a good idea to have all of that stuff configurable in one place
[21:57] <@TekniQue> so you don't have to hunt around to see if anything is configured to a pin
[21:58] <@TekniQue> or what pin the launch control is wired to

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.

Some good info there, thanks! :-)

Fred.

[jharvey]

I seem to recall that most of preludelinux list is on Fred's non configurable list. Last I looked at it, I seem to recall we have a very limited set of items that Fred plans to allow to have some form of configuration.

The opposite is true! What are you smoking? I want some!

Core pins are fixed, and used for core functions first, available for other things if not being used for core functions.

"Core" being the operative word not found in XDP512-freeEMS-pin-assignment.ods

Column Q notes AN0 to AN15 like this, "All these yellow ones are swap able to suit board layout needs at the designers whim." However in this thread viewtopic.php?f=60&t=333&p=17630& you miss quote yourself when you claim they aren't swap able and that it notes they "could" be swap able.

I participial like how in the same post, you claim TPS is required, and optional. That's some Fred gold right there.

I'm not sure what to make of your actions, they certainly aren't clear, or easy to work with. 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.

[sim]

All the possible auxiliary functions that an EMS can be put to,
and all the pin choices available, and all of the pin and IO modes
(ADC, digital in, digital out, PWM out, CANbus in/out, etc.) and
all of the possible algorithm choices to control them amount to a
combinatorical explosion.

This complexity is, I believe, a big factor in the mess that MS
appears to have become. Organic growth, and gradually accruing
features make for a complex, nasty, and incomplete means of
configuring the EMS.

This problem is something that I have been mulling over for some
time. I believe the solution to the problem of configuring a
custom EMS is a small Domain Specific Language[0].

A well designed DSL would maximize the expressive power available
to specify the configuration of a custom EMS. A GUI interface
cannot even come close, though simpler user interfaces could be
built on top of it, and the underlying language would overcome
any shortcomings of the UI if access to the code that the UI
creates is kept open.

Let me quote Greenspun's Tenth Rule of Programming:
"Any sufficiently complicated C or Fortran program contains an
ad-hoc, informally-specified, bug-ridden, slow implementation of
half of CommonLisp."[1]. Let's take care of this one explicitly.

Ultimately, whatever scheme[2] is chosen to allow configuration
of non-core functions, the pins will have to be abstracted, the
parameters will have to be abstracted, and the algorithms will
have to be abstracted. Better to do this explicitly, at the
outset, and have a clean API for hooking shit up.

In the case of an EMS, obviously the overhead of interpreting a
DSL will be too high[3]. On the other hand, a compiled language
can run almost as fast as hard coded values and logic, and
possibly run even faster than a spaghetti mess of rules and
configurable constants. This compilation could occur in the
tuning software[5] to simplify the firmware.

Another advantage is the ability to make some parameters
generically dynamic, for instance, set up a PID loop in such a
way that it gets its P, I and D constants (and the cut-off value
and cut-on, etc) from a pointer, rather than a hard coded value,
or one that is set once in the tuning software. That way a
function can run from time to time to auto-tune the PID
constants[6]. PID constants, or other constants, could also
easily be modified for situations like cold-start, or overheat,
etc.

How would it work? Simply an ASCII stream run through a compiler
that does the backend magic.

Example:

Code: Select all

# Dynamic variables for the eFan PWM PID controller.
object fan_control_params (
    integer P
    integer I
    integer D
)

# Electric Fan control
for pin PT5 (
    name "PID PWM fan control"
    schedule absolute 1000ms         # Run once a second.
    input CHT
    controller pid(fan_control_params.P, fan_control_params.I, fan_control_params.D, setpoint=100)
   
    #Less to more important.
    if input under 80 (
        output off
    )
    if input hysteresis 120 125 (
        output on 100%
        pin PT6 on                  # GPIO High speed fan relay 
    )
    if input over 130 (
        pin CANBUS.DASH.OHL on      # On dash overheat lamp
    )
    if input under 128 (
        pin CANBUS.DASH.OHL off     # On dash overheat lamp off
)

[7]

For a User Interface, this kind of output is trivial to produce
for known sensor/set-up combinations. In the event that the
desired configuration is outside the considerations of a GUI (for
example, the CANBUS.DASH.OHL overheat lamp above) manual
editing of the config code makes modifications trivial.

Fred, I'm not suggesting that this is what you need to build. To
me[8], this seems like a masters level dissertation in computer
science. I'd expect it to take a competent programmer six months
to get right[9]. That said, if this kind of design becomes the
ultimate goal, the abstractions required can be built into the
code in a way that it can fairly easily become a virtual machine
for future bytecode. Think to the future. Much of this stuff can
be handled in the present with #defines and constants. So long as
you operate on a memory address, rather than a value, you can use
a compiled DSL to specify and initially populate the value at
that address. I think the MCU has the grunt to handle at least
that much indirection. Think about looking up functions in a table
also.

Respectfully,
sim

[0] Postscript is a Domain Specific Language. So is LOGO, and
BBcode.
[1] http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming
(For the record, I'm not a Lisper, I may not be smart enough.)
[2] Pun intended.
[3] At least, for now. At some point in the future we can assume
a processor will become available that is fast enough and
cheap enough to control an engine with code written in Visual
Basic[4].
[4] Aiiieeee! Run!
[5] Probably a library, or an external console based program.
[6] Other stuff that we haven't even thought of yet also
becomes possible, possibly even easy.
[7] Consider this a quick sketch of how it might work. I have not
given much thought to the syntax of such a DSL.
Missing is the semantics of how the constants P,I and D are
populated.
[8] I am not qualified to estimate at this level.
[9] Given a lotto win, I'd love to spend six (or twelve) months
on this problem, given reality, it will be a few years before
that is possible.

A PID controlled PWM eFan is one of my pet projects, can you
tell? Water pump is next.

[Dan]

I seem to recall we have a very limited set of items that Fred plans to allow to have some form of configuration.

"Core" being the operative word not found in XDP512-freeEMS-pin-assignment.ods

That's some Fred gold right there. I'm not sure what to make of your actions, they certainly aren't clear, or easy to work with.

Dude, seriously, if you want to talk dribble and whinge and moan then maybe this is not the forum for you. It is clear that you are personally attacking people (namely Fred) on here and I dont find this very constructive at all.

In fact, it has been a fucking waste of my time reading your garbage lately.

Carrying on like a little school girl instead of continuing to contribute in a constructive manner (I know you can as you have before) doesnt do you any favours.

You are intelligent and know your stuff, but you cannot continue to rave on about things that you cant let go of. Please continue to contribute in a constructive manner as you often do and leave the shit stirring and being a smartass for other places on the internet.