Skip to content
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

Util Timer enhancements #1444

Open
2 of 5 tasks
gfwilliams opened this issue May 24, 2018 · 3 comments
Open
2 of 5 tasks

Util Timer enhancements #1444

gfwilliams opened this issue May 24, 2018 · 3 comments

Comments

@gfwilliams
Copy link
Task lists! Give feedback
Member

@gfwilliams gfwilliams commented May 24, 2018

  • Currently we use a 64 bit time in the util times, which really slows things down as we're doing 64 bit maths inside the IRQ. We could move to 32 bits, perhaps switching to a 'time until scheduled' method rather than storing the raw system time.

  • We also use a queue which is shuffled around to reschedule, requiring a reasonably big copy each time. We could keep this constant and just have an array of indexes that we reordered. Another benefit of this would be that timers had unique IDs, so could be easily checked in the code.

  • Some things (like waveform) continually poll to see if the waveform is active or not. The waveform could actually just post to the event queue (using the new timer IDs) to avoid this polling.

  • When doing ADC reads, we wait in the IRQ for the read to complete. The HAL could be modified to allow an ADC read with callback function + user data, which would make waveform to take up a lot less time.

  • Currently timers are set using a global time. It means that stuff like digitalPulse has to use getTime()+pulseLength internally which makes the accuracy dependent on the RTC. We could just avoid using the RTC completely - timing would potentially be a little less accurate (because of the time taken to reschedule the event not being counted via the timer) but then most Util Timer tasks are reasonably short-lived anyway.

@wilberforce
Copy link
Member

@wilberforce wilberforce commented May 24, 2018

Is it worth benchmarking the 32 bit vs 64 bit for point 1 to see what the real gains are? I'm sure this will be different for each platform too.

@gfwilliams
Copy link
Member Author

@gfwilliams gfwilliams commented May 25, 2018

Is it worth benchmarking the 32 bit vs 64 bit

Yes, definitely. My plan is to toggle a pin on IRQ entry and exit and look at it with an oscilloscope. The reason I suggest it was when I was doing things a while back I did exactly that and felt that the IRQ was taking too long to complete.

@gfwilliams
Copy link
Member Author

@gfwilliams gfwilliams commented Oct 7, 2020

Done some work on this - as you note the hit from 64->32 math isn't huge. There hasn't been a massive improvement.

The one that hurt was recurring timers which used what ended up being a 64 bit divide, so it's nice to get rid of that.

gfwilliams added a commit that referenced this issue Oct 9, 2020
… from the hardware timer itself (fix #1749, ref #1444)"

This reverts commit 0c6b0c8.
gfwilliams added a commit that referenced this issue Nov 3, 2020
…e hardware timer itself (fix #1749, ref #1444)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants