1. 26 Apr, 2023 22 commits
  2. 21 Apr, 2023 3 commits
    • Damien George's avatar
      extmod/btstack: Switch to use hci_dump_init instead of hci_dump_open. · 9e6885ad
      Damien George authored
      The latter is no longer available in the version of BTstack now in use by
      this repository.
      Signed-off-by: default avatarDamien George <damien@micropython.org>
      9e6885ad
    • Damien George's avatar
      shared/tinyusb: Revert setting of CFG_TUD_CDC_EP_BUFSIZE to 256. · ec1eecca
      Damien George authored
      This reverts commit 0613d3e3.
      
      The value of CFG_TUD_CDC_EP_BUFSIZE should match the endpoint size,
      otherwise data may stay in the lower layers of the USB stack (and not
      passed up to the higher layers) until a total of CFG_TUD_CDC_EP_BUFSIZE
      bytes have been received, which may not happen for a long time.
      
      Fixes issue #11253.
      Signed-off-by: default avatarDamien George <damien@micropython.org>
      ec1eecca
    • David (Pololu)'s avatar
      rp2/machine_i2c: Add timeout parameter for machine.I2C(). · bf3eb9dc
      David (Pololu) authored
      This commit adds support for the `timeout` keyword argument to machine.I2C
      on the rp2 port, following how it's done on other ports.
      
      The main motivation here is avoid the interpreter crashing due to infinite
      loops when SDA is stuck low, which is quite common if the board gets reset
      while reading from an I2C device.
      
      A default timeout of 50ms is chosen because it's consistent with:
      - Commit a707fe50 which used a timeout of
        50,000us for zero-length writes on the rp2 port.
      - The machine.SoftI2C class which uses 50,000us as the default timeout.
      - The stm32 port's hardware I2C, which uses 50,000us for
        I2C_POLL_DEFAULT_TIMEOUT_US.
      
      This commit also fixes the default timeout on the esp32 port to be
      consistent with the above, and updates the documentation for machine.I2C to
      document this keyword argument.
      bf3eb9dc
  3. 14 Apr, 2023 1 commit
  4. 12 Apr, 2023 1 commit
  5. 11 Apr, 2023 5 commits
  6. 07 Apr, 2023 1 commit
    • Jim Mussared's avatar
      tools/manifestfile.py: Add support for publishing packages to PyPI. · cfd3b709
      Jim Mussared authored
      This adds a new MODE_PYPROJECT, which gives basic support to allow
      packaging a small subset of micropython-lib packages to PyPI.
      
      This change allows a package in micropython-lib to:
      - Add a "pypi" name to its metadata indicating that it's based on a PyPI
        package.
      - Add "stdlib" to its metadata indicating that it's a micropython version
        of a stdlib package.
      - Add a "pypi_publish" name to its metadata to indicate that it can be
        published to PyPI (this can be different to the package name, e.g. "foo"
        might want to be published as "micropython-foo").
      
      When a package requires() another one, if it's in MODE_PYPROJECT then if
      the package is from pypi then it will record that as a pypi dependency
      instead (or no dependency at all if it's from stdlib).
      
      Also allows require() to explicitly specify the pypi name.
      Signed-off-by: default avatarJim Mussared <jim.mussared@gmail.com>
      cfd3b709
  7. 05 Apr, 2023 4 commits
    • David Grayson's avatar
      shared/runtime/pyexec: Don't allow Ctrl+C to interrupt frozen boot code. · c046b23e
      David Grayson authored
      Helps prevent the filesystem from getting formatted by mistake, among other
      things.  For example, on a Pico board, entering Ctrl+D and Ctrl+C fast many
      times will eventually wipe the filesystem (without warning or notice).
      
      Further rationale: Ctrl+C is used a lot by automation scripts (eg mpremote)
      and UI's (eg Mu, Thonny) to get the board into a known state.  If the board
      is not responding for a short time then it's not possible to know if it's
      just a slow start up (eg in _boot.py), or an infinite loop in the main
      application.  The former should not be interrupted, but the latter should.
      The only way to distinguish these two cases would be to wait "long enough",
      and if there's nothing on the serial after "long enough" then assume it's
      running the application and Ctrl+C should break out of it.  But defining
      "long enough" is impossible for all the different boards and their possible
      behaviour.  The solution in this commit is to make it so that frozen
      start-up code cannot be interrupted by Ctrl+C.  That code then effectively
      acts like normal C start-up code, which also cannot be interrupted.
      
      Note: on the stm32 port this was never seen as an issue because all
      start-up code is in C.  But now other ports start to put more things in
      _boot.py and so this problem crops up.
      Signed-off-by: default avatarDavid Grayson <davidegrayson@gmail.com>
      c046b23e
    • iabdalkader's avatar
      mimxrt/pendsv: Clean up PendSV code. · db4b416e
      iabdalkader authored
      The dispatch active flag is only set once and never reset, so it will
      always call the dispatch handler (once enabled), and it's not really
      needed because it doesn't make things more efficient.
      
      Also remove unused included headers.
      db4b416e
    • robert-hh's avatar
      nrf/modules/machine/uart: Prevent UART lock-up after a receive error. · eb6e5143
      robert-hh authored
      Like frame error, overrun, etc.  Fix is provided by @ricksorensen.
      eb6e5143
    • robert-hh's avatar
      nrf/nrfx_config: Use UARTE for nrf52xxx devices. · a529e0e8
      robert-hh authored
      It was incomplete.
      a529e0e8
  8. 04 Apr, 2023 3 commits