Skip to content

RSDK-12491: performance improvements and full step mode support#8

Merged
Steve Briskin (stevebriskin) merged 12 commits into
mainfrom
performance
Nov 25, 2025
Merged

RSDK-12491: performance improvements and full step mode support#8
Steve Briskin (stevebriskin) merged 12 commits into
mainfrom
performance

Conversation

@stevebriskin

@stevebriskin Steve Briskin (stevebriskin) commented Nov 20, 2025

Copy link
Copy Markdown
Contributor

Performance on the rpi zero 2w is notably better up to about 5rpm with full step mode. Testing on an rpi5 pending.
Key changes:

  • support for full step mode. (reduces number of steps by 2x)
  • calling setpin operations in parallel (experimentally reduces latency by 2x)
  • latest rdk reduces grpc call latency by 2x
  • actually keep track of timing. the previous implementation assumed no latency on setpin calls.

The overhead of module to module communication has a significant impact on our ability to drive these steppers at high speed.

There are still a number of issues with this module (see TODOs) that I will follow up on after this.
This repo hasn't been updated in a while so some changes were needed to appease linter and compiler.

Comment thread uln28byj48/28byj-48.go
time.Sleep(m.stepperDelay - elapsed) // will return immediately on negative or zero duration

/*
m.logger.Infof("stepperDelay: %v, elapsed: %v, totalDurationinSetPins: %v, sleptFor: %v",

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be removed in a followup pr after I'm done profiling.

Comment thread uln28byj48/28byj-48.go
return err
}
m.workers.Stop()
if m.workers != nil {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this was a bug that caused a panic if the stepper is Closed having never had an operation run on it.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fun! You had a TODO about actually using a mutex to protect state variables. Assuming protecting the assignment/access of workers is part of that TODO.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed. when i tried to dumbly add mutexes i deadlocked somewhere so i just did this so i could keep working.

@dgottlieb Dan Gottlieb (dgottlieb) left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this PR is achieving what it has scoped out to do. Just highlighted the parts I wanted to make sure were intentionally out of scope.

Comment thread uln28byj48/28byj-48.go
err := m.doStep(doRunCtx, m.getStepPosition() < m.getTargetStepPosition())
if err != nil {
m.logger.Errorf("error stepping %v", err)
return

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be clear -- stoppable workers will repeatably call this lambda function. So if we hit an error here, I expect doStep to be retried "immediately".

I think addressing anything of that nature was understandably out of scope for this PR. But wanted to make the API clear. It's not obvious to me this usage was fully aware.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point. i'll address it in the next pass.

Comment thread uln28byj48/28byj-48.go
return err
}
m.workers.Stop()
if m.workers != nil {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fun! You had a TODO about actually using a mutex to protect state variables. Assuming protecting the assignment/access of workers is part of that TODO.

@stevebriskin
Steve Briskin (stevebriskin) merged commit ade5d98 into main Nov 25, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants