This commit addes an example showing how to receive messages using the TWAI
driver interface and a CAN transceiver. Specifically, the example demonstrates:
- How to configure and install the TWAI drvier
- How to poll for TWAI events (i.e., alerts) using twai_read_alerts()
- How to handle the various events (such as TWAI_ALERT_RX_DATA)
Closes https://github.com/espressif/arduino-esp32/pull/7430
Co-authored-by: Stephan Martin <designer2k2@gmail.com>
* Add I2C and SPI pin definitions to wt32-eth01 pins
Added missing pins based on testing using a RTC (I2C) and SD card reader (SPI).
* Remove define macros
Co-authored-by: Rodrigo Garcia <rodrigo.garcia@espressif.com>
Co-authored-by: Jan Procházka <90197375+P-R-O-C-H-Y@users.noreply.github.com>
* Added enableScenes API
* Added enableScenes API documentation
* Added enableScenes API to example
Co-authored-by: Jan Procházka <90197375+P-R-O-C-H-Y@users.noreply.github.com>
* Add the Partition Scheme Menu to HELTEC LoRa32 V1
This is missing from many boards, i may add that to all of them
* reordered heltec_wifi_lora_32 partition options
Co-authored-by: Jan Procházka <90197375+P-R-O-C-H-Y@users.noreply.github.com>
* added test for touch peripheral
* removed cfg.json
* pass test for unsupported chips
* fixed condition
* changed released value for S2
* add new chip error
Fixed#7406 . The "reason2str" macro in WiFiGeneric.cpp tries to read memory from index "-1" in "system_event_reasons" array when handling STA_DISCONNECTED event with reason 0. Dealing with reason 0 as a reason 1 (WIFI_REASON_UNSPECIFIED) will solve the problem (the reason for this event to arrive with reason 0 is unknown). #7406
The original code assumes 100Hz FreeRTOS tick rate and just supplies vTaskDelay with the assumed number of ticks required for the wanted delay. This patch simply fixes it to use portTICK_PERIOD_MS, thereby working correctly regardless of what tick rate FreeRTOS has been configured to run at.
Somehow the fix#7129 was not applied to NORA-W10 probably both changes were happening at around the same time, this PR fixes this.
Co-authored-by: Jan Procházka <90197375+P-R-O-C-H-Y@users.noreply.github.com>
As per #6962 we have another case of build.flash_type incorrectly named qspi; this commit fixes the issue for the unphone9 board.
Co-authored-by: Jan Procházka <90197375+P-R-O-C-H-Y@users.noreply.github.com>
* Update of supported SoCs
Changed ESP32-S3 support to stable.
* Update getting_started.rst
Co-authored-by: Pedro Minatel <pedro.minatel@espressif.com>
* Added support for Cytron Maker Feather AIoT S3.
* 1. Select OPI PSRAM by default.
2. Fixed pin name error in variant.cpp.
3. Added definition for RGB_BUILTIN.
* Define the RGB_BUILTIN as shown in #6979.
* Added pin definition for A12 (Vin Sense).
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.
Issue: Serial data sent during frequency change is corrupted.
Fixes corrupt debug message by printing the message after the frequency change is completed.
* Changes UART ISR to only trigger on RX FIFO Full and timeout
* changes initial RX timeout
* Eliminates extra testing for _uart != NULL
* reconfiguration with "uartSetFastReading()"
* Adds new function "uartSetFastReading()"
* changed default onReceive() behaviour
* forces User callback in case of error
* Error Code Order
Set NO_ERROR as first error code, same as ESP_OK = 0
