unexpected try-except drop through #19077
Replies: 9 comments 8 replies
-
|
Could it be the wraparound on https://docs.micropython.org/en/latest/library/time.html#time.ticks_diff |
Beta Was this translation helpful? Give feedback.
-
|
furthermore, there's a ticks_add() function, allowing to add or subtract an initial value. 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()) |
Beta Was this translation helpful? Give feedback.
-
|
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()) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Still subtracting values from a ring-counter? |
Beta Was this translation helpful? Give feedback.
-
|
In your test code I'm missing a statement like was=now. |
Beta Was this translation helpful? Give feedback.
-
|
To add to @GitHubsSilverBullet 's observation, please read the doc for ticks_diff(). |
Beta Was this translation helpful? Give feedback.
-
|
Based on this I have changed the typestubs in order to flag subtracting values from a ring-counter in static type checking, 
That will be included in the v1.28.0 stubs that are close to release. (some more testing to be done) |
Beta Was this translation helpful? Give feedback.
-
|
Given ticks_ms() overflows at 0x3FFFFFFF on the rpi pico & the timeout is much much less than why the problem with doing now-was style arithmetic? |
Beta Was this translation helpful? Give feedback.
-
|
You are assuming it restarts at zero, it may, or may not. It is opaque/ magic. |
Beta Was this translation helpful? Give feedback.
-
Imagine you read |
Beta Was this translation helpful? Give feedback.
-
|
Happy to use ticks_diff, I'm just curious about what's going on. I've seen overflow 50 years ago with 4000 series cmos counters, the counter would roll through the max count & all bits would flip back to zero. It was predictable, you could even crib an extra bit by checking if the new count was less than the previous in an n stage counter & adding n to the result if it was. This doesn't behave like that, instead there are these big, unpredictable jumps in ticks_ms() followed by the the count resuming from where it was before the jump. Just doesn't feel like counter wrap around to me, more like a gremlin injects a bogus result into an otherwise orderly progression of milliseconds. |
Beta Was this translation helpful? Give feedback.
-
|
Here, try this: # vim: fileencoding=utf-8: ts=4: sw=4: expandtab:
from time import ticks_diff,ticks_add
WRAP = const(0x3fffffff)
i = WRAP - 8
j = i + 2
n = 16
while True:
good_delta = ticks_diff(j, i)
bad_delta = j - i
print(f'{i:12} {i:08x} {good_delta} {bad_delta}')
n -= 1
if n == 0:
break
i = i + 1 if i < WRAP else 0
j = j + 1 if j < WRAP else 0
That's something I've never experienced and I'm using the ticks-stuff a lot. A LOT. |
Beta Was this translation helpful? Give feedback.
-
|
I am pretty confident that ticks_ms() timer itself is monotonic without "big jumps", except for the overflow from 0x3fff_ffff to 0. If you see that in your code & in the way you test it is most likely something else you observe. |
Beta Was this translation helpful? Give feedback.
-
|
Well I guess that's the whole point of using ticks_diff, so you don't see it Nor. I think you're probably right Rob, I polled ticks_ms() in a tight loop at millisec rates & never found a jump, so something to do with the uart I guess. I'm just gonna swallow the blue pill & use ticks_dif from now on. |
Beta Was this translation helpful? Give feedback.
-
|
About your initial question for this part of your first test code: uart.read() returns None if no data is available. And for None there is no decode() method, which raises an exception. |
Beta Was this translation helpful? Give feedback.
-
That's how a binary counter with a finite number of bits works, whether implemented in hardware or software. The basic concept is modular arithmetic and affects any mapping of the infinite set of integers onto some finite set that aims to represent them. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
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?
Beta Was this translation helpful? Give feedback.
All reactions