- Mon Jan 02, 2017 12:13 pm
#60278
I've noticed that once the 1st SAVE starts causing a reboot with script corruption, a 2nd SAVE straight after reboot reconnection may work ok. But after a while of getting by doing that, the basic interpreter will also eventually start being corrupted, which needs a reformat and reflash to sort out, but will start re-occuring again unless steps are taken with the script to 'lighten the load'.
The first and easiest thing to consider where possible, is to reformat and reflash 4Mb devices to 1Mb build which uses less resources, otherwise you will need to find other ways to lighten the load. A tedious way is to temporarily comment out lines or even whole sections of script individually (something which might be much quicker and simpler if a 'block comment' feature was available). Bearing in mind that script comments get saved and reloaded from the device (unlike with a compiler), therefore they must be taking up space somewhere, so it is probably best to prune out as much of the 'dead wood' comments as possible.
Another way of 'cutting some slack' is to temporarily bypass non-essential code by enabling/disabling it using IF ... ENDIF. I inevitably have various option flags at the top of my scripts to selectively turn on features which might otherwise not all work together without causing problems (such as a memory guage plus debugmsg window). Hopefully when such 'dev' features are no longer required they will eventually free up sufficient space for the script to run ok. How much is enough may actually depend on if wifi is actually required or not, because it seems that wifi reliability is the first caualty, and the basic interpreter might keep coping with events long after wifi connection has been lost.
The first and easiest thing to consider where possible, is to reformat and reflash 4Mb devices to 1Mb build which uses less resources, otherwise you will need to find other ways to lighten the load. A tedious way is to temporarily comment out lines or even whole sections of script individually (something which might be much quicker and simpler if a 'block comment' feature was available). Bearing in mind that script comments get saved and reloaded from the device (unlike with a compiler), therefore they must be taking up space somewhere, so it is probably best to prune out as much of the 'dead wood' comments as possible.
Another way of 'cutting some slack' is to temporarily bypass non-essential code by enabling/disabling it using IF ... ENDIF. I inevitably have various option flags at the top of my scripts to selectively turn on features which might otherwise not all work together without causing problems (such as a memory guage plus debugmsg window). Hopefully when such 'dev' features are no longer required they will eventually free up sufficient space for the script to run ok. How much is enough may actually depend on if wifi is actually required or not, because it seems that wifi reliability is the first caualty, and the basic interpreter might keep coping with events long after wifi connection has been lost.
