Thanks to visit codestin.com
Credit goes to github.com

Skip to content

v1.22.1: uart.flush() takes way too long #13377

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hmaerki opened this issue Jan 7, 2024 · 7 comments
Closed

v1.22.1: uart.flush() takes way too long #13377

hmaerki opened this issue Jan 7, 2024 · 7 comments
Labels

Comments

@hmaerki
Copy link
Contributor

hmaerki commented Jan 7, 2024

Observation

Raspberry Pi pico, v1.21.0, uart.flush() takes 11ms (correct)
Raspberry Pi pico, v1.22.1/0, uart.flush() takes 785ms (way too long)

How to reproduce

import sys
import time
from machine import UART

print(sys.implementation)

bits_per_s = 9600
uart = UART(0, bits_per_s, bits=8, parity=None, stop=1, tx="GPIO0", rx="GPIO1")

text = "Hello World"
start_us = time.ticks_us()
uart.write(text)
print(f"Duration write() {time.ticks_diff(time.ticks_us(), start_us)/1000:0.2f}ms")

uart.flush()
print(f"Duration write()+flush() {time.ticks_diff(time.ticks_us(), start_us)/1000:0.2f}ms")

bits_per_char = 11 # 1(startbit)+8(bits)+1(stopbit)+1(parity)
print(f"Expected time {len(text)*bits_per_char/bits_per_s*1000:0.2f}ms")

Output

(name='micropython', version=(1, 21, 0), _machine='Raspberry Pi Pico with RP2040', _mpy=4358)
Duration write() 0.16ms
Duration write()+flush() **11.41ms** (ok)
Expected time 12.60ms
(name='micropython', version=(1, 22, 0, ''), _machine='Raspberry Pi Pico with RP2040', _mpy=4614)
Duration write() 0.15ms
Duration write()+flush() **785.37ms** (way too long)
Expected time 12.60ms
(name='micropython', version=(1, 22, 1, ''), _machine='Raspberry Pi Pico with RP2040', _mpy=4614)
Duration write() 0.20ms
Duration write()+flush() **785.42ms** (way too long)
Expected time 12.60ms
@beyonlo
Copy link

beyonlo commented Jan 7, 2024

Hello,

I executed this code in the ESP32-S3 using 1.22 and the flush works fine, without that long time:

$ mpremote run uart_flush_test.py 
(name='micropython', version=(1, 22, 0, ''), _machine='Generic ESP32S3 module with ESP32S3', _mpy=10758)
Duration write() 0.15ms
Duration write()+flush() 11.61ms
Expected time 12.60ms

Ps: I changed just the UART init to proper configuration for the ESP32-S3:

uart = UART(1, bits_per_s, bits=8, parity=None, stop=1, tx=37, rx=38)

@robert-hh
Copy link
Contributor

robert-hh commented Jan 7, 2024

It was this commit 2852935 which changed the wait loop to call mp_event_wait_ms((timeout - now) / 1000);. It should better call mp_event_handle_nowait().

Edit: With that change, the result is:

(name='micropython', version=(1, 23, 0, 'preview'), _machine='Raspberry Pi Pico with RP2040', _mpy=4614)
Duration write() 0.18ms
Duration write()+flush() 10.49ms
Expected time 11.46ms

The expected time is 11.45 ms (no parity!), so it returns while the last byte is sent.

@hmaerki
Copy link
Contributor Author

hmaerki commented Jan 7, 2024

Hi @robert-hh

You are a hero!

  • May you do a Pull Request with your change?
  • If you send me your patched firmware, I can test it in my MODBUS application and the scope.

@robert-hh
Copy link
Contributor

Fixed firmware is here: https://github.com/robert-hh/Shared-Stuff, files firmware_PICO_flush.uf2 and firmware_PICO_W_flush.uf2.

@robert-hh
Copy link
Contributor

By the way, instead of uart.flush() you can as well use while not uart.txdone(): pass.

dpgeorge pushed a commit to robert-hh/micropython that referenced this issue Jan 15, 2024
Do not wait in the worst case up to the timeout.

Fixes issue micropython#13377.

Signed-off-by: robert-hh <[email protected]>
@dpgeorge
Copy link
Member

Fixed by 07472d0

@hmaerki
Copy link
Contributor Author

hmaerki commented Jan 19, 2024

Fixed firmware is here: https://github.com/robert-hh/Shared-Stuff, files firmware_PICO_flush.uf2 and firmware_PICO_W_flush.uf2.

Thank you @robert-hh / @dpgeorge - I successfully tested RPI_PICO-20240117-v1.23.0-preview.47.g16c6bc47c.uf2.

dpgeorge pushed a commit that referenced this issue Feb 20, 2024
Do not wait in the worst case up to the timeout.

Fixes issue #13377.

Signed-off-by: robert-hh <[email protected]>
graeme-winter pushed a commit to winter-special-projects/micropython that referenced this issue Sep 21, 2024
Do not wait in the worst case up to the timeout.

Fixes issue micropython#13377.

Signed-off-by: robert-hh <[email protected]>
ThomasHornschuh added a commit to bonfireprocessor/micropython that referenced this issue Feb 15, 2025
* rp2/rp2_flash: Lockout second core only when doing flash erase/write.

Using the multicore lockout feature in the general atomic section makes it
much more difficult to get correct.

Signed-off-by: Damien George <[email protected]>

* rp2/mutex_extra: Implement additional mutex functions.

These allow entering/exiting a mutex and also disabling/restoring
interrupts, in an atomic way.

Signed-off-by: Damien George <[email protected]>

* rp2/mpthreadport: Fix race with IRQ when entering atomic section.

Prior to this commit there is a potential deadlock in
mp_thread_begin_atomic_section(), when obtaining the atomic_mutex, in the
following situation:
- main thread calls mp_thread_begin_atomic_section() (for whatever reason,
  doesn't matter)
- the second core is running so the main thread grabs the mutex via the
  call mp_thread_mutex_lock(&atomic_mutex, 1), and this succeeds
- before the main thread has a chance to run save_and_disable_interrupts()
  a USB IRQ comes in and the main thread jumps off to process this IRQ
- that USB processing triggers a call to the dcd_event_handler() wrapper
  from commit bcbdee2
- that then calls mp_sched_schedule_node()
- that then attempts to obtain the atomic section, calling
  mp_thread_begin_atomic_section()
- that call then blocks trying to obtain atomic_mutex
- core0 is now deadlocked on itself, because the main thread has the mutex
  but the IRQ handler (which preempted the main thread) is blocked waiting
  for the mutex, which will never be free

The solution in this commit is to use mutex enter/exit functions that also
atomically disable/restore interrupts.

Fixes issues micropython#12980 and micropython#13288.

Signed-off-by: Damien George <[email protected]>

* all: Bump version to 1.22.1.

Signed-off-by: Damien George <[email protected]>

* Generic STM32F401CD Port Compiles (not working yet...)

* rp2/rp2_dma: Fix fetching 'write' buffers for writing not reading.

Signed-off-by: Nicko van Someren <[email protected]>

* rp2/machine_uart: Fix event wait in uart.flush() and uart.read().

Do not wait in the worst case up to the timeout.

Fixes issue micropython#13377.

Signed-off-by: robert-hh <[email protected]>

* renesas-ra/ra: Fix SysTick clock source.

The SysTick_Config function must use the system/CPU clock to configure the
ticks.

Signed-off-by: iabdalkader <[email protected]>

* renesas-ra/boards/ARDUINO_PORTENTA_C33: Fix the RTC clock source.

Switch the RTC clock source to Sub-clock (XCIN). This board has an
accurate LSE crystal, and it should be used for the RTC clock
source.

Signed-off-by: iabdalkader <[email protected]>

* extmod/asyncio: Support gather of tasks that finish early.

Adds support to asyncio.gather() for the case that one or more (or all)
sub-tasks finish and/or raise an exception before the gather starts.

Signed-off-by: Damien George <[email protected]>

* mimxrt/modmachine: Fix deepsleep wakeup pin ifdef.

Signed-off-by: Kwabena W. Agyeman <[email protected]>

* extmod/modssl_mbedtls: Fix cipher iteration in SSLContext.get_ciphers.

Prior to this commit it would skip every second cipher returned from
mbedtls.

The corresponding test is also updated and now passes on esp32, rp2, stm32
and unix.

Signed-off-by: Damien George <[email protected]>

* rp2: Change machine.I2S and rp2.DMA to use shared DMA IRQ handlers.

These separate drivers must share the DMA resource with each other.

Fixes issue micropython#13380.

Signed-off-by: Damien George <[email protected]>

* py/compile: Fix potential Py-stack overflow in try-finally with return.

If a return is executed within the try block of a try-finally then the
return value is stored on the top of the Python stack during the execution
of the finally block.  In this case the Python stack is one larger than it
normally would be in the finally block.

Prior to this commit, the compiler was not taking this case into account
and could have a Python stack overflow if the Python stack used by the
finally block was more than that used elsewhere in the function.  In such
a scenario the last argument of the function would be clobbered by the
top-most temporary value used in the deepest Python expression/statement.

This commit fixes that case by making sure enough Python stack is allocated
to the function.

Fixes issue micropython#13562.

Signed-off-by: Damien George <[email protected]>

* renesas-ra/ra/ra_i2c: Fix 1 byte and 2 bytes read issue.

Tested on Portenta C33 with AT24256B (addrsize=16) and SSD1306.

Fixes issue micropython#13280.

Signed-off-by: Takeo Takahashi <[email protected]>

* extmod/btstack: Reset pending_value_handle before calling write-done cb.

The pending_value_handle needs to be freed and reset before calling
mp_bluetooth_gattc_on_read_write_status(), which will call the Python IRQ
handler, which may in turn call back into BTstack to perform an action like
a write.  In that case the pending_value_handle will need to be available
for the write/read/etc to proceed.

Fixes issue micropython#13611.

Signed-off-by: Damien George <[email protected]>

* extmod/btstack: Reset pending_value_handle before calling read-done cb.

Similar to the previous commit but for MP_BLUETOOTH_IRQ_GATTC_READ_DONE:
the pending_value_handle needs to be reset before calling
mp_bluetooth_gattc_on_read_write_status(), which will call the Python IRQ
handler, which may in turn call back into BTstack to perform an action like
a write.  In that case the pending_value_handle will need to be available
for the write/read/etc to proceed.

Fixes issue micropython#13634.

Signed-off-by: Damien George <[email protected]>

* esp32/mpnimbleport: Release the GIL while doing NimBLE port deinit.

In case callbacks must run (eg a disconnect event happens during the
deinit) and the GIL must be obtained to run the callback.

Fixes part of issue micropython#12349.

Signed-off-by: Damien George <[email protected]>

* esp32: Increase NimBLE task stack size and overflow detection headroom.

The Python BLE IRQ handler will most likely run on the NimBLE task, so its
C stack must be large enough to accommodate reasonably complicated Python
code (eg a few call depths).  So increase this stack size.

Also increase the headroom from 1024 to 2048 bytes.  This is needed because
(1) the esp32 architecture uses a fair amount of stack in general; and (2)
by the time execution gets to setting the Python stack top via
`mp_stack_set_top()` in this interlock code, about 600 bytes of stack are
already used, which reduces the amount available for Python.

Fixes issue micropython#12349.

Signed-off-by: Damien George <[email protected]>

* all: Bump version to 1.22.2.

Signed-off-by: Damien George <[email protected]>

* Submodule update

---------

Signed-off-by: Damien George <[email protected]>
Signed-off-by: Nicko van Someren <[email protected]>
Signed-off-by: robert-hh <[email protected]>
Signed-off-by: iabdalkader <[email protected]>
Signed-off-by: Kwabena W. Agyeman <[email protected]>
Signed-off-by: Takeo Takahashi <[email protected]>
Co-authored-by: Damien George <[email protected]>
Co-authored-by: Nicko van Someren <[email protected]>
Co-authored-by: robert-hh <[email protected]>
Co-authored-by: iabdalkader <[email protected]>
Co-authored-by: Kwabena W. Agyeman <[email protected]>
Co-authored-by: Takeo Takahashi <[email protected]>
ThomasHornschuh added a commit to bonfireprocessor/micropython that referenced this issue Feb 16, 2025
* rp2/rp2_flash: Lockout second core only when doing flash erase/write.

Using the multicore lockout feature in the general atomic section makes it
much more difficult to get correct.

Signed-off-by: Damien George <[email protected]>

* rp2/mutex_extra: Implement additional mutex functions.

These allow entering/exiting a mutex and also disabling/restoring
interrupts, in an atomic way.

Signed-off-by: Damien George <[email protected]>

* rp2/mpthreadport: Fix race with IRQ when entering atomic section.

Prior to this commit there is a potential deadlock in
mp_thread_begin_atomic_section(), when obtaining the atomic_mutex, in the
following situation:
- main thread calls mp_thread_begin_atomic_section() (for whatever reason,
  doesn't matter)
- the second core is running so the main thread grabs the mutex via the
  call mp_thread_mutex_lock(&atomic_mutex, 1), and this succeeds
- before the main thread has a chance to run save_and_disable_interrupts()
  a USB IRQ comes in and the main thread jumps off to process this IRQ
- that USB processing triggers a call to the dcd_event_handler() wrapper
  from commit bcbdee2
- that then calls mp_sched_schedule_node()
- that then attempts to obtain the atomic section, calling
  mp_thread_begin_atomic_section()
- that call then blocks trying to obtain atomic_mutex
- core0 is now deadlocked on itself, because the main thread has the mutex
  but the IRQ handler (which preempted the main thread) is blocked waiting
  for the mutex, which will never be free

The solution in this commit is to use mutex enter/exit functions that also
atomically disable/restore interrupts.

Fixes issues micropython#12980 and micropython#13288.

Signed-off-by: Damien George <[email protected]>

* all: Bump version to 1.22.1.

Signed-off-by: Damien George <[email protected]>

* Generic STM32F401CD Port Compiles (not working yet...)

* rp2/rp2_dma: Fix fetching 'write' buffers for writing not reading.

Signed-off-by: Nicko van Someren <[email protected]>

* rp2/machine_uart: Fix event wait in uart.flush() and uart.read().

Do not wait in the worst case up to the timeout.

Fixes issue micropython#13377.

Signed-off-by: robert-hh <[email protected]>

* renesas-ra/ra: Fix SysTick clock source.

The SysTick_Config function must use the system/CPU clock to configure the
ticks.

Signed-off-by: iabdalkader <[email protected]>

* renesas-ra/boards/ARDUINO_PORTENTA_C33: Fix the RTC clock source.

Switch the RTC clock source to Sub-clock (XCIN). This board has an
accurate LSE crystal, and it should be used for the RTC clock
source.

Signed-off-by: iabdalkader <[email protected]>

* extmod/asyncio: Support gather of tasks that finish early.

Adds support to asyncio.gather() for the case that one or more (or all)
sub-tasks finish and/or raise an exception before the gather starts.

Signed-off-by: Damien George <[email protected]>

* mimxrt/modmachine: Fix deepsleep wakeup pin ifdef.

Signed-off-by: Kwabena W. Agyeman <[email protected]>

* extmod/modssl_mbedtls: Fix cipher iteration in SSLContext.get_ciphers.

Prior to this commit it would skip every second cipher returned from
mbedtls.

The corresponding test is also updated and now passes on esp32, rp2, stm32
and unix.

Signed-off-by: Damien George <[email protected]>

* rp2: Change machine.I2S and rp2.DMA to use shared DMA IRQ handlers.

These separate drivers must share the DMA resource with each other.

Fixes issue micropython#13380.

Signed-off-by: Damien George <[email protected]>

* py/compile: Fix potential Py-stack overflow in try-finally with return.

If a return is executed within the try block of a try-finally then the
return value is stored on the top of the Python stack during the execution
of the finally block.  In this case the Python stack is one larger than it
normally would be in the finally block.

Prior to this commit, the compiler was not taking this case into account
and could have a Python stack overflow if the Python stack used by the
finally block was more than that used elsewhere in the function.  In such
a scenario the last argument of the function would be clobbered by the
top-most temporary value used in the deepest Python expression/statement.

This commit fixes that case by making sure enough Python stack is allocated
to the function.

Fixes issue micropython#13562.

Signed-off-by: Damien George <[email protected]>

* renesas-ra/ra/ra_i2c: Fix 1 byte and 2 bytes read issue.

Tested on Portenta C33 with AT24256B (addrsize=16) and SSD1306.

Fixes issue micropython#13280.

Signed-off-by: Takeo Takahashi <[email protected]>

* extmod/btstack: Reset pending_value_handle before calling write-done cb.

The pending_value_handle needs to be freed and reset before calling
mp_bluetooth_gattc_on_read_write_status(), which will call the Python IRQ
handler, which may in turn call back into BTstack to perform an action like
a write.  In that case the pending_value_handle will need to be available
for the write/read/etc to proceed.

Fixes issue micropython#13611.

Signed-off-by: Damien George <[email protected]>

* extmod/btstack: Reset pending_value_handle before calling read-done cb.

Similar to the previous commit but for MP_BLUETOOTH_IRQ_GATTC_READ_DONE:
the pending_value_handle needs to be reset before calling
mp_bluetooth_gattc_on_read_write_status(), which will call the Python IRQ
handler, which may in turn call back into BTstack to perform an action like
a write.  In that case the pending_value_handle will need to be available
for the write/read/etc to proceed.

Fixes issue micropython#13634.

Signed-off-by: Damien George <[email protected]>

* esp32/mpnimbleport: Release the GIL while doing NimBLE port deinit.

In case callbacks must run (eg a disconnect event happens during the
deinit) and the GIL must be obtained to run the callback.

Fixes part of issue micropython#12349.

Signed-off-by: Damien George <[email protected]>

* esp32: Increase NimBLE task stack size and overflow detection headroom.

The Python BLE IRQ handler will most likely run on the NimBLE task, so its
C stack must be large enough to accommodate reasonably complicated Python
code (eg a few call depths).  So increase this stack size.

Also increase the headroom from 1024 to 2048 bytes.  This is needed because
(1) the esp32 architecture uses a fair amount of stack in general; and (2)
by the time execution gets to setting the Python stack top via
`mp_stack_set_top()` in this interlock code, about 600 bytes of stack are
already used, which reduces the amount available for Python.

Fixes issue micropython#12349.

Signed-off-by: Damien George <[email protected]>

* all: Bump version to 1.22.2.

Signed-off-by: Damien George <[email protected]>

* Submodule update

---------

Signed-off-by: Damien George <[email protected]>
Signed-off-by: Nicko van Someren <[email protected]>
Signed-off-by: robert-hh <[email protected]>
Signed-off-by: iabdalkader <[email protected]>
Signed-off-by: Kwabena W. Agyeman <[email protected]>
Signed-off-by: Takeo Takahashi <[email protected]>
Co-authored-by: Damien George <[email protected]>
Co-authored-by: Nicko van Someren <[email protected]>
Co-authored-by: robert-hh <[email protected]>
Co-authored-by: iabdalkader <[email protected]>
Co-authored-by: Kwabena W. Agyeman <[email protected]>
Co-authored-by: Takeo Takahashi <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants