1. 19 9月, 2022 1 次提交
  2. 17 9月, 2022 4 次提交
    • M
      Update Arduino version to 2.0.5 · 2d6ca351
      me-no-dev 提交于
      2d6ca351
    • Z
      Add newly board (Deneyap Kart G) (#7257) · aac028a4
      Zeynep Dicle 提交于
      * Add new board (Deneyap Kart 1A)
      
      * Update pins_arduino.h
      
      * Add newly  board (Deneyap Kart G)
      
      New Deneyap Family member, wearable development board
      aac028a4
    • R
      Fix race condition with USBHID semaphore (#7205) · ccf0d877
      RefactorFactory 提交于
      The HID semaphore allows USBHID::SendReport() to wait for the completion of
      report sending.
      
      With a zero timeout xSemaphoreTake() after calling tud_hid_n_report(),
      occasionally, the following would happening:
      
      1. USBHID::SendReport() would send a report by calling tud_hid_n_report().
      2. The send would complete and (presumably on another thread)
         tud_hid_report_complete_cb() would be called and it would xSemaphoreGive()
         the semaphore.
      3. In USBHID::SendReport(), the zero timeout xSemaphoreTake(sem, 0) would
         succeed, taking the semaphore.
      4. On the next line, xSemaphoreTake(sem, timeout_ms ...) would timeout
         because the semaphore was already taken by the previous line of code.
      
      The result would be waiting timeout_ms for no reason.
      
      The purpose of the zero timeout xSemaphoreTake() is to clear the semaphore in
      case a previous SendReport() timed out waiting for the semaphore. In that case,
      tud_hid_report_complete_cb() may be called after the timeout, giving the
      semaphore. Then the next SendReport() would start with the semaphore given,
      which isn't desired if we want to call xSemaphoreTake(sem, timeout_ms ...) on
      it.
      
      There have also been other cases where tud_hid_report_complete_cb() is called
      an extra time, causing the same situation.
      
      The fix is to move the zero timeout xSemaphoreTake() before the call to
      tud_hid_n_report(). This eliminates the race between the zero timeout
      xSemaphoreTake() and tud_hid_report_complete_cb() in the common case when no
      timeout occurs.
      
      There is still a possible race condition between the zero timeout
      xSemaphoreTake() and tud_hid_report_complete_cb() in the case of a timeout,
      but that should be rarer.
      ccf0d877
    • D
      Fix corrupt debug message in esp32-hal-cpu.c (#7264) · b473fc69
      David McCurley 提交于
      Issue: Serial data sent during frequency change is corrupted.
      Fixes corrupt debug message by printing the message after the frequency change is completed.
      b473fc69
  3. 16 9月, 2022 2 次提交
  4. 15 9月, 2022 2 次提交
  5. 14 9月, 2022 12 次提交
  6. 07 9月, 2022 4 次提交
  7. 06 9月, 2022 1 次提交
    • V
      Update PlatformIO build scripts (#7200) · 074f3151
      Valerii Koval 提交于
      This update includes the following:
      
      - Implemented an additional build step that produces an adjusted bootloader image with updated headers
        according to  selected flash mode and size values. This step is only executed for debugging or uploading
        via debug probes.
      
      - Implemented a basic mechanism to dynamically add an extra UF2 bootloader image if corresponding
        partition is selected (e.g. for Adafruit targets)
      
      - Minor code formatting
      074f3151
  8. 29 8月, 2022 2 次提交
  9. 26 8月, 2022 1 次提交
  10. 24 8月, 2022 1 次提交
  11. 22 8月, 2022 4 次提交
  12. 16 8月, 2022 5 次提交
  13. 15 8月, 2022 1 次提交
    • J
      Added NVS test sketch + test script (#6885) · ac7879c6
      Jan Procházka 提交于
      * Added NVS test sketch + test script
      
      * Added cfg.json with multiple fqbns
      
      * cfg.json missing commas fix
      
      * Changed OPI PSRAM to QSPI accordind to new HW setup.
      
      * disabled PSRAM for ESP32S3
      
      * Reverting PSRAM changes
      
      * Remove Octal flash test
      
      Octal flash needs to be tested locally before each release.
      ac7879c6