Spare IO And Aux Functionality UIs

[Fred]

Thanks Dan, I appreciate the moral support.

Sim, you made me ROFL a lot with that post. Some of it is off-target, but some of it is exactly what I was thinking. Great post, top marks! :-)

More detailed reply to everyone after everyone that I want to see in here has said something!

Fred.

[sim]

Thanks Dan, I appreciate the moral support.

Sim, you made me ROFL a lot with that post. Some of it is off-target, but some of it is exactly what I was thinking. Great post, top marks!

More detailed reply to everyone after everyone that I want to see in here has said something!

Fred.

Thanks Fred, I tried to keep the jokes to the footnotes...

Re-reading in the light of day, I think the pseudo-code is not
quite right. For this kind of application, I think it would be
best to base a DSL around the scheduler and an event model. The
pseudo-code should look more like this:

Code: Select all

eFan = PT5
eFan_high = PT6
KnockSense = PK3

set eFan PWM
set eFan_high GPIO_out
set KnockSense GPIO_in

# 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,
    )

    # Switch on high speed relay when CHT reaches 125 degrees.
    if CHT hysteresis(low 120, high 125) {
        pin eFan_high on
        log "High speed fan engaged"
    } else {
        pin eFan_high off
        log "High speed fan disengaged"
    }

    # Switch on dashboard overheat lamp when CHT exceeds 130
    # degrees.
    if CHT hysteresis(low 128, high 130) {
        pin CANBUS.DASH.OHL on
        log "Dash overheat light on"
    } else {
        pin CANBUS.DASH.OHL off
    }
}

# Log CHT every 10 seconds if over 130 degrees.
schedule absolute 10000ms {
    if CHT > 130 {
        log "OVERHEAT! ", CHT
    }
}


# Retard timing on knock
# KnockSense pulls output low on knock.
on pin KnockSense low {
    ignition.trim.trim_this_cell(-5)
    log "Knock detected, timing retarded on cell: ", ignition.this_cell_name
}

In a case like this, verbosity and simplicity is best. We can
expect that tuners, who may not also be programmers, will need to
use and modify the code. It is a little like SQL in that respect,
however I'd strongly recommend avoiding CAPITALIZED KEYWORDS.


sim (Has disabled capslock on his keyboard)

[Fred]

For many years my capslock was control! :-) I use it from time to time, now, though.

This is where you were a bit off target. All this spare IO stuff will not be at build time, if it was, it'd be childs play to set it up with macros and header trickery. It will be built once and configured via a UI of some sort from a tuning app and it will function beautifully. I don't see it as taking years to complete. I'm just starting now with this thread to milk everyone for their vast array of knowledge. Then I'll let it soak in for several weeks while I do more important things and eventually start designing it on paper, then code it, then iteratively improve it, etc.

Fred.

[Fred]

Thanks Fred, I tried to keep the jokes to the footnotes...

BTW, you had me confused as hell about [4] for a while there! :-) I could NOT find it in the body of the post... ;-)

[jharvey]

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

I just posted this article, I though you might find it interesting. viewtopic.php?f=35&t=1334

Also OpenServo might be a handy reference for PID with a low cost AVR controller. It's not hugely expensive if you buy the one from spark fun. http://www.sparkfun.com/products/9014

Any how, I thought I'd mention it in case you hadn't already come across it. Hope your PID controller works out. Enjoy.

[sim]

For many years my capslock was control! I use it from time to time, now, though.

This is where you were a bit off target. All this spare IO stuff will not be at build time, if it was, it'd be childs play to set it up with macros and header trickery. It will be built once and configured via a UI of some sort from a tuning app and it will function beautifully. I don't see it as taking years to complete. I'm just starting now with this thread to milk everyone for their vast array of knowledge. Then I'll let it soak in for several weeks while I do more important things and eventually start designing it on paper, then code it, then iteratively improve it, etc.

Fred.

Heh, capslock just serves to confuse and anger vi users.
I do miss it if I have to edit lots of SQL.


I suppose I must have not stated my idea clearly enough.

The configuration language I propose is completely separate from
the firmware, except that the firmware effectively 'runs' the
configuration.

The firmware exposes an API for all of the parameters of its
operation. All of the pins, including access to their
configuration, are available.

The EMS high level configuration is coded in a specific language
that models the EMS. Ideally, it is a Turing complete language.

If it's unreasonable to expect the EMS to interpret a configuration
language at run time, a client program on a tuning laptop can
be used to byte compile the config source into something that can
run on the EMS. The EMS scheduler is essentially a virtual machine.

At boot, the config code is loaded, and it connects event handlers
to function pointers, and populates data with constants or
running values saved from prior engine runs.

While the engine is running, the config code also runs. The
scheduler calls functions at appropriate times, data is updated,
etc. For instance in the pseudo-code I posted, at "program load"
time, a function pointer gets inserted into some scheduler table
that causes a list of EMS "instructions" (run PID algo, check if
the engine is in an overheat situation, etc) to run.

Changing the config is simply loading new code. The EMS behaves
like a virtual machine that the config code runs on.

preludelinux was on the right track talking about iptables as
that is essentially a domain specific language, be it a baroque
and somewhat ad-hoc language.

The configuration systems for many things are best expressed as
languages. Exim and Sendmail both have what amount to languages as
configuration systems.

If your problem domain is very complex, and you know that your
users will eventually want to try just about every possible way
of hooking stuff up, one of the best things you can do is design
for maximum complexity. Using a language as an interface is a
pretty good way to manage complexity.

This configuration language can be generated by a tuning app,
just like FrontPage can generate HTML from a WYSIWYG editor. The
real power though is that you can hand edit the code, or even
create a configuration from scratch in a text editor.

I hope I'm making sense, I'm talking a bit above my pay grade
here.

[Fred]

You're making perfect sense. Now my question is, what *exactly* is your API to the VM? Or, what is the language specification? It seems to me that that is the meat in the sandwich for your idea. I like the principle of it, however I'm unsure of the practicality in implementation in C inside our hardware and, as you pointed out, dev time frames. Bring out the details! :-)

[AbeFM]

Ok, I haven't read the thread yet, I'm not caught up. But I keep sending Fred stuff via IM because I don't want to lose a thought.

So forgive me if this is off-topic or already been covered, here's a few thoughts I've been having:

Yeah - the idea now is... examine the range of things you might WANT to control and make sure your interface will allow you to do it.

shift lights. That has to be temp and load dependent. Possibly even two-stage.


Here's a question. Simple, but still. Is everything you need to know about the car contained in the ECU itself? Can ANYONE'S laptop connect and get what's going on?
It'd be nice to put some space aside for things like human-readable-names. I'm not sure how much space we're taking up, but if it says "Car Freshener Scent Dispenser" and "Active Low" and whatnot, then you don't need to have a matched file... The FreeEMS will be software-independent. You could talk to the thing over a serial terminal and still know what everything is and why.

With MegaSquirt too often I find myself looking at someone's car and having to open the box to check the wiring to figure out what's really going on. (Without broaching the Evil Topic of input polarity... The idea that you never have to open the box to figure out why the car does what it does is good to me.

I enjoy soldering - but having to do it to see why the fans are coming on is inane. The hardware, once built, should never do anything but just work. And labeling stuff in human readable names will help. So many hours have been wasted writing down charts of the 4 different names for the same pin in MS you could have finished this project 3 times over.

I'll think a bit more on the shift lights and over temps... And I'd like to see if there's some way to do a bit more - to have commonality with other things. Instead of "turn on pin 7 when engine temp is over XXX and RPM is under YYY", I want to say "Do ZZZ when engine temp is over XXX and RPM is under YYY", where ZZZ might be a soft rev limit or richening the mixture. The idea being it's not just outputs... It's control.

Is that too far fetched? I don't like the MS version of all these stand alone little "modules" for controlling each feature. Perhaps from a software standpoint it's desirable.

[Fred]

Re:

Is everything you need to know about the car contained in the ECU itself?

That is off-topic and independent of the ideas that we need to be throwing around in this thread. No further talk of that in this thread please. Let's stay focussed.

I'll think a bit more on the shift lights and over temps... And I'd like to see if there's some way to do a bit more - to have commonality with other things. Instead of "turn on pin 7 when engine temp is over XXX and RPM is under YYY", I want to say "Do ZZZ when engine temp is over XXX and RPM is under YYY", where ZZZ might be a soft rev limit or richening the mixture. The idea being it's not just outputs... It's control.

Is that too far fetched?

No, I think it's exactly what we're aiming for! We're all just using different language to say it. There is someone who is going to add a LOT of value to this thread yet to post, possibly more than one. I'm holding out for and looking forward to those posts too.

I don't like the MS version of all these stand alone little "modules" for controlling each feature. Perhaps from a software standpoint it's desirable.

It depends on the feature. For some features special code will be required, but for many many features, it's just a bunch of basic logic and common functionality blocks. For such things GPIO interface design is the answer. You nailed it with:

examine the range of things you might WANT to control and make sure your interface will allow you to do it.

What's not covered by such things requires more complex and specific logic that would be too error prone or confusing to do with generic code and is better just done as a module.

Fred.

[sim]

You're making perfect sense. Now my question is, what *exactly* is your API to the VM? Or, what is the language specification? It seems to me that that is the meat in the sandwich for your idea. I like the principle of it, however I'm unsure of the practicality in implementation in C inside our hardware and, as you pointed out, dev time frames. Bring out the details!

Okay, let me try to sketch out a specification here.

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.
• Input/Output:
  • Physical CPU pins.
  • More abstract IO, such as CANbus messages, SPI, etc.
  • A means to configure the pins/CANbus devices/etc.
  • Communication with attached laptop/tuning software.
  • Logging.
  • Reading and writing to flash.
• 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.
• Library Functions:
  The common stuff everyone will need to do should be baked in
  to the language. Stuff like fuel calculations, generic PID
  controllers, etc. Even things like flat-shift and launch
  control can be exposed here, however these types of features
  can be implemented *in* the config language.
  
  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).

As for the language itself, it needs to be small, and easy to
parse, while also being clear and easy to use. Ideally, you
should be able to send a hunk of code to the EMS and it will run
it, modifying its running state right away.

Some language requirements:

• First class functions.
  Functions will be created and passed to the scheduler all
  the time. First class functions are needed to make this
  simple and elegant.
  
  First class functions also make modifications easier. You
  can swap out a function dynamically. Or wrap an existing
  function in another that modifies the behavior without
  reimplementing the older routine. Maybe you want to start
  water injection before retarding the timing, just wrap the
  knock retard function with something that adds water first.
• An object model.
  To keep the namespace clean, if nothing else.
  For instance: io.adc.AN06.value rather than leaving
  all the pin variables strewn around causing trouble.
  
  With first class functions and a decent object model, code
  could be written in OO style. The language should remain
  flexible though, it should be possible to write in a more
  functional style.
• Synchronization.
  With the xgate processing interrupts, it is important that
  data access is safe. As much as possible, this should happen
  behind the scenes. This will likely be tricky, so it is
  important that it is an initial design goal.
  
  Ideally, end users should not have to be concerned about
  concurrency and managing locks. A language that is more to
  the functional end of the spectrum can help with this.
  
  The existing code copies the pin values after reading them
  to ensure that the code has a consistent (if not absolutely
  up to date) set of values. This sort of low level stuff
  stays in the VM.
• Error handling.
  Some kind of exception framework needs to exist. Errors
  should be trappable so that if something is wrong in a
  subsystem, that part of the code should have a chance to
  deal with it.
  
  An exception in a boost control routine should result in
  boost control being disabled (at the lowest level) and a log
  message produced, but the engine should continue to run.
  
  A well written routine will contain sanity checks and
  contingency code, the language must provide the tools to do
  this robustly.
• Introspection.
  The interpreter should be able to access as much of its
  internal state as is possible. A third party module (like a
  flat-shift routine, for example) should be able to ascertain
  things like the firmware version, names assigned to pins,
  a list of other modules installed, etc.
  
  AbeFM touches on this in his post. This is what the "name"
  keyword in my (very rough) pseudo-code is getting at; "what
  does this pin do?". If you could get the value of
  io.adc.AN06.name you could save a whole lot of
  headache.
• A live console.
  This is more of a nice-to-have, but is a powerful tool.
  Combined with introspection, a live shell is a very
  useful debugging tool.
  
  Something like PostgreSQL's psql utility would be amazing.
• Good sanity checking in the virtual machine.
  One of the big features of a little language is that it
  "gives you enough rope to hang yourself". A side effect of
  being given the power to configure your system completely is
  the potential to really screw things up.
  
  Given that an EMS is typically installed in some kind of
  vehicle, screw ups can do real damage to an engine, and
  damaged engines can result in wrecks.
  
  The system should be built to be robust, where possible. If
  you want to write code that runs your advance way past the
  detonation threshold, well, that's your problem, but if the
  CHT sensor says that the engine is overheated, the EMS
  should shut it down (or do something, at least).
• A means to combine source files.
  A source file should deal with a single issue, when
  possible. If done right, much of the high level
  functionality of the EMS can be written in the config
  language. This fairly static code should live apart from
  end-user config and extra modules.
  
  It sounds obvious, but it takes some thought to get right.

In broad strokes, this is what I believe needs to be exposed by
the EMS, and what the shape of the configuration language should
be.

I've read a lot of books, but I've never built anything quite
like this before. There are a few books on my shelf that I would
like to have another read of before sketching out my ideas of
what an appropriate language would be.

There is a lot of potential in a plan like this, but the design
has to be good, otherwise it just becomes a huge mess.