New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

teensy 3.6 millis() issue #505

Open
Artemkamax opened this Issue Sep 27, 2017 · 8 comments

Comments

Projects
None yet
2 participants
@Artemkamax

Artemkamax commented Sep 27, 2017

Hello!
When using 16 way parallel output example time in teensy is 10% faster.
100sec is 110 in teensy.
standart example, just added Serial.println(millis()); in loop

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Sep 27, 2017

Member

You don't mention whether or not you've defined FASTLED_ALLOW_INTTERUPTS or not - did you?

When interrupts are disabled, we make an attempt to adjust the time to account for how long interrupts were disabled for (because the clock is advanced by way of an interrupt) - however it isn't exactly precise and will drift - there's not a lot that can be done about that.

Member

focalintent commented Sep 27, 2017

You don't mention whether or not you've defined FASTLED_ALLOW_INTTERUPTS or not - did you?

When interrupts are disabled, we make an attempt to adjust the time to account for how long interrupts were disabled for (because the clock is advanced by way of an interrupt) - however it isn't exactly precise and will drift - there's not a lot that can be done about that.

@Artemkamax

This comment has been minimized.

Show comment
Hide comment
@Artemkamax

Artemkamax Sep 27, 2017

yes, I tested it. The result is the same. 16 way, 540led each

Artemkamax commented Sep 27, 2017

yes, I tested it. The result is the same. 16 way, 540led each

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Sep 27, 2017

Member

FastLED isn't doing the time adjustment if you aren't using #define FASTLED_ALLOW_INTERRUPTS = 0 - so there may be something else that's causing the time to drift.

I just checked in a typo fix aorund this in the block code - there's a slim chance it will affect what you're seeing, but it also might not (if anything, the typo would've prevented any clock adjustment from happening - and without clock adjustments happening, millis runs slower than real world time (because the interrupts that are supposed to increment time aren't firing) )

(Also - MCU clocks often have some drift to them - I tried doing a clock with an arduino once and the time would drift by a few minutes a day - depending on how accurately you need to track time passing, you night need an RTC module)

Member

focalintent commented Sep 27, 2017

FastLED isn't doing the time adjustment if you aren't using #define FASTLED_ALLOW_INTERRUPTS = 0 - so there may be something else that's causing the time to drift.

I just checked in a typo fix aorund this in the block code - there's a slim chance it will affect what you're seeing, but it also might not (if anything, the typo would've prevented any clock adjustment from happening - and without clock adjustments happening, millis runs slower than real world time (because the interrupts that are supposed to increment time aren't firing) )

(Also - MCU clocks often have some drift to them - I tried doing a clock with an arduino once and the time would drift by a few minutes a day - depending on how accurately you need to track time passing, you night need an RTC module)

@Artemkamax

This comment has been minimized.

Show comment
Hide comment
@Artemkamax

Artemkamax Sep 27, 2017

Yes, but now millis run faster than real world. 10% faster, not slower.
without FastLed millis show true time.

Artemkamax commented Sep 27, 2017

Yes, but now millis run faster than real world. 10% faster, not slower.
without FastLed millis show true time.

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Sep 28, 2017

Member

Is it faster with interrupts enabled or disabled?

When interrupts are disabled I make an attempt to approximately adjust the time - but it’s approximate, I try to adjust the counter for how much time passed while interrupts were fully disabled — when interrupts are enabled (which should be the default - but I got the 3.6 port from someone else, as I’m not actively doing major work on the library right now) - then I’m relying on the standard system’s method of advancing the timer. However, interrupts are still disabled for a few microseconds at a time to handle the led data rate timing, it’s possible that over a large enough range of time spent led writing, that will also cause drift).

Member

focalintent commented Sep 28, 2017

Is it faster with interrupts enabled or disabled?

When interrupts are disabled I make an attempt to approximately adjust the time - but it’s approximate, I try to adjust the counter for how much time passed while interrupts were fully disabled — when interrupts are enabled (which should be the default - but I got the 3.6 port from someone else, as I’m not actively doing major work on the library right now) - then I’m relying on the standard system’s method of advancing the timer. However, interrupts are still disabled for a few microseconds at a time to handle the led data rate timing, it’s possible that over a large enough range of time spent led writing, that will also cause drift).

@Artemkamax

This comment has been minimized.

Show comment
Hide comment
@Artemkamax

Artemkamax Sep 28, 2017

FASTLED_ALLOW_INTTERUPTS no change nothing in my situation. I think this is not interrupt problem? because miilis is faster than time. I think problem like this: #437

Artemkamax commented Sep 28, 2017

FASTLED_ALLOW_INTTERUPTS no change nothing in my situation. I think this is not interrupt problem? because miilis is faster than time. I think problem like this: #437

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Sep 28, 2017

Member

Time is, by definition, an interrupt problem, as the “clock” is updated via interrupts. 437 was adding the clock adjustment to the code - which the teensy 3.6 code already had.

When I start setting up hardware and running testing and doing work on the library again I’ll do some more testing with this.

Member

focalintent commented Sep 28, 2017

Time is, by definition, an interrupt problem, as the “clock” is updated via interrupts. 437 was adding the clock adjustment to the code - which the teensy 3.6 code already had.

When I start setting up hardware and running testing and doing work on the library again I’ll do some more testing with this.

@Artemkamax

This comment has been minimized.

Show comment
Hide comment
@Artemkamax

Artemkamax commented Sep 29, 2017

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment