Issue with printing in loops

[MrTinkerman]

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]

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.

[MrTinkerman]

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]

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]

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]

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.

[andrewleech]

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.

[MattPeddlesden]

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.