Skip to content

Fix autoreload on SAMD21 #3532

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

Merged
merged 1 commit into from
Oct 9, 2020
Merged

Conversation

tannewt
Copy link
Member

@tannewt tannewt commented Oct 9, 2020

The issue was that a time.sleep() would set the RTC wake up
further into the future even if we wanted to tick every ms. Ticking
every ms is used to time the autoreload delay and without it,
autoreload doesn't work.

Fixes #3528

The issue was that a time.sleep() would set the RTC wake up
further into the future even if we wanted to tick every ms. Ticking
every ms is used to time the autoreload delay and without it,
autoreload doesn't work.

Fixes micropython#3528
@tannewt
Copy link
Member Author

tannewt commented Oct 9, 2020

@todbot, this should fix the autoreload issue.

Copy link
Member

@gamblor21 gamblor21 left a comment

Choose a reason for hiding this comment

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

Built and tested on a Feather M0 Basic that I had tested the issue on previously. These changes fix the problem.

Copy link

@jepler jepler left a comment

Choose a reason for hiding this comment

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

I didn't see anything to be concerned abut in the re-organization of _port_interrupt_after_ticks, and at a high level the explanation of the problem makes sense. No testing performed.

@todbot
Copy link

todbot commented Oct 9, 2020

I'm curious: what's the device-based testing regime like? Is that documented somewhere? I'd like to get into testing stuff like this and would like to leverage any existing work.

And thanks for such a quick turnaround on this!

@tannewt
Copy link
Member Author

tannewt commented Oct 9, 2020

I'm curious: what's the device-based testing regime like? Is that documented somewhere? I'd like to get into testing stuff like this and would like to leverage any existing work.

I think you are assuming we're more rigorous than we are. I just replicated the problem and then fixed it. I didn't test on other devices. I rely on folks trying their own main builds and the latest from S3 as a way to find other issues.

You can test PR changes by either pulling the PR down and building locally or waiting for the CI to complete. Once the CI is complete, you can access the built versions by:

  1. Open the build results page by clicking any of the "Details" links. Example: https://github.com/adafruit/circuitpython/pull/3532/checks?check_run_id=1233432700
  2. Click "Artifacts" in the top right and select the board of interest. It will download a zip of all the different language builds for a board. This button only appears after the entire build is complete.

And thanks for such a quick turnaround on this!

No problem! It's core to the CircuitPython experience so it's good to get fixed.

@tannewt tannewt merged commit c7d87ce into adafruit:main Oct 9, 2020
@todbot
Copy link

todbot commented Oct 9, 2020

oh wow I didn't realize you had CI produce artifacts for every board for every PR! Go github actions I guess eh? This is much easier than the process I just did. (the standard PR pull, build via cmdline, and fish out firmware.uf2)

@tannewt
Copy link
Member Author

tannewt commented Oct 9, 2020

Yup! It's nice but a little slow. :-)

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

Successfully merging this pull request may close these issues.

Auto-reload works only occasionally on file save
4 participants