Fred's firmware development diary comments thread

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: Fred's firmware development diary comments thread

Post by Fred »

Yeah, thats true, and as rpm drop, your ability to advance decreases too (max of 52ms at the mo).

However, why switch algorithms based on rpm? why not do it the same? I would really like to see a one algorithm for all conditions setup for this where you tune all of the load areas including idle and start up in the same fashion.

If you do fire on trigger pin rather than some fixed amount after it, then you have two algorithms and a transition period somewhere. Not ideal in my opinion.

Anyway, as I said, this really is proto code, and will need some reengineering anyway. Proof of algorithm and concept is key here. Stuff we know works that we can use later if we see a need (a tool box if you like).

Bed, 323am now lol

Admin.
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
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: Fred's firmware development diary comments thread

Post by jbelanger »

I see it more as how you handle exceptions rather than having different algorithms. You chose to handle the exceptions by keeping the timing as accurate as possible and I propose to ignore the fraction of a tooth gap until you can time it correctly in a single timer interval. In both cases you add code to handle the exceptions so you have to evaluate the cost/benefit of both in terms of performance, reliability, maintainability, ...

As for the transition, I doubt that there's going to be a big issue with a 10 degree difference in timing when starting. If the transition is not a starting event only then it is definitely undesirable but otherwise it's a non issue. Also, with the fast changing rpm at startup, the injection timing is likely to be unreliable anyways.

But as you say, this is a good time for proof of concept and experimentation. If you can come up with something generic, simple, fast (or fast enough) and reliable then this is great. If not, there are other avenues to explore. No matter what the choices are now, things will start to get interesting when other interrupt driven code starts to be incorporated in the mix.

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

Re: Fred's firmware development diary comments thread

Post by Fred »

jbelanger wrote:I see it more as how you handle exceptions rather than having different algorithms. You chose to handle the exceptions by keeping the timing as accurate as possible and I propose to ignore the fraction of a tooth gap until you can time it correctly in a single timer interval. In both cases you add code to handle the exceptions so you have to evaluate the cost/benefit of both in terms of performance, reliability, maintainability, ...
I'm not certain I understand what you mean by "exceptions" with code, to me, that usually means "stuff went wrong, handle it", but I feel like you mean something more like corner cases? Either way, As much as it is a bit extreme when you hit 100% duty, my engine is like that from 6500 up to 7500 right now (thought they would be big enough, made more power...) and I don't consider it an exceptional circumstance, but one that does need to be handled gracefully. If you meant start up time, I don't think thats exceptional at all, just normal engine behaviour at a lower speed.
As for the transition, I doubt that there's going to be a big issue with a 10 degree difference in timing when starting. If the transition is not a starting event only then it is definitely undesirable but otherwise it's a non issue. Also, with the fast changing rpm at startup, the injection timing is likely to be unreliable anyways.
If your engine is running a decent wheel (36-1 or similar, or maybe even less) and you schedule it off the nearest practical tooth to the event, it cant be more out (angle wise) than a tooth or so at worst. I don't think it would be an issue either, but I can't see a reason to include such behaviour when the standard behaviour (which you need for the entire rest of the time) can handle it.
But as you say, this is a good time for proof of concept and experimentation. If you can come up with something generic, simple, fast (or fast enough) and reliable then this is great. If not, there are other avenues to explore.
I think I (finally) have it sussed. But there is always room for improvement and change.
No matter what the choices are now, things will start to get interesting when other interrupt driven code starts to be incorporated in the mix.
I have some ideas about how to handle latency on the injector channels, so I don't think those will need to be high priority. I think the engine input ISRs should be highest, and ignition PIT channels second highest.Below that, it's anybodies.

Thanks for being the only one to bother commenting in here! I appreciate it :-)

Admin.
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
sry_not4sale
LQFP144 - On Top Of The Game
Posts: 568
Joined: Mon Mar 31, 2008 12:47 am
Location: New Zealand, land of the long white burnout
Contact:

Re: Fred's firmware development diary comments thread

Post by sry_not4sale »

Just been going through the source files, loving the density of comments!!!
Owner / Builder: 1983 Mazda Cosmo 12at (1200cc 2-rotor turbo) coupe [SPASTK]
165hp @ 6psi standard - fastest production car in japan Oct 82
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary comments thread

Post by Fred »

Thanks mate, it's a bit of a mess at the moment, but it's getting better each time I don't have to hack it up to fix something ;-)

The idea is that if something is non-obvious, and let's face it, C is non-obvious, that it is docced in the code, or via a link describing the technique. Hence there are a lot of links showing exactly where I found the information.

I'm glad you like it!

Admin.
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
ababkin
LQFP112 - Up with the play
Posts: 215
Joined: Tue Jan 15, 2008 5:14 pm

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

Post by ababkin »


Fixed bug 5 : forgot to add code run time to test for injector hard on behaviour!
good job, i rekon that was a very important bug :P

(is there a 'comments' thread to your firmware diary? couldn't find)
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Fred's firmware development diary comments thread

Post by Fred »

Bump. (ha ha ha)
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
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: Fred's firmware development diary comments thread

Post by jbelanger »

I had to dig this thread out from way down the list...

About writing to flash, hasn't AN2720 given enough to effectively do this? From a quick glance at it, it seems to be almost exactly what is used in MS2 (not that is should be the reference). Is it due to some difference between the DP256 in the AN and the XDP512 or some annoying omissions/errors?

By the way, I had a hell of a time having it work on an HCS08 because Freescale's software for the HCS08 AN is actually the HCS12 code and the assembler instructions are not correct for the HCS08 (minor issue) but the issue was that the clock setting given in the AN was not correct (slightly higher than required) and the flash burning does not work when you use the BDM at all after setting the flash clock (and you can only set it once). I also had to fight CodeWarrior idiosyncrasies.

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

Re: Fred's firmware development diary comments thread

Post by Fred »

Yeah, probably some differences such as those you mention. Sean is better placed to comment, I just dug it up, had a read and started to think about it. He's been actually working on it. I've made a stack of other changes to the code that are unrelated in the mean time, but nothing important enough to release. I was hoping the next one would be burning stuff, but perhaps not. Still, if he gets it up and running "in time" (no idea when) then we can merge our efforts and include that too.

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
SleepyKeys
LQFP144 - On Top Of The Game
Posts: 549
Joined: Mon Feb 11, 2008 10:52 pm
Location: Arizona
Contact:

Re: Fred's firmware development diary comments thread

Post by SleepyKeys »

There are some differences. I had some errors in my flashinit(). I have checked everything against the XDP512 docs and all should be well. It no longer resets when erasesector() is called. The main hang up is my inexperience with C. I'm hoping to finally get erasesector() done soon.
You snooze, you lose!
Post Reply