setOverflow() vs. setPeriod()

LeafLabs Garden » Support » Maple Hardware Support

setOverflow() vs. setPeriod()

(11 posts) (2 voices)

Started 5 years ago by Silntknight
Latest reply from Silntknight

Silntknight
Moderator
Do these really do the same thing by manipulating different values? From what I understand, setPeriod() changes the prescaler automatically to make the period close to the defined value (in us). That means that the counter will always count to 65535 before resetting, but each count may have a different time value (10us per count, 1us per count, 1s per count...) depending on the prescaler value. setOverflow(), from what I was reading, will change the value that the counters count up to. I don't think I can do this, but I'd like to actually set that value higher than 65535. I have an external interrupt that handles resetting the counters back to zero, so I'd rather disable the internal feature. I know I could make a code like this,
```
void setup() {
  Timer1.setCompare1(65534);
  Timer1.attachCompare1Interrupt(Reset);
}
void Reset() {
  Timer1.setCount(1);
}
```
but I'd prefer not to. The fewer interrupts I deal with, the better. I'd rather make this code.
```
void setup() {
  Timer1.setOverflow(999999); //999999 is arbitrary here to show a really long time.
}
```
Any ideas?
Posted 5 years ago #
gbulmer
Moderator
Do these really do the same thing ...?

No, not quite.

Do these really ... manipulating different values?

setPeriod uses setPrescaleFactor and setOverflow to do its stuff.

I don't think I can do this, but I'd like to actually set that value higher than 65535.

Your correct, you can't do that in any easy way.

I think you are focusing on repetitive events coming from the timers.
The result is the code spends effort trying to avoid any bad consequence from a repetition but also spends effort setting up that repetition.
IMHO, this is an alert that there is likely something which is not right.

Timers don't have to be used to generate repetitive events. They can be used to generate one off events at a precise time; a timer can be used like an alarm clock, it goes off once, and then code stops it.
I think I understand what needs to be done to cause the engine to turn, and that is one-off timing, calculated each cycle, not repetitive timing.

It is pretty straightforward to stop a timer from going off repetitively.
For example
Timer1.detachCompare1Interrupt() disconnects code from the timer channel.
Timer1.pause() - stops the timer without changing it's settings

My honest advice is to try understand how to use timers. It is pretty much all about the counter, the counters prescaled clock, and some comparison values.
```
for (uint16 couter=0; counter<reload; counter++) {
  if (counter == channel1compare) { ... do stuff, run interrupt handler }
  if (counter == channel2compare) { ... do stuff, ... }
  if (counter == channel3compare) { ... do stuff, ... }
  if (counter == channel4compare) { ... do stuff, ... }
  delay(prescaler count cycles)
}
```
Okay?
Posted 5 years ago #
Silntknight
Moderator

Kind of okay. See, I know I can use timers with interrupts to handle my "one off" events, but I'd rather not have a 3ms delay in one of my interrupts. Using a PWM helps me here. This is the hardware solution we came up with earlier. Right now, all I am trying to do is increase my output resolution. I am limited to 10us by the fact that any smaller and the counters reach the overflow value before the Hall Sensor triggers a reset. This is bad. Any larger and I am being counter productive. If I can prevent the timer from overflowing on its own, them I am fine. I am also fine without increasing my resolution to 1us, but I'd prefer to.

Also, my original example is incorrect. The interrupt value should actually be very close to zero. It could be 100 or 200, but values close to 65536 will actually give me many more problems.

Finally, I thought about this a little more, and I decided I wouldn't bother to increase resolution further. If I did, I might need my entire range of numbers, so I couldn't even set an interrupt to freeze counting without causing more problems.

Posted 5 years ago #
gbulmer
Moderator

what is the rev range of the engine?

Posted 5 years ago #
Silntknight
Moderator

I'm not sure on the low end, but I think is is 400RPM. The rated max is 3600RPM, but we regularly push is past that to 4000, so all my calculations assume that to be the max. I found that with 1us resolution, I would use all my "counts" for an idle of ~900RPM. The torque/power curves show a minimum of 1800RPM, but I know that's incorrect.

Posted 5 years ago #
gbulmer
Moderator

Okay,
4000rpm ~= 67 revs/second, so 1 rev = 0.015 seconds = 15,000uS
400rpm ~= 6.7 revs/second, so 1 rev = 0.15 seconds = 150,000us

Why do you need 1uS resolution?
Isn't 1uS resolution spurious?
i.e. a rev won't even be consistent from on rev to the next to that sort of resolution?
Have you had any discussions with engineers about the limits of resolution for the engine? Do they think significantly better than 1 part in 1,500 is achievable?

Previously you'd writen that 10uS resolution was good enough.

In the ideal case, to make the software easy, and hence flexible, the timers would be set up so that they give better than 10uSec resolution, without having to change the prescaler. A single timer can count to 65,535. (Timers can be 'chained' to create higher resolutions, but I'd recommend keeping things simple for now, and not doing that.)

I found that with 1us resolution, I would use all my "counts" for an idle of ~900RPM.

Yes, 65,535 uSec ~= the duration of one rev at 915.5 rpm.

Leave yourself a bit of headroom (just in case things change) and count to 60,000.
Then set the prescaler to increment the timer count at
150,000us/60,000 count = 15/6 = 2.5uS

This would cover the range of the fastest rev with a resolution of 2.5uS too;
a count of 15,000/2.5uS = 6,000, which corresponds to a rotation of 0.06 degrees, or the rotation of the minute hand on a clock in 0.6 seconds, which is pretty small.

Posted 5 years ago #
Silntknight
Moderator

1us resolution will help with fuel injection control. I've read about how the minimum pulse width should be .7ms because the ECU (Megasquirt) can only handle .1ms intervals. If you had a .2ms idle pulsewidth, then the next richer/leaner combination is 50% richer/leaner. Because I can handle 10x more accuracy, my minimum pulsewidth can be .07ms or 70us. I also did some math to calculate the change is pressure over the time interval that I am injecting fuel. The curve shows a change of abut .3 bar maximum (near the middle range). This changes the rate at which fuel is delivered because the cylinder pressure effectively changes the fuel pressure (gauge pressure vs. absolute pressure). I therefore need as high a flow rating as I can possibly handle, and 1us resolution gives me a minimum time of 7us. I realize that this may be excessive and nearly impossible to implement effectively. I'm actually pretty sure that a fuel injector could never inject for 7us anyway.

I'm not going to chain timers. I don't want the complexity and I don't have enough timers anyway. I was considering changing the overflow and prescaler to do something similar to what you are suggesting.
The problem with changing the total time it takes to overflow is that I don't want my engine self-starting. Right now, it takes ~.65 seconds to overflow. If it is allowed to overflow, the PWMs are activated and the strokes begin on a non-moving engine. That creates major problems because the Maple will "know" an RPM value and use that for most calculations. The engine will actually open the exhaust valve, then the intake, then fire the fuel injector for some random amount of time, then fire the spark plug. I'm not sure what would end up happening. .65 seconds is plenty to work within because of how I wrote my kill switch code, but .15 seconds is really pushing the limits of my driver. That being said, he'll be running auto-pilot most of the time anyway (I'll explain later), so .15 seconds is also plenty of time because the Maple would control start-up. Still, I can possibly try .3 seconds (300000us/60000counts) and have only half the accuracy that your idea would give me. I could also leave it as is and not worry about changing any of the math. I'll probably be fine with a 70us minimum pulse width anyway. If things scale properly, as they should with multiplication, then I should have a maximum fuel injector rating of 125lbs/hr anyway, because 12.5lbs/hr is the maximum for a .7ms pulse. Thanks!

Posted 5 years ago #
gbulmer
Moderator

Silntknight -

I therefore need as high a flow rating as I can possibly handle, and 1us resolution gives me a minimum time of 7us.

Eh? Why does 1us result in 7us?

I realize that this may be excessive and nearly impossible to implement effectively.

Summary: trying to run at 1us, may be 10x faster than meaningful (maybe 70x faster), and breaks?

IMHO this may be an example of 'premature optimisation'.
It is very common for developers to try to get a 'perfect program', before they have got a program that reliably and robustly gets a minimal, adequate answer.
The effect of premature optimisation is programs can become complex, distorted and pushed in a direction that is extremly hard to get working reliably.

May I suggest: make it as simple as humanly possible, and get it working reliably. Then try to increase the performance?

About 80% of the time, the simple program is more than adequate, and the 'perfect program' is never needed.

If it is allowed to overflow, the PWMs are activated and the strokes begin on a non-moving engine.

You are still assuming the hardware timer has to generate a repetitive PWM signal.
It does NOT have to.
The timers have many other behaviours they can generate.
It is only doing repetitive PWM because that is how your code uses it.
If repetitive PWM causes a problem, don't use the timer that way.

Posted 5 years ago #
Silntknight
Moderator

As I stated earlier, .7ms was recommended because of the Megasquirts resolution of .1ms. It allows for modulation in less severe increments that 50% (trying to go from .2 to .3ms). If I had 1us resolution, then the same logic would apply.

This really isn't "premature optimization." I actually need to know the pulse length to determine the size of the fuel injector I need. There are a lot of data still uncollected, but anything I can do analytically I will do now. Time is VERY valuable for this project. The way this engine runs, I actually need to know everything I am asking about, otherwise it won't run. I need the fuel pulse length to fit in the timer interval when the intake valve is closed and the spark hasn't fired or else I risk destroying the fuel injector. The flow rating is absolutely essential to doing this right. In any case, I calculated it to be 32lbs/hr @ 3 bar, raised to ~40lbs/hr @ 4.5 bar. IMHO, this program is as simple as it gets. Perfection is a long way from here.

True, I am assuming that I have to use a PWM for this, but that creates the most simplest program. Otherwise, I'd need to write in a lot of timer interrupts. I could run on only one timer, but I'd have to spend way more time than I care to just redoing the math. Maybe if I have time (and keep in mind I am a high school senior) I will attempt to make this interrupt based, free up 3 timers, and end my rollover problems.

IMHO, the timer rolling over every half second isn't a problem. Rather, if it is, I already have a solution.

Posted 5 years ago #
gbulmer
Moderator

As I stated earlier, .7ms was recommended because of the Megasquirts resolution of .1ms. It allows for modulation in less severe increments that 50% (trying to go from .2 to .3ms). If I had 1us resolution, then the same logic would apply.

Nope, I still don't get it.
0.7ms is 700us
This is a mechanical system, runing at 15ms/rev.
1us is 1/24,000 of a rev

I would be surprised to find that even Forula One, uses that level of resolution.

<>True, I am assuming that I have to use a PWM for this, but that creates the most simplest program.</>
If the program has have code to switch off PWM, because it only ever wants one pulse, then IMHO it is more complex than using a timer to generate one precise pulse.

But, I'll stop. You have a program that you are satisfied with, and understand.

Posted 5 years ago #
Silntknight
Moderator

.7ms is used with resolutions of .1ms because it allows for incrementing without adding excessive amounts or fuel relative to the previous pulse width (the whole .2 to .3 is a 50% increase stuff). If I increase my resolution by a factor of 10, then I can also change the .7 to .07ms.

Formula One probably doesn't use this level of resolution, but that's also because they have engines that run differently from mine. They don't use direct injection AFAIK.

I no longer get what you mean by "one pulse." Each output gets one pulse per two cycles, true, but there are many cycles. In fact, at least 400 every minute. AFAIK, this is by definition a PWM controllable output.

Also, I just realized that the timer resets every two cycles, so I need to make sure that the idle rpm isn't lower than 400rpm, otherwise I still run into problems... More to think about.

Posted 5 years ago #

RSS feed for this topic

Reply

You must log in to post.