diff --git a/components/driver/usb_serial_jtag/usb_serial_jtag.c b/components/driver/usb_serial_jtag/usb_serial_jtag.c index b113beca1f90..e1f1354c2aba 100644 --- a/components/driver/usb_serial_jtag/usb_serial_jtag.c +++ b/components/driver/usb_serial_jtag/usb_serial_jtag.c @@ -32,7 +32,6 @@ typedef struct{ // TX parameters uint32_t tx_buf_size; /*!< TX buffer size */ RingbufHandle_t tx_ring_buf; /*!< TX ring buffer handler */ - bool tx_has_tried_blocking; /*!< TX have we tried a blocking send already? */ } usb_serial_jtag_obj_t; static usb_serial_jtag_obj_t *p_usb_serial_jtag_obj = NULL; @@ -162,31 +161,11 @@ int usb_serial_jtag_write_bytes(const void* src, size_t size, TickType_t ticks_t ESP_RETURN_ON_FALSE(src != NULL, ESP_ERR_INVALID_ARG, USB_SERIAL_JTAG_TAG, "Invalid buffer pointer."); ESP_RETURN_ON_FALSE(p_usb_serial_jtag_obj != NULL, ESP_ERR_INVALID_ARG, USB_SERIAL_JTAG_TAG, "The driver hasn't been initialized"); - usb_serial_jtag_obj_t* sjtag = p_usb_serial_jtag_obj; - - // try to send without blocking - if (xRingbufferSend(sjtag->tx_ring_buf, (void*) (src), size, 0)) { - goto success; - } - - // If the ring buffer is full, try to send again with a short - // blocking delay, hoping for the buffer to become available soon. - // If we still fail, dont ever block again until the buffer has space again. - if (sjtag->tx_has_tried_blocking == false) { - if (xRingbufferSend(sjtag->tx_ring_buf, (void*) (src), size, ticks_to_wait)) { - goto success; - } else { - sjtag->tx_has_tried_blocking = true; - } - } - - // tx failure - return 0; - -success: - // Now trigger the ISR to read more data from the ring buffer. + const uint8_t *buff = (const uint8_t *)src; + // Blocking method, Sending data to ringbuffer, and handle the data in ISR. + xRingbufferSend(p_usb_serial_jtag_obj->tx_ring_buf, (void*) (buff), size, ticks_to_wait); + // Now trigger the ISR to read data from the ring buffer. usb_serial_jtag_ll_ena_intr_mask(USB_SERIAL_JTAG_INTR_SERIAL_IN_EMPTY); - sjtag->tx_has_tried_blocking = false; // clear return size; } diff --git a/components/vfs/vfs_usb_serial_jtag.c b/components/vfs/vfs_usb_serial_jtag.c index b5427d394be3..d17a2a4d6c76 100644 --- a/components/vfs/vfs_usb_serial_jtag.c +++ b/components/vfs/vfs_usb_serial_jtag.c @@ -77,6 +77,8 @@ typedef struct { // When the driver is used (via esp_vfs_usb_serial_jtag_use_driver), // reads are either blocking or non-blocking depending on this flag. bool non_blocking; + // TX has already tried a blocking send. + bool tx_tried_blocking; // Newline conversion mode when transmitting esp_line_endings_t tx_mode; // Newline conversion mode when receiving @@ -405,7 +407,18 @@ static void usbjtag_tx_char_via_driver(int fd, int c) { char ch = (char) c; TickType_t ticks = (TX_FLUSH_TIMEOUT_US / 1000) / portTICK_PERIOD_MS; - usb_serial_jtag_write_bytes(&ch, 1, ticks); + if (usb_serial_jtag_write_bytes(&ch, 1, 0) != 0) { + s_ctx.tx_tried_blocking = false; + return; + } + + if (s_ctx.tx_tried_blocking == false) { + if (usb_serial_jtag_write_bytes(&ch, 1, ticks) != 0) { + return; + } else { + s_ctx.tx_tried_blocking = true; + } + } } void esp_vfs_usb_serial_jtag_use_nonblocking(void) diff --git a/docs/en/api-guides/usb-serial-jtag-console.rst b/docs/en/api-guides/usb-serial-jtag-console.rst index 8c7eb1620f38..fcb9a3e7fbd1 100644 --- a/docs/en/api-guides/usb-serial-jtag-console.rst +++ b/docs/en/api-guides/usb-serial-jtag-console.rst @@ -61,9 +61,9 @@ There are several limitations to the USB Serial/JTAG console feature. These may 2. If the application enters deep sleep mode, the USB Serial/JTAG device will disappear from the system. -3. For data sent in the direction of ESP32 to PC Terminal (e.g. stdout, logs), the ESP32 first writes to a small internal buffer. If this buffer becomes full (for example, if no PC Terminal is connected), the ESP32 will do a one-time wait of 50ms hoping for the PC Terminal to request the data. This can appear as a very brief 'pause' in your application. +3. For data sent in the direction of {IDF_TARGET_NAME} to PC Terminal (e.g. stdout, logs), the {IDF_TARGET_NAME} first writes to a small internal buffer. If this buffer becomes full (for example, if no PC Terminal is connected), the {IDF_TARGET_NAME} will do a one-time wait of 50ms hoping for the PC Terminal to request the data. This can appear as a very brief 'pause' in your application. -4. For data sent in the PC Terminal to ESP32 direction (e.g. console commands), many PC Terminals will wait for the ESP32 to ingest the bytes before allowing you to sending more data. This is in contrast to using a USB-to-Serial (UART) bridge chip, which will always ingest the bytes and send them to a (possibly not listening) ESP32. +4. For data sent in the PC Terminal to {IDF_TARGET_NAME} direction (e.g. console commands), many PC Terminals will wait for the {IDF_TARGET_NAME} to ingest the bytes before allowing you to sending more data. This is in contrast to using a USB-to-Serial (UART) bridge chip, which will always ingest the bytes and send them to a (possibly not listening) {IDF_TARGET_NAME}. 5. The USB Serial/JTAG device won't work in sleep modes as normal due to the lack of APB clock in sleep modes. This includes deep-sleep, light-sleep (automataic light-sleep as well).