View unanswered posts | View active topics It is currently Wed Oct 18, 2017 8:19 am



Reply to topic  [ 110 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10, 11  Next
FreeEMS firmware feature wishlist! (out of date) 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14822
Location: Home sweet home!
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!


Mon Nov 24, 2008 2:01 pm
Profile WWW
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
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.



Mon Nov 24, 2008 6:22 pm
Profile
1N4001 - Signed up

Joined: Thu May 29, 2008 1:23 am
Posts: 307
Location: Long Beach CA
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


Tue Nov 25, 2008 4:14 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14822
Location: Home sweet home!
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!


Tue Nov 25, 2008 6:56 am
Profile WWW
1N4001 - Signed up

Joined: Thu May 29, 2008 1:23 am
Posts: 307
Location: Long Beach CA
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.


Tue Nov 25, 2008 7:16 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14822
Location: Home sweet home!
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!


Tue Nov 25, 2008 11:20 am
Profile WWW
1N4001 - Signed up
User avatar

Joined: Tue Jun 10, 2008 5:17 pm
Posts: 1607
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.


Tue Nov 25, 2008 12:07 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14822
Location: Home sweet home!
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!


Tue Nov 25, 2008 12:51 pm
Profile WWW
Post Whore!
User avatar

Joined: Sat Feb 16, 2008 12:11 am
Posts: 629
Location: Sunny San Diego
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"


Wed Nov 26, 2008 12:18 am
Profile ICQ YIM
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14822
Location: Home sweet home!
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!


Wed Nov 26, 2008 1:09 am
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 110 posts ]  Go to page Previous  1 ... 6, 7, 8, 9, 10, 11  Next

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.