FreeEMS firmware feature wishlist! (out of date)

Official FreeEMS vanilla firmware development, the heart and soul of the system!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeEMS firmware feature wishlist (your suggestions here!)

Post by Fred »

Nice ideas, thanks for taking the time to explain, it would definitely be worth implementing some of those at a later date once the basics are more complete :-)

I'll keep it in mind as I push the init code around and around :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: Pin out research thread - comments

Post by jharvey »

MotoFab wrote:lost program watchdog timer reset': Loosely described as filling each line in the unused portion of the program code space with a call to an endless loop somewhere.
I've also seen the unused space filled with a jump command sending it to a chunk of debug code. That way when you jump in the weeds for who know why, the debug code captures what data it can, trying to capute enought data so you can debug. Then does a manual reset.

Any how, that's for a bit later I think. Probably best to make it squirt and fire before we worry about the weeds.
Last edited by jharvey on Wed Nov 26, 2008 1:23 am, edited 2 times in total.
MotoFab
1N4001 - Signed up
Posts: 307
Joined: Thu May 29, 2008 1:23 am
Location: Long Beach CA

Re: FreeEMS firmware feature wishlist (your suggestions here!)

Post by MotoFab »

jharvey wrote:Any how, that's for a bit later I think. Probably best to make it squirt and fire before we worry about the weeds.
Please don't take these comments the wrong way, I'm pulling for this project.

They almost can't be worried about later. And when later arrives with a problem, the solutions do not often include statements like, "Well let's go back and do what we should have done in the first place."

It takes moments to add the lines while writing the code. And is extraordinarily difficult to add the ruggedness later. So much so that they don't get added later.

Problems that this observer can see are caused by firmware, after it's brought into real world, do not often get fixed after the code gets too complex. And instead the solution often used is the mainstay failure of "let's add a capacitor" or similar.

Am I saying that this'll happen with FreeEMS? No, of course not. But "we'll worry about it later" usually is a path to somewhere. I believe everyone has direct experience with that.

- Jim
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeEMS firmware feature wishlist (your suggestions here!)

Post by Fred »

I agree with most/all of that, except the "getting more complex" bit ;-) I've worked very hard to ensure that doesn't happen. Your things would be as easy to add at the end as any other time. I can't think of an easy way to do the spare space thing though. Besides, that is something unlikely to be an issue with C, more for asm.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
MotoFab
1N4001 - Signed up
Posts: 307
Joined: Thu May 29, 2008 1:23 am
Location: Long Beach CA

Re: FreeEMS firmware feature wishlist (your suggestions here!)

Post by MotoFab »

Fred wrote:I can't think of an easy way to do the spare space thing though. Besides, that is something unlikely to be an issue with C, more for asm.
Filling the space between address ranges with an instruction(s) might be a compiler instruction/directive? Like how a directive places some code at a particular address.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeEMS firmware feature wishlist (your suggestions here!)

Post by Fred »

Doing that would also double code load time which I find unacceptable at this point. It's a later, if ever, thing :-)
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jharvey
1N4001 - Signed up
Posts: 1607
Joined: Tue Jun 10, 2008 5:17 pm

Re: FreeEMS firmware feature wishlist (your suggestions here!)

Post by jharvey »

I can see both points here. When developing, it's really annoying when the code goes from 10 second uploads to 20 second uploads. However when released the end user won't care if it's 20 seconds because it's done so rarely. I seem to recall the use of DEBUG in many GNU software packages. I forget the details of how it works, but seem to recall it resides in the code, then is removed when a released version is compiled. Perhaps a similar technique can be used here. Have the extra space filled when compiled with out the DEBUG thing. I also see Fred's point than you shouldn't be in the weeds to begin with.

About the complex vs reliability thing, I disagree. I've see very complicated code, that has run quite reliably. Look at the Linux kernel for an example. The key in reliability is the quality of the code. Fred, sry_not4sale, and a couple others have been doing a good job on writing higher level code in a quality manner. This will allow for lower level intervention(s) later, if required. It also prevents the need for lower level intervention.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeEMS firmware feature wishlist (your suggestions here!)

Post by Fred »

jharvey wrote:I forget the details of how it works, but seem to recall it resides in the code, then is removed when a released version is compiled. Perhaps a similar technique can be used here. Have the extra space filled when compiled with out the DEBUG thing.
This can create it's own issues when you test one thing and release another ;-)

Reality is, with C, there can not be any strange instruction pointers by definition. If it was ASM, that is not necessarily the case... we aren't using ASM though.

Also, the probability of hitting the filled space drops as the code grows. right now 50% is used and therefore your hit rate is 50%, when we are using 90% (soon enough) it shall be a 10% hit rate and near useless.

I do like the COP ISR gathering data and reporting it somehow (serial or eeprom), but probably only in the case of a time out.

http://freeems.aaronb.info/tracker/view.php?id=69

Currently the COP handler is the same as all other UISR stuff. I should probably fill out the UISR handler with calls to similar code to report what was going on. There is already a counter for it such that you know it has occurred, but we could do more.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
AbeFM
Post Whore!
Posts: 629
Joined: Sat Feb 16, 2008 12:11 am
Location: Sunny San Diego
Contact:

EGO Is The Best.

Post by AbeFM »

Ok, little idea that's been running in the back of my head...

After recently enabling EGO correction on my MS, and picking newer, richer targets for "near idle" operation like 100 mph super-cruise, my mileage went up from a VERY consistent 17 mpg to something which seems to be bouncing between 25 and 29 mpg. This 70% reduction in vehicle operating costs has, um, made me very happy. :-)

Well, the issue is the car doesn't respond QUITE as well with EGO on, can surge just a bit, etc. I keep thinking how I'd like to keep the laptop always on to turn it on and off on the fly.

Then I thought: Why not a dash mounted switch (and the inevitable answer: The MS has little to no I/O. It actually has negative I/O. When I put my laptop in the car, I end up with at least one less USB port, QED).
Anyway, something to turn EGO on when I'm cruising, and off when I want fine control, would be awesome. Sure, you could limit it on RPM, but I still get great mileage even approaching redline, so I wouldn't want to. You could do it on MAP, but that hurts because spool up sucks, and you want to be able to run lean even into 5 psi. And I know when I want it off.

Of course, I did have one more thought: TPS based EGO overide. When the TPS is below 20% I really don't care, I just want my MPG.

So my ultimate system, aside from having great, transparent EGO I could leave on all the time, would be to have four conditions which would turn it off:
Below ___ RPM
Above ___ MAP
Above ___ TPS
When a hardware switch is on.

None of this should be hard, but I think it would make EGO much finer. Certainly EGO is the quick way of trying a new "map"
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: FreeEMS firmware feature wishlist (your suggestions here!)

Post by Fred »

Abe, total tune switching should solve your issues. You can use table switching to do this. Your entire tune could be different, or just one little bit of it. etc. You could combine the lean one with a lower boost cut etc if you wanted to get flash :-) Otherwise it should be a piece of cake to hack in a condition like that :-)
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply