I'm sorry if I'm not catching on, but please help clarify this for me.

I completely understand taking the TDC time and storing it. I also agree with and understand the method of using the values of 0001 to 0999 instead of degrees.

You mention to multiply these numbers by the time between tdc, but I don't see how that works.

Its not clicking with me on how to take the time per revolution and find a position with that. I want to say you take the time (ex 500) and divide it by the total revolution 1000, giving a ratio of where its at, but every time the RPM's change the ratio will be off.

At the start of loop(), you detach interrupts. At the end of loop(), you reattach them. The only time for an interrupt to be fired is between the end of one iteration of loop, and the beginning of the next. As you might imagine, that's an awfully short time.

tdc does not stand for top-dead-center as you are calculating a value. It is the time required to complete one revolution at the current speed.

This last posting does not contain the actual interrupt handler, so it is not possible to determine if you record WHEN the interrupt fired (when TDC occurred).

Absent that knowledge, you have no idea when anything else needs to happen, because you have no point of reference.

At the start of loop(), you detach interrupts. At the end of loop(), you reattach them. The only time for an interrupt to be fired is between the end of one iteration of loop, and the beginning of the next. As you might imagine, that's an awfully short time.

Agreed. Is there a way to give more time time for my interrupt? I don't think a delay would be smart. If then engine is spinning at 2000 rpm that's 30,000 us between each pulse. How much time does the arduino need?

Quote

This last posting does not contain the actual interrupt handler, so it is not possible to determine if you record WHEN the interrupt fired (when TDC occurred).

Why would we ever want to detach the interrupt?It seems to me like the interrupt handler should simply record the "time" (in microseconds) of TDC.Then on each trip through the loop you look at the loop time and see whether you need to open or close something.

I thought thats what you guys meant when saying "recording the time"

If I delete the interrupts, it gets rid of the mess Paul was talking about, which could be handy.

No. You have an attachInterrupt statement. It says "call this function (the handler) when someConditionIsTrue". It's that code (event_count()) that we need to see.

Quote

what I can do to give myself more time for the interrupts.

Start by asking yourself why you are disabling interrupts at all. The answer to that is that any non-byte-sized value affected (written to) by the interrupt handlers (you only have one) could be affected (written to) by the interrupt service routine while you are in the middle of resetting it. To prevent this, you temporarily disable interrupts.

As soon as the reset of eventcount is complete (along with any other values affected by the interrupt handler(s), you should enable interrupts again.

If I were doing this, I would want to actually RECORD the TIME (in microseconds) when the TDC interrupt was received. Else, we are only recording the next time through the loop AFTER TDC. That does not seem as accurate to me.

No. That is exactly what I mean is wrong. That does NOT belong in the loop() It was not an accident that I wrote it as a standalone function, OUTSIDE the loop().

That is why we have interrupt handlers, to handle time-sensitive things, while the loop() simply goes round and round without any specific reference to when it begins and when it ends/restarts.

The interrupt presumably triggers when the TDC sensor goes high. AT THAT MOMENT, regardless of what is happening in loop(), we want to know the TIME of the TDC so that all subsequent activities inside the loop() are referenced to an exact time of TDC.

Ok that makes sense. This also means that the time-time old function in void loop is now no longer needed. Correct?

I'm looking into the overflow code, I have to read up on it later, and will update tomorrow.

If you end up with some tremendously large number, you do a simple subtraction to restore it to "nominal".If I weren't so tired this evening, I could remember what you subtract...

No worries. I was assuming you were referring to using timer0_overflow_count = 0; at first, but found that the code is used for millis() not micros()If you subtract the large number by a standard ratio of something over 1000 like a 10 to 1 ratio I.E 10000/1000 would it not bring it back into "perspective"?

I'm not having too much luck finding this overflow code that works with my application.

The micros() overflow at 71 minutes. If the engine ever takes that long to rotate once, somethings wrong. So if we reset prevTDCtime to zero after it has re enabled the interrupt, won't it work perfectly? Like so

attachInterrupt(0, event_count, RISING); // re-enable the interrupt now that we are done prevTDCtime = 0;}

If not, have you remembered what the subtraction rule is?

Also, with the void event_count, if its not looping, how does the program know to go back through and detach interrupts and calculate ect... all over again? Or is that the purpose of the interrupt where its name actually means its definition; where when the interrupt signal is triggered it interrupts the code in progress goes back to that event_count code and then continues the loop?

Or is that the purpose of the interrupt where its name actually means its definition; where when the interrupt signal is triggered it interrupts the code in progress goes back to that event_count code and then continues the loop?

Exactly. An interrupt is like a telephone ringing. You mark your spot in the book you are reading, answer the phone, tell the caller to get lost, and resume reading, right where you left off.

The output from micros() rolls over every 71 minutes. If, as you point out, it takes less than that to make one revolution, you can forget about issues with micros rolling over, as long as you only subtract earlier values from "now".

No, setting prevTDCTime to 0 after enabling interrupts again is not needed and not correct.

Exactly. An interrupt is like a telephone ringing. You mark your spot in the book you are reading, answer the phone, tell the caller to get lost, and resume reading, right where you left off.

The output from micros() rolls over every 71 minutes. If, as you point out, it takes less than that to make one revolution, you can forget about issues with micros rolling over, as long as you only subtract earlier values from "now".

No, setting prevTDCTime to 0 after enabling interrupts again is not needed and not correct.

That telephone ring is a great example. Thank you.And yes it will never ever take 71 minutes to make one revolution, and I am always subtracting the new TDC from the previous TDC