Funtion is to large to send to board

[Wenjie Wu]

User reports from Silicon Valley-Mars Environmental Exploration Challenge.

Here is the user’s code:

https://scratch3-files.just4fun.site/Sample V2-代码量过大.ubp

[Turgut Guneysu]

Hi Wenjie,

I had a hard time trying to figure out what the blocks were doing due to Chinese names.

However, here is a bit of info for you to control the problem:

Due to memory restrictions in the micro controllers, MicroBlocks function routines are limited to 1000 byte size. One can monitor the generated code size by enabling “advanced blocks” in Settings, and then right-clicking the function header block and select “show compiled bytes”:

This will display the generated size of the function definition:

As you can see in the display, the offending block is 1044 bytes - too large.

To make functions smaller, various repetitive sections can be encapsulated and called with parameters, rather than explicitly.

I have followed some of the code and noticed the following: In the function

“Get a Trackbit state value” block is a command function, and sets a state variable, which in turn gets evaluated by the “Trackbit is” function. “The Trackbit is” function in turn is trying to evaluate graphical state into a binary state by repetitively evaluating the black and white dots. All this could be optimized by making the original Get a Trackbit state value block a REPORTER that operates on binary TRUE/FALSE states and returns the analysis result. Instead of IFs, one could use a state table that translates to speeds, and then do a look-up. This will simplify the blocks, the evaluations, and reduce the size of the code written significantly. These kind of optimizations become crucial as one starts working on advanced projects with complicated logic.

Another observation is:

This custom block does nothing but set motor speeds using another library block, but the changing parameter is the wait delay value! There is no need to create this kind of custom blocks. One can use the original library blocks for motor control followed by the wait block and achieve a more optimized size. Here is the difference between the two techniques:

Custom Function call version:

‌

Straight Calls:

‌

As you can see, there is a 40 byte penalty for making a no-need custom block.

There are probably many more optimizations that we could suggest, but not knowing what is really happening, I do not want to confuse the issue.

I have also noticed in the submitted coding samples that there is a tendency and preference to list IF blocks in sequence even though they evaluate the same condition. While this has nothing to do with the size problem, it will prolong the execution of routines and evaluate untrue conditions unnecessarily.

When the same variable is checked for various different values, it will be more efficient to combine the IF conditions with ELSE, so that once a matching condition is found, the rest will be skipped. This technique will have a definite impact on how fast the routines execute; since MicroBlocks will not exit a function block until it is executed to completion.

I hope these suggestions will help your team to bring things under control.

[Wenjie Wu]

Due to memory restrictions in the micro controllers, MicroBlocks function routines are limited to 1000 byte size. One can monitor the generated code size by enabling “advanced blocks” in Settings, and then right-clicking the function header block and select “show compiled bytes”:

Thank you for the detailed debugging and explaining the cause of the problem !

These suggestions for optimization are useful.

Since the program is written by the participating students themselves, we want to give more freedom to the user and optimization is not necessary.

Since the challenge is focused on whether the user accomplishes the goal (like test-driven), we want to be lenient about whether the program is optimized or not, and we don't really want the user to be unable to run the program because of optimization issues when the logic of code is correct.

I will also sync your answer to the challenge operators to see if more training needs to be given to the participating students. It may be a matter of balance between what the participating students should know and what he is free to do.

‌

[John Maloney]

How often are you getting reports about functions being too large to send to the board?

It's generally easier to work with shorter functions and it makes the code more readable, but I understand that you don't want to force students to refactor their code. Unfortunately, the function size limit stems directly from the limited amount of RAM on the micro:bit v1: the entire function needs to be stored in a RAM buffer before before it gets written into Flash memory.

However, we could increase the buffer size somewhat (say, by 50%) by decreasing the amount of MicroBlocks object memory (used for lists and string manipulation). Of course, that would lower the number and size of lists and strings you can use. It's a tradeoff...

Short term, however, we'll need to live with the current limit. Users who hit that limit will need to split large functions into smaller ones.

[Wenjie Wu]

How often are you getting reports about functions being too large to send to the board?

I'm not directly involved in the challenge, so I don't know enough about it, but I've heard Elite staff mention that there seems to be often, and that newcomers always seem to like to write long functions, just like beginners like to use global variables.

Short term, however, we'll need to live with the current limit. Users who hit that limit will need to split large functions into smaller ones.

I agree with this, no need to tweak the buffer for now. The error hints in the IDE are clear enough to not cause confusion, and the problem will fade away as the hardware is upgraded..

So I think just add this tip to the training . I will sync these suggestions to Elite staff.

‌

[John Maloney]

This has has been addressed in two ways. First, the 16-bit instruction set allows more code to fit into the 1k RAM code buffer. Second, MicroBlocks 2.0 gives you an error message when you try to run a script that is too large to download.

A silver lining of the script size limitation is that it encourages users to factor their code into smaller scripts, which usually make the code easier to understand and change.