Page 2 of 35

Re: Fred's firmware development diary comments thread

Posted: Sun Mar 09, 2008 4:24 am
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.

Re: Fred's firmware development diary comments thread

Posted: Sun Mar 09, 2008 5:08 am
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

Re: Fred's firmware development diary comments thread

Posted: Sun Mar 09, 2008 12:13 pm
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.

Re: Fred's firmware development diary comments thread

Posted: Mon Mar 31, 2008 1:51 am
by sry_not4sale
Just been going through the source files, loving the density of comments!!!

Re: Fred's firmware development diary comments thread

Posted: Mon Mar 31, 2008 7:10 am
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.

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

Posted: Sat May 24, 2008 10:34 pm
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)

Re: Fred's firmware development diary comments thread

Posted: Sat May 24, 2008 10:51 pm
by Fred
Bump. (ha ha ha)

Re: Fred's firmware development diary comments thread

Posted: Sat Aug 16, 2008 7:39 pm
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

Re: Fred's firmware development diary comments thread

Posted: Sat Aug 16, 2008 8:27 pm
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.

Re: Fred's firmware development diary comments thread

Posted: Sat Aug 16, 2008 8:41 pm
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.