Communication Scratch-Microbit stops after a while with intensive communication

[mobluse]

In the attached project the communication Scratch-Microbit stops after a few minutes with much sound, e.g. buttons A and B does not work, and the LEDs does not update. The Scratch-project continues to run and updates the screen. There is no error message in the Command Prompt. You should not uncompress the zip-file, just rename it so that .zip is removed, since sb2-files are actually zip-files, but GitHub does not recognize this w/o the zip extension. s2m-loudness.sb2.zip

The communication hangs faster if video in Scratch is switched on.

I think communication last longer if I e.g. change "wait 0 secs" in the forever-loop to e.g. "wait 0.2 secs".

A suggestion is, if possible, to output a message in s2m console that the communication with the micro:bit is broken.

It works again if I stop with Ctrl+C and then restart s2m.

I use a trial version of Windows that came out after Windows FCU. It's the latest in Slow Ring. Microsoft Windows [Version 10.0.17025.1000]

I use latest Scratch and latest Adobe Air: Scratch 2 Offline Editor v458.0.1

I use the latest serial driver that works with Mu for Windows REPL: https://codewith.mu/ i.e. https://os.mbed.com/media/downloads/drivers/mbedWinSerial_16466.exe

This is all output from s2m in Command Prompt:

s2m version 1.09  Copyright(C) 2017 Alan Yorinks  All rights reserved.

Python Version 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:32:19) [MSC v.1500 32 bit (Intel)]
Autodetecting serial port. Please wait...
Using COM Port:com3

s2mb Version: s2mb.py Version 1.04 23 November 2017

Auto launching Scratch
Starting HTTP Server!
Use <Ctrl-C> to exit the extension.
Please make sure you save your Scratch project BEFORE pressing Ctrl-C.

[MrYsLab]

@mobluse Thank you for the information. I changed the wait time at the bottom of the forever loop to be 0.4 seconds and ran the project for about an hour and it was still responsive. Anything shorter than 0.3 and I experienced the crash. I am exploring ways to be able to shorten that delay significantly, but it will take a little time for me to do so. As soon as I have something that is working properly I will post here.

[MrYsLab]

@mobluse I have tried several different coding schemes to allow a shorter delay loop and what I found to be the best solution so far is to change the delay in micro: bit script, s2mb.py. I changed line 20 from sleep(50) to sleep(2) and by doing so, was able to shorten the delay loop in the Scratch project down to 0.002.

The flashing of the LEDs is still somewhat erratic because there are several asynchronous clocks running at the same time. There is the forever loop on the micro: bit, a forever loop in the Scratch project, and an additional loop for Scratch to retrieve reporting data. That Scratch reporter data poll clock fires about 30 times per seconds at which time Scratch expects to get all of the reporting data in a single shot.

The crash occurs when the micro: bit gets overwhelmed and there is no easy way to detect when this occurs. Adding a keep-alive type signal kills the performance because of the additional serial traffic overhead.

Please try shortening the sleep in s2mb.py and let me know if that helps at all.

[mobluse]

I've tested it and it doesn't hang communication with sleep(2). BTW it's on line 40. There is about a 20 second delay between sound and display on Microbit when wait 0.002 secs in Scratch 2. If I change to wait 0.4 secs it works without delay.

Maybe you could improve the protocol between s2m and s2mb.py so that it is compressed and as brief as possible, e.g. it might be faster with binary numbers than numbers as strings.

I programmed it using Mu and when I used the Check-button there were a few warnings about s2mb.py: Two many blank lines & Blank line at end of file.

[MrYsLab]

@mobluse The major communication delay is actually not sending strings vs binary data, but the amount of time it takes to execute retrieval of the accelerometer information. The accelerometer is an i2c device and these are notoriously slow.

That being said, I am looking to rearchitect several things for efficiency. I may try using binary data representation but it does make things much harder to debug.

This is all going to take several days, and I will post when I have something available.

[MrYsLab]

@mobluse I did some timing tests for the round trip of requesting and receiving polling data from the micro:bit. As I suspected, reducing the number of bytes from 52 for the current text scheme to 12 bytes, which would be the equivalent if I converted to binary data, did not have any major effect on the round trip time, confirming, most of the time is taken by the internal calls to the micro:bit to retrieve the sensor data.

I was able to rearchitect the two s2m files. This reduced the overall CPU utilization on my machine from ~60% to 40% while running your Scratch project. Also, it reduced the delays for button presses and detecting gesture changes.

I will be doing some additional testing and then will change the Write Pixel block to allow you to use variables. When I publish I will send you a message to let you know it is available.

I am closing this issue, but if you have any other questions about this issue, you can post here and I will be notified.

By the way, about the mu editor complaining about the number of lines, if you simply remove some comments or blank lines, that should free up the space to enter more code. The editor is rather "dumb" in that it literally is complaining about the number of lines of code and not the size of the resultant hex file.

Thanks.

[MrYsLab]

@mobluse I have released version 1.10. I had to change the sleep in s2mb.py to 8 since a value of 2 was causing the system to miss Scratch commands.