FreeEMS firmware feature wishlist! (out of date)

[Russianblue]

again, not sure what all is on tap and don't how this could be done, but it would be very cool to have the display be able to output to the auxilliary inputs of a standard in-dash DVD. even cooler would be able to use the touchscreen capaiblity of a Pioneer or Alpine unit like this one below in order to control the ECU, make changes etc. Eliminates the need for proprietary displays and all the custom mounting and bother that goes along with it.

[Fred]

I agree, RTC required for that, however, possibly on an external chip, not sure yet.

[thebigmacd]

again, not sure what all is on tap and don't how this could be done, but it would be very cool to have the display be able to output to the auxilliary inputs of a standard in-dash DVD. even cooler would be able to use the touchscreen capaiblity of a Pioneer or Alpine unit like this one below in order to control the ECU, make changes etc. Eliminates the need for proprietary displays and all the custom mounting and bother that goes along with it.

Yes this would be great. If it is not feasible, my Parallax shipment just came in and I am beginning development of a Propeller-based "gauge controller" that is VGA/NTSC/PAL capable.

[Fred]

The last post referred to your log post.

All tuning devices should interface with the EMS through the same well defined serial interface. That way it is modular and simple for all concerned.

Whether you can tune on an alpine or cell phone or ipod etc is down to the skill of the coder on that platform and hardware interface required between them.

Fred.

[AbeFM]

RTC? Wazzat?

I DO want to see something, it's kinda a nice thing, but expensive computationally - constant logging, at a decent speed of stuff, into some high speed internal ring buffer. Then, on events you specify (conditions such as knock events, user pressing a button, etc) it will give you some time period up to the button press plus some time period after, ideally of higher resolution data than you would normally log.

Also, when it comes to idiot lights:
Ford has a really awesome guage on some of it's diesels (so I've read), it takes coolant temperature and coolant pressure, to give you a 'coolant health' guage. Coolant at 220 degrees and 10 psi guage is fine, coolant at 250 degrees and 15 psi is also fine, but getting warm (swing the needle up some). But 220 degrees and 0 psi is BAD so you want the needle in the yellow, 240 and 2 psi is boiling for sure and you want it in the red.

There are other schemes you could come out with, but my basic ideal is a 'health guage'. Much like I'd like an AFR-error guage. Something that looks at my 'target', and gives me an idea of how far off. I don't mind idling at 17:1, cruising at 16:1. 13.5:1 is rich at low pressure and lean at 2 bar.
What I'm saying is I want a few analog outs that are proportional to a small matrix of conditions. In the case above, I don't need a BAD WRONG guage for being off a bit at idle, but a small error would be good. But being at 15:1 under boost I want the guage in the red. Something like (AFR_actual - AFR_target)*(MAP) = guage out


And the picture of the GPS reminded me of another, totally unrelated idea I had last night. I want a GPS that has a mark on the road your on, 1/4 mile away from you at all times. Press a button, and that mark freezes, and a timer starts. Ideally, with an animated starting tree.

[GartnerProspect]

LOL.

RTC = Real Time Clock

I like the rolling "black box" log function. But I have a feeling that's going to need to be done in external (to the main MCU...) hardware.

What I'd like to do with my car is run a LCD gauge cluster, to be hooked up to the ECU always, which would afford me the luxury of doing most of what you envision on PC hardware rather than within the ECU. Unfortunately, I don't see most people doing that.

[Fred]

I like the rolling "black box" log function. But I have a feeling that's going to need to be done in external (to the main MCU...) hardware.

Yeah, quite right. What we really want is efficient configurable logging. If you choose two vars, it is lightening, if you choose 50 vars, it is reasonable. ETC. either way, this sort of thing probably has to be done outside the EMS for memory and speed reasons.

[AbeFM]

Well, the question is: Is the primary load on the ECU in actually loging the numbers (bothering to check them, and stuff them somewhere) or is it in coms overhead to some extrenal device/uart? My idea was a small internal buffer, so you could switch from general recording (as much info as possible) to high speed detailed info when you have some reason to.

I really want an LCD cluster. The problem is that I have too many guages for MS. Things like speedo and fuel level, so then I'd need a PC to take some info from the MS, some from the car, and then combine them in some software I would write and... And then sticking with what I got seems like a pretty good idea.

[Fred]

With regards the burn stumble issue :

Apparently our chip has something to stop that happening, BUT, I haven't looked into it just yet. At all.

OK, there are techniques to ensure that the code runs and runs properly while burning flash. On involves not burning the block you are running from. That seems appropriate, esp if we can use global addressing in our code!

Links :
http://forums.freescale.com/freescale/b ... ad.id=5603
http://forums.freescale.com/freescale/b ... 08904#M302

Fred.

[thebigmacd]

Support of MAF and speed-density at the same time. It *could* be trivial to continuously fine-tune the VE table while running off the MAF, then if the MAF fails one could switch over to use the VE table in limp-home mode. Snatching this idea from older GM ecus.