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