python-editor-v3
python-editor-v3 copied to clipboard
[Serial] Initial serial output after connecting over WebUSB is lost
Bug Description
A clear and concise description of what the bug is.
Needs a repro. Not sure if this is a bug as I haven’t been able to reproduce as yet, but on a zoom call flashing this code via WebUSB produced an error on the device for line 6, but not in the editor.
How To Reproduce
- Connect via WebUSB
- Flash erroneous program to micro:bit
- See error on device but not in editor
- Repeat 2&3
We then fixed the code and flashed the device which works as expected, then introduced a different error (removing the colon : from while True
and this errored as expected.
Expected behavior
Would expect error bar to show as with this example
Environment
Desktop (please complete the following information):
- OS: [e.g. iOS] Windows
- Browser [e.g. chrome, safari] Chrome
- Version [e.g. 22] 97
Additional context
Did not open the serial console to check to see if the error was present in the REPL.
The most useful thing would be to see what the serial output was at that point. The serial area error highlighting works by pattern-matching the output, so if some of the output was missing that could be the cause.
It's a known issue that the first few characters sent from the micro:bit are lost. We should consider whether we can work around this. See https://github.com/ARMmbed/DAPLink/issues/903
@microbit-carlos, @jaustin asks if there's a way to sidestep this issue without impact on a user program.
It's possible this isn't the cause of this issue but it seems like the thing to address first.
@microbit-carlos, @jaustin asks if there's a way to sidestep this issue without impact on a user program.
As it currently stands @jaustin is still more familiar with this issue than I am, so I don't have an answer from the top of my head. If needed I would have to schedule some time aside to investigate, is there any timeline/deadline for this?
I think it's possible to interrupt the micro:bit after connecting in order to generate some serial data for us to check this buffer is cleared.
One use-case we need to consider is the situation where the micro:bit has been used to collect data that needs to be exported over serial. After plugging the board in, we want to press button A to 'read out' our logged data. Things we do for this issue should not break that if possible.
I think it's possible to interrupt the micro:bit after connecting in order to generate some serial data for us to check this buffer is cleared.
We can stop the user code from running by entering the REPL (Ctrl+c
raising a KeyboardInterrupt exception), but I am not aware of a way to pause the programme where it could later be resumed where it left off.
One use-case we need to consider is the situation where the micro:bit has been used to collect data that needs to be exported over serial. After plugging the board in, we want to press button A to 'read out' our logged data. Things we do for this issue should not break that if possible.
Yes, with this in mind a way to avoid breaking this use case would be to, only before WebUSB flashing, we could send Ctrl + C commands to MicroPython until we read the expected data (we could try to match simply the last few bytes of the full string MicroPython prints to serial).
Came up via support: https://support.microbit.org/a/tickets/56484 (private)