unexpected try-except drop through

[krismc]

Reading an rpi pico uart with
start=ticks_ms()
while ticks_ms()-start<100:
if uart.any(): return uart.read().decode()
print('timeout', ticks_ms()-start); return uart.read().decode()

it works OK, but if I put the last line inside a try except

start='ticks_ms()
while ticks_ms()-start<100:
if uart.any(): return uart.read().decode()
try:
print('timeout', ticks_ms()-start); return uart.read().decode()
except Exception as e: sys.print_exception(e)

it occasionally drops through into the timeout print without the while timeout loop having expired, typically after 0 to 2ms. I'm struggling to explain this. Any ideas?

[ricksorensen]

Could it be the wraparound on time.ticks_ms()? There us a time function to help avoid this:

start=ticks_ms()
while time.ticks_diff(ticks_ms(),start<100):
     dostuff()

https://docs.micropython.org/en/latest/library/time.html#time.ticks_diff

[GitHubsSilverBullet]

furthermore, there's a ticks_add() function, allowing to add or subtract an initial value.
target = ticks_add(ticks_ms(), 100)

Not to mention the inherent flaw:

from machine import UART
from time import ticks_ms, ticks_diff, ticks_add
from sys import print_exception

def anything():
    timeout_at = ticks_add(ticks_ms(), 500)
    while ticks_diff((now:=ticks_ms()), timeout_at) < 0:
        if uart.any():
            return uart.read().decode() # there's something to decode
    try:
        print('timeout', now)
        return uart.read().decode()     # reading without checking, there might NOT be anything to decode,
    except Exception as e:              # thus throwing an…
        print_exception(e)              # …AttributeError

uart = UART(0)
print(anything())

[peterhinch]

Why not use the UART's built-in timeout?

from machine import UART
from time import ticks_ms, ticks_diff

def anything():
    start = ticks_ms()
    res = uart.read()
    if res is None:  # Timed out waiting for 1st or subsequent chars
        print(f"Timeout at {ticks_diff(ticks_ms(), start)}ms")
    else:
        return res.decode()

uart = UART(0, timeout=500, timeout_char=500)
print(anything())

[krismc]

Tnx for the ideas all. Went down a bit of a rabbit hole looking for the cause of the occasional unexpected timeout. To me it looks like a dodgy integer is somehow inserted in the flow of integers from ticks_ms(). The 'post' event values for now, was & d look exactly like what I would expect to see if the event never occurred.

cycle=1; gotcha=now0=was0=d0=0; was=ticks_ms()
while 1:
    now=ticks_ms(); d=now-was
    cycle+=1
    if d>100:
      if gotcha==0:  print( 'TIMEOUT  prev', now0, was0, d0, now, was, d, end=' '); gotcha=cycle
    if gotcha==cycle-1: print('  post', now, was, d); break
    now0=now; was0=was; d0=d
    if uart.any():  return uart.read()

TIMEOUT  prev 37616179 37616177 2  37801355 37616177 185178   post 37616181 37616177 4      

[GitHubsSilverBullet]

now=ticks_ms(); d=now-was

Still subtracting values from a ring-counter?

[robert-hh]

In your test code I'm missing a statement like was=now.

[peterhinch]

To add to @GitHubsSilverBullet 's observation, please read the doc for ticks_diff().

[Josverl]

Based on this I have changed the typestubs in order to flag subtracting values from a ring-counter in static type checking,
Type checkers will show a type error on mathematical operations on any of the ring counters.

That will be included in the v1.28.0 stubs that are close to release. (some more testing to be done)