all: Bump version to 1.22.2.

Signed-off-by: Damien George <damien@micropython.org>

.git-blame-ignore-revs

@@ -1,12 +1,3 @@
-# all: Prune trailing whitespace.
-dda9b9c6da5d3c31fa8769e581a753e95a270803
-
-# all: Remove the "STATIC" macro and just use "static" instead.
-decf8e6a8bb940d5829ca3296790631fcece7b21
-
-# renesas-ra: Fix spelling mistakes found by codespell.
-b3f2f18f927fa2fad10daf63d8c391331f5edf58
-
 # all: Update Python formatting to ruff-format.
 bbd8760bd9a2302e5abee29db279102bb11d7732
 

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,25 @@
+---
+name: Bug report
+about: Report an issue
+title: ''
+labels: bug
+assignees: ''
+
+---
+
+* Please search existing issues before raising a new issue. For questions about MicroPython or for help using MicroPython, or any sort of "how do I?" requests, please use the Discussions tab or raise a documentation request instead.
+
+* In your issue, please include a clear and concise description of what the bug is, the expected output, and how to replicate it.
+
+* If this issue involves external hardware, please include links to relevant datasheets and schematics.
+
+* If you are seeing code being executed incorrectly, please provide a minimal example and expected output (e.g. comparison to CPython).
+
+* For build issues, please include full details of your environment, compiler versions, command lines, and build output.
+
+* Please provide as much information as possible about the version of MicroPython you're running, such as:
+ - firmware file name
+ - git commit hash and port/board
+ - version information shown in the REPL (hit Ctrl-B to see the startup message)
+
+* Remove all placeholder text above before submitting.

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -1,109 +0,0 @@
-name: Bug report
-description: Report a bug or unexpected behaviour
-labels: ["bug"]
-body:
-  - type: markdown
-    attributes:
-      value: |
-        Please provide as much detail as you can, it really helps us find and fix bugs faster.
-
-        #### Not a bug report?
-
-        * If you have a question \"How Do I ...?\", please post it on [GitHub Discussions](https://github.com/orgs/micropython/discussions/) or [Discord](https://discord.gg/RB8HZSAExQ) instead of here.
-        * For missing or incorrect documentation, or feature requests, then please [choose a different issue type](https://github.com/micropython/micropython/issues/new/choose).
-
-        #### Existing issue?
-
-        * Please search for [existing issues](https://github.com/micropython/micropython/issues) matching this bug before reporting.
-  - type: input
-    id: port-board-hw
-    attributes:
-      label: Port, board and/or hardware
-      description: |
-        Which MicroPython port(s) and board(s) are you using?
-      placeholder: |
-        esp32 port, ESP32-Fantastic board.
-    validations:
-      required: true
-  - type: textarea
-    id: version
-    attributes:
-      label: MicroPython version
-      description: |
-        To find the version:
-
-        1. Open a serial REPL.
-        2. Type Ctrl-B to see the startup message.
-        3. Copy-paste that output here.
-
-        If the issue is about building MicroPython, please provide output of `git describe --dirty` and as much information as possible about the build environment.
-
-        If the version or configuration is modified from the official MicroPython releases or the master branch, please tell us the details of this as well.
-      placeholder: |
-        MicroPython v6.28.3 on 2029-01-23; PyBoard 9 with STM32F9
-    validations:
-      required: true
-  - type: textarea
-    id: steps-reproduce
-    attributes:
-      label: Reproduction
-      description: |
-        What steps will reproduce the problem? Please include all details that could be relevant about the environment, configuration, etc.
-
-        If there is Python code to reproduce this issue then please either:
-        a. Type it into a code block below ([code block guide](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-and-highlighting-code-blocks)), or
-        b. Post longer code to a [GitHub gist](https://gist.github.com/), or
-        c. Create a sample project on GitHub.
-
-        For build issues, please provide the exact build commands that you ran.
-      placeholder: |
-        1. Copy paste the code provided below into a new file
-        2. Use `mpremote run` to execute it on the board.
-    validations:
-      required: true
-  - type: textarea
-    id: expected
-    attributes:
-      label: Expected behaviour
-      description: |
-         What did you expect MicroPython to do? If comparing output with CPython or a different MicroPython port/version then please provide that output here.
-      placeholder: |
-        Expected to print "Hello World".
-
-        Here is the correct output, seen with previous MicroPython version v3.14.159:
-
-        > [...]
-  - type: textarea
-    id: what-happened
-    attributes:
-      label: Observed behaviour
-      description: |
-        What actually happened? Where possible please paste exact output, or the complete build log, etc. Very long output can be linked in a [GitHub gist](https://gist.github.com/).
-      placeholder: |
-        This unexpected exception appears:
-
-        > [...]
-    validations:
-      required: true
-  - type: textarea
-    id: additional
-    attributes:
-      label: Additional Information
-      description: |
-        Is there anything else that might help to resolve this issue?
-      value: No, I've provided everything above.
-  - type: dropdown
-    id: code-of-conduct
-    attributes:
-      label: Code of Conduct
-      description: |
-        Do you agree to follow the MicroPython [Code of Conduct](https://github.com/micropython/micropython/blob/master/CODEOFCONDUCT.md) to ensure a safe and respectful space for everyone?
-      options:
-        - "Yes, I agree"
-      multiple: true
-    validations:
-      required: true
-  - type: markdown
-    attributes:
-      value: |
-        Thanks for taking the time to help improve MicroPython.

.github/ISSUE_TEMPLATE/documentation.md

@@ -0,0 +1,16 @@
+---
+name: Documentation issue
+about: Report areas of the documentation or examples that need improvement
+title: 'docs: '
+labels: documentation
+assignees: ''
+
+---
+
+* Please search existing issues before raising a new issue. For questions about MicroPython or for help using MicroPython, or any sort of "how do I?" requests, please use the Discussions tab instead.
+
+* Describe what was missing from the documentation and/or what was incorrect/incomplete.
+
+* If possible, please link to the relevant page on https://docs.micropython.org/
+
+* Remove all placeholder text above before submitting.

.github/ISSUE_TEMPLATE/documentation.yml

@@ -1,46 +0,0 @@
-name: Documentation issue
-description: Report areas of the documentation or examples that need improvement
-title: "docs: "
-labels: ["documentation"]
-body:
-  - type: markdown
-    attributes:
-      value: |
-        This form is for reporting issues with the documentation or examples provided with MicroPython.
-
-        If you have a general question \"How Do I ...?\", please post it on [GitHub Discussions](https://github.com/orgs/micropython/discussions/) or [Discord](https://discord.gg/RB8HZSAExQ) instead of here.
-
-        #### Existing issue?
-
-        * Please search for [existing issues](https://github.com/micropython/micropython/issues) before reporting a new one.
-  - type: input
-    id: page
-    attributes:
-      label: Documentation URL
-      description: |
-        Does this issue relate to a particular page in the [online documentation](https://docs.micropython.org/en/latest/)? If yes, please paste the URL of the page:
-      placeholder: |
-        https://docs.micropython.org/en/latest/
-  - type: textarea
-    id: version
-    attributes:
-      label: Description
-      description: |
-        Please describe what was missing from the documentation and/or what was incorrect/incomplete.
-    validations:
-      required: true
-  - type: dropdown
-    id: code-of-conduct
-    attributes:
-      label: Code of Conduct
-      description: |
-        Do you agree to follow the MicroPython [Code of Conduct](https://github.com/micropython/micropython/blob/master/CODEOFCONDUCT.md) to ensure a safe and respectful space for everyone?
-      options:
-        - "Yes, I agree"
-      multiple: true
-    validations:
-      required: true
-  - type: markdown
-    attributes:
-      value: |
-        Thanks for taking the time to help improve MicroPython.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,24 @@
+---
+name: Feature request
+about: Request a feature or improvement
+title: ''
+labels: enhancement
+assignees: ''
+
+---
+
+* Please search existing issues before raising a new issue. For questions about MicroPython or for help using MicroPython, or any sort of "how do I?" requests, please use the Discussions tab or raise a documentation request instead.
+
+* Describe the feature you'd like to see added to MicroPython. In particular, what does this feature enable and why is it useful. MicroPython aims to strike a balance between functionality and code size, so please consider whether this feature can be optionally enabled and whether it can be provided in other ways (e.g. pure-Python library).
+
+* For core Python features, where possible please include a link to the relevant PEP.
+
+* For new architectures / ports / boards, please provide links to relevant documentation, specifications, and toolchains. Any information about the popularity and unique features about this hardware would also be useful.
+
+* For features for existing ports (e.g. new peripherals or microcontroller features), please describe which port(s) it applies too, and whether this is could be an extension to the machine API or a port-specific module?
+
+* For drivers (e.g. for external hardware), please link to datasheets and/or existing drivers from other sources.
+
+* Who do you expect will implement the feature you are requesting? Would you be willing to sponsor this work?
+
+* Remove all placeholder text above before submitting.

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -1,74 +0,0 @@
-name: Feature request
-description: Request a feature or improvement
-labels: ['enhancement']
-body:
-  - type: markdown
-    attributes:
-      value: |
-        This form is for requesting features or improvements in MicroPython.
-
-        #### Get feedback first
-
-        Before submitting a new feature idea here, suggest starting a discussion on [Discord](https://discord.gg/RB8HZSAExQ) or [GitHub Discussions](https://github.com/orgs/micropython/discussions/) to get early feedback from the community and maintainers.
-
-        #### Not a MicroPython core feature?
-
-        * If you have a question \"How Do I ...?\", please post it on GitHub Discussions or Discord instead of here.
-        * Could this feature be implemented as a pure Python library? If so, please open the request on the [micropython-lib repository](https://github.com/micropython/micropython-lib/issues) instead.
-
-        #### Existing issue?
-
-        * Please search for [existing issues](https://github.com/micropython/micropython/issues) before opening a new one.
-  - type: textarea
-    id: feature
-    attributes:
-      label: Description
-      description: |
-        Describe the feature you'd like to see added to MicroPython. What does this feature enable and why is it useful?
-
-        * For core Python features, where possible please include a link to the relevant PEP or CPython documentation.
-        * For new architectures / ports / boards, please provide links to relevant documentation, specifications, and toolchains. Any information about the popularity and unique features about this hardware would also be useful.
-        * For features for existing ports (e.g. new peripherals or microcontroller features), please describe which port(s) it applies to, and whether this is could be an extension to the machine API or a port-specific module?
-        * For drivers (e.g. for external hardware), please link to datasheets and/or existing drivers from other sources.
-
-        If there is an existing discussion somewhere about this feature, please add a link to it as well.
-    validations:
-      required: true
-  - type: textarea
-    id: size
-    attributes:
-      label: Code Size
-      description: |
-         MicroPython aims to strike a balance between functionality and code size. Can this feature be optionally enabled?
-
-         If you believe the usefulness of this feature would outweigh the additional code size, please explain. (It's OK to say you're unsure here, we're happy to discuss this with you.)
-  - type: dropdown
-    id: implementation
-    attributes:
-      label: Implementation
-      description: |
-        What is your suggestion for implementing this feature?
-
-        (See also: [How to sponsor](https://github.com/sponsors/micropython#sponsors), [How to submit a Pull Request](https://github.com/micropython/micropython/wiki/ContributorGuidelines).)
-      options:
-        - I hope the MicroPython maintainers or community will implement this feature
-        - I intend to implement this feature and would submit a Pull Request if desirable
-        - I would like to sponsor development of this feature
-      multiple: true
-    validations:
-      required: true
-  - type: dropdown
-    id: code-of-conduct
-    attributes:
-      label: Code of Conduct
-      description: |
-        Do you agree to follow the MicroPython [Code of Conduct](https://github.com/micropython/micropython/blob/master/CODEOFCONDUCT.md) to ensure a safe and respectful space for everyone?
-      options:
-        - "Yes, I agree"
-      multiple: true
-    validations:
-      required: true
-  - type: markdown
-    attributes:
-      value: |
-        Thanks for taking the time to suggest improvements for MicroPython.

.github/ISSUE_TEMPLATE/security.md

@@ -0,0 +1,16 @@
+---
+name: Security report
+about: Report a security issue or vulnerability in MicroPython
+title: ''
+labels: security
+assignees: ''
+
+---
+
+* If you need to raise this issue privately with the MicroPython team, please email contact@micropython.org instead.
+
+* Include a clear and concise description of what the security issue is.
+
+* What does this issue allow an attacker to do?
+
+* Remove all placeholder text above before submitting.

.github/ISSUE_TEMPLATE/security.yml

@@ -1,60 +0,0 @@
-name: Security report
-description: Report a security issue or vulnerability in MicroPython
-labels: ["security"]
-body:
-  - type: markdown
-    attributes:
-      value: |
-        This form is for reporting security issues in MicroPython that are not readily exploitable.
-
-        1. For issues that are readily exploitable or have high impact, please email contact@micropython.org instead.
-        1. If this is a question about security, please ask it in [Discussions](https://github.com/orgs/micropython/discussions/) or [Discord](https://discord.gg/RB8HZSAExQ) instead.
-
-        #### Existing issue?
-
-        * Please search for [existing issues](https://github.com/micropython/micropython/issues) before reporting a new one.
-
-  - type: input
-    id: port-board-hw
-    attributes:
-      label: Port, board and/or hardware
-      description: |
-        Which MicroPython port(s) and board(s) are you using?
-      placeholder: |
-        esp32 port, ESP32-Duper board.
-  - type: textarea
-    id: version
-    attributes:
-      label: MicroPython version
-      description: |
-        To find the version:
-
-        1. Open a serial REPL.
-        2. Type Ctrl-B to see the startup message.
-        3. Copy-paste that output here.
-
-        If the version or configuration is modified from the official MicroPython releases or the master branch, please tell us the details of this as well.
-      placeholder: |
-        MicroPython v6.28.3 on 2029-01-23; PyBoard 9 with STM32F9
-  - type: textarea
-    id: report
-    attributes:
-      label: Issue Report
-      description: |
-        Please provide a clear and concise description of the security issue.
-
-        * What does this issue allow an attacker to do?
-        * How does the attacker exploit this issue?
-    validations:
-      required: true
-  - type: dropdown
-    id: code-of-conduct
-    attributes:
-      label: Code of Conduct
-      description: |
-        Do you agree to follow the MicroPython [Code of Conduct](https://github.com/micropython/micropython/blob/master/CODEOFCONDUCT.md) to ensure a safe and respectful space for everyone?
-      options:
-        - "Yes, I agree"
-      multiple: true
-    validations:
-      required: true

.github/pull_request_template.md

@@ -1,33 +0,0 @@
-<!-- Thanks for submitting a Pull Request! We appreciate you spending the
-     time to improve MicroPython. Please provide enough information so that
-     others can review your Pull Request.
-
-     Before submitting, please read:
-     https://github.com/micropython/micropython/blob/master/CODEOFCONDUCT.md
-     https://github.com/micropython/micropython/wiki/ContributorGuidelines
-
-     Please check any CI failures that appear after your Pull Request is opened.
--->
-
-### Summary
-
-<!-- Explain the reason for making this change. What problem does the pull request
-     solve, or what improvement does it add? Add links if relevant. -->
-
-
-### Testing
-
-<!-- Explain what testing you did, and on which boards/ports. If there are
-     boards or ports that you couldn't test, please mention this here as well.
-
-     If you leave this empty then your Pull Request may be closed. -->
-
-
-### Trade-offs and Alternatives
-
-<!-- If the Pull Request has some negative impact (i.e. increased code size)
-     then please explain why you think the trade-off improvement is worth it.
-     If you can think of alternative ways to do this, please explain that here too.
-
-     Delete this heading if not relevant (i.e. small fixes) -->
-

.github/workflows/biome.yml

@@ -1,16 +0,0 @@
-name: JavaScript code lint and formatting with Biome
-
-on: [push, pull_request]
-
-jobs:
-  eslint:
-    runs-on: ubuntu-latest
-    steps:
-    - name: Checkout
-      uses: actions/checkout@v4
-    - name: Setup Biome
-      uses: biomejs/setup-biome@v2
-      with:
-        version: 1.5.3
-    - name: Run Biome
-      run: biome ci --indent-style=space --indent-width=4 tests/ ports/webassembly

.github/workflows/code_formatting.yml

@@ -18,3 +18,13 @@ jobs:
       run: source tools/ci.sh && ci_c_code_formatting_run
     - name: Check code formatting
       run: git diff --exit-code
+
+  code-spelling:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v4
+    - uses: actions/setup-python@v5
+    - name: Install packages
+      run: source tools/ci.sh && ci_code_spell_setup
+    - name: Run spell checker
+      run: source tools/ci.sh && ci_code_spell_run

.github/workflows/code_size.yml

@@ -8,15 +8,9 @@ on:
       - 'tools/**'
       - 'py/**'
       - 'extmod/**'
-      - 'shared/**'
       - 'lib/**'
       - 'ports/bare-arm/**'
-      - 'ports/mimxrt/**'
       - 'ports/minimal/**'
-      - 'ports/rp2/**'
-      - 'ports/samd/**'
-      - 'ports/stm32/**'
-      - 'ports/unix/**'
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
@@ -24,7 +18,7 @@ concurrency:
 
 jobs:
   build:
-    runs-on: ubuntu-22.04
+    runs-on: ubuntu-20.04
     steps:
     - uses: actions/checkout@v4
       with:

.github/workflows/code_size_comment.yml

@@ -11,7 +11,7 @@ concurrency:
 
 jobs:
   comment:
-    runs-on: ubuntu-22.04
+    runs-on: ubuntu-20.04
     steps:
       - name: 'Download artifact'
         id: download-artifact

.github/workflows/codespell.yml

@@ -1,13 +0,0 @@
-name: Check spelling with codespell
-
-on: [push, pull_request]
-
-jobs:
-  codespell:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@v4
-    # codespell version should be kept in sync with .pre-commit-config.yml
-    - run: pip install --user codespell==2.2.6 tomli
-    - run: codespell
-

.github/workflows/ports_esp32.yml

@@ -35,7 +35,7 @@ jobs:
 
     - name: Cached ESP-IDF install
       id: cache_esp_idf
-      uses: actions/cache@v4
+      uses: actions/cache@v3
       with:
         path: |
           ./esp-idf/

.github/workflows/ports_mimxrt.yml

@@ -20,13 +20,8 @@ concurrency:
 jobs:
   build:
     runs-on: ubuntu-20.04
-    defaults:
-      run:
-        working-directory: 'micropython repo'  # test build with space in path
     steps:
     - uses: actions/checkout@v4
-      with:
-        path: 'micropython repo'
     - name: Install packages
       run: source tools/ci.sh && ci_mimxrt_setup
     - name: Build

.github/workflows/ports_qemu-arm.yml

@@ -0,0 +1,32 @@
+name: qemu-arm port
+
+on:
+  push:
+  pull_request:
+    paths:
+      - '.github/workflows/*.yml'
+      - 'tools/**'
+      - 'py/**'
+      - 'extmod/**'
+      - 'shared/**'
+      - 'lib/**'
+      - 'drivers/**'
+      - 'ports/qemu-arm/**'
+      - 'tests/**'
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  build_and_test:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v4
+    - name: Install packages
+      run: source tools/ci.sh && ci_qemu_arm_setup
+    - name: Build and run test suite
+      run: source tools/ci.sh && ci_qemu_arm_build
+    - name: Print failures
+      if: failure()
+      run: grep --before-context=100 --text "FAIL" ports/qemu-arm/build/console.out

.github/workflows/ports_qemu.yml

@@ -1,44 +0,0 @@
-name: qemu port
-
-on:
-  push:
-  pull_request:
-    paths:
-      - '.github/workflows/*.yml'
-      - 'tools/**'
-      - 'py/**'
-      - 'extmod/**'
-      - 'shared/**'
-      - 'lib/**'
-      - 'drivers/**'
-      - 'ports/qemu/**'
-      - 'tests/**'
-
-concurrency:
-  group: ${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: true
-
-jobs:
-  build_and_test_arm:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@v4
-    - name: Install packages
-      run: source tools/ci.sh && ci_qemu_setup_arm
-    - name: Build and run test suite
-      run: source tools/ci.sh && ci_qemu_build_arm
-    - name: Print failures
-      if: failure()
-      run: tests/run-tests.py --print-failures
-
-  build_and_test_rv32:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@v4
-    - name: Install packages
-      run: source tools/ci.sh && ci_qemu_setup_rv32
-    - name: Build and run test suite
-      run: source tools/ci.sh && ci_qemu_build_rv32
-    - name: Print failures
-      if: failure()
-      run: tests/run-tests.py --print-failures

.github/workflows/ports_rp2.yml

@@ -20,13 +20,8 @@ concurrency:
 jobs:
   build:
     runs-on: ubuntu-latest
-    defaults:
-      run:
-        working-directory: 'micropython repo'  # test build with space in path
     steps:
     - uses: actions/checkout@v4
-      with:
-        path: 'micropython repo'
     - name: Install packages
       run: source tools/ci.sh && ci_rp2_setup
     - name: Build

.github/workflows/ports_stm32.yml

@@ -25,7 +25,6 @@ jobs:
         ci_func:  # names are functions in ci.sh
           - stm32_pyb_build
           - stm32_nucleo_build
-          - stm32_misc_build
     runs-on: ubuntu-20.04
     steps:
     - uses: actions/checkout@v4

.github/workflows/ports_unix.yml

@@ -88,11 +88,10 @@ jobs:
         (cd ports/unix && gcov -o build-coverage/py ../../py/*.c || true)
         (cd ports/unix && gcov -o build-coverage/extmod ../../extmod/*.c || true)
     - name: Upload coverage to Codecov
-      uses: codecov/codecov-action@v4
+      uses: codecov/codecov-action@v3
       with:
         fail_ci_if_error: true
         verbose: true
-        token: ${{ secrets.CODECOV_TOKEN }}
     - name: Print failures
       if: failure()
       run: tests/run-tests.py --print-failures
@@ -194,7 +193,7 @@ jobs:
       run: tests/run-tests.py --print-failures
 
   macos:
-    runs-on: macos-latest
+    runs-on: macos-11.0
     steps:
     - uses: actions/checkout@v4
     - uses: actions/setup-python@v5
@@ -235,17 +234,3 @@ jobs:
     - name: Print failures
       if: failure()
       run: tests/run-tests.py --print-failures
-
-  qemu_riscv64:
-    runs-on: ubuntu-latest
-    steps:
-    - uses: actions/checkout@v4
-    - name: Install packages
-      run: source tools/ci.sh && ci_unix_qemu_riscv64_setup
-    - name: Build
-      run: source tools/ci.sh && ci_unix_qemu_riscv64_build
-    - name: Run main test suite
-      run: source tools/ci.sh && ci_unix_qemu_riscv64_run_tests
-    - name: Print failures
-      if: failure()
-      run: tests/run-tests.py --print-failures

.github/workflows/ports_windows.yml

@@ -18,125 +18,7 @@ concurrency:
   cancel-in-progress: true
 
 jobs:
-  build-vs:
-    strategy:
-      fail-fast: false
-      matrix:
-        platform: [x86, x64]
-        configuration: [Debug, Release]
-        variant: [dev, standard]
-        visualstudio: ['2017', '2019', '2022']
-        include:
-        - visualstudio: '2017'
-          runner: windows-latest
-          vs_version: '[15, 16)'
-        - visualstudio: '2019'
-          runner: windows-2019
-          vs_version: '[16, 17)'
-        - visualstudio: '2022'
-          runner: windows-2022
-          vs_version: '[17, 18)'
-        # trim down the number of jobs in the matrix
-        exclude:
-        - variant: standard
-          configuration: Debug
-        - visualstudio: '2019'
-          configuration: Debug
-    env:
-      CI_BUILD_CONFIGURATION: ${{ matrix.configuration }}
-    runs-on: ${{ matrix.runner }}
-    steps:
-    - name: Install Visual Studio 2017
-      if: matrix.visualstudio == '2017'
-      run: |
-        choco install visualstudio2017buildtools
-        choco install visualstudio2017-workload-vctools
-        choco install windows-sdk-8.1
-    - uses: microsoft/setup-msbuild@v2
-      with:
-        vs-version: ${{ matrix.vs_version }}
-    - uses: actions/setup-python@v5
-      if: matrix.runner == 'windows-2019'
-      with:
-        python-version: '3.9'
-    - uses: actions/checkout@v4
-    - name: Build mpy-cross.exe
-      run: msbuild mpy-cross\mpy-cross.vcxproj -maxcpucount -property:Configuration=${{ matrix.configuration }} -property:Platform=${{ matrix.platform }}
-    - name: Update submodules
-      run: git submodule update --init lib/micropython-lib
-    - name: Build micropython.exe
-      run: msbuild ports\windows\micropython.vcxproj -maxcpucount -property:Configuration=${{ matrix.configuration }} -property:Platform=${{ matrix.platform }} -property:PyVariant=${{ matrix.variant }}
-    - name: Get micropython.exe path
-      id: get_path
-      run: |
-        $exePath="$(msbuild ports\windows\micropython.vcxproj -nologo -v:m -t:ShowTargetPath -property:Configuration=${{ matrix.configuration }} -property:Platform=${{ matrix.platform }} -property:PyVariant=${{ matrix.variant }})"
-        echo ("micropython=" + $exePath.Trim()) >> $env:GITHUB_OUTPUT
-    - name: Run tests
-      id: test
-      env:
-        MICROPY_MICROPYTHON: ${{ steps.get_path.outputs.micropython }}
-      working-directory: tests
-      run: python run-tests.py
-    - name: Print failures
-      if: failure() && steps.test.conclusion == 'failure'
-      working-directory: tests
-      run: python run-tests.py --print-failures
-    - name: Run mpy tests
-      id: test_mpy
-      env:
-        MICROPY_MICROPYTHON: ${{ steps.get_path.outputs.micropython }}
-      working-directory: tests
-      run: python run-tests.py --via-mpy -d basics float micropython
-    - name: Print mpy failures
-      if: failure() && steps.test_mpy.conclusion == 'failure'
-      working-directory: tests
-      run: python run-tests.py --print-failures
-
-  build-mingw:
-    strategy:
-      fail-fast: false
-      matrix:
-        variant: [dev, standard]
-        sys: [mingw32, mingw64]
-        include:
-          - sys: mingw32
-            env: i686
-          - sys: mingw64
-            env: x86_64
-    runs-on: windows-2022
-    env:
-      CHERE_INVOKING: enabled_from_arguments
-    defaults:
-      run:
-        shell: msys2 {0}
-    steps:
-    - uses: msys2/setup-msys2@v2
-      with:
-        msystem: ${{ matrix.sys }}
-        update: true
-        install: >-
-          make
-          mingw-w64-${{ matrix.env }}-gcc
-          pkg-config
-          mingw-w64-${{ matrix.env }}-python3
-          git
-          diffutils
-    - uses: actions/checkout@v4
-    - name: Build mpy-cross.exe
-      run: make -C mpy-cross -j2
-    - name: Update submodules
-      run: make -C ports/windows VARIANT=${{ matrix.variant }} submodules
-    - name: Build micropython.exe
-      run: make -C ports/windows -j2 VARIANT=${{ matrix.variant }}
-    - name: Run tests
-      id: test
-      run: make -C ports/windows test_full VARIANT=${{ matrix.variant }}
-    - name: Print failures
-      if: failure() && steps.test.conclusion == 'failure'
-      working-directory: tests
-      run: python run-tests.py --print-failures
-
-  cross-build-on-linux:
+  build:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@v4

.github/workflows/ports_zephyr.yml

@@ -20,15 +20,6 @@ jobs:
   build:
     runs-on: ubuntu-latest
     steps:
-    - uses: jlumbroso/free-disk-space@main
-      with:
-        # Only free up a few things so this step runs quickly.
-        android: false
-        dotnet: true
-        haskell: true
-        large-packages: false
-        docker-images: false
-        swap-storage: false
     - uses: actions/checkout@v4
     - name: Install packages
       run: source tools/ci.sh && ci_zephyr_setup
@@ -36,8 +27,3 @@ jobs:
       run: source tools/ci.sh && ci_zephyr_install
     - name: Build
       run: source tools/ci.sh && ci_zephyr_build
-    - name: Run main test suite
-      run: source tools/ci.sh && ci_zephyr_run_tests
-    - name: Print failures
-      if: failure()
-      run: tests/run-tests.py --print-failures

.github/workflows/ruff.yml

@@ -1,13 +1,11 @@
+# https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python
 name: Python code lint and formatting with ruff
-
 on: [push, pull_request]
-
 jobs:
   ruff:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@v4
-    # ruff version should be kept in sync with .pre-commit-config.yaml
     - run: pip install --user ruff==0.1.3
     - run: ruff check --output-format=github .
     - run: ruff format --diff .

.gitignore

@@ -11,9 +11,8 @@ build/
 build-*/
 docs/genrst/
 
-# Test failure outputs and intermediate artefacts
+# Test failure outputs
 tests/results/*
-tests/ports/unix/ffi_lib.so
 
 # Python cache files
 __pycache__/

.gitmodules

@@ -3,13 +3,13 @@
 	url = https://github.com/micropython/axtls.git
 [submodule "lib/libffi"]
 	path = lib/libffi
-	url = https://github.com/libffi/libffi
+	url = https://github.com/atgreen/libffi
 [submodule "lib/lwip"]
 	path = lib/lwip
 	url = https://github.com/lwip-tcpip/lwip.git
 [submodule "lib/berkeley-db-1.xx"]
 	path = lib/berkeley-db-1.xx
-	url = https://github.com/micropython/berkeley-db-1.xx
+	url = https://github.com/pfalcon/berkeley-db-1.xx
 [submodule "lib/stm32lib"]
 	path = lib/stm32lib
 	url = https://github.com/micropython/stm32lib
@@ -59,12 +59,3 @@
 [submodule "lib/protobuf-c"]
 	path = lib/protobuf-c
 	url = https://github.com/protobuf-c/protobuf-c.git
-[submodule "lib/open-amp"]
-	path = lib/open-amp
-	url = https://github.com/OpenAMP/open-amp.git
-[submodule "lib/libmetal"]
-	path = lib/libmetal
-	url = https://github.com/OpenAMP/libmetal.git
-[submodule "lib/arduino-lib"]
-	path = lib/arduino-lib
-	url = https://github.com/arduino/arduino-lib-mpy.git

.pre-commit-config.yaml

@@ -12,16 +12,7 @@ repos:
         verbose: true
         stages: [commit-msg]
   - repo: https://github.com/charliermarsh/ruff-pre-commit
-    # Version should be kept in sync with .github/workflows/ruff.yml
     rev: v0.1.3
     hooks:
       - id: ruff
       - id: ruff-format
-  - repo: https://github.com/codespell-project/codespell
-    # Version should be kept in sync with .github/workflows/codespell.yml
-    rev: v2.2.6
-    hooks:
-      - id: codespell
-        name: Spellcheck for changed files (codespell)
-        additional_dependencies:
-          - tomli

CODECONVENTIONS.md

@@ -104,22 +104,6 @@ This command may work, please raise a new Issue if it doesn't:
 curl -L https://github.com/Homebrew/homebrew-core/raw/2b07d8192623365078a8b855a164ebcdf81494a6/Formula/uncrustify.rb > uncrustify.rb && brew install uncrustify.rb && rm uncrustify.rb
 ```
 
-Code spell checking
-===================
-
-Code spell checking is done using [codespell](https://github.com/codespell-project/codespell#codespell)
-and runs in a GitHub action in CI.  Codespell is configured via `pyproject.toml`
-to avoid false positives.  It is recommended run codespell before submitting a
-PR.  To simplify this, codespell is configured as a pre-commit hook and will be
-installed if you run `pre-commit install` (see below).
-
-If you want to install and run codespell manually, you can do so by running:
-
-```
-$ pip install codespell tomli
-$ codespell
-```
-
 Automatic Pre-Commit Hooks
 ==========================
 

LICENSE

@@ -1,6 +1,6 @@
 The MIT License (MIT)
 
-Copyright (c) 2013-2024 Damien P. George
+Copyright (c) 2013-2023 Damien P. George
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
@@ -48,17 +48,16 @@ used during the build process and is not part of the compiled source code.
         /cmsis (BSD-3-clause)
         /crypto-algorithms (NONE)
         /libhydrogen (ISC)
-        /libmetal (BSD-3-clause)
         /littlefs (BSD-3-clause)
         /lwip (BSD-3-clause)
         /mynewt-nimble (Apache-2.0)
         /nrfx (BSD-3-clause)
         /nxp_driver (BSD-3-Clause)
         /oofatfs (BSD-1-clause)
-        /open-amp (BSD-3-clause)
         /pico-sdk (BSD-3-clause)
         /re15 (BSD-3-clause)
         /stm32lib (BSD-3-clause)
+        /tinytest (BSD-3-clause)
         /tinyusb (MIT)
         /uzlib (Zlib)
         /wiznet5k (MIT)
@@ -72,7 +71,6 @@ used during the build process and is not part of the compiled source code.
             /ppp_set_auth.* (Apache-2.0)
         /rp2
             /mutex_extra.c (BSD-3-clause)
-            /clocks_extra.c (BSD-3-clause)
         /stm32
             /usbd*.c (MCD-ST Liberty SW License Agreement V2)
             /stm32_it.* (MIT + BSD-3-clause)

README.md

@@ -19,7 +19,7 @@ Python 3.5 and some select features from later versions). The following core
 datatypes are provided: `str`(including basic Unicode support), `bytes`,
 `bytearray`, `tuple`, `list`, `dict`, `set`, `frozenset`, `array.array`,
 `collections.namedtuple`, classes and instances. Builtin modules include
-`os`, `sys`, `time`, `re`, and `struct`, etc. Some ports have support for
+`os`, `sys`, `time`, `re`, and `struct`, etc. Select ports have support for
 `_thread` module (multithreading), `socket` and `ssl` for networking, and
 `asyncio`. Note that only a subset of Python 3 functionality is implemented
 for the data types and modules.
@@ -35,8 +35,8 @@ DAC, PWM, SPI, I2C, CAN, Bluetooth, and USB.
 Getting started
 ---------------
 
-See the [online documentation](https://docs.micropython.org/) for the API
-reference and information about using MicroPython and information about how
+See the [online documentation](https://docs.micropython.org/) for API
+references and information about using MicroPython and information about how
 it is implemented.
 
 We use [GitHub Discussions](https://github.com/micropython/micropython/discussions)
@@ -108,13 +108,13 @@ track of the code size of the core runtime and VM.
 
 In addition, the following ports are provided in this repository:
  - [cc3200](ports/cc3200) -- Texas Instruments CC3200 (including PyCom WiPy).
- - [esp32](ports/esp32) -- Espressif ESP32 SoC (including ESP32S2, ESP32S3, ESP32C3, ESP32C6).
+ - [esp32](ports/esp32) -- Espressif ESP32 SoC (including ESP32S2, ESP32S3, ESP32C3).
  - [esp8266](ports/esp8266) -- Espressif ESP8266 SoC.
  - [mimxrt](ports/mimxrt) -- NXP m.iMX RT (including Teensy 4.x).
  - [nrf](ports/nrf) -- Nordic Semiconductor nRF51 and nRF52.
  - [pic16bit](ports/pic16bit) -- Microchip PIC 16-bit.
  - [powerpc](ports/powerpc) -- IBM PowerPC (including Microwatt)
- - [qemu](ports/qemu) -- QEMU-based emulated target (for testing)
+ - [qemu-arm](ports/qemu-arm) -- QEMU-based emulated target, for testing)
  - [renesas-ra](ports/renesas-ra) -- Renesas RA family.
  - [rp2](ports/rp2) -- Raspberry Pi RP2040 (including Pico and Pico W).
  - [samd](ports/samd) -- Microchip (formerly Atmel) SAMD21 and SAMD51.

docs/conf.py

@@ -68,7 +68,7 @@ master_doc = "index"
 
 # General information about the project.
 project = "MicroPython"
-copyright = "- The MicroPython Documentation is Copyright © 2014-2024, Damien P. George, Paul Sokolovsky, and contributors"
+copyright = "- The MicroPython Documentation is Copyright © 2014-2023, Damien P. George, Paul Sokolovsky, and contributors"
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the

docs/develop/cmodules.rst

@@ -59,7 +59,7 @@ A MicroPython user C module is a directory with the following files:
     SRC_USERMOD_LIB_C += $(EXAMPLE_MOD_DIR)/utils/algorithm.c
 
   Similarly, use ``SRC_USERMOD_CXX`` and ``SRC_USERMOD_LIB_CXX`` for C++
-  source files. If you want to include assembly files use ``SRC_USERMOD_LIB_ASM``.
+  source files.
 
   If you have custom compiler options (like ``-I`` to add directories to search
   for header files), these should be added to ``CFLAGS_USERMOD`` for C code

docs/develop/compiler.rst

@@ -98,7 +98,7 @@ Then also edit ``py/lexer.c`` to add the new keyword literal text:
 .. code-block:: c
    :emphasize-lines: 12
 
-   static const char *const tok_kw[] = {
+   STATIC const char *const tok_kw[] = {
        ...
        "or",
        "pass",
@@ -157,7 +157,7 @@ The most relevant method you should know about is this:
        mp_compile_to_raw_code(parse_tree, source_file, is_repl, &cm);
 
        // Create and return a function object that executes the outer module.
-       return mp_make_function_from_proto_fun(cm.rc, cm.context, NULL);
+       return mp_make_function_from_raw_code(cm.rc, cm.context, NULL);
    }
 
 The compiler compiles the code in four passes: scope, stack size, code size and emit.
@@ -301,7 +301,7 @@ code statement:
 
 .. code-block:: c
 
-   static void emit_native_unary_op(emit_t *emit, mp_unary_op_t op) {
+   STATIC void emit_native_unary_op(emit_t *emit, mp_unary_op_t op) {
         vtype_kind_t vtype;
         emit_pre_pop_reg(emit, &vtype, REG_ARG_2);
         if (vtype == VTYPE_PYOBJ) {

docs/develop/gettingstarted.rst

@@ -112,7 +112,7 @@ Check that you have Python available on your system:
 .. code-block:: bash
 
    $ python3
-   Python 3.5.0 (default, Jul 17 2020, 14:04:10)
+   Python 3.5.0 (default, Jul 17 2020, 14:04:10) 
    [GCC 5.4.0 20160609] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> 

docs/develop/library.rst

@@ -48,16 +48,16 @@ hypothetical new module ``subsystem`` in the file ``modsubsystem.c``:
    #if MICROPY_PY_SUBSYSTEM
 
    // info()
-   static mp_obj_t py_subsystem_info(void) {
+   STATIC mp_obj_t py_subsystem_info(void) {
        return MP_OBJ_NEW_SMALL_INT(42);
    }
    MP_DEFINE_CONST_FUN_OBJ_0(subsystem_info_obj, py_subsystem_info);
 
-   static const mp_rom_map_elem_t mp_module_subsystem_globals_table[] = {
+   STATIC const mp_rom_map_elem_t mp_module_subsystem_globals_table[] = {
        { MP_ROM_QSTR(MP_QSTR___name__), MP_ROM_QSTR(MP_QSTR_subsystem) },
        { MP_ROM_QSTR(MP_QSTR_info), MP_ROM_PTR(&subsystem_info_obj) },
    };
-   static MP_DEFINE_CONST_DICT(mp_module_subsystem_globals, mp_module_subsystem_globals_table);
+   STATIC MP_DEFINE_CONST_DICT(mp_module_subsystem_globals, mp_module_subsystem_globals_table);
 
    const mp_obj_module_t mp_module_subsystem = {
        .base = { &mp_type_module },

docs/develop/natmod.rst

@@ -128,7 +128,7 @@ The file ``factorial.c`` contains:
     #include "py/dynruntime.h"
 
     // Helper function to compute factorial
-    static mp_int_t factorial_helper(mp_int_t x) {
+    STATIC mp_int_t factorial_helper(mp_int_t x) {
         if (x == 0) {
             return 1;
         }
@@ -136,7 +136,7 @@ The file ``factorial.c`` contains:
     }
 
     // This is the function which will be called from Python, as factorial(x)
-    static mp_obj_t factorial(mp_obj_t x_obj) {
+    STATIC mp_obj_t factorial(mp_obj_t x_obj) {
         // Extract the integer from the MicroPython input object
         mp_int_t x = mp_obj_get_int(x_obj);
         // Calculate the factorial
@@ -145,7 +145,7 @@ The file ``factorial.c`` contains:
         return mp_obj_new_int(result);
     }
     // Define a Python reference to the function above
-    static MP_DEFINE_CONST_FUN_OBJ_1(factorial_obj, factorial);
+    STATIC MP_DEFINE_CONST_FUN_OBJ_1(factorial_obj, factorial);
 
     // This is the entry point and is called when the module is imported
     mp_obj_t mpy_init(mp_obj_fun_bc_t *self, size_t n_args, size_t n_kw, mp_obj_t *args) {

docs/develop/optimizations.rst

@@ -33,7 +33,7 @@ Variables
 MicroPython processes local and global variables differently. Global variables
 are stored and looked up from a global dictionary that is allocated on the heap
 (note that each module has its own separate dict, so separate namespace).
-Local variables on the other hand are stored on the Python value stack, which may
+Local variables on the other hand are are stored on the Python value stack, which may
 live on the C stack or on the heap.  They are accessed directly by their offset
 within the Python stack, which is more efficient than a global lookup in a dict.
 

docs/develop/porting.rst

@@ -83,7 +83,7 @@ The basic MicroPython firmware is implemented in the main port file, e.g ``main.
    }
 
    // There is no filesystem so opening a file raises an exception.
-   mp_lexer_t *mp_lexer_new_from_file(qstr filename) {
+   mp_lexer_t *mp_lexer_new_from_file(const char *filename) {
        mp_raise_OSError(MP_ENOENT);
    }
 
@@ -262,17 +262,17 @@ To add a custom module like ``myport``, first add the module definition in a fil
 
    #include "py/runtime.h"
 
-   static mp_obj_t myport_info(void) {
+   STATIC mp_obj_t myport_info(void) {
        mp_printf(&mp_plat_print, "info about my port\n");
        return mp_const_none;
    }
-   static MP_DEFINE_CONST_FUN_OBJ_0(myport_info_obj, myport_info);
+   STATIC MP_DEFINE_CONST_FUN_OBJ_0(myport_info_obj, myport_info);
 
-   static const mp_rom_map_elem_t myport_module_globals_table[] = {
+   STATIC const mp_rom_map_elem_t myport_module_globals_table[] = {
        { MP_OBJ_NEW_QSTR(MP_QSTR___name__), MP_OBJ_NEW_QSTR(MP_QSTR_myport) },
        { MP_ROM_QSTR(MP_QSTR_info), MP_ROM_PTR(&myport_info_obj) },
    };
-   static MP_DEFINE_CONST_DICT(myport_module_globals, myport_module_globals_table);
+   STATIC MP_DEFINE_CONST_DICT(myport_module_globals, myport_module_globals_table);
 
    const mp_obj_module_t myport_module = {
        .base = { &mp_type_module },

docs/differences/modules_preamble.txt

@@ -1,33 +0,0 @@
-.. Preamble section inserted into generated output
-
-Positional-only Parameters
---------------------------
-
-To save code size, many functions that accept keyword arguments in CPython only accept positional arguments in MicroPython.
-
-MicroPython marks positional-only parameters in the same way as CPython, by inserting a ``/`` to mark the end of the positional parameters. Any function whose signature ends in ``/`` takes *only* positional arguments. For more details, see `PEP 570 <https://peps.python.org/pep-0570/>`_.
-
-Example
-~~~~~~~
-
-For example, in CPython 3.4 this is the signature of the constructor ``socket.socket``::
-
-    socket.socket(family=AF_INET, type=SOCK_STREAM, proto=0, fileno=None)
-
-However, the signature documented in :func:`MicroPython<socket.socket>` is::
-
-    socket(af=AF_INET, type=SOCK_STREAM, proto=IPPROTO_TCP, /)
-
-The ``/`` at the end of the parameters indicates that they are all positional-only in MicroPython. The following code works in CPython but not in most MicroPython ports::
-
-    import socket
-    s = socket.socket(type=socket.SOCK_DGRAM)
-
-MicroPython will raise an exception::
-
-    TypeError: function doesn't take keyword arguments
-
-The following code will work in both CPython and MicroPython::
-
-    import socket
-    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

docs/differences/python_37.rst

@@ -105,4 +105,4 @@ Changes to built-in modules:
 
 .. rubric:: Notes
 
-.. [#ftimenanosec] Only :func:`time.time_ns` is implemented.
+.. [#ftimenanosec] Only :func:`time.time_ns` is implemented. 

docs/esp32/quickref.rst

@@ -18,9 +18,6 @@ working with this board it may be useful to get an overview of the microcontroll
    general.rst
    tutorial/index.rst
 
-Note that there are several varieties of ESP32 -- ESP32, ESP32C3, ESP32C6, ESP32S2, ESP32S3 --
-supported by MicroPython, with some differences in functionality between them.
-
 Installing MicroPython
 ----------------------
 
@@ -61,18 +58,12 @@ The :mod:`esp32` module::
     import esp32
 
     esp32.raw_temperature() # read the internal temperature of the MCU, in Fahrenheit
-    esp32.ULP()             # access to the Ultra-Low-Power Co-processor, not on ESP32C3/C6
+    esp32.ULP()             # access to the Ultra-Low-Power Co-processor
 
 Note that the temperature sensor in the ESP32 will typically read higher than
 ambient due to the IC getting warm while it runs.  This effect can be minimised
 by reading the temperature sensor immediately after waking up from sleep.
 
-ESP32C3, ESP32C6, ESP32S2, and ESP32S3 also have an internal temperature sensor available.
-It is implemented a bit differently to the ESP32 and returns the temperature in
-Celsius::
-
-    esp32.mcu_temperature() # read the internal temperature of the MCU, in Celsius
-
 Networking
 ----------
 
@@ -89,7 +80,7 @@ The :mod:`network` module::
     wlan.isconnected()      # check if the station is connected to an AP
     wlan.connect('ssid', 'key') # connect to an AP
     wlan.config('mac')      # get the interface's MAC address
-    wlan.ipconfig('addr4')  # get the interface's IPv4 addresses
+    wlan.ifconfig()         # get the interface's IP/netmask/gw/DNS addresses
 
     ap = network.WLAN(network.AP_IF) # create access-point interface
     ap.config(ssid='ESP-AP') # set the SSID of the access point
@@ -107,7 +98,7 @@ A useful function for connecting to your local WiFi network is::
             wlan.connect('ssid', 'key')
             while not wlan.isconnected():
                 pass
-        print('network config:', wlan.ipconfig('addr4'))
+        print('network config:', wlan.ifconfig())
 
 Once the network is established the :mod:`socket <socket>` module can be used
 to create and use TCP/UDP sockets as usual, and the ``requests`` module for
@@ -130,14 +121,13 @@ To use the wired interfaces one has to specify the pins and mode ::
 
     lan = network.LAN(mdc=PIN_MDC, ...)   # Set the pin and mode configuration
     lan.active(True)                      # activate the interface
-    lan.ipconfig('addr4')                 # get the interface's IPv4 addresses
+    lan.ifconfig()                        # get the interface's IP/netmask/gw/DNS addresses
 
 
 The keyword arguments for the constructor defining the PHY type and interface are:
 
 - mdc=pin-object    # set the mdc and mdio pins.
 - mdio=pin-object
-- reset=pin-object  # set the reset pin of the PHY device.
 - power=pin-object  # set the pin which switches the power of the PHY device.
 - phy_type=<type>   # Select the PHY device type. Supported devices are PHY_LAN8710,
   PHY_LAN8720, PH_IP101, PHY_RTL8201, PHY_DP83848 and PHY_KSZ8041
@@ -660,15 +650,15 @@ SD card
 
 See :ref:`machine.SDCard <machine.SDCard>`. ::
 
-    import machine, os, vfs
+    import machine, os
 
     # Slot 2 uses pins sck=18, cs=5, miso=19, mosi=23
     sd = machine.SDCard(slot=2)
-    vfs.mount(sd, '/sd') # mount
+    os.mount(sd, '/sd')  # mount
 
     os.listdir('/sd')    # list directory contents
 
-    vfs.umount('/sd')    # eject
+    os.umount('/sd')     # eject
 
 RMT
 ---

docs/esp32/tutorial/peripheral_access.rst

@@ -32,18 +32,6 @@ the prescaler of the MCPWM0 peripheral.
     mem32[MCPWM0] = 0x55      # change PWM_CLK_PRESCALE
     print(hex(mem32[MCPWM0])) # read PWM_CLK_CFG_REG
 
-The specific addresses will be different on different ESP32
-models. For example, ESP32-S3 uses these values:
-
-.. code-block:: python3
-
-    DR_REG_DPORT_BASE = const(0x600C_0000)
-    DPORT_PERIP_CLK_EN0_REG = const(DR_REG_DPORT_BASE + 0x0018)
-    DPORT_PERIP_RST_EN0_REG = const(DR_REG_DPORT_BASE + 0x0020)
-    DPORT_PWM0_CLK_EN = const(1 << 17)
-    MCPWM0 = const(0x6001_E000 + 0x0004)
-    ...
-
 Note that before a peripheral can be used its clock must be enabled and it must
 be taken out of reset.  In the above example the following registers are used
 for this:

docs/esp8266/quickref.rst

@@ -59,7 +59,7 @@ The :mod:`network` module::
     wlan.isconnected()      # check if the station is connected to an AP
     wlan.connect('ssid', 'key') # connect to an AP
     wlan.config('mac')      # get the interface's MAC address
-    wlan.ipconfig('addr4')  # get the interface's IPv4 addresses
+    wlan.ifconfig()         # get the interface's IP/netmask/gw/DNS addresses
 
     ap = network.WLAN(network.AP_IF) # create access-point interface
     ap.active(True)         # activate the interface
@@ -76,7 +76,7 @@ A useful function for connecting to your local WiFi network is::
             wlan.connect('ssid', 'key')
             while not wlan.isconnected():
                 pass
-        print('network config:', wlan.ipconfig('addr4'))
+        print('network config:', wlan.ifconfig())
 
 Once the network is established the :mod:`socket <socket>` module can be used
 to create and use TCP/UDP sockets as usual.

docs/esp8266/tutorial/network_basics.rst

@@ -19,10 +19,10 @@ You can check if the interfaces are active by::
 
 You can also check the network settings of the interface by::
 
-    >>> ap_if.ipconfig('addr4')
-    ('192.168.4.1', '255.255.255.0')
+    >>> ap_if.ifconfig()
+    ('192.168.4.1', '255.255.255.0', '192.168.4.1', '8.8.8.8')
 
-The returned values are: IP address and netmask.
+The returned values are: IP address, netmask, gateway, DNS.
 
 Configuration of the WiFi
 -------------------------
@@ -45,8 +45,8 @@ To check if the connection is established use::
 
 Once established you can check the IP address::
 
-    >>> sta_if.ipconfig('addr4')
-    ('192.168.0.2', '255.255.255.0')
+    >>> sta_if.ifconfig()
+    ('192.168.0.2', '255.255.255.0', '192.168.0.1', '8.8.8.8')
 
 You can then disable the access-point interface if you no longer need it::
 
@@ -64,7 +64,7 @@ connect to your WiFi network::
             sta_if.connect('<ssid>', '<key>')
             while not sta_if.isconnected():
                 pass
-        print('network config:', sta_if.ipconfig('addr4'))
+        print('network config:', sta_if.ifconfig())
 
 Sockets
 -------

docs/library/asyncio.rst

@@ -149,7 +149,8 @@ class ThreadSafeFlag
 
     Create a new flag which can be used to synchronise a task with code running
     outside the asyncio loop, such as other threads, IRQs, or scheduler
-    callbacks.  Flags start in the cleared state.
+    callbacks.  Flags start in the cleared state.  The class does not currently
+    work under the Unix build of MicroPython.
 
 .. method:: ThreadSafeFlag.set()
 

docs/library/bluetooth.rst

@@ -312,7 +312,7 @@ Broadcaster Role (Advertiser)
     in all broadcasts, and *resp_data* is send in reply to an active scan.
 
     **Note:** if *adv_data* (or *resp_data*) is ``None``, then the data passed
-    to the previous call to ``gap_advertise`` will be reused. This allows a
+    to the previous call to ``gap_advertise`` will be re-used. This allows a
     broadcaster to resume advertising with just ``gap_advertise(interval_us)``.
     To clear the advertising payload pass an empty ``bytes``, i.e. ``b''``.
 
@@ -722,7 +722,7 @@ Pairing and bonding
     and ``_IRQ_SET_SECRET`` events.
 
     **Note:** This is currently only supported when using the NimBLE stack on
-    ESP32, STM32 and Unix.
+    STM32 and Unix (not ESP32).
 
 .. method:: BLE.gap_pair(conn_handle, /)
 

docs/library/builtins.rst

@@ -82,10 +82,6 @@ Functions and types
       In MicroPython, `byteorder` parameter must be positional (this is
       compatible with CPython).
 
-      .. note:: The optional ``signed`` kwarg from CPython is not supported.
-                MicroPython currently converts negative integers as signed,
-                and positive as unsigned. (:ref:`Details <cpydiff_types_int_to_bytes>`.)
-
 .. function:: isinstance()
 
 .. function:: issubclass()

docs/library/collections.rst

@@ -18,9 +18,7 @@ Classes
     appends and pops from either side of the deque.  New deques are created
     using the following arguments:
 
-        - *iterable* is an iterable used to populate the deque when it is
-          created.  It can be an empty tuple or list to create a deque that
-          is initially empty.
+        - *iterable* must be the empty tuple, and the new deque is created empty.
 
         - *maxlen* must be specified and the deque will be bounded to this
           maximum length.  Once the deque is full, any new items added will
@@ -28,37 +26,18 @@ Classes
 
         - The optional *flags* can be 1 to check for overflow when adding items.
 
-    Deque objects support `bool`, `len`, iteration and subscript load and store.
-    They also have the following methods:
+    As well as supporting `bool` and `len`, deque objects have the following
+    methods:
 
     .. method:: deque.append(x)
 
         Add *x* to the right side of the deque.
-        Raises ``IndexError`` if overflow checking is enabled and there is
-        no more room in the queue.
-
-    .. method:: deque.appendleft(x)
-
-        Add *x* to the left side of the deque.
-        Raises ``IndexError`` if overflow checking is enabled and there is
-        no more room in the queue.
-
-    .. method:: deque.pop()
-
-        Remove and return an item from the right side of the deque.
-        Raises ``IndexError`` if no items are present.
+        Raises IndexError if overflow checking is enabled and there is no more room left.
 
     .. method:: deque.popleft()
 
         Remove and return an item from the left side of the deque.
-        Raises ``IndexError`` if no items are present.
-
-    .. method:: deque.extend(iterable)
-
-        Extend the deque by appending all the items from *iterable* to
-        the right of the deque.
-        Raises ``IndexError`` if overflow checking is enabled and there is
-        no more room in the deque.
+        Raises IndexError if no items are present.
 
 .. function:: namedtuple(name, fields)
 

docs/library/esp32.rst

@@ -114,7 +114,7 @@ methods to enable over-the-air (OTA) updates.
 
     These methods implement the simple and :ref:`extended
     <block-device-interface>` block protocol defined by
-    :class:`vfs.AbstractBlockDev`.
+    :class:`os.AbstractBlockDev`.
 
 .. method:: Partition.set_boot()
 

docs/library/index.rst

@@ -103,9 +103,7 @@ the following libraries.
    micropython.rst
    neopixel.rst
    network.rst
-   openamp.rst
    uctypes.rst
-   vfs.rst
 
 The following libraries provide drivers for hardware components.
 

docs/library/machine.ADCBlock.rst

@@ -26,7 +26,7 @@ Constructors
 
    Access the ADC peripheral identified by *id*, which may be an integer
    or string.
-
+   
    The *bits* argument, if given, sets the resolution in bits of the
    conversion process.  If not specified then the previous or default
    resolution is used.

docs/library/machine.PWM.rst

@@ -86,7 +86,7 @@ Specific PWM class implementations
 
 The following concrete class(es) implement enhancements to the PWM class.
 
-   | :ref:`pyb.Timer for PyBoard <pyb.Timer>`
+   | :ref:`pyb.Timer for PyBoard <pyb.Timer>`  
 
 Limitations of PWM
 ------------------
@@ -103,7 +103,7 @@ Limitations of PWM
   Some ports like the RP2040 one use a fractional divider, which allow a finer
   granularity of the frequency at higher frequencies by switching the PWM
   pulse duration between two adjacent values, such that the resulting average
-  frequency is more close to the intended one, at the cost of spectral purity.
+  frequency is more close to the intended one, at the cost of spectral purity. 
 
 * The duty cycle has the same discrete nature and its absolute accuracy is not
   achievable.  On most hardware platforms the duty will be applied at the next

docs/library/machine.Pin.rst

@@ -238,12 +238,6 @@ The following methods are not part of the core Pin API and only implemented on c
 
    Availability: cc3200 port.
 
-.. method:: Pin.toggle()
-
-   Toggle output pin from "0" to "1" or vice-versa.
-
-   Availability: mimxrt, samd, rp2 ports.
-
 Constants
 ---------
 

docs/library/machine.RTC.rst

@@ -75,21 +75,6 @@ Methods
       - ``wake`` specifies the sleep mode from where this interrupt can wake
         up the system.
 
-.. method:: RTC.memory([data])
-
-   ``RTC.memory(data)`` will write *data* to the RTC memory, where *data* is any
-   object which supports the buffer protocol (including `bytes`, `bytearray`,
-   `memoryview` and `array.array`). ``RTC.memory()`` reads RTC memory and returns
-   a `bytes` object.
-
-   Data written to RTC user memory is persistent across restarts, including
-   `machine.soft_reset()` and `machine.deepsleep()`.
-
-   The maximum length of RTC user memory is 2048 bytes by default on esp32,
-   and 492 bytes on esp8266.
-
-   Availability: esp32, esp8266 ports.
-
 Constants
 ---------
 

docs/library/machine.SD.rst

@@ -20,11 +20,11 @@ more info regarding the pins which can be remapped to be used with a SD card.
 Example usage::
 
     from machine import SD
-    import vfs
+    import os
     # clk cmd and dat0 pins must be passed along with
     # their respective alternate functions
     sd = machine.SD(pins=('GP10', 'GP11', 'GP15'))
-    vfs.mount(sd, '/sd')
+    os.mount(sd, '/sd')
     # do normal file operations
 
 Constructors

docs/library/machine.SDCard.rst

@@ -27,10 +27,10 @@ vary from platform to platform.
 
     This class provides access to SD or MMC storage cards using either
     a dedicated SD/MMC interface hardware or through an SPI channel.
-    The class implements the block protocol defined by :class:`vfs.AbstractBlockDev`.
+    The class implements the block protocol defined by :class:`os.AbstractBlockDev`.
     This allows the mounting of an SD card to be as simple as::
 
-      vfs.mount(machine.SDCard(), "/sd")
+      os.mount(machine.SDCard(), "/sd")
 
     The constructor takes the following parameters:
 

docs/library/machine.UART.rst

@@ -152,6 +152,31 @@ Methods
    Send a break condition on the bus. This drives the bus low for a duration
    longer than required for a normal transmission of a character.
 
+.. method:: UART.irq(trigger, priority=1, handler=None, wake=machine.IDLE)
+
+   Create a callback to be triggered when data is received on the UART.
+
+       - *trigger* can only be ``UART.RX_ANY``
+       - *priority* level of the interrupt. Can take values in the range 1-7.
+         Higher values represent higher priorities.
+       - *handler* an optional function to be called when new characters arrive.
+       - *wake* can only be ``machine.IDLE``.
+
+   .. note::
+
+      The handler will be called whenever any of the following two conditions are met:
+
+          - 8 new characters have been received.
+          - At least 1 new character is waiting in the Rx buffer and the Rx line has been
+            silent for the duration of 1 complete frame.
+
+      This means that when the handler function is called there will be between 1 to 8
+      characters waiting.
+
+   Returns an irq object.
+
+   Availability: WiPy.
+
 .. method:: UART.flush()
 
    Waits until all data has been sent. In case of a timeout, an exception is raised. The timeout
@@ -160,7 +185,7 @@ Methods
 
    .. note::
 
-       For the esp8266 and nrf ports the call returns while the last byte is sent.
+       For the rp2, esp8266 and nrf ports the call returns while the last byte is sent.
        If required, a one character wait time has to be added in the calling script.
 
    Availability: rp2, esp32, esp8266, mimxrt, cc3200, stm32, nrf ports, renesas-ra
@@ -172,91 +197,17 @@ Methods
 
    .. note::
 
-       For the esp8266 and nrf ports the call may return ``True`` even if the last byte
+       For the rp2, esp8266 and nrf ports the call may return ``True`` even if the last byte
        of a transfer is still being sent. If required, a one character wait time has to be
        added in the calling script.
 
    Availability: rp2, esp32, esp8266, mimxrt, cc3200, stm32, nrf ports, renesas-ra
 
-.. method:: UART.irq(handler=None, trigger=0, hard=False)
-
-   Configure an interrupt handler to be called when a UART event occurs.
-
-   The arguments are:
-
-     - *handler* is an optional function to be called when the interrupt event
-       triggers.  The handler must take exactly one argument which is the
-       ``UART`` instance.
-
-     - *trigger* configures the event(s) which can generate an interrupt.
-       Possible values are a mask of one or more of the following:
-
-       - ``UART.IRQ_RXIDLE`` interrupt after receiving at least one character
-         and then the RX line goes idle.
-       - ``UART.IRQ_RX`` interrupt after each received character.
-       - ``UART.IRQ_TXIDLE`` interrupt after or while the last character(s) of
-         a message are or have been sent.
-       - ``UART.IRQ_BREAK`` interrupt when a break state is detected at RX
-
-     - *hard* if true a hardware interrupt is used.  This reduces the delay
-       between the pin change and the handler being called. Hard interrupt
-       handlers may not allocate memory; see :ref:`isr_rules`.
-
-   Returns an irq object.
-
-   Due to limitations of the hardware not all trigger events are available on all ports.
-
-   .. table:: Availability of triggers
-      :align: center 
-
-      ============== ========== ====== ========== =========
-      Port / Trigger IRQ_RXIDLE IRQ_RX IRQ_TXIDLE IRQ_BREAK
-      ============== ========== ====== ========== =========
-      CC3200                      yes
-      ESP32            yes        yes                yes
-      MIMXRT           yes                yes
-      NRF                         yes     yes
-      RENESAS-RA       yes        yes
-      RP2              yes                yes        yes
-      SAMD             yes        yes     yes
-      STM32            yes        yes
-      ============== ========== ====== ========== =========
-
-
-   .. note::
-     - The ESP32 port does not support the option hard=True.
-
-     - The rp2 port's UART.IRQ_TXIDLE is only triggered when the message
-       is longer than 5 characters and the trigger happens when still 5 characters
-       are to be sent.
-
-     - The rp2 port's UART.IRQ_BREAK needs receiving valid characters for triggering
-       again.
-
-     - The SAMD port's UART.IRQ_TXIDLE is triggered while the last character is sent.
-
-     - On STM32F4xx MCU's, using the trigger UART.IRQ_RXIDLE the handler will be called once
-       after the first character and then after the end of the message, when the line is
-       idle.
-
-
-   Availability: cc3200, esp32, mimxrt, nrf, renesas-ra, rp2, samd, stm32.
-
 Constants
 ---------
 
-.. data:: UART.RTS
-          UART.CTS
+.. data:: UART.RX_ANY
 
-    Flow control options.
+    IRQ trigger sources
 
-    Availability: esp32, mimxrt, renesas-ra, rp2, stm32.
-
-.. data:: UART.IRQ_RXIDLE
-          UART.IRQ_RX
-          UART.IRQ_TXIDLE
-          UART.IRQ_BREAK
-
-    IRQ trigger sources.
-
-    Availability: renesas-ra, stm32, esp32, rp2040, mimxrt, samd, cc3200.
+    Availability: WiPy.

docs/library/machine.USBDevice.rst

@@ -1,303 +0,0 @@
-.. currentmodule:: machine
-.. _machine.USBDevice:
-
-class USBDevice -- USB Device driver
-====================================
-
-.. note:: ``machine.USBDevice`` is currently only supported on the rp2 and samd
-          ports.
-
-USBDevice provides a low-level Python API for implementing USB device functions using
-Python code.
-
-.. warning:: This low-level API assumes familiarity with the USB standard. There
-   are high-level `usb driver modules in micropython-lib`_ which provide a
-   simpler interface and more built-in functionality.
-
-Terminology
------------
-
-- A "Runtime" USB device interface or driver is one which is defined using this
-  Python API after MicroPython initially starts up.
-
-- A "Built-in" USB device interface or driver is one that is compiled into the
-  MicroPython firmware, and is always available. Examples are USB-CDC (serial
-  port) which is usually enabled by default. Built-in USB-MSC (Mass Storage) is an
-  option on some ports.
-
-Lifecycle
----------
-
-Managing a runtime USB interface can be tricky, especially if you are communicating
-with MicroPython over a built-in USB-CDC serial port that's part of the same USB
-device.
-
-- A MicroPython soft reset will always clear all runtime USB interfaces, which
-  results in the entire USB device disconnecting from the host. If MicroPython
-  is also providing a built-in USB-CDC serial port then this will re-appear
-  after the soft reset.
-
-  This means some functions (like ``mpremote run``) that target the USB-CDC
-  serial port will immediately fail if a runtime USB interface is active,
-  because the port goes away when ``mpremote`` triggers a soft reset. The
-  operation should succeed on the second try, as after the soft reset there is
-  no more runtime USB interface.
-
-- To configure a runtime USB device on every boot, it's recommended to place the
-  configuration code in the ``boot.py`` file on the :ref:`device VFS
-  <filesystem>`. On each reset this file is executed before the USB subsystem is
-  initialised (and before ``main.py``), so it allows the board to come up with the runtime
-  USB device immediately.
-
-- For development or debugging, it may be convenient to connect a hardware
-  serial REPL and disable the built-in USB-CDC serial port entirely. Not all ports
-  support this (currently only ``rp2``). The custom build should be configured
-  with ``#define MICROPY_HW_USB_CDC (0)`` and ``#define
-  MICROPY_HW_ENABLE_UART_REPL (1)``.
-
-Constructors
-------------
-
-.. class:: USBDevice()
-
-   Construct a USBDevice object.
-
-   .. note:: This object is a singleton, each call to this constructor
-             returns the same object reference.
-
-Methods
--------
-
-.. method:: USBDevice.config(desc_dev, desc_cfg, desc_strs=None, open_itf_cb=None, reset_cb=None, control_xfer_cb=None, xfer_cb=None)
-
-    Configures the ``USBDevice`` singleton object with the USB runtime device
-    state and callback functions:
-
-    - ``desc_dev`` - A bytes-like object containing
-      the new USB device descriptor.
-
-    - ``desc_cfg`` - A bytes-like object containing the
-      new USB configuration descriptor.
-
-    - ``desc_strs`` - Optional object holding strings or bytes objects
-       containing USB string descriptor values. Can be a list, a dict, or any
-       object which supports subscript indexing with integer keys (USB string
-       descriptor index).
-
-       Strings are an optional USB feature, and this parameter can be unset
-       (default) if no strings are referenced in the device and configuration
-       descriptors, or if only built-in strings should be used.
-
-       Apart from index 0, all the string values should be plain ASCII. Index 0
-       is the special "languages" USB descriptor, represented as a bytes object
-       with a custom format defined in the USB standard. ``None`` can be
-       returned at index 0 in order to use a default "English" language
-       descriptor.
-
-       To fall back to providing a built-in string value for a given index, a
-       subscript lookup can return ``None``, raise ``KeyError``, or raise
-       ``IndexError``.
-
-    - ``open_itf_cb`` - This callback is called once for each interface
-      or Interface Association Descriptor in response to a Set
-      Configuration request from the USB Host (the final stage before
-      the USB device is available to the host).
-
-      The callback takes a single argument, which is a memoryview of the
-      interface or IAD descriptor that the host is accepting (including
-      all associated descriptors). It is a view into the same
-      ``desc_cfg`` object that was provided as a separate
-      argument to this function. The memoryview is only valid until the
-      callback function returns.
-
-    - ``reset_cb`` - This callback is called when the USB host performs
-      a bus reset. The callback takes no arguments. Any in-progress
-      transfers will never complete. The USB host will most likely
-      proceed to re-enumerate the USB device by calling the descriptor
-      callbacks and then ``open_itf_cb()``.
-
-    - ``control_xfer_cb`` - This callback is called one or more times
-      for each USB control transfer (device Endpoint 0). It takes two
-      arguments.
-
-      The first argument is the control transfer stage. It is one of:
-
-      - ``1`` for SETUP stage.
-      - ``2`` for DATA stage.
-      - ``3`` for ACK stage.
-
-      Second argument is a memoryview to read the USB control request
-      data for this stage. The memoryview is only valid until the
-      callback function returns. Data in this memoryview will be the same
-      across each of the three stages of a single transfer.
-
-      A successful transfer consists of this callback being called in sequence
-      for the three stages. Generally speaking, if a device wants to do
-      something in response to a control request then it's best to wait until
-      the ACK stage to confirm the host controller completed the transfer as
-      expected.
-
-      The callback should return one of the following values:
-
-      - ``False`` to stall the endpoint and reject the transfer. It won't
-        proceed to any remaining stages.
-      - ``True`` to continue the transfer to the next stage.
-      - A buffer object can be returned at the SETUP stage when the transfer
-        will send or receive additional data. Typically this is the case when
-        the ``wLength`` field in the request has a non-zero value. This should
-        be a writable buffer for an ``OUT`` direction transfer, or a readable
-        buffer with data for an ``IN`` direction transfer.
-
-    - ``xfer_cb`` - This callback is called whenever a non-control
-      transfer submitted by calling :func:`USBDevice.submit_xfer` completes.
-
-      The callback has three arguments:
-
-      1. The Endpoint number for the completed transfer.
-      2. Result value: ``True`` if the transfer succeeded, ``False``
-         otherwise.
-      3. Number of bytes successfully transferred. In the case of a
-         "short" transfer, The result is ``True`` and ``xferred_bytes``
-         will be smaller than the length of the buffer submitted for the
-         transfer.
-
-      .. note:: If a bus reset occurs (see :func:`USBDevice.reset`),
-                ``xfer_cb`` is not called for any transfers that have not
-                already completed.
-
-.. method:: USBDevice.active(self, [value] /)
-
-    Returns the current active state of this runtime USB device as a
-    boolean. The runtime USB device is "active" when it is available to
-    interact with the host, it doesn't mean that a USB Host is actually
-    present.
-
-    If the optional ``value`` argument is set to a truthy value, then
-    the USB device will be activated.
-
-    If the optional ``value`` argument is set to a falsey value, then
-    the USB device is deactivated. While the USB device is deactivated,
-    it will not be detected by the USB Host.
-
-    To simulate a disconnect and a reconnect of the USB device, call
-    ``active(False)`` followed by ``active(True)``. This may be
-    necessary if the runtime device configuration has changed, so that
-    the host sees the new device.
-
-.. attribute:: USBDevice.builtin_driver
-
-   This attribute holds the current built-in driver configuration, and must be
-   set to one of the ``USBDevice.BUILTIN_`` named constants defined on this object.
-
-   By default it holds the value :data:`USBDevice.BUILTIN_NONE`.
-
-   Runtime USB device must be inactive when setting this field. Call the
-   :func:`USBDevice.active` function to deactivate before setting if necessary
-   (and again to activate after setting).
-
-   If this value is set to any value other than :data:`USBDevice.BUILTIN_NONE` then
-   the following restrictions apply to the :func:`USBDevice.config` arguments:
-
-   - ``desc_cfg`` should begin with the built-in USB interface descriptor data
-     accessible via :data:`USBDevice.builtin_driver` attribute ``desc_cfg``.
-     Descriptors appended after the built-in configuration descriptors should use
-     interface, string and endpoint numbers starting from the max built-in values
-     defined in :data:`USBDevice.builtin_driver` attributes ``itf_max``, ``str_max`` and
-     ``ep_max``.
-
-   - The ``bNumInterfaces`` field in the built-in configuration
-     descriptor will also need to be updated if any new interfaces
-     are appended to the end of ``desc_cfg``.
-
-   - ``desc_strs`` should either be ``None`` or a list/dictionary where index
-     values less than ``USBDevice.builtin_driver.str_max`` are missing or have
-     value ``None``. This reserves those string indexes for the built-in
-     drivers. Placing a different string at any of these indexes overrides that
-     string in the built-in driver.
-
-.. method:: USBDevice.remote_wakeup(self)
-
-    Wake up host if we are in suspend mode and the REMOTE_WAKEUP feature
-    is enabled by the host. This has to be enabled in the USB attributes,
-    and on the host. Returns ``True`` if remote wakeup was enabled and
-    active and the host was woken up.
-
-.. method:: USBDevice.submit_xfer(self, ep, buffer /)
-
-            Submit a USB transfer on endpoint number ``ep``. ``buffer`` must be
-            an object implementing the buffer interface, with read access for
-            ``IN`` endpoints and write access for ``OUT`` endpoints.
-
-            .. note:: ``ep`` cannot be the control Endpoint number 0. Control
-               transfers are built up through successive executions of
-               ``control_xfer_cb``, see above.
-
-            Returns ``True`` if successful, ``False`` if the transfer could not
-            be queued (as USB device is not configured by host, or because
-            another transfer is queued on this endpoint.)
-
-            When the USB host completes the transfer, the ``xfer_cb`` callback
-            is called (see above).
-
-            Raises ``OSError`` with reason ``MP_EINVAL`` If the USB device is not
-            active.
-
-.. method:: USBDevice.stall(self, ep, [stall] /)
-
-            Calling this function gets or sets the STALL state of a device endpoint.
-
-            ``ep`` is the number of the endpoint.
-
-            If the optional ``stall`` parameter is set, this is a boolean flag
-            for the STALL state.
-
-            The return value is the current stall state of the endpoint (before
-            any change made by this function).
-
-            An endpoint that is set to STALL may remain stalled until this
-            function is called again, or STALL may be cleared automatically by
-            the USB host.
-
-            Raises ``OSError`` with reason ``MP_EINVAL`` If the USB device is not
-            active.
-
-Constants
----------
-
-.. data:: USBDevice.BUILTIN_NONE
-.. data:: USBDevice.BUILTIN_DEFAULT
-.. data:: USBDevice.BUILTIN_CDC
-.. data:: USBDevice.BUILTIN_MSC
-.. data:: USBDevice.BUILTIN_CDC_MSC
-
-          These constant objects hold the built-in descriptor data which is
-          compiled into the MicroPython firmware. ``USBDevice.BUILTIN_NONE`` and
-          ``USBDevice.BUILTIN_DEFAULT`` are always present. Additional objects may be present
-          depending on the firmware build configuration and the actual built-in drivers.
-
-          .. note:: Currently at most one of ``USBDevice.BUILTIN_CDC``,
-                    ``USBDevice.BUILTIN_MSC`` and ``USBDevice.BUILTIN_CDC_MSC`` is defined
-                    and will be the same object as ``USBDevice.BUILTIN_DEFAULT``.
-                    These constants are defined to allow run-time detection of
-                    the built-in driver (if any). Support for selecting one of
-                    multiple built-in driver configurations may be added in the
-                    future.
-
-          These values are assigned to :data:`USBDevice.builtin_driver` to get/set the
-          built-in configuration.
-
-          Each object contains the following read-only fields:
-
-          - ``itf_max`` - One more than the highest bInterfaceNumber value used
-            in the built-in configuration descriptor.
-          - ``ep_max`` - One more than the highest bEndpointAddress value used
-            in the built-in configuration descriptor. Does not include any
-            ``IN`` flag bit (0x80).
-          - ``str_max`` - One more than the highest string descriptor index
-            value used by any built-in descriptor.
-          - ``desc_dev`` - ``bytes`` object containing the built-in USB device
-            descriptor.
-          - ``desc_cfg`` - ``bytes`` object containing the complete built-in USB
-            configuration descriptor.
-
-.. _usb driver modules in micropython-lib: https://github.com/micropython/micropython-lib/tree/master/micropython/usb#readme

docs/library/machine.rst

@@ -127,20 +127,14 @@ Power related functions
 
 .. function:: idle()
 
-   Gates the clock to the CPU, useful to reduce power consumption at any time
-   during short or long periods. Peripherals continue working and execution
-   resumes as soon as any interrupt is triggered, or at most one millisecond
-   after the CPU was paused.
-
-   It is recommended to call this function inside any tight loop that is
-   continuously checking for an external change (i.e. polling). This will reduce
-   power consumption without significantly impacting performance. To reduce
-   power consumption further then see the :func:`lightsleep`,
-   :func:`time.sleep()` and :func:`time.sleep_ms()` functions.
+   Gates the clock to the CPU, useful to reduce power consumption at any time during
+   short or long periods. Peripherals continue working and execution resumes as soon
+   as any interrupt is triggered (on many ports this includes system timer
+   interrupt occurring at regular intervals on the order of millisecond).
 
 .. function:: sleep()
 
-   .. note:: This function is deprecated, use :func:`lightsleep()` instead with no arguments.
+   .. note:: This function is deprecated, use `lightsleep()` instead with no arguments.
 
 .. function:: lightsleep([time_ms])
               deepsleep([time_ms])
@@ -271,4 +265,3 @@ Classes
    machine.WDT.rst
    machine.SD.rst
    machine.SDCard.rst
-   machine.USBDevice.rst

docs/library/math.rst

@@ -125,11 +125,8 @@ Functions
    Return the natural logarithm of the gamma function of ``x``.
 
 .. function:: log(x)
-              log(x, base)
 
-   With one argument, return the natural logarithm of *x*.
-
-   With two arguments, return the logarithm of *x* to the given *base*.
+   Return the natural logarithm of ``x``.
 
 .. function:: log10(x)
 

docs/library/micropython.rst

@@ -136,14 +136,6 @@ Functions
    the heap may be locked) and scheduling a function to call later will lift
    those restrictions.
 
-   On multi-threaded ports, the scheduled function's behaviour depends on
-   whether the Global Interpreter Lock (GIL) is enabled for the specific port:
-
-   - If GIL is enabled, the function can preempt any thread and run in its
-     context.
-   - If GIL is disabled, the function will only preempt the main thread and run
-     in its context.
-
    Note: If `schedule()` is called from a preempting IRQ, when memory
    allocation is not allowed and the callback to be passed to `schedule()` is
    a bound method, passing this directly will fail. This is because creating a
@@ -155,71 +147,3 @@ Functions
 
    There is a finite queue to hold the scheduled functions and `schedule()`
    will raise a `RuntimeError` if the queue is full.
-
-Classes
--------
-
-.. class:: RingIO(size)
-.. class:: RingIO(buffer)
-   :noindex:
-
-   Provides a fixed-size ringbuffer for bytes with a stream interface. Can be
-   considered like a fifo queue variant of `io.BytesIO`.
-
-   When created with integer size a suitable buffer will be allocated.
-   Alternatively a `bytearray` or similar buffer protocol object can be provided
-   to the constructor for in-place use.
-
-   The classic ringbuffer algorithm is used which allows for any size buffer
-   to be used however one byte will be consumed for tracking. If initialised
-   with an integer size this will be accounted for, for example ``RingIO(16)``
-   will allocate a 17 byte buffer internally so it can hold 16 bytes of data.
-   When passing in a pre-allocated buffer however one byte less than its
-   original length will be available for storage, eg. ``RingIO(bytearray(16))``
-   will only hold 15 bytes of data.
-
-   A RingIO instance can be IRQ / thread safe when used to pass data in a single
-   direction eg. when written to in an IRQ and read from in a non-IRQ function
-   (or vice versa). This does not hold if you try to eg. write to a single instance
-   from both IRQ and non-IRQ code, this would often cause data corruption.
-
-    .. method:: RingIO.any()
-
-        Returns an integer counting the number of characters that can be read.
-
-    .. method:: RingIO.read([nbytes])
-
-        Read available characters. This is a non-blocking function. If ``nbytes``
-        is specified then read at most that many bytes, otherwise read as much
-        data as possible.
-
-        Return value: a bytes object containing the bytes read. Will be
-        zero-length bytes object if no data is available.
-
-    .. method:: RingIO.readline([nbytes])
-
-        Read a line, ending in a newline character or return if one exists in
-        the buffer, else return available bytes in buffer. If ``nbytes`` is
-        specified then read at most that many bytes.
-
-        Return value: a bytes object containing the line read.
-
-    .. method:: RingIO.readinto(buf[, nbytes])
-
-        Read available bytes into the provided ``buf``.  If ``nbytes`` is
-        specified then read at most that many bytes.  Otherwise, read at
-        most ``len(buf)`` bytes.
-
-        Return value: Integer count of the number of bytes read into ``buf``.
-
-    .. method:: RingIO.write(buf)
-
-        Non-blocking write of bytes from ``buf`` into the ringbuffer, limited
-        by the available space in the ringbuffer.
-
-        Return value: Integer count of bytes written.
-
-    .. method:: RingIO.close()
-
-        No-op provided as part of standard `stream` interface. Has no effect
-        on data in the ringbuffer.

docs/library/neopixel.rst

@@ -43,8 +43,7 @@ Constructors
         - *pin* is a machine.Pin instance.
         - *n* is the number of LEDs in the strip.
         - *bpp* is 3 for RGB LEDs, and 4 for RGBW LEDs.
-        - *timing* is 0 for 400KHz, and 1 for 800kHz LEDs (most are 800kHz). You
-          may also supply a timing tuple as accepted by `machine.bitstream()`.
+        - *timing* is 0 for 400KHz, and 1 for 800kHz LEDs (most are 800kHz).
 
 Pixel access methods
 --------------------

docs/library/network.LAN.rst

@@ -10,7 +10,7 @@ Example usage::
 
     import network
     nic = network.LAN(0)
-    print(nic.ipconfig("addr4"))
+    print(nic.ifconfig())
 
     # now use socket as usual
     ...

docs/library/network.PPP.rst

@@ -1,98 +0,0 @@
-.. currentmodule:: network
-.. _network.PPP:
-
-class PPP -- create network connections over serial PPP
-=======================================================
-
-This class allows you to create a network connection over a serial port using
-the PPP protocol.  It is only available on selected ports and boards.
-
-Example usage::
-
-    import network
-
-    ppp = network.PPP(uart)
-    ppp.connect()
-
-    while not ppp.isconnected():
-        pass
-
-    print(ppp.ipconfig("addr4"))
-
-    # use the socket module as usual, etc
-
-    ppp.disconnect()
-
-Constructors
-------------
-
-.. class:: PPP(stream)
-
-   Create a PPP driver object.
-
-   Arguments are:
-
-     - *stream* is any object that supports the stream protocol, but is most commonly a
-       :class:`machine.UART` instance.  This stream object must have an ``irq()`` method
-       and an ``IRQ_RXIDLE`` constant, for use by `PPP.connect`.
-
-Methods
--------
-
-.. method:: PPP.connect(security=SEC_NONE, user=None, key=None)
-
-   Initiate a PPP connection with the given parameters:
-
-     - *security* is the type of security, either ``PPP.SEC_NONE``, ``PPP.SEC_PAP``,
-       or ``PPP.SEC_CHAP``.
-     - *user* is an optional user name to use with the security mode.
-     - *key* is an optional password to use with the security mode.
-
-   When this method is called the underlying stream has its interrupt configured to call
-   `PPP.poll` via ``stream.irq(ppp.poll, stream.IRQ_RXIDLE)``.  This makes sure the
-   stream is polled, and data passed up the PPP stack, wheverver data becomes available
-   on the stream.
-
-   The connection proceeds asynchronously, in the background.
-
-.. method:: PPP.disconnect()
-
-   Terminate the connection.  This must be called to cleanly close the PPP connection.
-
-.. method:: PPP.isconnected()
-
-   Returns ``True`` if the PPP link is connected and up.
-   Returns ``False`` otherwise.
-
-.. method:: PPP.status()
-
-   Returns the PPP status.
-
-.. method:: PPP.config(config_parameters)
-
-   Sets or gets parameters of the PPP interface. There are currently no parameter that
-   can be set or retrieved.
-
-.. method:: PPP.ipconfig('param')
-            PPP.ipconfig(param=value, ...)
-
-   See `AbstractNIC.ipconfig`.
-
-.. method:: PPP.ifconfig([(ip, subnet, gateway, dns)])
-
-   See `AbstractNIC.ifconfig`.
-
-.. method:: PPP.poll()
-
-   Poll the underlying stream for data, and pass it up the PPP stack.
-   This is called automatically if the stream is a UART with a RXIDLE interrupt,
-   so it's not usually necessary to call it manually.
-
-Constants
----------
-
-.. data:: PPP.SEC_NONE
-          PPP.SEC_PAP
-          PPP.SEC_CHAP
-
-    The type of connection security.

docs/library/network.WIZNET5K.rst

@@ -13,7 +13,7 @@ Example usage::
 
     import network
     nic = network.WIZNET5K(pyb.SPI(1), pyb.Pin.board.X5, pyb.Pin.board.X4)
-    print(nic.ipconfig("addr4"))
+    print(nic.ifconfig())
 
     # now use socket as usual
     ...
@@ -51,7 +51,20 @@ Constructors
 Methods
 -------
 
-This class implements most methods from `AbstractNIC <AbstractNIC>`, which are documented there. Additional methods are:
+.. method:: WIZNET5K.isconnected()
+
+   Returns ``True`` if the physical Ethernet link is connected and up.
+   Returns ``False`` otherwise.
+
+.. method:: WIZNET5K.ifconfig([(ip, subnet, gateway, dns)])
+
+   Get/set IP address, subnet mask, gateway and DNS.
+
+   When called with no arguments, this method returns a 4-tuple with the above information.
+
+   To set the above values, pass a 4-tuple with the required information.  For example::
+
+    nic.ifconfig(('192.168.0.4', '255.255.255.0', '192.168.0.1', '8.8.8.8'))
 
 .. method:: WIZNET5K.regs()
 

docs/library/network.WLAN.rst

@@ -107,7 +107,7 @@ Methods
 
    Get or set general network interface parameters. These methods allow to work
    with additional parameters beyond standard IP configuration (as dealt with by
-   `AbstractNIC.ipconfig()`). These include network-specific and hardware-specific
+   `WLAN.ifconfig()`). These include network-specific and hardware-specific
    parameters. For setting parameters, keyword argument syntax should be used,
    multiple parameters can be set at once. For querying, parameters name should
    be quoted as a string, and only one parameter can be queries at time::

docs/library/network.WLANWiPy.rst

@@ -20,7 +20,7 @@ This class provides a driver for the WiFi network processor in the WiPy. Example
     wlan.connect('your-ssid', auth=(WLAN.WPA2, 'your-key'))
     while not wlan.isconnected():
         time.sleep_ms(50)
-    print(wlan.ipconfig("addr4"))
+    print(wlan.ifconfig())
 
     # now use socket as usual
     ...
@@ -96,10 +96,16 @@ Methods
    In case of STA mode, returns ``True`` if connected to a WiFi access point and has a valid IP address.
    In AP mode returns ``True`` when a station is connected, ``False`` otherwise.
 
-.. method:: WLANWiPy.ipconfig('param')
-            WLANWiPy.ipconfig(param=value, ...)
+.. method:: WLANWiPy.ifconfig(if_id=0, config=['dhcp' or configtuple])
 
-   See :meth:`AbstractNIC.ipconfig <AbstractNIC.ipconfig>`. Supported parameters are: ``dhcp4``, ``addr4``, ``gw4``.
+   With no parameters given returns a 4-tuple of *(ip, subnet_mask, gateway, DNS_server)*.
+
+   if ``'dhcp'`` is passed as a parameter then the DHCP client is enabled and the IP params
+   are negotiated with the AP.
+
+   If the 4-tuple config is given then a static IP is configured. For instance::
+
+      wlan.ifconfig(config=('192.168.0.4', '255.255.255.0', '192.168.0.1', '8.8.8.8'))
 
 .. method:: WLANWiPy.mode([mode])
 

docs/library/network.rst

@@ -24,7 +24,7 @@ For example::
         print("Waiting for connection...")
         while not nic.isconnected():
             time.sleep(1)
-    print(nic.ipconfig("addr4"))
+    print(nic.ifconfig())
 
     # now use socket as usual
     import socket
@@ -113,48 +113,8 @@ parameter should be `id`.
          connected to the AP.  The list contains tuples of the form
          (MAC, RSSI).
 
-.. method:: AbstractNIC.ipconfig('param')
-            AbstractNIC.ipconfig(param=value, ...)
-
-       Get or set interface-specific IP-configuration interface parameters.
-       Supported parameters are the following (availability of a particular
-       parameter depends on the port and the specific network interface):
-
-       * ``dhcp4`` (``True/False``) obtain an IPv4 address, gateway and dns
-         server via DHCP. This method does not block and wait for an address
-         to be obtained. To check if an address was obtained, use the read-only
-         property ``has_dhcp4``.
-       * ``gw4`` Get/set the IPv4 default-gateway.
-       * ``dhcp6`` (``True/False``) obtain a DNS server via stateless DHCPv6.
-         Obtaining IP Addresses via DHCPv6 is currently not implemented.
-       * ``autoconf6`` (``True/False``) obtain a stateless IPv6 address via
-         the network prefix shared in router advertisements. To check if a
-         stateless address was obtained, use the read-only
-         property ``has_autoconf6``.
-       * ``addr4`` (e.g. ``192.168.0.4/24``) obtain the current IPv4 address
-         and network mask as ``(ip, subnet)``-tuple, regardless of how this
-         address was obtained. This method can be used to set a static IPv4
-         address either as ``(ip, subnet)``-tuple or in CIDR-notation.
-       * ``addr6`` (e.g. ``fe80::1234:5678``) obtain a list of current IPv6
-         addresses as ``(ip, state, preferred_lifetime, valid_lifetime)``-tuple.
-         This include link-local, slaac and static addresses.
-         ``preferred_lifetime`` and ``valid_lifetime`` represent the remaining
-         valid and preferred lifetime of each IPv6 address, in seconds.
-         ``state`` indicates the current state of the address:
-
-         * ``0x08`` - ``0x0f`` indicates the address is tentative, counting the
-           number of probes sent.
-         * ``0x10`` The address is deprecated (but still valid)
-         * ``0x30`` The address is preferred (and valid)
-         * ``0x40`` The address is duplicated and can not be used.
-
-         This method can be used to set a static IPv6
-         address, by setting this parameter to the address, like ``fe80::1234:5678``.
-
 .. method:: AbstractNIC.ifconfig([(ip, subnet, gateway, dns)])
 
-       .. note:: This function is deprecated, use `ipconfig()` instead.
-
        Get/set IP-level network interface parameters: IP address, subnet mask,
        gateway and DNS server. When called with no arguments, this method returns
        a 4-tuple with the above information. To set the above values, pass a
@@ -167,7 +127,7 @@ parameter should be `id`.
 
        Get or set general network interface parameters. These methods allow to work
        with additional parameters beyond standard IP configuration (as dealt with by
-       `ipconfig()`). These include network-specific and hardware-specific
+       `ifconfig()`). These include network-specific and hardware-specific
        parameters. For setting parameters, the keyword argument
        syntax should be used, and multiple parameters can be set at once. For
        querying, a parameter name should be quoted as a string, and only one
@@ -192,7 +152,6 @@ provide a way to control networking interfaces of various kinds.
    network.WLANWiPy.rst
    network.WIZNET5K.rst
    network.LAN.rst
-   network.PPP.rst
 
 Network functions
 =================
@@ -236,20 +195,6 @@ The following are functions available in the network module.
 
     The default hostname is typically the name of the board.
 
-.. function:: ipconfig('param')
-              ipconfig(param=value, ...)
-
-       Get or set global IP-configuration parameters.
-       Supported parameters are the following (availability of a particular
-       parameter depends on the port and the specific network interface):
-
-       * ``dns`` Get/set DNS server. This method can support both, IPv4 and
-         IPv6 addresses.
-       * ``prefer`` (``4/6``) Specify which address type to return, if a domain
-         name has both A and AAAA records. Note, that this does not clear the
-         local DNS cache, so that any previously obtained addresses might not
-         change.
-
 .. function:: phy_mode([mode])
 
     Get or set the PHY mode.

docs/library/openamp.rst

@@ -1,115 +0,0 @@
-:mod:`openamp` -- provides standard Asymmetric Multiprocessing (AMP) support
-============================================================================
-
-.. module:: openamp
-   :synopsis: provides standard Asymmetric Multiprocessing (AMP) support
-
-The ``openamp`` module provides a standard inter-processor communications infrastructure
-for MicroPython. The module handles all of the details of OpenAMP, such as setting up
-the shared resource table, initializing vrings, etc. It provides an API for using the
-RPMsg bus infrastructure with the `Endpoint` class, and provides processor Life Cycle
-Management (LCM) support, such as loading firmware and starting and stopping a remote
-core, via the `RemoteProc` class.
-
-Example usage::
-
-    import openamp
-
-    def ept_recv_callback(src, data):
-        print("Received message on endpoint", data)
-
-    # Create a new RPMsg endpoint to communicate with the remote core.
-    ept = openamp.Endpoint("vuart-channel", callback=ept_recv_callback)
-
-    # Create a RemoteProc object, load its firmware and start it.
-    rproc = openamp.RemoteProc("virtual_uart.elf") # Or entry point address (ex 0x081E0000)
-    rproc.start()
-
-    while True:
-        if ept.is_ready():
-            ept.send("data")
-
-Functions
----------
-
-.. function:: new_service_callback(ns_callback)
-
-    Set the new service callback.
-
-    The *ns_callback* argument is a function that will be called when the remote processor
-    announces new services. At that point the host processor can choose to create the
-    announced endpoint, if this particular service is supported, or ignore it if it's
-    not. If this function is not set, the host processor should first register the
-    endpoint locally, and it will be automatically bound when the remote announces
-    the service.
-
-Endpoint class
---------------
-
-.. class:: Endpoint(name, callback, src=ENDPOINT_ADDR_ANY, dest=ENDPOINT_ADDR_ANY)
-
-   Construct a new RPMsg Endpoint. An endpoint is a bidirectional communication
-   channel between two cores.
-
-   Arguments are:
-
-        - *name* is the name of the endpoint.
-        - *callback* is a function that is called when the endpoint receives data with the
-          source address of the remote point, and the data as bytes passed by reference.
-        - *src* is the endpoint source address. If none is provided one will be assigned
-          to the endpoint by the library.
-        - *dest* is the endpoint destination address. If the endpoint is created from the
-          new_service_callback, this must be provided and it must match the remote endpoint's
-          source address. If the endpoint is registered locally, before the announcement, the
-          destination address will be assigned by the library when the endpoint is bound.
-
-.. method:: Endpoint.deinit()
-
-   Destroy the endpoint and release all of its resources.
-
-.. method:: Endpoint.is_ready()
-
-   Returns True if the endpoint is ready to send (i.e., has both a source and destination addresses)
-
-.. method:: Endpoint.send(src=-1, dest=-1, timeout=-1)
-
-   Send a message to the remote processor over this endpoint.
-
-   Arguments are:
-
-        - *src* is the source endpoint address of the message. If none is provided, the
-          source address the endpoint is bound to is used.
-        - *dest* is the destination endpoint address of the message. If none is provided,
-          the destination address the endpoint is bound to is used.
-        - *timeout* specifies the time in milliseconds to wait for a free buffer. By default
-          the function is blocking.
-
-RemoteProc class
-----------------
-
-.. class:: RemoteProc(entry)
-
-   The RemoteProc object provides processor Life Cycle Management (LCM) support, such as
-   loading firmware, starting and stopping a remote core.
-
-   The *entry* argument can be a path to firmware image, in which case the firmware is
-   loaded from file to its target memory, or an entry point address, in which case the
-   firmware must be loaded already at the given address.
-
-.. method:: RemoteProc.start()
-
-   Starts the remote processor.
-
-.. method:: RemoteProc.stop()
-
-   Stops the remote processor. The exact behavior is platform-dependent. On the STM32H7 for
-   example it's not possible to stop and then restart the Cortex-M4 core, so a complete
-   system reset is performed on a call to this function.
-
-.. method:: RemoteProc.shutdown()
-
-   Shutdown stops the remote processor and releases all of its resources. The exact behavior
-   is platform-dependent, however typically it disables power and clocks to the remote core.
-   This function is also used as the finaliser (i.e., called when ``RemoteProc`` object is
-   collected). Note that on the STM32H7, it's not possible to stop and then restart the
-   Cortex-M4 core, so a complete system reset is performed on a call to this function.

docs/library/os.rst

@@ -136,30 +136,192 @@ Terminal redirection and duplication
 Filesystem mounting
 -------------------
 
-The following functions and classes have been moved to the :mod:`vfs` module.
-They are provided in this module only for backwards compatibility and will be
-removed in version 2 of MicroPython.
+Some ports provide a Virtual Filesystem (VFS) and the ability to mount multiple
+"real" filesystems within this VFS.  Filesystem objects can be mounted at either
+the root of the VFS, or at a subdirectory that lives in the root.  This allows
+dynamic and flexible configuration of the filesystem that is seen by Python
+programs.  Ports that have this functionality provide the :func:`mount` and
+:func:`umount` functions, and possibly various filesystem implementations
+represented by VFS classes.
 
 .. function:: mount(fsobj, mount_point, *, readonly)
 
-    See `vfs.mount`.
+    Mount the filesystem object *fsobj* at the location in the VFS given by the
+    *mount_point* string.  *fsobj* can be a a VFS object that has a ``mount()``
+    method, or a block device.  If it's a block device then the filesystem type
+    is automatically detected (an exception is raised if no filesystem was
+    recognised).  *mount_point* may be ``'/'`` to mount *fsobj* at the root,
+    or ``'/<name>'`` to mount it at a subdirectory under the root.
+
+    If *readonly* is ``True`` then the filesystem is mounted read-only.
+
+    During the mount process the method ``mount()`` is called on the filesystem
+    object.
+
+    Will raise ``OSError(EPERM)`` if *mount_point* is already mounted.
 
 .. function:: umount(mount_point)
 
-    See `vfs.umount`.
+    Unmount a filesystem. *mount_point* can be a string naming the mount location,
+    or a previously-mounted filesystem object.  During the unmount process the
+    method ``umount()`` is called on the filesystem object.
+
+    Will raise ``OSError(EINVAL)`` if *mount_point* is not found.
 
 .. class:: VfsFat(block_dev)
 
-    See `vfs.VfsFat`.
+    Create a filesystem object that uses the FAT filesystem format.  Storage of
+    the FAT filesystem is provided by *block_dev*.
+    Objects created by this constructor can be mounted using :func:`mount`.
+
+    .. staticmethod:: mkfs(block_dev)
+
+        Build a FAT filesystem on *block_dev*.
 
 .. class:: VfsLfs1(block_dev, readsize=32, progsize=32, lookahead=32)
 
-    See `vfs.VfsLfs1`.
+    Create a filesystem object that uses the `littlefs v1 filesystem format`_.
+    Storage of the littlefs filesystem is provided by *block_dev*, which must
+    support the :ref:`extended interface <block-device-interface>`.
+    Objects created by this constructor can be mounted using :func:`mount`.
+
+    See :ref:`filesystem` for more information.
+
+    .. staticmethod:: mkfs(block_dev, readsize=32, progsize=32, lookahead=32)
+
+        Build a Lfs1 filesystem on *block_dev*.
+
+    .. note:: There are reports of littlefs v1 failing in certain situations,
+              for details see `littlefs issue 347`_.
 
 .. class:: VfsLfs2(block_dev, readsize=32, progsize=32, lookahead=32, mtime=True)
 
-    See `vfs.VfsLfs2`.
+    Create a filesystem object that uses the `littlefs v2 filesystem format`_.
+    Storage of the littlefs filesystem is provided by *block_dev*, which must
+    support the :ref:`extended interface <block-device-interface>`.
+    Objects created by this constructor can be mounted using :func:`mount`.
 
-.. class:: VfsPosix(root=None)
+    The *mtime* argument enables modification timestamps for files, stored using
+    littlefs attributes.  This option can be disabled or enabled differently each
+    mount time and timestamps will only be added or updated if *mtime* is enabled,
+    otherwise the timestamps will remain untouched.  Littlefs v2 filesystems without
+    timestamps will work without reformatting and timestamps will be added
+    transparently to existing files once they are opened for writing.  When *mtime*
+    is enabled `os.stat` on files without timestamps will return 0 for the timestamp.
 
-    See `vfs.VfsPosix`.
+    See :ref:`filesystem` for more information.
+
+    .. staticmethod:: mkfs(block_dev, readsize=32, progsize=32, lookahead=32)
+
+        Build a Lfs2 filesystem on *block_dev*.
+
+    .. note:: There are reports of littlefs v2 failing in certain situations,
+              for details see `littlefs issue 295`_.
+
+.. _littlefs v1 filesystem format: https://github.com/ARMmbed/littlefs/tree/v1
+.. _littlefs v2 filesystem format: https://github.com/ARMmbed/littlefs
+.. _littlefs issue 295: https://github.com/ARMmbed/littlefs/issues/295
+.. _littlefs issue 347: https://github.com/ARMmbed/littlefs/issues/347
+
+Block devices
+-------------
+
+A block device is an object which implements the block protocol. This enables a
+device to support MicroPython filesystems. The physical hardware is represented
+by a user defined class. The :class:`AbstractBlockDev` class is a template for
+the design of such a class: MicroPython does not actually provide that class,
+but an actual block device class must implement the methods described below.
+
+A concrete implementation of this class will usually allow access to the
+memory-like functionality of a piece of hardware (like flash memory). A block
+device can be formatted to any supported filesystem and mounted using ``os``
+methods.
+
+See :ref:`filesystem` for example implementations of block devices using the
+two variants of the block protocol described below.
+
+.. _block-device-interface:
+
+Simple and extended interface
+.............................
+
+There are two compatible signatures for the ``readblocks`` and ``writeblocks``
+methods (see below), in order to support a variety of use cases.  A given block
+device may implement one form or the other, or both at the same time. The second
+form (with the offset parameter) is referred to as the "extended interface".
+
+Some filesystems (such as littlefs) that require more control over write
+operations, for example writing to sub-block regions without erasing, may require
+that the block device supports the extended interface.
+
+.. class:: AbstractBlockDev(...)
+
+    Construct a block device object.  The parameters to the constructor are
+    dependent on the specific block device.
+
+    .. method:: readblocks(block_num, buf)
+                readblocks(block_num, buf, offset)
+
+        The first form reads aligned, multiples of blocks.
+        Starting at the block given by the index *block_num*, read blocks from
+        the device into *buf* (an array of bytes).
+        The number of blocks to read is given by the length of *buf*,
+        which will be a multiple of the block size.
+
+        The second form allows reading at arbitrary locations within a block,
+        and arbitrary lengths.
+        Starting at block index *block_num*, and byte offset within that block
+        of *offset*, read bytes from the device into *buf* (an array of bytes).
+        The number of bytes to read is given by the length of *buf*.
+
+    .. method:: writeblocks(block_num, buf)
+                writeblocks(block_num, buf, offset)
+
+        The first form writes aligned, multiples of blocks, and requires that the
+        blocks that are written to be first erased (if necessary) by this method.
+        Starting at the block given by the index *block_num*, write blocks from
+        *buf* (an array of bytes) to the device.
+        The number of blocks to write is given by the length of *buf*,
+        which will be a multiple of the block size.
+
+        The second form allows writing at arbitrary locations within a block,
+        and arbitrary lengths.  Only the bytes being written should be changed,
+        and the caller of this method must ensure that the relevant blocks are
+        erased via a prior ``ioctl`` call.
+        Starting at block index *block_num*, and byte offset within that block
+        of *offset*, write bytes from *buf* (an array of bytes) to the device.
+        The number of bytes to write is given by the length of *buf*.
+
+        Note that implementations must never implicitly erase blocks if the offset
+        argument is specified, even if it is zero.
+
+    .. method:: ioctl(op, arg)
+
+        Control the block device and query its parameters.  The operation to
+        perform is given by *op* which is one of the following integers:
+
+          - 1 -- initialise the device (*arg* is unused)
+          - 2 -- shutdown the device (*arg* is unused)
+          - 3 -- sync the device (*arg* is unused)
+          - 4 -- get a count of the number of blocks, should return an integer
+            (*arg* is unused)
+          - 5 -- get the number of bytes in a block, should return an integer,
+            or ``None`` in which case the default value of 512 is used
+            (*arg* is unused)
+          - 6 -- erase a block, *arg* is the block number to erase
+
+       As a minimum ``ioctl(4, ...)`` must be intercepted; for littlefs
+       ``ioctl(6, ...)`` must also be intercepted. The need for others is
+       hardware dependent.
+
+       Prior to any call to ``writeblocks(block, ...)`` littlefs issues
+       ``ioctl(6, block)``. This enables a device driver to erase the block
+       prior to a write if the hardware requires it. Alternatively a driver
+       might intercept ``ioctl(6, block)`` and return 0 (success). In this case
+       the driver assumes responsibility for detecting the need for erasure.
+
+       Unless otherwise stated ``ioctl(op, arg)`` can return ``None``.
+       Consequently an implementation can ignore unused values of ``op``. Where
+       ``op`` is intercepted, the return value for operations 4 and 5 are as
+       detailed above. Other operations should return 0 on success and non-zero
+       for failure, with the value returned being an ``OSError`` errno code.

docs/library/pyb.Flash.rst

@@ -43,7 +43,7 @@ Methods
 
     These methods implement the simple and :ref:`extended
     <block-device-interface>` block protocol defined by
-    :class:`vfs.AbstractBlockDev`.
+    :class:`os.AbstractBlockDev`.
 
 Hardware Note
 -------------

docs/library/pyb.rst

@@ -213,11 +213,11 @@ Miscellaneous functions
 .. function:: mount(device, mountpoint, *, readonly=False, mkfs=False)
 
    .. note:: This function is deprecated. Mounting and unmounting devices should
-      be performed by :meth:`vfs.mount` and :meth:`vfs.umount` instead.
+      be performed by :meth:`os.mount` and :meth:`os.umount` instead.
 
    Mount a block device and make it available as part of the filesystem.
    ``device`` must be an object that provides the block protocol. (The
-   following is also deprecated. See :class:`vfs.AbstractBlockDev` for the
+   following is also deprecated. See :class:`os.AbstractBlockDev` for the
    correct way to create a block device.)
 
     - ``readblocks(self, blocknum, buf)``

docs/library/rp2.DMA.rst

@@ -1,293 +0,0 @@
-.. currentmodule:: rp2
-.. _rp2.DMA:
-
-class DMA -- access to the RP2040's DMA controller
-==================================================
-
-The :class:`DMA` class offers access to the RP2040's Direct Memory Access (DMA)
-controller, providing the ability move data between memory blocks and/or IO registers. The DMA
-controller has its own, separate read and write bus master connections onto the bus fabric and
-each DMA channel can independently read data from one address and write it back to another
-address, optionally incrementing one or both pointers, allowing it to perform transfers on behalf
-of the processor while the processor carries out other tasks or enters a low power state. The
-RP2040's DMA controller has 12 independent DMA channels that can run concurrently. For full
-details of the RP2040's DMA system see section 2.5 of the `RP2040 Datasheet
-<https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.pdf>`_.
-
-Examples
---------
-
-The simplest use of the DMA controller is to move data from one block of memory to another.
-This can be accomplished with the following code::
-
-    a = bytearray(32*1024)
-    b = bytearray(32*1024)
-    d = rp2.DMA()
-    c = d.pack_ctrl()  # Just use the default control value.
-    # The count is in 'transfers', which defaults to four-byte words, so divide length by 4
-    d.config(read=a, write=b, count=len(a)//4, ctrl=c, trigger=True)
-    # Wait for completion
-    while d.active():
-        pass
-
-Note that while this example sits in an idle loop while it waits for the transfer to complete,
-the program could just as well do some useful work in this time instead.
-
-Another, perhaps more common use of the DMA controller is to transfer between memory and an IO
-peripheral. In this situation the address of the IO register does not change for each transfer but
-the memory address needs to be incremented. It is also necessary to control the pace of the
-transfer so as to not write data before it can be accepted by a peripheral or read it before the
-data is ready, and this can be controlled with the ``treq_sel`` field of the DMA channel's control
-register. The various fields of the control register for each DMA channel can be packed
-using the :meth:`DMA.pack_ctrl()` method and unpacked using the :meth:`DMA.unpack_ctrl()`
-static method. Code to transfer data from a byte array to the TX FIFO of a PIO state machine,
-one byte at a time, looks like this::
-
-    # pio_num is index of the PIO block being used, sm_num is the state machine in that block.
-    # my_state_machine is an rp2.PIO() instance.
-    DATA_REQUEST_INDEX = (pio_num << 3) + sm_num
-
-    src_data = bytearray(1024)
-    d = rp2.DMA()
-
-    # Transfer bytes, rather than words, don't increment the write address and pace the transfer.
-    c = d.pack_ctrl(size=0, inc_write=False, treq_sel=DATA_REQUEST_INDEX)
-
-    d.config(
-        read=src_data,
-        write=my_state_machine,
-        count=len(src_data),
-        ctrl=c,
-        trigger=True
-    )
-
-Note that in this example the value given for the write address is just the PIO state machine to
-which we are sending the data. This works because PIO state machines present the buffer protocol,
-allowing direct access to their data FIFO registers.
-
-Constructor
------------
-
-.. class:: DMA()
-
-    Claim one of the DMA controller channels for exclusive use.
-
-Methods
--------
-
-.. method:: DMA.config(read=None, write=None, count=None, ctrl=None, trigger=False)
-
-    Configure the DMA registers for the channel and optionally start the transfer.
-    Parameters are:
-
-    - *read*: The address from which the DMA controller will start reading data or
-      an object that will provide data to be read. It can be an integer or any
-      object that supports the buffer protocol.
-    - *write*: The address to which the DMA controller will start writing or an
-      object into which data will be written. It can be an integer or any object
-      that supports the buffer protocol.
-    - *count*: The number of bus transfers that will execute before this channel
-      stops. Note that this is the number of transfers, not the number of bytes.
-      If the transfers are 2 or 4 bytes wide then the total amount of data moved
-      (and thus the size of required buffer) needs to be multiplied accordingly.
-    - *ctrl*: The value for the DMA control register. This is an integer value
-      that is typically packed using the :meth:`DMA.pack_ctrl()`.
-    - *trigger*: Optionally commence the transfer immediately.
-
-.. method:: DMA.irq(handler=None, hard=False)
-
-    Returns the IRQ object for this DMA channel and optionally configures it.
-
-.. method:: DMA.close()
-
-    Release the claim on the underlying DMA channel and free the interrupt
-    handler. The :class:`DMA` object can not be used after this operation.
-
-.. method:: DMA.pack_ctrl(default=None, **kwargs)
-
-    Pack the values provided in the keyword arguments into the named fields of a new control
-    register value. Any field that is not provided will be set to a default value. The
-    default will either be taken from the provided ``default`` value, or if that is not
-    given, a default suitable for the current channel; setting this to the current value
-    of the `DMA.ctrl` attribute provides an easy way to override a subset of the fields.
-
-    The keys for the keyword arguments can be any key returned by the :meth:`DMA.unpack_ctrl()`
-    method. The writable values are:
-
-    - *enable*: ``bool`` Set to enable the channel (default: ``True``).
-
-    - *high_pri*: ``bool`` Make this channel's bus traffic high priority (default: ``False``).
-
-    - *size*: ``int`` Transfer size: 0=byte, 1=half word, 2=word (default: 2).
-
-    - *inc_read*: ``bool`` Increment the read address after each transfer (default: ``True``).
-
-    - *inc_write*: ``bool`` Increment the write address after each transfer (default: ``True``).
-
-    - *ring_size*: ``int`` If non-zero, only the bottom ``ring_size`` bits of one
-      address register will change when an address is incremented, causing the
-      address to wrap at the next ``1 << ring_size`` byte boundary. Which
-      address is wrapped is controlled by the ``ring_sel`` flag. A zero value
-      disables address wrapping.
-
-    - *ring_sel*: ``bool`` Set to ``False`` to have the ``ring_size`` apply to the read address
-      or ``True`` to apply to the write address.
-
-    - *chain_to*: ``int`` The channel number for a channel to trigger after this transfer
-      completes. Setting this value to this DMA object's own channel number
-      disables chaining (this is the default).
-
-    - *treq_sel*: ``int`` Select a Transfer Request signal. See section 2.5.3 in the RP2040
-      datasheet for details.
-
-    - *irq_quiet*: ``bool`` Do not generate interrupt at the end of each transfer. Interrupts
-      will instead be generated when a zero value is written to the trigger
-      register, which will halt a sequence of chained transfers (default:
-      ``True``).
-
-    - *bswap*: ``bool`` If set to true, bytes in words or half-words will be reversed before
-      writing (default: ``True``).
-
-    - *sniff_en*: ``bool`` Set to ``True`` to allow data to be accessed by the chips sniff
-      hardware (default: ``False``).
-
-    - *write_err*: ``bool`` Setting this to ``True`` will clear a previously reported write
-      error.
-
-    - *read_err*: ``bool`` Setting this to ``True`` will clear a previously reported read
-      error.
-
-    See the description of the ``CH0_CTRL_TRIG`` register in section 2.5.7 of the RP2040
-    datasheet for details of all of these fields.
-
-.. method:: DMA.unpack_ctrl(value)
-
-    Unpack a value for a DMA channel control register into a dictionary with key/value pairs
-    for each of the fields in the control register.  *value* is the ``ctrl`` register value
-    to unpack.
-
-    This method will return values for all the keys that can be passed to ``DMA.pack_ctrl``.
-    In addition, it will also return the read-only flags in the control register: ``busy``,
-    which goes high when a transfer starts and low when it ends, and ``ahb_err``, which is
-    the logical OR of the ``read_err`` and ``write_err`` flags. These values will be ignored
-    when packing, so that the dictionary created by unpacking a control register can be used
-    directly as the keyword arguments for packing.
-
-.. method:: DMA.active([value])
-
-    Gets or sets whether the DMA channel is currently running.
-
-    >>> sm.active()
-    0
-    >>> sm.active(1)
-    >>> while sm.active():
-    ...     pass
-
-Attributes
-----------
-
-.. attribute:: DMA.read
-
-    This attribute reflects the address from which the next bus transfer
-    will read. It may be written with either an integer or an object
-    that supports the buffer protocol and doing so has immediate effect.
-
-.. attribute:: DMA.write
-
-    This attribute reflects the address to which the next bus transfer
-    will write.  It may be written with either an integer or an object
-    that supports the buffer protocol and doing so has immediate effect.
-
-.. attribute:: DMA.count
-
-    Reading this attribute will return the number of remaining bus
-    transfers in the *current* transfer sequence. Writing this attribute
-    sets the total number of transfers to be the *next* transfer sequence.
-
-.. attribute:: DMA.ctrl
-
-    This attribute reflects DMA channel control register. It is typically written
-    with an integer packed using the :meth:`DMA.pack_ctrl()` method. The returned
-    register value can be unpacked using the :meth:`DMA.unpack_ctrl()` method.
-
-.. attribute:: DMA.channel
-
-    The channel number of the DMA channel. This can be passed in the ``chain_to``
-    argument of `DMA.pack_ctrl()` on another channel to allow DMA chaining.
-
-.. attribute:: DMA.registers
-
-    This attribute is an array-like object that allows direct access to
-    the DMA channel's registers. The index is by word, rather than by byte,
-    so the register indices are the register address offsets divided by 4.
-    See the RP2040 data sheet for register details.
-
-Chaining and trigger register access
-------------------------------------
-
-The DMA controller in the RP2040 offers a couple advanced features to allow one DMA channel
-to initiate a transfer on another channel. One is the use of the ``chain_to`` value in the
-control register and the other is writing to one of the DMA channel's registers that has a
-trigger effect. When coupled with the ability to have one DMA channel write directly to the
-`DMA.registers` of another channel, this allows for complex transactions to be performed
-without any CPU intervention.
-
-Below is an example of using both chaining and register
-triggering to implement gathering of multiple blocks of data into a single destination. Full
-details of these features can be found in section 2.5 of the RP2040 data sheet and the code
-below is a Pythonic version of the example in sub-section 2.5.6.2.
-
-.. code-block:: python
-
-    from rp2 import DMA
-    from uctypes import addressof
-    from array import array
-
-    def gather_strings(string_list, buf):
-        # We use two DMA channels. The first sends lengths and source addresses from the gather
-        # list to the registers of the second. The second copies the data itself.
-        gather_dma = DMA()
-        buffer_dma = DMA()
-
-        # Pack up length/address pairs to be sent to the registers.
-        gather_list = array("I")
-
-        for s in string_list:
-            gather_list.append(len(s))
-            gather_list.append(addressof(s))
-
-        gather_list.append(0)
-        gather_list.append(0)
-
-        # When writing to the registers of the second DMA channel, we need to wrap the
-        # write address on an 8-byte (1<<3 bytes) boundary. We write to the ``TRANS_COUNT``
-        # and ``READ_ADD_TRIG`` registers in the last register alias (registers 14 and 15).
-        gather_ctrl = gather_dma.pack_ctrl(ring_size=3, ring_sel=True)
-        gather_dma.config(
-            read=gather_list, write=buffer_dma.registers[14:16],
-            count=2, ctrl=gather_ctrl
-        )
-
-        # When copying the data, the transfer size is single bytes, and when completed we need
-        # to chain back to the start another gather DMA transaction.
-        buffer_ctrl = buffer_dma.pack_ctrl(size=0, chain_to=gather_dma.channel)
-        # The read and count values will be set by the other DMA channel.
-        buffer_dma.config(write=buf, ctrl=buffer_ctrl)
-
-        # Set the transfer in motion.
-        gather_dma.active(1)
-
-        # Wait until all the register values have been sent
-        end_address = addressof(gather_list) + 4 * len(gather_list)
-        while gather_dma.read != end_address:
-            pass
-
-    input = ["This is ", "a ", "test", " of the scatter", " gather", " process"]
-    output = bytearray(64)
-
-    print(output)
-    gather_strings(input, output)
-    print(output)
-
-This example idles while waiting for the transfer to complete; alternatively it could
-set an interrupt handler and return immediately.

docs/library/rp2.Flash.rst

@@ -32,5 +32,5 @@ Methods
 
     These methods implement the simple and extended
     :ref:`block protocol <block-device-interface>` defined by
-    :class:`vfs.AbstractBlockDev`.
+    :class:`os.AbstractBlockDev`.
 

docs/library/rp2.PIO.rst

@@ -27,17 +27,6 @@ Constructors
 Methods
 -------
 
-.. method:: PIO.gpio_base([base])
-
-    Query and optionally set the current GPIO base for this PIO instance.
-
-    If an argument is given then it must be a pin (or integer corresponding to a pin
-    number), restricted to either GPIO0 or GPIO16.  The GPIO base will then be set to
-    that pin.  Setting the GPIO base must be done before any programs are added or state
-    machines created.
-
-    Returns the current GPIO base pin.
-
 .. method:: PIO.add_program(program)
 
     Add the *program* to the instruction memory of this PIO instance.

docs/library/rp2.StateMachine.rst

@@ -32,7 +32,7 @@ Methods
 
     The program is added to the instruction memory of this PIO instance. If the
     instruction memory already contains this program, then its offset is
-    reused so as to save on instruction memory.
+    re-used so as to save on instruction memory.
 
     - *freq* is the frequency in Hz to run the state machine at. Defaults to
       the system clock frequency.
@@ -140,10 +140,3 @@ Methods
 
      Optionally configure it.
 
-Buffer protocol
----------------
-
-The StateMachine class supports the `buffer protocol`, allowing direct access to the transmit
-and receive FIFOs for each state machine. This is primarily in order to allow StateMachine
-objects to be passed directly as the read or write parameters when configuring a `rp2.DMA()`
-channel.

docs/library/rp2.rst

@@ -241,7 +241,6 @@ Classes
 .. toctree::
     :maxdepth: 1
 
-    rp2.DMA.rst
     rp2.Flash.rst
     rp2.PIO.rst
     rp2.StateMachine.rst

docs/library/ssl.rst

@@ -13,7 +13,7 @@ facilities for network sockets, both client-side and server-side.
 Functions
 ---------
 
-.. function:: ssl.wrap_socket(sock, server_side=False, key=None, cert=None, cert_reqs=CERT_NONE, cadata=None, server_hostname=None, do_handshake=True)
+.. function:: ssl.wrap_socket(sock, server_side=False, keyfile=None, certfile=None, cert_reqs=CERT_NONE, cadata=None, server_hostname=None, do_handshake=True)
 
     Wrap the given *sock* and return a new wrapped-socket object.  The implementation
     of this function is to first create an `SSLContext` and then call the `SSLContext.wrap_socket`

docs/library/struct.rst

@@ -45,8 +45,6 @@ The following data types are supported:
 +--------+--------------------+-------------------+---------------+
 | Q      | unsigned long long | integer (`1<fn>`) | 8             |
 +--------+--------------------+-------------------+---------------+
-| e      | n/a (half-float)   | float (`2<fn>`)   | 2             |
-+--------+--------------------+-------------------+---------------+
 | f      | float              | float (`2<fn>`)   | 4             |
 +--------+--------------------+-------------------+---------------+
 | d      | double             | float (`2<fn>`)   | 8             |

docs/library/sys.rst

@@ -69,7 +69,7 @@ Constants
    MicroPython, it has following attributes:
 
    * *name* - string "micropython"
-   * *version* - tuple (major, minor, micro, releaselevel), e.g. (1, 22, 0, '')
+   * *version* - tuple (major, minor, micro), e.g. (1, 7, 0)
    * *_machine* - string describing the underlying machine
    * *_mpy* - supported mpy file-format version (optional attribute)
 
@@ -77,9 +77,6 @@ Constants
    Python implementations (note that it still may not exist in the very
    minimal ports).
 
-   Starting with version 1.22.0-preview, the fourth node *releaselevel* in
-   *implementation.version* is either an empty string or ``"preview"``.
-
    .. admonition:: Difference to CPython
       :class: attention
 

docs/library/vfs.rst

@@ -1,208 +0,0 @@
-:mod:`vfs` -- virtual filesystem control
-========================================
-
-.. module:: vfs
-   :synopsis: virtual filesystem control
-
-The ``vfs`` module contains functions for creating filesystem objects and
-mounting/unmounting them in the Virtual Filesystem.
-
-Filesystem mounting
--------------------
-
-Some ports provide a Virtual Filesystem (VFS) and the ability to mount multiple
-"real" filesystems within this VFS.  Filesystem objects can be mounted at either
-the root of the VFS, or at a subdirectory that lives in the root.  This allows
-dynamic and flexible configuration of the filesystem that is seen by Python
-programs.  Ports that have this functionality provide the :func:`mount` and
-:func:`umount` functions, and possibly various filesystem implementations
-represented by VFS classes.
-
-.. function:: mount(fsobj, mount_point, *, readonly)
-
-    Mount the filesystem object *fsobj* at the location in the VFS given by the
-    *mount_point* string.  *fsobj* can be a a VFS object that has a ``mount()``
-    method, or a block device.  If it's a block device then the filesystem type
-    is automatically detected (an exception is raised if no filesystem was
-    recognised).  *mount_point* may be ``'/'`` to mount *fsobj* at the root,
-    or ``'/<name>'`` to mount it at a subdirectory under the root.
-
-    If *readonly* is ``True`` then the filesystem is mounted read-only.
-
-    During the mount process the method ``mount()`` is called on the filesystem
-    object.
-
-    Will raise ``OSError(EPERM)`` if *mount_point* is already mounted.
-
-.. function:: umount(mount_point)
-
-    Unmount a filesystem. *mount_point* can be a string naming the mount location,
-    or a previously-mounted filesystem object.  During the unmount process the
-    method ``umount()`` is called on the filesystem object.
-
-    Will raise ``OSError(EINVAL)`` if *mount_point* is not found.
-
-.. class:: VfsFat(block_dev)
-
-    Create a filesystem object that uses the FAT filesystem format.  Storage of
-    the FAT filesystem is provided by *block_dev*.
-    Objects created by this constructor can be mounted using :func:`mount`.
-
-    .. staticmethod:: mkfs(block_dev)
-
-        Build a FAT filesystem on *block_dev*.
-
-.. class:: VfsLfs1(block_dev, readsize=32, progsize=32, lookahead=32)
-
-    Create a filesystem object that uses the `littlefs v1 filesystem format`_.
-    Storage of the littlefs filesystem is provided by *block_dev*, which must
-    support the :ref:`extended interface <block-device-interface>`.
-    Objects created by this constructor can be mounted using :func:`mount`.
-
-    See :ref:`filesystem` for more information.
-
-    .. staticmethod:: mkfs(block_dev, readsize=32, progsize=32, lookahead=32)
-
-        Build a Lfs1 filesystem on *block_dev*.
-
-    .. note:: There are reports of littlefs v1 failing in certain situations,
-              for details see `littlefs issue 347`_.
-
-.. class:: VfsLfs2(block_dev, readsize=32, progsize=32, lookahead=32, mtime=True)
-
-    Create a filesystem object that uses the `littlefs v2 filesystem format`_.
-    Storage of the littlefs filesystem is provided by *block_dev*, which must
-    support the :ref:`extended interface <block-device-interface>`.
-    Objects created by this constructor can be mounted using :func:`mount`.
-
-    The *mtime* argument enables modification timestamps for files, stored using
-    littlefs attributes.  This option can be disabled or enabled differently each
-    mount time and timestamps will only be added or updated if *mtime* is enabled,
-    otherwise the timestamps will remain untouched.  Littlefs v2 filesystems without
-    timestamps will work without reformatting and timestamps will be added
-    transparently to existing files once they are opened for writing.  When *mtime*
-    is enabled `os.stat` on files without timestamps will return 0 for the timestamp.
-
-    See :ref:`filesystem` for more information.
-
-    .. staticmethod:: mkfs(block_dev, readsize=32, progsize=32, lookahead=32)
-
-        Build a Lfs2 filesystem on *block_dev*.
-
-    .. note:: There are reports of littlefs v2 failing in certain situations,
-              for details see `littlefs issue 295`_.
-
-.. class:: VfsPosix(root=None)
-
-    Create a filesystem object that accesses the host POSIX filesystem.
-    If *root* is specified then it should be a path in the host filesystem to use
-    as the root of the ``VfsPosix`` object.  Otherwise the current directory of
-    the host filesystem is used.
-
-.. _littlefs v1 filesystem format: https://github.com/ARMmbed/littlefs/tree/v1
-.. _littlefs v2 filesystem format: https://github.com/ARMmbed/littlefs
-.. _littlefs issue 295: https://github.com/ARMmbed/littlefs/issues/295
-.. _littlefs issue 347: https://github.com/ARMmbed/littlefs/issues/347
-
-Block devices
--------------
-
-A block device is an object which implements the block protocol. This enables a
-device to support MicroPython filesystems. The physical hardware is represented
-by a user defined class. The :class:`AbstractBlockDev` class is a template for
-the design of such a class: MicroPython does not actually provide that class,
-but an actual block device class must implement the methods described below.
-
-A concrete implementation of this class will usually allow access to the
-memory-like functionality of a piece of hardware (like flash memory). A block
-device can be formatted to any supported filesystem and mounted using ``os``
-methods.
-
-See :ref:`filesystem` for example implementations of block devices using the
-two variants of the block protocol described below.
-
-.. _block-device-interface:
-
-Simple and extended interface
-.............................
-
-There are two compatible signatures for the ``readblocks`` and ``writeblocks``
-methods (see below), in order to support a variety of use cases.  A given block
-device may implement one form or the other, or both at the same time. The second
-form (with the offset parameter) is referred to as the "extended interface".
-
-Some filesystems (such as littlefs) that require more control over write
-operations, for example writing to sub-block regions without erasing, may require
-that the block device supports the extended interface.
-
-.. class:: AbstractBlockDev(...)
-
-    Construct a block device object.  The parameters to the constructor are
-    dependent on the specific block device.
-
-    .. method:: readblocks(block_num, buf)
-                readblocks(block_num, buf, offset)
-
-        The first form reads aligned, multiples of blocks.
-        Starting at the block given by the index *block_num*, read blocks from
-        the device into *buf* (an array of bytes).
-        The number of blocks to read is given by the length of *buf*,
-        which will be a multiple of the block size.
-
-        The second form allows reading at arbitrary locations within a block,
-        and arbitrary lengths.
-        Starting at block index *block_num*, and byte offset within that block
-        of *offset*, read bytes from the device into *buf* (an array of bytes).
-        The number of bytes to read is given by the length of *buf*.
-
-    .. method:: writeblocks(block_num, buf)
-                writeblocks(block_num, buf, offset)
-
-        The first form writes aligned, multiples of blocks, and requires that the
-        blocks that are written to be first erased (if necessary) by this method.
-        Starting at the block given by the index *block_num*, write blocks from
-        *buf* (an array of bytes) to the device.
-        The number of blocks to write is given by the length of *buf*,
-        which will be a multiple of the block size.
-
-        The second form allows writing at arbitrary locations within a block,
-        and arbitrary lengths.  Only the bytes being written should be changed,
-        and the caller of this method must ensure that the relevant blocks are
-        erased via a prior ``ioctl`` call.
-        Starting at block index *block_num*, and byte offset within that block
-        of *offset*, write bytes from *buf* (an array of bytes) to the device.
-        The number of bytes to write is given by the length of *buf*.
-
-        Note that implementations must never implicitly erase blocks if the offset
-        argument is specified, even if it is zero.
-
-    .. method:: ioctl(op, arg)
-
-        Control the block device and query its parameters.  The operation to
-        perform is given by *op* which is one of the following integers:
-
-          - 1 -- initialise the device (*arg* is unused)
-          - 2 -- shutdown the device (*arg* is unused)
-          - 3 -- sync the device (*arg* is unused)
-          - 4 -- get a count of the number of blocks, should return an integer
-            (*arg* is unused)
-          - 5 -- get the number of bytes in a block, should return an integer,
-            or ``None`` in which case the default value of 512 is used
-            (*arg* is unused)
-          - 6 -- erase a block, *arg* is the block number to erase
-
-       As a minimum ``ioctl(4, ...)`` must be intercepted; for littlefs
-       ``ioctl(6, ...)`` must also be intercepted. The need for others is
-       hardware dependent.
-
-       Prior to any call to ``writeblocks(block, ...)`` littlefs issues
-       ``ioctl(6, block)``. This enables a device driver to erase the block
-       prior to a write if the hardware requires it. Alternatively a driver
-       might intercept ``ioctl(6, block)`` and return 0 (success). In this case
-       the driver assumes responsibility for detecting the need for erasure.
-
-       Unless otherwise stated ``ioctl(op, arg)`` can return ``None``.
-       Consequently an implementation can ignore unused values of ``op``. Where
-       ``op`` is intercepted, the return value for operations 4 and 5 are as
-       detailed above. Other operations should return 0 on success and non-zero
-       for failure, with the value returned being an ``OSError`` errno code.

docs/library/zephyr.DiskAccess.rst

@@ -34,5 +34,5 @@ Methods
 
     These methods implement the simple and extended
     :ref:`block protocol <block-device-interface>` defined by
-    :class:`vfs.AbstractBlockDev`.
+    :class:`os.AbstractBlockDev`.
 

docs/library/zephyr.FlashArea.rst

@@ -37,4 +37,4 @@ Methods
 
     These methods implement the simple and extended
     :ref:`block protocol <block-device-interface>` defined by
-    :class:`vfs.AbstractBlockDev`.
+    :class:`os.AbstractBlockDev`.

docs/mimxrt/pinout.rst

@@ -319,7 +319,7 @@ MIXMXRT1050-EVKB   D10/-/D11/D12/D13 (*)            -                        -
 MIXMXRT1060-EVK    D10/-/D11/D12/D13 (*)            -                        -
 MIXMXRT1064-EVK    D10/-/D11/D12/D13 (*)            -                        -
 MIXMXRT1170-EVK    D10/-/D11/D12/D13          D28/-/D25/D24/D26        -/-/D14/D15/D24
-Adafruit Metro M7  -/-/MOSI/MISO/SCK                -                        -
+Adafruit Metro M7  -/-/MOSI/MISO/SCK                -                        -         
 Olimex RT1010Py             -                 CS0/-/SDO/SDI/SCK        SDCARD with CS1
 Seeed ARCH MIX     J4_12/-/J4_14/J4_13/J4_15  J3_09/J3_05/J3_08_J3_11
 =================  =========================  =======================  ===============
@@ -375,7 +375,7 @@ Teensy 4.0         2   33     4        3       2       -        -       5
 Teensy 4.1         1   23     26       27      7       21       20      8
 Teensy 4.1         2   33     4        3       2       -        -       5
 Seeed Arch MIX     1   J4_09  J4_14    J4_15   J14_13  J4_11    J4_10   J4_10
-Adafruit Metro M7  1   D8     D10      D9      D12     D14      D15     D13
+Adafruit Metro M7  1   D8     D10      D9      D12     D14      D15     D13     
 Olimex RT1010Py    1   D8     D6       D7      D4      D1       D2      D3
 Olimex RT1010Py    3   -      D10      D9      D11     -        -       -
 MIMXRT_DEV         1   "MCK"  "SCK_TX" "WS_TX" "SD_TX" "SCK_RX" "WS_RX" "SD_RX"

docs/mimxrt/quickref.rst

@@ -309,7 +309,7 @@ rates (up to 30Mhz).  Hardware SPI is accessed via the
 For the assignment of Pins to SPI signals, refer to
 :ref:`Hardware SPI pinout <mimxrt_spi_pinout>`.
 The keyword option cs=n can be used to enable the cs pin 0 or 1 for an automatic cs signal. The
-default is cs=-1. Using cs=-1 the automatic cs signal is not created.
+default is cs=-1. Using cs=-1 the automatic cs signal is not created. 
 In that case, cs has to be set by the script. Clearing that assignment requires a power cycle.
 
 Notes:
@@ -438,36 +438,32 @@ The i.MXRT MCU supports battery backup of the RTC.  By connecting a battery of
 current drawn from the battery is ~20µA, which is rather high.  A CR2032 coin
 cell will last for about one year.
 
-Note: In v1.23.0 the support for subseconds was removed. When reading the RTC, 0 will
-be returned as value for subsecond, When setting the RTC time, the subsecond
-field is ignored. The RTC itself does not provide a microsecond value.
-
 SD card
 -------
 
 See :ref:`machine.SDCard <machine.SDCard>`::
 
-    import machine, os, vfs
+    import machine, os
 
     sd = machine.SDCard()
-    fs = vfs.VfsFat(sd)
-    vfs.mount(fs, "/sd") # mount
+    fs = os.VfsFat(sd)
+    os.mount(fs, "/sd")  # mount
     os.listdir('/sd')    # list directory contents
-    vfs.umount('/sd')    # eject
+    os.umount('/sd')     # eject
 
 Note: The i.mx-rt 1011 and 1015 based boards do not support the ``machine.SDCard``
 class.  For these, the SPI based driver ``sdcard.py`` from the MicroPython drivers
 can be used.  When using it, you have to overdrive the CS pin of the SPI hardware
 module.  Example::
 
-    import vfs, sdcard, machine
+    import os, sdcard, machine
 
     cs_pin = "D10"
     spi = machine.SPI(0) # SPI0 with cs at Pin "D10" used for SDCARD
     cs = machine.Pin(cs_pin, machine.Pin.OUT, value=1)
     sd = sdcard.SDCard(spi, cs)
-    fs = vfs.VfsFat(sd)
-    vfs.mount(fs, "/sdcard")
+    vfs = os.VfsFat(sd)
+    os.mount(vfs, "/sdcard")
 
 OneWire driver
 --------------
@@ -532,7 +528,7 @@ Ethernet.  Example usage::
     lan.active(True)
 
 If there is a DHCP server in the LAN, the IP address is supplied by that server.
-Otherwise, the IP address can be set with lan.ipconfig(addr4="...").  The default address
+Otherwise, the IP address can be set with lan.ifconfig().  The default address
 is 192.168.0.1.
 
 Teensy 4.1 does not have an Ethernet jack on the board, but PJRC offers an

docs/pyboard/general.rst

@@ -21,7 +21,7 @@ If needed, you can prevent the use of the SD card by creating an empty file
 called ``/flash/SKIPSD``.  If this file exists when the pyboard boots
 up then the SD card will be skipped and the pyboard will always boot from the
 internal filesystem (in this case the SD card won't be mounted but you can still
-mount and use it later in your program using ``vfs.mount``).
+mount and use it later in your program using ``os.mount``).
 
 (Note that on older versions of the board, ``/flash`` is called ``0:/`` and ``/sd``
 is called ``1:/``).

docs/reference/constrained.rst

@@ -211,7 +211,7 @@ two loops:
         spi.readinto(buf)
         # process data in buf
 
-The first creates a buffer on each pass whereas the second reuses a pre-allocated
+The first creates a buffer on each pass whereas the second re-uses a pre-allocated
 buffer; this is both faster and more efficient in terms of memory fragmentation.
 
 **Bytes are smaller than ints**

docs/reference/filesystem.rst

@@ -40,7 +40,7 @@ Block devices
 -------------
 
 A block device is an instance of a class that implements the
-:class:`vfs.AbstractBlockDev` protocol.
+:class:`os.AbstractBlockDev` protocol.
 
 Built-in block devices
 ~~~~~~~~~~~~~~~~~~~~~~
@@ -108,16 +108,16 @@ RAM using a ``bytearray``::
 
 It can be used as follows::
 
-    import vfs
+    import os
 
     bdev = RAMBlockDev(512, 50)
-    vfs.VfsFat.mkfs(bdev)
-    vfs.mount(bdev, '/ramdisk')
+    os.VfsFat.mkfs(bdev)
+    os.mount(bdev, '/ramdisk')
 
 An example of a block device that supports both the simple and extended
 interface (i.e. both signatures and behaviours of the
-:meth:`vfs.AbstractBlockDev.readblocks` and
-:meth:`vfs.AbstractBlockDev.writeblocks` methods) is::
+:meth:`os.AbstractBlockDev.readblocks` and
+:meth:`os.AbstractBlockDev.writeblocks` methods) is::
 
     class RAMBlockDev:
         def __init__(self, block_size, num_blocks):
@@ -148,13 +148,13 @@ interface (i.e. both signatures and behaviours of the
                 return 0
 
 As it supports the extended interface, it can be used with :class:`littlefs
-<vfs.VfsLfs2>`::
+<os.VfsLfs2>`::
 
-    import vfs
+    import os
 
     bdev = RAMBlockDev(512, 50)
-    vfs.VfsLfs2.mkfs(bdev)
-    vfs.mount(bdev, '/ramdisk')
+    os.VfsLfs2.mkfs(bdev)
+    os.mount(bdev, '/ramdisk')
 
 Once mounted, the filesystem (regardless of its type) can be used as it
 normally would be used from Python code, for example::
@@ -166,8 +166,8 @@ normally would be used from Python code, for example::
 Filesystems
 -----------
 
-MicroPython ports can provide implementations of :class:`FAT <vfs.VfsFat>`,
-:class:`littlefs v1 <vfs.VfsLfs1>` and :class:`littlefs v2 <vfs.VfsLfs2>`.
+MicroPython ports can provide implementations of :class:`FAT <os.VfsFat>`,
+:class:`littlefs v1 <os.VfsLfs1>` and :class:`littlefs v2 <os.VfsLfs2>`.
 
 The following table shows which filesystems are included in the firmware by
 default for given port/board combinations, however they can be optionally
@@ -197,16 +197,16 @@ recommended to use littlefs instead.
 To format the entire flash using FAT::
 
     # ESP8266 and ESP32
-    import vfs
-    vfs.umount('/')
-    vfs.VfsFat.mkfs(bdev)
-    vfs.mount(bdev, '/')
+    import os
+    os.umount('/')
+    os.VfsFat.mkfs(bdev)
+    os.mount(bdev, '/')
 
     # STM32
-    import os, vfs, pyb
-    vfs.umount('/flash')
-    vfs.VfsFat.mkfs(pyb.Flash(start=0))
-    vfs.mount(pyb.Flash(start=0), '/flash')
+    import os, pyb
+    os.umount('/flash')
+    os.VfsFat.mkfs(pyb.Flash(start=0))
+    os.mount(pyb.Flash(start=0), '/flash')
     os.chdir('/flash')
 
 Littlefs
@@ -222,16 +222,16 @@ resistant to filesystem corruption.
 To format the entire flash using littlefs v2::
 
     # ESP8266 and ESP32
-    import vfs
-    vfs.umount('/')
-    vfs.VfsLfs2.mkfs(bdev)
-    vfs.mount(bdev, '/')
+    import os
+    os.umount('/')
+    os.VfsLfs2.mkfs(bdev)
+    os.mount(bdev, '/')
 
     # STM32
-    import os, vfs, pyb
-    vfs.umount('/flash')
-    vfs.VfsLfs2.mkfs(pyb.Flash(start=0))
-    vfs.mount(pyb.Flash(start=0), '/flash')
+    import os, pyb
+    os.umount('/flash')
+    os.VfsLfs2.mkfs(pyb.Flash(start=0))
+    os.mount(pyb.Flash(start=0), '/flash')
     os.chdir('/flash')
 
 A littlefs filesystem can be still be accessed on a PC over USB MSC using the
@@ -264,14 +264,14 @@ block devices spanning a subset of the flash device.
 For example, to configure the first 256kiB as FAT (and available over USB MSC),
 and the remainder as littlefs::
 
-    import os, vfs, pyb
-    vfs.umount('/flash')
+    import os, pyb
+    os.umount('/flash')
     p1 = pyb.Flash(start=0, len=256*1024)
     p2 = pyb.Flash(start=256*1024)
-    vfs.VfsFat.mkfs(p1)
-    vfs.VfsLfs2.mkfs(p2)
-    vfs.mount(p1, '/flash')
-    vfs.mount(p2, '/data')
+    os.VfsFat.mkfs(p1)
+    os.VfsLfs2.mkfs(p2)
+    os.mount(p1, '/flash')
+    os.mount(p2, '/data')
     os.chdir('/flash')
 
 This might be useful to make your Python files, configuration and other
@@ -282,9 +282,9 @@ failure, etc.
 The partition at offset ``0`` will be mounted automatically (and the filesystem
 type automatically detected), but you can add::
 
-    import vfs, pyb
+    import os, pyb
     p2 = pyb.Flash(start=256*1024)
-    vfs.mount(p2, '/data')
+    os.mount(p2, '/data')
 
 to ``boot.py`` to mount the data partition.
 
@@ -297,7 +297,7 @@ define an arbitrary partition layout.
 At boot, the partition named "vfs" will be mounted at ``/`` by default, but any
 additional partitions can be mounted in your ``boot.py`` using::
 
-    import esp32, vfs
+    import esp32, os
     p = esp32.Partition.find(esp32.Partition.TYPE_DATA, label='foo')
-    vfs.mount(p, '/foo')
+    os.mount(p, '/foo')
 

docs/reference/manifest.rst

@@ -95,17 +95,6 @@ Note: The ``opt`` keyword argument can be set on the various functions, this con
 the optimisation level used by the cross-compiler.
 See :func:`micropython.opt_level`.
 
-.. function:: add_library(library, library_path, prepend=False)
-
-    Register the path to an external named *library*.
-
-    The path *library_path* will be automatically searched when using `require`.
-    By default the added library is added to the end of the list of libraries to
-    search.  Pass ``True`` to *prepend* to add it to the start of the list.
-
-    Additionally, the added library can be explicitly requested by using
-    ``require("name", library="library")``.
-
 .. function:: package(package_path, files=None, base_path=".", opt=None)
 
     This is equivalent to copying the "package_path" directory to the device
@@ -149,13 +138,11 @@ See :func:`micropython.opt_level`.
 
     You can use the variables above, such as ``$(PORT_DIR)`` in ``base_path``.
 
-.. function:: require(name, library=None)
+.. function:: require(name, unix_ffi=False)
 
     Require a package by name (and its dependencies) from :term:`micropython-lib`.
 
-    Optionally specify *library* (a string) to reference a package from a
-    library that has been previously registered with `add_library`. Otherwise
-    the list of library paths will be used.
+    Optionally specify unix_ffi=True to use a module from the unix-ffi directory.
 
 .. function:: include(manifest_path)
 

docs/reference/micropython2_migration.rst

@@ -71,11 +71,4 @@ which is useful for development and testing.
 Changes
 ~~~~~~~
 
-Introduction of a new module :mod:`vfs`.  The following functions and
-classes have moved out of :mod:`os` to :mod:`vfs`:
-- `os.mount`
-- `os.umount`
-- `os.VfsFat`
-- `os.VfsLfs1`
-- `os.VfsLfs2`
-- `os.VfsPosix`
+*None yet*

docs/reference/mpremote.rst

@@ -227,12 +227,11 @@ The full list of supported commands are:
   - ``cat <file..>`` to show the contents of a file or files on the device
   - ``ls`` to list the current directory
   - ``ls <dirs...>`` to list the given directories
-  - ``cp [-rf] <src...> <dest>`` to copy files
+  - ``cp [-r] <src...> <dest>`` to copy files
   - ``rm <src...>`` to remove files on the device
   - ``mkdir <dirs...>`` to create directories on the device
   - ``rmdir <dirs...>`` to remove directories on the device
   - ``touch <file..>`` to create the files (if they don't already exist)
-  - ``sha256sum <file..>`` to calculate the SHA256 sum of files
 
   The ``cp`` command uses a convention where a leading ``:`` represents a remote
   path. Without a leading ``:`` means a local path. This is based on the
@@ -257,11 +256,6 @@ The full list of supported commands are:
   This will copy the file to the device then enter the REPL. The ``+`` prevents
   ``"repl"`` being interpreted as a path.
 
-  The ``cp`` command supports the ``-r`` option to make a recursive copy.  By
-  default ``cp`` will skip copying files to the remote device if the SHA256 hash
-  of the source and destination file matches.  To force a copy regardless of the
-  hash use the ``-f`` option.
-
   **Note:** For convenience, all of the filesystem sub-commands are also
   :ref:`aliased as regular commands <mpremote_shortcuts>`, i.e. you can write
   ``mpremote cp ...`` instead of ``mpremote fs cp ...``.
@@ -475,9 +469,9 @@ An example ``config.py`` might look like:
     for ap in wl.scan():
         print(ap)
     """,], # Print out nearby WiFi networks.
-        "wl_ipconfig": [
+        "wl_ifconfig": [
     "exec",
-    "import network; sta_if = network.WLAN(network.STA_IF); print(sta_if.ipconfig('addr4'))",
+    "import network; sta_if = network.WLAN(network.STA_IF); print(sta_if.ifconfig())",
     """,], # Print ip address of station interface.
         "test": ["mount", ".", "exec", "import test"], # Mount current directory and run test.py.
         "demo": ["run", "path/to/demo.py"], # Execute demo.py on the device.
@@ -688,13 +682,6 @@ See :ref:`packages`.
 Install the package from the specified branch at org/repo on GitHub to the
 device. See :ref:`packages`.
 
-.. code-block:: bash
-
-  mpremote mip install gitlab:org/repo@branch
-
-Install the package from the specified branch at org/repo on GitLab to the
-device. See :ref:`packages`.
-
 .. code-block:: bash
 
   mpremote mip install --target /flash/third-party functools

docs/reference/mpyfiles.rst

@@ -58,7 +58,7 @@ If importing an .mpy file fails then try the following:
     sys_mpy = sys.implementation._mpy
     arch = [None, 'x86', 'x64',
         'armv6', 'armv6m', 'armv7m', 'armv7em', 'armv7emsp', 'armv7emdp',
-        'xtensa', 'xtensawin', 'rv32imc'][sys_mpy >> 10]
+        'xtensa', 'xtensawin'][sys_mpy >> 10]
     print('mpy version:', sys_mpy & 0xff)
     print('mpy sub-version:', sys_mpy >> 8 & 3)
     print('mpy flags:', end='')
@@ -86,8 +86,7 @@ and .mpy version.
 =================== ============
 MicroPython release .mpy version
 =================== ============
-v1.23.0 and up      6.3
-v1.22.x             6.2
+v1.22.0 and up      6.2
 v1.20 - v1.21.0     6.1
 v1.19.x             6
 v1.12 - v1.18       5
@@ -103,7 +102,6 @@ MicroPython repository at which the .mpy version was changed.
 =================== ========================================
 .mpy version change Git commit
 =================== ========================================
-6.2 to 6.3          bdbc869f9ea200c0d28b2bc7bfb60acd9d884e1b
 6.1 to 6.2          6967ff3c581a66f73e9f3d78975f47528db39980
 6 to 6.1            d94141e1473aebae0d3c63aeaa8397651ad6fa01
 5 to 6              f2040bfc7ee033e48acef9f289790f3b4e6b74e5

docs/reference/packages.rst

@@ -7,7 +7,7 @@ Installing packages with ``mip``
 --------------------------------
 
 Network-capable boards include the ``mip`` module, which can install packages
-from :term:`micropython-lib` and from third-party sites (including GitHub, GitLab).
+from :term:`micropython-lib` and from third-party sites (including GitHub).
 
 ``mip`` ("mip installs packages") is similar in concept to Python's ``pip`` tool,
 however it does not use the PyPI index, rather it uses :term:`micropython-lib`
@@ -38,28 +38,24 @@ install third-party libraries. The simplest way is to download a file directly::
 When installing a file directly, the ``target`` argument is still supported to set
 the destination path, but ``mpy`` and ``version`` are ignored.
 
-The URL can also start with ``github:`` or ``gitlab:`` as a simple way of pointing to content
-hosted on GitHub or GitLab::
+The URL can also start with ``github:`` as a simple way of pointing to content
+hosted on GitHub::
 
     >>> mip.install("github:org/repo/path/foo.py")  # Uses default branch
     >>> mip.install("github:org/repo/path/foo.py", version="branch-or-tag")  # Optionally specify the branch or tag
-    >>> mip.install("gitlab:org/repo/path/foo.py")  # Uses default branch
-    >>> mip.install("gitlab:org/repo/path/foo.py", version="branch-or-tag")  # Optionally specify the branch or tag
 
 More sophisticated packages (i.e. with more than one file, or with dependencies)
 can be downloaded by specifying the path to their ``package.json``.
 
     >>> mip.install("http://example.com/x/package.json")
     >>> mip.install("github:org/user/path/package.json")
-    >>> mip.install("gitlab:org/user/path/package.json")
 
 If no json file is specified, then "package.json" is implicitly added::
 
     >>> mip.install("http://example.com/x/")
     >>> mip.install("github:org/repo")  # Uses default branch of that repo
     >>> mip.install("github:org/repo", version="branch-or-tag")
-    >>> mip.install("gitlab:org/repo")  # Uses default branch of that repo
-    >>> mip.install("gitlab:org/repo", version="branch-or-tag")
+
 
 Using ``mip`` on the Unix port
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -87,8 +83,6 @@ can be used from a host PC to install packages to a locally connected device
     $ mpremote mip install http://example.com/x/y/foo.py
     $ mpremote mip install github:org/repo
     $ mpremote mip install github:org/repo@branch-or-tag
-    $ mpremote mip install gitlab:org/repo
-    $ mpremote mip install gitlab:org/repo@branch-or-tag
 
 The ``--target=path``, ``--no-mpy``, and ``--index`` arguments can be set::
 
@@ -126,8 +120,7 @@ A typical ``package.json`` for an example ``mlx90640`` library looks like::
       "deps": [
         ["collections-defaultdict", "latest"],
         ["os-path", "latest"],
-        ["github:org/micropython-additions", "main"],
-        ["gitlab:org/micropython-otheradditions", "main"]
+        ["github:org/micropython-additions", "main"]
       ],
       "version": "0.2"
     }

docs/reference/pyboard.py.rst

@@ -120,8 +120,9 @@ Some more examples::
     # Same, but using . instead.
     $ pyboard.py --device /dev/ttyACM0 -f cp :main.py .
 
-    # Copy three files to the device, keeping their names.
-    $ pyboard.py --device /dev/ttyACM0 -f cp main.py app.py foo.py :
+    # Copy three files to the device, keeping their names
+    # and paths (note: `lib` must exist on the device)
+    $ pyboard.py --device /dev/ttyACM0 -f cp main.py app.py lib/foo.py :
 
     # Remove a file from the device.
     $ pyboard.py --device /dev/ttyACM0 -f rm util.py

docs/renesas-ra/quickref.rst

@@ -387,15 +387,15 @@ SDCard
 The frozen sdcard driver (drivers/sdcard/sdcard.py) is available by connecting microSD card device to hardware SPI0 pins.::
 
     from machine import Pin, SPI
-    import os, vfs, sdcard
+    import os, sdcard
 
     spi = SPI(0, baudrate=500000)
     cs = Pin.cpu.P103
     sd = sdcard.SDCard(spi, cs)
-    vfs.mount(sd, '/sd')
+    os.mount(sd, '/sd')
     os.listdir('/')
     os.chdir('/sd')
-    vfs.umount('/sd')
+    os.umount('/sd')
 
 OneWire driver
 --------------

docs/rp2/quickref.rst

@@ -31,25 +31,12 @@ The MicroPython REPL is accessed via the USB serial port. Tab-completion is usef
 find out what methods an object has. Paste mode (ctrl-E) is useful to paste a
 large slab of Python code into the REPL.
 
-The :mod:`machine` module:
-
-machine.freq() allows to change the MCU frequency and control the peripheral
-frequency for UART and SPI. Usage::
-
-    machine.freq(MCU_frequency[, peripheral_frequency=48_000_000])
-
-The MCU frequency can be set in a range from less than 48 MHz to about 250MHz.
-The default at boot time is 125 MHz. The peripheral frequency must be either
-48 MHz or identical to the MCU frequency, with 48 MHz as the default.
-If the peripheral frequency is changed, any already existing instance of
-UART and SPI will change it's baud rate and may have to be re-configured::
+The :mod:`machine` module::
 
     import machine
 
     machine.freq()          # get the current frequency of the CPU
-    machine.freq(240000000) # set the CPU frequency to 240 MHz and keep
-                            # the UART frequency at 48MHz
-    machine.freq(125000000, 125000000) # set the CPU and UART frequency to 125 MHz
+    machine.freq(240000000) # set the CPU frequency to 240 MHz
 
 The :mod:`rp2` module::
 
@@ -200,14 +187,6 @@ Use the :ref:`machine.ADC <machine.ADC>` class::
     adc = ADC(Pin(26))     # create ADC object on ADC pin
     adc.read_u16()         # read value, 0-65535 across voltage range 0.0v - 3.3v
 
-The argument of the constructor ADC specifies either a Pin by number, name of as
-Pin object, or a channel number in the range 0 - 3 or ADC.CORE_TEMP for the
-internal temperature sensor. If a pin is specified,
-the pin is initialized in high-Z mode. If a channel number is used, the pin
-is not initialized and configuring is left to the user code. After hard reset,
-RP2040 pins operate in current sink mode at about 60µA. If the pin is not
-otherwise configured, that may lead to wrong ADC readings.
-
 Software SPI bus
 ----------------
 

docs/samd/pinout.rst

@@ -17,12 +17,12 @@ Adafruit ItsyBitsy M0 Express pin assignment table
 === ==== ============ ==== ==== ====== ====== ====== ======
 Pin GPIO Pin name     IRQ  ADC  Serial Serial TCC/TC TCC/TC
 === ==== ============ ==== ==== ====== ====== ====== ======
-  2 PA02           A0   2   0     -       -     -      -
- 40 PB08           A1   8   2     -      4/0   4/0     -
- 41 PB09           A2   9   3     -      4/1   4/1     -
-  4 PA04           A3   4   4     -      0/0   0/0     -
-  5 PA05           A4   5   5     -      0/1   0/1     -
- 34 PB02           A5   2  10     -      5/0   6/0     -
+  2 PA02           A0   2   0     -       -     -      - 
+ 40 PB08           A1   8   2     -      4/0   4/0     - 
+ 41 PB09           A2   9   3     -      4/1   4/1     - 
+  4 PA04           A3   4   4     -      0/0   0/0     - 
+  5 PA05           A4   5   5     -      0/1   0/1     - 
+ 34 PB02           A5   2  10     -      5/0   6/0     - 
  11 PA11           D0  11  19    0/3     2/3   1/1    0/3
  10 PA10           D1  10  18    0/2     2/2   1/0    0/2
  14 PA14           D2  14   -    2/2     4/2   3/0    0/4
@@ -30,31 +30,31 @@ Pin GPIO Pin name     IRQ  ADC  Serial Serial TCC/TC TCC/TC
   8 PA08           D4   -  16    0/0     2/0   0/0    1/2
  15 PA15           D5  15   -    2/3     4/3   3/1    0/5
  21 PA21           D7   5   -    5/3     3/3   7/1    0/7
-  7 PA07           D9   7   7     -      0/3   1/1     -
+  7 PA07           D9   7   7     -      0/3   1/1     - 
  18 PA18          D10   2   -    1/2     3/2   3/0    0/2
  16 PA16          D11   0   -    1/0     3/0   2/0    0/6
  19 PA19          D12   3   -    1/3     3/3   3/1    0/3
  17 PA17          D13   1   -    1/1     3/1   2/1    0/7
-  0 PA00  DOTSTAR_CLK   0   -     -      1/0   2/0     -
-  1 PA01 DOTSTAR_DATA   1   -     -      1/1   2/1     -
- 27 PA27     FLASH_CS  15   -     -       -     -      -
- 35 PB03   FLASH_MISO   3  11     -      5/1   6/1     -
- 54 PB22   FLASH_MOSI   6   -     -      5/2   7/0     -
- 55 PB23    FLASH_SCK   7   -     -      5/3   7/1     -
+  0 PA00  DOTSTAR_CLK   0   -     -      1/0   2/0     - 
+  1 PA01 DOTSTAR_DATA   1   -     -      1/1   2/1     - 
+ 27 PA27     FLASH_CS  15   -     -       -     -      - 
+ 35 PB03   FLASH_MISO   3  11     -      5/1   6/1     - 
+ 54 PB22   FLASH_MOSI   6   -     -      5/2   7/0     - 
+ 55 PB23    FLASH_SCK   7   -     -      5/3   7/1     - 
  12 PA12         MISO  12   -    2/0     4/0   2/0    0/6
  42 PB10         MOSI  10   -     -      4/2   5/0    0/4
  43 PB11          SCK  11   -     -      4/3   5/1    0/5
  23 PA23          SCL   7   -    3/1     5/1   4/1    0/5
  22 PA22          SDA   6   -    3/0     5/0   4/0    0/4
- 30 PA30        SWCLK  10   -     -      1/2   1/0     -
- 31 PA31        SWDIO  11   -     -      1/3   1/1     -
+ 30 PA30        SWCLK  10   -     -      1/2   1/0     - 
+ 31 PA31        SWDIO  11   -     -      1/3   1/1     - 
  24 PA24       USB_DM  12   -    3/2     5/2   5/0    1/2
  25 PA25       USB_DP  13   -    3/3     5/3   5/1    1/3
-  3 PA03                3   1     -       -     -      -
-  6 PA06                6   6     -      0/2   1/0     -
+  3 PA03                3   1     -       -     -      - 
+  6 PA06                6   6     -      0/2   1/0     - 
  13 PA13               13   -    2/1     4/1   2/0    0/7
  20 PA20                4   -    5/2     3/2   7/0    0/4
- 28 PA28                8   -     -       -     -      -
+ 28 PA28                8   -     -       -     -      - 
 === ==== ============ ==== ==== ====== ====== ====== ======
 
 
@@ -348,12 +348,12 @@ Adafruit Metro M4 Airlift pin assignment table
 === ==== ============ ==== ==== ==== ====== ====== ===== ===== =====
 Pin GPIO Pin name     IRQ  ADC  ADC  Serial Serial  TC    PWM   PWM
 === ==== ============ ==== ==== ==== ====== ====== ===== ===== =====
-  2 PA02           A0  2     0    -     -      -     -     -     -
-  5 PA05           A1  5     5    -     -     0/1   0/1    -     -
-  6 PA06           A2  6     6    -     -     0/2   1/0    -     -
- 32 PB00           A3  9    12    -     -     5/2   7/0    -     -
- 40 PB08           A4  8     2    0     -     4/0   4/0    -     -
- 41 PB09           A5  9     3    1     -     4/1   4/1    -     -
+  2 PA02           A0  2     0    -     -      -     -     -     - 
+  5 PA05           A1  5     5    -     -     0/1   0/1    -     - 
+  6 PA06           A2  6     6    -     -     0/2   1/0    -     - 
+ 32 PB00           A3  9    12    -     -     5/2   7/0    -     - 
+ 40 PB08           A4  8     2    0     -     4/0   4/0    -     - 
+ 41 PB09           A5  9     3    1     -     4/1   4/1    -     - 
  23 PA23           D0  7     -    -    3/1    5/0   4/1   1/7   0/3
  22 PA22           D1  6     -    -    3/0    5/1   4/0   1/6   0/2
  49 PB17           D2  1     -    -    5/1     -    6/1   3/1   0/5
@@ -364,17 +364,17 @@ Pin GPIO Pin name     IRQ  ADC  ADC  Serial Serial  TC    PWM   PWM
  44 PB12           D7 12     -    -    4/0     -    4/0   3/0   0/0
  21 PA21           D8  5     -    -    5/3    3/3   7/1   1/5   0/1
  20 PA20           D9  4     -    -    5/2    3/2   7/0   1/4   0/0
-  3 PA03         AREF  3    10    -     -      -     -     -     -
+  3 PA03         AREF  3    10    -     -      -     -     -     - 
  18 PA18          D10  2     -    -    1/2    3/2   3/0   1/2   0/6
  19 PA19          D11  3     -    -    1/3    3/3   3/1   1/3   0/7
  16 PA16          D13  0     -    -    1/0    3/1   2/0   1/0   0/4
- 36 PB04     ESP_BUSY  4     -    6     -      -     -     -     -
+ 36 PB04     ESP_BUSY  4     -    6     -      -     -     -     - 
  15 PA15       ESP_CS 15     -    -    2/3    4/3   3/1   2/1   1/3
- 33 PB01    ESP_GPIO0  1    13    -     -     5/3   7/1    -     -
- 37 PB05    ESP_RESET  5     -    7     -      -     -     -     -
- 55 PB23      ESP_RTS  7     -    -    1/3    5/3   7/1    -     -
-  7 PA07       ESP_RX  7     7    -     -     0/3   1/1    -     -
-  4 PA04       ESP_TX  4     4    -     -     0/0   0/0    -     -
+ 33 PB01    ESP_GPIO0  1    13    -     -     5/3   7/1    -     - 
+ 37 PB05    ESP_RESET  5     -    7     -      -     -     -     - 
+ 55 PB23      ESP_RTS  7     -    -    1/3    5/3   7/1    -     - 
+  7 PA07       ESP_RX  7     7    -     -     0/3   1/1    -     - 
+  4 PA04       ESP_TX  4     4    -     -     0/0   0/0    -     - 
  43 PB11     FLASH_CS 12     -    -     -     4/3   5/1   0/5   1/1
  11 PA11   FLASH_HOLD 11    11    -    0/3    2/3   1/1   0/3   1/7
   9 PA09   FLASH_MISO  9     9    3    0/1    2/0   0/1   0/1   1/5
@@ -383,21 +383,21 @@ Pin GPIO Pin name     IRQ  ADC  ADC  Serial Serial  TC    PWM   PWM
  10 PA10     FLASH_WP 10    10    -    0/2    2/2   1/0   0/2   1/6
  14 PA14         MISO 14     -    -    2/2    4/2   3/0   2/0   1/2
  12 PA12         MOSI 12     -    -    2/0    4/1   2/0   0/6   1/2
- 54 PB22     NEOPIXEL 22     -    -    1/2    5/2   7/0    -     -
- 38 PB06        RXLED  6     -    8     -      -     -     -     -
+ 54 PB22     NEOPIXEL 22     -    -    1/2    5/2   7/0    -     - 
+ 38 PB06        RXLED  6     -    8     -      -     -     -     - 
  13 PA13          SCK 13     -    -    2/1    4/0   2/1   0/7   1/3
- 35 PB03          SCL  9    15    -     -     5/1   6/1    -     -
- 34 PB02          SDA  2    14    -     -     5/0   6/0   2/2    -
- 30 PA30        SWCLK 14     -    -    7/2    1/2   6/0   2/0    -
- 31 PA31        SWDIO 15     -    -    7/3    1/3   6/1   2/1    -
+ 35 PB03          SCL  9    15    -     -     5/1   6/1    -     - 
+ 34 PB02          SDA  2    14    -     -     5/0   6/0   2/2    - 
+ 30 PA30        SWCLK 14     -    -    7/2    1/2   6/0   2/0    - 
+ 31 PA31        SWDIO 15     -    -    7/3    1/3   6/1   2/1    - 
  62 PB30          SWO 14     -    -    7/0    5/1   0/0   4/0   0/6
- 39 PB07        TXLED  7     -    9     -      -     -     -     -
- 24 PA24       USB_DM  8     -    -    3/2    5/2   5/0   2/2    -
- 25 PA25       USB_DP  9     -    -    3/3    5/3   5/1    -     -
+ 39 PB07        TXLED  7     -    9     -      -     -     -     - 
+ 24 PA24       USB_DM  8     -    -    3/2    5/2   5/0   2/2    - 
+ 25 PA25       USB_DP  9     -    -    3/3    5/3   5/1    -     - 
  17 PA17   USB_HOSTEN  1     -    -    1/1    3/0   2/1   1/1   0/5
-  0 PA00            -  0     -    -     -     1/0   2/0    -     -
-  1 PA01            -  1     -    -     -     1/1   2/1    -     -
- 27 PA27            - 11     -    -     -      -     -     -     -
+  0 PA00            -  0     -    -     -     1/0   2/0    -     - 
+  1 PA01            -  1     -    -     -     1/1   2/1    -     - 
+ 27 PA27            - 11     -    -     -      -     -     -     - 
  63 PB31            - 15     -    -    7/1    5/0   0/1   4/1   0/7
 === ==== ============ ==== ==== ==== ====== ====== ===== ===== =====
 
@@ -870,7 +870,7 @@ Adafruit ItsyBitsy M4 Express :ref:`samd51_pinout_table`.
 
 The default devices at the board are:
 
-- UART 2 at pins PA13/PA12, labelled RXD/TXD
+- UART 1 at pins PB23/PB22, labelled RXD/TXD
 - I2C 5 at pins PA22/PA23, labelled SDA/SCL
 - SPI 4 at pins PB12/PB11/PB13, labelled MOSI, MISO and SCK
 - DAC output on pins PA02 and PA05, labelled A0 and A4
@@ -884,36 +884,36 @@ The tables shown above were created with small a Python script running on the ta
   from machine import Pin
   import os
 
-  def print_item(e, txt):
+  def print_entry(e, txt):
       print(txt, end=": ")
       if e == 255:
           print(" - ", end="")
       else:
           print("%d/%d" % (e >> 4, e & 0x0f), end="")
 
-  def print_pininfo(pin_id, name, info):
-
-      print("%3d" % pin_id, end=" ")
-      print("%4s %12s" % (info[0], name), end="")
+  def print_pininfo(pin, info):
+      print("%3d" % pin, end=" ")
+      print("P%c%02d" % ("ABCD"[pin // 32], pin % 32), end="")
+      print(" %12s" % info[0], end="")
       print(" IRQ:%2s" % (info[1] if info[1] != 255 else "-"), end="")
       print(" ADC0:%2s" % (info[2] if info[2] != 255 else "-"), end="")
       if len(info) == 7:
-          print_item(info[3], " Serial1")
-          print_item(info[4], " Serial2")
-          print_item(info[5], " PWM1" if (info[5] >> 4) < 3 else "   TC")
-          print_item(info[6], " PWM2")
+          print_entry(info[3], " Serial1")
+          print_entry(info[4], " Serial2")
+          print_entry(info[5], " PWM1" if (info[5] >> 4) < 3 else "   TC")
+          print_entry(info[6], " PWM2")
       else:
           print(" ADC1:%2s" % (info[3] if info[3] != 255 else "-"), end="")
-          print_item(info[4], " Serial1")
-          print_item(info[5], " Serial2")
-          print_item(info[6], " TC")
-          print_item(info[7], " PWM1")
-          print_item(info[8], " PWM2")
+          print_entry(info[4], " Serial1")
+          print_entry(info[5], " Serial2")
+          print_entry(info[6], " TC")
+          print_entry(info[7], " PWM1")
+          print_entry(info[8], " PWM2")
       print()
 
   def tblkey(i):
-      name = i[1]
-      if name != "":
+      name = i[1][0]
+      if name != "-":
           if len(name) < 3:
               return " " + name
           else:
@@ -921,25 +921,17 @@ The tables shown above were created with small a Python script running on the ta
       else:
           return "zzzzzzz%03d" % i[0]
 
-  def table(num=127, sort=True):
+  def table(num = 127):
       pintbl = []
-      inv_bd = {v: k for k, v in Pin.board.__dict__.items()}
       for i in range(num):
           try:
-              p = Pin(i)
-              pi = pininfo(p)
-              if p in inv_bd.keys():
-                  name = inv_bd[p]
-              else:
-                  name = ""
-              pintbl.append((i, name, pininfo(i)))
+              pintbl.append((i, pininfo(i)))
           except:
               pass
               # print("not defined")
 
-      if sort:
-          pintbl.sort(key=tblkey)
+      pintbl.sort(key=tblkey)
       for item in pintbl:
-          print_pininfo(item[0], item[1], item[2])
+          print_pininfo(item[0], item[1])
 
   table()

docs/samd/quickref.rst

@@ -65,8 +65,6 @@ Use the :mod:`time <time>` module::
     start = time.ticks_ms() # get millisecond counter
     delta = time.ticks_diff(time.ticks_ms(), start) # compute time difference
 
-Note that :func:`time.sleep_us()` delays by busy waiting. During that time, other tasks are
-not scheduled.
 
 Clock and time
 --------------

docs/wipy/general.rst

@@ -373,7 +373,7 @@ functions are defined in ``os`` module:
    Mounts a block device (like an ``SD`` object) in the specified mount
    point. Example::
 
-      vfs.mount(sd, '/sd')
+      os.mount(sd, '/sd')
 
 .. function:: unmount(path)