Issue with printing in loops #16378

MrTinkerman · 2024-12-09T15:53:52Z

MrTinkerman
Dec 9, 2024

Thonny on Windows 10
XIAO nRF52840

Today i flashed uP v1.24.1 on XIAO nRF52840 to use new deque functionality.
But I'm having an issue when printing inside loops. The code I used to test and the results are below.

The results look ok, however:

In v1.23.0 each line is printed seperately with 100ms pauses, as I would expect
In v1.24.0/1 and v1.25preview nothing is printed until the loops finish and then all line are printed at once

Does anyone know why this is happening?

Thanks

EDIT
For now I will use v1.23.0:
-- It has the new deque functionality I want to use
-- It prints as expected inside loops

import time

for i in range(5):
    print(f'{time.ticks_ms()}  {i}  for loop')
    time.sleep_ms(100)
    

def print_line(i):
    print(f'{time.ticks_ms()}  {i}  function call from for loop')

for i in range(5):
    print_line(i)
    time.sleep_ms(100)
    
    
i = 0

while i < 5:
    print(f'{time.ticks_ms()}  {i}  while loop')
    i += 1
    time.sleep_ms(100)


'''
RESULTS

v1.23.0

2675303  0  for loop
2675404  1  for loop
2675505  2  for loop
2675605  3  for loop
2675706  4  for loop
2675807  0  function call from for loop
2675909  1  function call from for loop
2676009  2  function call from for loop
2676110  3  function call from for loop
2676211  4  function call from for loop
2676312  0  while loop
2676413  1  while loop
2676514  2  while loop
2676615  3  while loop
2676716  4  while loop

v1.24.0/1 and
v1.25.0-preview

26724  0  for loop
26824  1  for loop
26924  2  for loop
27025  3  for loop
27126  4  for loop
27226  0  function call from for loop
27327  1  function call from for loop
27428  2  function call from for loop
27528  3  function call from for loop
27628  4  function call from for loop
27729  0  while loop
27829  1  while loop
27930  2  while loop
28031  3  while loop
28132  4  while loop
'''

scruss · 2024-12-09T17:06:05Z

scruss
Dec 9, 2024
Sponsor

In v1.24.0/1 and v1.25preview nothing is printed until the loops finish and then all line are printed at once

It looks like something is caching output: the time stamp shows that print is being called every 100 ms.
Can you try the code in a serial terminal or with mpremote to see if Thonny is causing the cache issue?

MicroPython's print() function doesn't have CPython's flush parameter, unfortunately.

3 replies

MrTinkerman Dec 9, 2024
Author

First, I'm totally not a CLI-Guy but I got some results in Putty and mpremote.
Same problem, the results are only printed after the loops finish, the code I ran is the same, loops.py

One thing I noticed, prior to v1.24+ the cdc comport assigned was 17 or 22, but with v1.24+ it's 49
I have know idea if this matters.

scruss Dec 9, 2024
Sponsor

The only nrf board I have is a micro:bit, which is extremely limited. For v1.24.1, it showed every line with a pause in between

MrTinkerman Dec 9, 2024
Author

Edit in opening post:

EDIT
For now I will use v1.23.0:
-- It has the new deque functionality I want to use
-- It prints as expected inside loops

robert-hh · 2024-12-09T19:59:32Z

robert-hh
Dec 9, 2024
Collaborator

I can confirm the behavior with a Seeed NRF52840 and a Arduino Nano 33 connect. It seems to be related to buffering in the USB stack. It does not happen with Micro:Bit, because that board has a serial interface at the nrf chip connected to a on-board serial/usb device, which also handles firmware upload by providing a drive.

0 replies

andrewleech · 2024-12-09T20:52:51Z

andrewleech
Dec 9, 2024
Collaborator Sponsor

Thanks for the report and clear reproduction case @MrTinkerman and thanks for the testing @robert-hh

I think this must be related to the stdio consolidation changes I made recently, though I'm really not sure why.

The stdout buffering setup was changed slightly, particularly relating to buffering the startup messages etc. I'm not sure why this would prevent the regular flushing of the text though and haven't seen / heard of this on other ports.

Maybe there's something slightly different with the configuration of the nrf driver, hopefully a comparison of the TinyUSB config before and after my changes might highlight a difference.

0 replies

MattPeddlesden · 2025-01-22T19:42:03Z

MattPeddlesden
Jan 22, 2025

I've had a similar problem - started with this exact issue, but I then changed the code to toggle the LED on and off on the board in a "while(1)" loop - and saved it as main.py.

Unplugging the USB and re-powering it up via 3v3/gnd pins, the board came to life and the LED started flashing - win!

Unplug that power, and then plug the USB in - the board comes to life and starts flashing. Ok. Fire up Thonny... and... there's no com port for it to connect to at all.

I tried numerous "reset" and reload of MP firmware and it just kept doing the same thing, no com port outside of bootloader mode (and in bootloader mode, I can't load new python code for obvious reasons).

Ultimately, I put CircuitPython's firmware on there - which did wipe the storage and the board was accessible. Re-wiped with Micropython, and it's all back.

So i'm wondering if everything, including com initialisation is being held until the script completes?

For now i'm just going to update my loop to read a GPIO pin and put a button on the board to abort but would be great if that wasnt needed :)

Thanks
Matt.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MicroPython

Issue with printing in loops #16378

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 4 comments 3 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

MicroPython

Issue with printing in loops #16378

Uh oh!

Uh oh!

MrTinkerman Dec 9, 2024

Replies: 4 comments · 3 replies

Uh oh!

scruss Dec 9, 2024 Sponsor

Uh oh!

MrTinkerman Dec 9, 2024 Author

Uh oh!

scruss Dec 9, 2024 Sponsor

Uh oh!

MrTinkerman Dec 9, 2024 Author

Uh oh!

robert-hh Dec 9, 2024 Collaborator

Uh oh!

andrewleech Dec 9, 2024 Collaborator Sponsor

Uh oh!

MattPeddlesden Jan 22, 2025

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

MrTinkerman
Dec 9, 2024

Replies: 4 comments 3 replies

scruss
Dec 9, 2024
Sponsor

MrTinkerman Dec 9, 2024
Author

scruss Dec 9, 2024
Sponsor

MrTinkerman Dec 9, 2024
Author

robert-hh
Dec 9, 2024
Collaborator

andrewleech
Dec 9, 2024
Collaborator Sponsor

MattPeddlesden
Jan 22, 2025