Go Down

Topic: reset micros() timer (Read 2172 times) previous topic - next topic

jstkatz

Is it possible to reset the micros() values to 0, if so, how do I do it? What will it break? Specifically interested in any effect on hardware serial. Thank you


PaulS

First things, first. You need to explain WHY you (think you) need to reset micros()'s output.

There are almost always better ways.

GaryP

Instead of resetting, I would like to be able to preset the internal counters.
Is it possible?

Cheers,
Kari
The only law for me; Ohms Law: U=R*I       P=U*I
Note to self: "Damn! Why don't you just fix it!!!"

Coding Badly

Quote
Instead of resetting, I would like to be able to preset the internal counters.


Why?

jstkatz

Its probably a dumb idea, but that hasn't always stopped me in the past.

I'm triggering two axes of stepper motors that have to move in sync but at arbitrary speeds in real time.

So I'm looping on something like

    if(currentx != targetx)
    {
      if(next_x < micros())
      {
        stepx()
        next_x += x_delay_period

And I feel like I'm coming close to the limit of what I can push through in terms of real time step rate while still catching all the serial traffic

This is more of a silly nit picky thing though, I don't want to have to check for overflows once per microstep per axis

I know bad practice is bad practice but I don't expect the bounds of the project to grow and if it wont actually break anything that I'm using then it would give me a little warm feeling to do it this way

someone please chastise some sense into me

Korman

#5
Apr 05, 2011, 08:58 am Last Edit: Apr 05, 2011, 09:03 am by Korman Reason: 1

So I'm looping on something like

Code: [Select]
if(currentx != targetx)
   {
     if(next_x < micros())
     {
       stepx()
       next_x += x_delay_period



Your code is flawed, and if you do it properly, you'll never have to worry about overflows. Here's how to do it properly:

Code: [Select]

void loop() {
   // Variables to remember last waiting period.
   // Those need to be static and of type unsigned long
   static unsigned long start_x = 0;
   static unsigned long start_y = 0;

   unsigned long curtime = micros();
   if (curtime - start_x >= delay_x) {
       ... do something useful with x axis ....

       // Reset timer for x
       start_x = curtime;
   }
   if (curtime - start_y >= delay_y) {
       ... do something useful with y axis ....

       // Reset timer for y
       start_y = curtime;
   }
}


That's it. The important parts to remember is to never compare values you get from millis() or micros() or add delays to those values, because that will fail at the overflow. Always substract the current time from the starting time and compare the difference against the expected period so that the subtraction will take care of the overflow for you.

Korman

Coding Badly

Quote
someone please chastise some sense into me


No need.  Post your Sketch.  I suspect you will receive a fairly simple revision that is immune to the overflow.

GaryP


Quote
Instead of resetting, I would like to be able to preset the internal counters.


Why?



C'moon, don't ask "why" when I ask is it possible?
:)

Cheers,
Kari
The only law for me; Ohms Law: U=R*I       P=U*I
Note to self: "Damn! Why don't you just fix it!!!"

Korman


C'moon, don't ask "why" when I ask is it possible?


If you need to ask if it's possible, you shouldn't do it. If you know how to do it, then you won't want to do it because you'd understand why it's a bad idea and what problems you'd create by doing it. You'd also know how to handle those variables correctly and see no reason to such a thing.

In short, telling someone who asks that question how to do it is in 100% of all cases the wrong thing to do. Better assume that you can't change those counters and resolve your problems the correct way.


Korman

GaryP

#9
Apr 05, 2011, 09:50 am Last Edit: Apr 05, 2011, 10:08 am by GaryP Reason: 1


C'moon, don't ask "why" when I ask is it possible?


If you need to ask if it's possible, you shouldn't do it. If you know how to do it, then you won't want to do it because you'd understand why it's a bad idea and what problems you'd create by doing it. You'd also know how to handle those variables correctly and see no reason to such a thing.

In short, telling someone who asks that question how to do it is in 100% of all cases the wrong thing to do. Better assume that you can't change those counters and resolve your problems the correct way.


Korman



My friends!

I don't understand your why you guys keep saying such a thing. I do take care of the logic in my programs, I just would like to do some things my way, if there's a way.

Simple example could be, that I wan't to avoid calculating difference between counter and external input. Let's say resetting internal timer to match with imaginative time, no RTC or GPS, only manual input. I try to avoid the need of extra functions for that.

I take your answer as you don't like the idea, but it won't help me. And if you don't know how to do it, it is ok.

Thanks for taking care of me and my application anyway, your consern is delightful.

For the Future!
I want to highlight one thing. I don't like pissing contest, who's argument is the last , it is not taking us anywhere. I have noticed that there's some attitudes and ways to express ourselves, that sounds sometimes a little moody (is this a real word?). I'm doing my best to correct this personaly, I've been feeling that this attitude is quite catching. When novices, newcomers, asks a question, there's a temptation to give quick and harsh answer, just because the same question has been asked 1001 times before, and every new person introduces themselves "HELP ME I'M N00B!".
If we have an answer, why hide it or be rude other ways.

So, I like to know different methods to do different things, if there's a good reason to avoid something, please, arguments are always welcome. Just don't think the inquirer is stupid, I have seen that the case is not always that.
;)

Cheers,
Kari
The only law for me; Ohms Law: U=R*I       P=U*I
Note to self: "Damn! Why don't you just fix it!!!"

Korman

#10
Apr 05, 2011, 10:23 am Last Edit: Apr 05, 2011, 10:26 am by Korman Reason: 1

I don't understand your why you guys keep saying such a thing.


Because you ask the wrong questions.

Simple example could be, that I wan't to avoid calculating difference between counter and external input.


So instead you prefer to mess around with linker values so that you can access the right variable and then also add the appropriate assembly instructions so that you don't get variable corruptions in case of simultaneous access by the ISR function. If you know how to do that on your own, that may be a useful option. But if you don't, messing around in that area is so completely out of your depth that nothing good will come from it. It's a just like cutting you arm off to clean your nails simply because you don't like bending your elbow and you come and ask how best to cut your arm off.

I take your answer as you don't like the idea, but it won't help me.


No, it has nothing to do with liking, it's all about knowing. I know that someone asking a question like this shouldn't do it. That's experience speaking. If you had a valid reason to reset the micros() timer, you'd ask completely different questions.

Korman

AWOL

#11
Apr 05, 2011, 10:30 am Last Edit: Apr 05, 2011, 10:44 am by AWOL Reason: 1
Quote
It's a just like cutting you arm off to clean your nails simply because you don't like bending your elbow and you come and ask how best to cut your arm off.

Great analogy!

@GaryP:
It isn't about a p155ing contest, it is about experience.

There is a programming adage that goes something like "For every problem there is a solution that is simple, elegant efficient...and wrong".

It is very easy to (p)reset the timers; much harder though to do it correctly.
Once you set out down the path towards the Dark Side, it can be very hard to retrace your footsteps.
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

PaulS

Quote
If you had a valid reason to reset the micros() timer, you'd ask completely different questions.

You'd also know all the places where the micros() timer is used, and all the things that would be impacted when you changed the micros() timer. And, therefore, you'd know that you should not be messing with the micros() timer.

MarkT

And you'd know how to do it because you would have examined its code in the process....

Basically micros() is potentially used by any library your sketch uses, so altering it could break them.  Its trivial to implement your own resettable version on top of micros():
Code: [Select]

long my_datum = 0L ;

long myMicros ()
{
  return micros() - my_datum ;
}

void myReset ()
{
  my_datum = micros () ;
}

[ I won't respond to messages, use the forum please ]

GaryP

Korman, stop the rage, you are scary!
:smiley-eek:

Thanks you all, arguments taken, and I will forget my original idea completely.. for now.
But the deeper knowlegde is there waiting.

Cheers,
Kari
The only law for me; Ohms Law: U=R*I       P=U*I
Note to self: "Damn! Why don't you just fix it!!!"

Go Up