1. 26 10月, 2022 4 次提交
  2. 25 10月, 2022 2 次提交
  3. 24 10月, 2022 2 次提交
  4. 30 9月, 2022 2 次提交
  5. 27 9月, 2022 1 次提交
  6. 24 9月, 2022 1 次提交
  7. 23 9月, 2022 1 次提交
  8. 19 9月, 2022 1 次提交
  9. 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
  10. 16 9月, 2022 2 次提交
  11. 15 9月, 2022 2 次提交
  12. 14 9月, 2022 12 次提交
  13. 07 9月, 2022 4 次提交
  14. 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
  15. 29 8月, 2022 1 次提交