Possible uses of our timer resources : ideas soon please!

[gearhead]

woah! Are you sure we need that much, Jean?

I mean, staged is to deal with the differing needs of injection. A smaller one for idle and adding another ( larger?) one to that for high power? Or to flow enough for methanol use. I think Rotaries use it, too with 2 injectors per rotor.
Once you get 6 cylinders, there are more injectors and 550cc - 700cc per cylinder is easy to find. What does that work out to... 600-700hp? With 8+, this is not so much of a problem. Am I missing something?

Gearhead

[AbeFM]

My GOD you've been busy. I'll comment quick!

I tend to think that staged sequential injection is a bonus, and that provided that the timing is consistent, you are only bringing in staged injectors at upper rpms/boosts and therefore sequential becomes less important. If you are still sequential, whether you are slightly late or early is splitting hairs. You can just tune the combined stop point for both as a good compromise for both (or more likely, the correct timing for low revs idle/cruise conditions where it matters.

Nothing wrong with opening at the same time and ending at different times. But if you don't tie either open or close together, you waste a timer. I'd be all for seeing them turn on at once and end at different times. Makes sense, fills the air as it goes by.

Being aware of making it compatible with siamese while designing is a good thing (provided it does not force massive unnecessary compromise) but at the end of the day, it's not all that much of a big deal to retrofit an extra timing table or two, add a few extra calcs, and vars to read from and change the wheel code to suit.

Well put - the suggestions about staged injection I've been making (seem to me) to be *broadly* applicable. Same with support for a generic crank + cam wheel. I think those will make a LOT of people be able to do a lot of very cool stuff without making the code weird.

8InchesFlacid wrote:
I have one question I want to preface this all with: Is there anything inheriently wrong with doing *everything* as a bit bang?
YES! you lose accuracy that you could have been using to good effect.

Still lost here. How is that accuracy lost? Latency should be well defined to write one word to one port, so you should be able to get the same accuracy: Timer blips, you write a word. Set the timer short by the amount of time it takes to write this word.

Seems like a slam dunk, and removes the "special case" of more than six primary channels.

That's why I'm so big on it. Then 42 cyl sequential becomes the same code as 3 cyl. I'm not trying to be a pain, but I want to understand how 6 times on a 6 is better than big banging a 6.

[Sequential timing] is still important despite how brain washed you (or i unfortunately) have become to the contrary on msefi.com. Also, its only a pin count thing if you use a single timer to start them, or two timers to control them outright.

Yep, I used to care a lot more...

Quote:
Traction control that only noticed that the wheel spun 4 rotations when it was supposed to spin 2 isn't doing you much good. If you want to know where to put more timers, use 4 for bit-banged injection as Jean suggested, and put the rest watching generic wheels like that.
I'll say it again, there is no way in hell any SIGNIFICANT compromises will be made to fundamental fuel/ign control for an accessory function. Secondly, do the math for us Flacid, how far can a wheel turn in 3rd gear with 100mph redline in that gear and 0.128 ms between potential samplings? If you have issues with the tooth count between RTI executions being too low : 4/5/4/5 etc you can use the one sampling interrupt being measured two fold short period for delta speed, long period for speed etc.

Ok, to rough approximation, wheel RPM is 1/3 (0.299:1 miata 5speed) engine RPM in top gear - so figure 2000 engine rpm = 500 wheel rpm, or 8 * # of teeth per second. For a 8 toothed wheel it's 64 hz, and it's 0.008 teeth per loop. Your count is going to see 0,0,0,0,0,1,0,0,0... Now, the nice part is, you basically have 1% accuracy on the timing of the single tooth you'd see.


In, say, second gear, where traction control is of the utmost importance, you have 0.129:1 or 774 rotations per minute at 6,000 rpm. So it means 78 cycles per tooth or a bit over 1.2% error in timing. So now the question becomes do you care about a 1% error? If you're looking for slipping starting to happen, when do you decide it's time to do something about it? 5% slip? 3%?

I guess I'm still not yet sure what it all means. If you have many teeth, these rates would change, your error would go up. But you're not going to touch teeth-per-cycle for a long time.

Yeah, a pair of timers for each set of sequential bit banged outputs. The reason you need one per channel if you use them as hardware is because they literally switch the output without your intervention and are "attached" to that output.

OMG! You're going to tell me ignition timing is somehow less critical than fuel delivery? I just don't buy it!! I can't see how you can bit-bang ignition but you need timers for fuel. I'm certainly misunderstanding something here. Dwells can be massively fudged but advance timing is ultra critical.




Overall, I'd say my only real comment/complaint/question is this why no bitbanging on fuel, and why bitbanging on spark. Everything else seems hunkey dorey to me and coding (not talking) in order.
Then I just need to find out what's up with this xgate/non-xgate chip thing, I think I'd do what Jean did, get set up for it since I think it will let me do dumb things like I like to do.

[ababkin]

i haven't looked hard at timers yet, but as i understand there are few ways to use them: one way is have the timer automatically set a port to specific value upon time expiration (no delay) and another way is to have timer generate an interrupt, which would be handled by a quick ISR, which will do the bitbanging upon timer expiration.
I think Fred says that the timer ISR + bitbang is less precise because there is an inherent delay assosiated with any ISR (even a one-liner i'd imagine). But i am thinking this delay could be measured and fudged (providing the MCU and it's speed stays the same)

over to Fred..

[AbeFM]

That was my take on it, too - and I want to see if that's what he thinks. I'm sure it's reasonably deterministic, and... at 40Mhz you'd get 1000 clock cycles per degree at full tilt, so if a few opperations snuck in there (I'm still thinking they wouldn't, but playing devil's advocate) you'd be well under 1% of 1 degree error.

What do you gain for this totally insignificant error? No IF statements in your code, just run the generic engine handler, without switching modes for 4 + staged + water, or 6 cyl straight up, or any combination you want.

Any fixed delay, within reason, and <50% of 1 degree is within reason, is totally easy to deal with and if done right doesn't hurt performance or make any sacrifices you could measure even if it is a bit hard on the instincts.

Again, I'm awaiting to see if there's something I'm missing. It wouldn't surprise me, but it wouldn't surprise me if I was right, either.

[Fred]

Because it's NOT a fixed delay because of all the other interrupts and their frequencies and associated beat frequencies. That is why.

To understand why spark is "less" important than fuel, you need to look at the units.

1 degree is probably good enough for timing. 1 degree is a hell of a long time in fuel.

17ms per cycle at 7000rpm

fuel resolution needs to be close to 0.001ms or 17000 divisions per engine cycle, 8500 per rev

compare with spark at 360, 720 or at MOST 1440 per rev and you get the picture.

esp when you see that we care about fuel accuracy at low pulsewidths the most. where that 0.001ms becomes 1% or so and dead time error kicks all our arses.

tune your opening time accurately!

of course, all this is true if you want your afrs consistent at all times, if you don't, i know a good diy efi solution that will let them wander with large injectors....

[ababkin]

Because it's NOT a fixed delay because of all the other interrupts and their frequencies and associated beat frequencies. That is why.

first of all, what are "beat frequencies"?
hmm, i don't think "other interrupts" can interrupt the current one (if the same priority), so the only possible variable delay can materialize due to another interrupt handler of the same priority not being finished yet - probability of which is minuscule i think, however even this IMO CAN be accounted for and dealt with on XDP/XEP using the multiple interrupt priorities (i think).
The idea (MY ORIGINAL idea (pat. pending) ) is to log the timestamps with higher priority ISRs (which only logs these timestamps, nothing more) before passing control to the lower priority ISRs, which in turn will consider the timestamps logged previously by the higher priority ISRs and pad the low priority ISR with nops to achieve delay constancy.
This way, if the lower priority ISR is being delayed by another low priority ISR, the former will still know when the original interrupt occurred as it was logged by high priority interrupt that interrupted the latter delaying low priority ISR.
Doing it this way IMO will ensure a constant delay, that can be safely fudged to get appropriate time precisely.

(hope you understand what i mean)

of course, all this is true if you want your afrs consistent at all times, if you don't, i know a good diy efi solution that will let them wander with large injectors....

Behave now!

[Fred]

first of all, what are "beat frequencies"?

http://hyperphysics.phy-astr.gsu.edu/hbase/sound/beat.html
http://en.wikipedia.org/wiki/Beat_(acoustics)

so the only possible variable delay can materialize due to another interrupt handler of the same priority not being finished yet

Exactly. However because of the variable frequency of each interrupt source, you end up with the amount left to run varying as described above in those acoustic papers.

The idea (MY ORIGINAL idea (pat. pending) ;) ) is to log the timestamps with higher priority ISRs (which only logs these timestamps, nothing more) before passing control to the lower priority ISRs, which in turn will consider the timestamps logged previously by the higher priority ISRs and pad the low priority ISR with nops to achieve delay constancy.
This way, if the lower priority ISR is being delayed by another low priority ISR, the former will still know when the original interrupt occurred as it was logged by high priority interrupt that interrupted the latter delaying low priority ISR.

Nice idea, but :
A where are you going to get all these magic interrupts?
B each might know when the other one sampled something, but that does not help it know when it's running.

The best you can do is record the time, calc the scheduling, set the ign and inj timers to go off when they should, make the code in the efficient. It's still no where near as good as pure timers would be.

For the record, I didn't mean that the pulsewidth control isn't good enough, I meant that batch mode = wandering AFRs no matter how good you are at controlling pulsewidth.

[Fred]

p.s. as I type, all 8 ECT timers are doing semi seq mode on an imaginary v12 :-)

[AbeFM]

Well, not to disagree with everything you said, but.. I disagree with everything you said.

At two squirts per cycle, 550cc injectors running 450 cc cyl, my idle pulse width is around 1.2ms. Given that the opening time is another 0.6 ms that gives me nearly 2 ms (or, maybe it works the other way and the 600us is included.) Anyway, a 1% error in fuel delivery is about 10 us. If my AFR's at idle are off by 1%, I don't care. At idle, it's 200 us/degree. There shouldn't be any issue for anything there.

At full tilt, well, if you're not running your injectors in the ~80% range, you have injectors that are too big for the job and don't deserve talking about.

7000 rpm / 60 sec/min * 360 deg/rot => 24 us/degree. So spark timing wants to be in the ballpark of 10 us accuracy.

Fuel, on the other hand, will be 80% of 7000/60 => 6.8 ms pulse width. A 1% error in pulse width is 70 us ms.

What's worse, a 1* error in spark, or a 1% error in pulse width? I imagine a 2% error in fuel (i.e. shooting for 12.5:1 but getting 12.75) is in the same ballpark as a 1* advance error. Meaning fueling needs to be done within 150us, and spark to within 10.

_____________________

I might be in over my head, but I'm with Mr. Penguin, the important thing is writing down what happened, when. I'm not sure when the book keeping would be done, but it would keep the interupts very very short. Certinaly an XGATE job. But aside from that, how long can a bit bang take?

Receive interrupt
Set output to stored value (pointer already set)
Figure out next bit series
move pointer

Even if you get interrupted in the middle of this sequence, you don't mess with your timing. The delay should be fixed, so there's no problems there. So if you DO get bothered in the middle (which careful selection of interupt priorities should prevent) the worst that happens is moving the pointer might get delayed.

I think it'd be a system which would run very fast.

------------------------------------

Hey! Congrats on the V-12. Too bad you can't make a motor that easy.

[Fred]

The uS accuracy doesn't matter a damn when you are at 80% DC. when you are at 1.1ms total pulsewidth (what ms reports as pulsewidth, we will report at least two figures so the third can be calced(dead, flowing, total)) and your dead time is 1.0ms, your 0.001ms is 1% which makes a significant difference when you plonk it on top of the existing injector to injector variation.

From your 200uS figures, perhaps you should pick up a nice shining MS1 box and install low res code on it :-)

There is a reason there is a MS2 in your dash and in mine! And we should aim to do better, not significantly worse :-)