[Microbit-Python] Maximum Size of Microbit Python Program?‏

Nevil Hunt nevil.hunt at hotmail.co.uk
Wed Jun 8 06:13:41 EDT 2016


Hi Nick,
 
Thanks for your reply - it sounds like it's an issue you are actively looking into - thanks!
 
Yes, I'm fairly sure in my case it is the size of the script that is the problem, not the run time memory since reducing the number of comments makes it work.
 
Do you have even a rough idea at this stage of how much more space could be freed up and/or a target for the maximum size script that you feel would be adequate?
 
Keep us posted with progress and keep up the good work!
 
 
Regards,
 
Nevil
 
From: ntoll at ntoll.org
To: microbit at python.org
Date: Wed, 8 Jun 2016 09:59:36 +0100
Subject: Re: [Microbit-Python]  Maximum Size of Microbit Python Program?‏

Hi Folks,
 
Essentially, what David W. said about how it works. It won't make a
difference which environment you use to generate the hex, they work in
the same way.
 
Let me be very clear: there are two issues relating to "size".
 
1) The size of the script.
2) The amount of memory used when running the script.
 
I hope we're all agreed that we're talking about 1 in this instance. Put
simply, it's the size of the Python file that's important here. Think of
it as a measure of the number of characters. Less characters is good.
 
There is actually a way to get more space for Python files but that
depends upon the file system work we're currently close to landing /
documenting / tooling.
 
I'll provide more details when things become available.
 
Best wishes,
 
N.
 
 
On 08/06/16 02:05, Mark Schafer wrote:
> I ran into this problem early on where lots of comments making my code
> too large.
> I could not come up with a solution except some sort of mode in mu (or
> similar IDE) that stripped comments before sending. If you read the
> results back though - you have lost info.  So needs to be tightly
> coupled with IDE :(
> 
> Its an interesting problem because teaching people implies more comments
> but this limits the runnable size to smaller programs. I had to remove
> all of my embedded explanations.
> 
> 
> On 6/8/2016 7:32 AM, Nevil Hunt wrote:
>> Thanks David,
>>  
>> I now see how it is done, so, yes, the comments will use up precious
>> memory space.
>>  
>> FYI I've just tried downloading the latest stand-alone mu editor to
>> see if that allows me to write bigger programs but it doesn't. When a
>> program gets over the same size and I hit "download" nothing happens
>> (i.e. the yellow led doesn't start to flash) but if I delete a few
>> lines of comments, the download  then works.
>>  
>> It sounds like you have already lodged the issue that exceeding the
>> program size limit whether from the web interface or from the mu
>> editor is silent - thanks.
>> It then leaves the other issue as to whether anything can be done to
>> increase the size of program that can be run. My program is really of
>> very modest size.
>>  
>> Anyone else got any thoughts on the matter?
>>  
>>  
>> Nevil
>>  
>> ------------------------------------------------------------------------
>> From: david at thinkingbinaries.com
>> Date: Tue, 7 Jun 2016 19:19:39 +0100
>> To: microbit at python.org
>> Subject: Re: [Microbit-Python] Maximum Size of Microbit Python Program?‏
>>
>> Hi Neville,
>>
>> I'm pretty sure the comments are included - the way it has always
>> worked is that the web interface just appends a small binary header
>> and then your python script to the embedded hex file it has cached in
>> the browser. That way, no processing of the script is required. i.e.
>> hex = [MICROPYTHONHEX + hex(BINARYHEADER) +
>> hex(SCRIPT_INCLUDING_COMMENTS)]
>>
>> Here is a Python version of the code that does that process:
>> https://github.com/bbcmicrobit/micropython/blob/master/tools/makecombinedhex.py
>>
>>
>> I believe that all that Nicholas does in the web interface is the
>> same, but in javascript, as it is easy.
>>
>> That way, of course, just like all of the other editors, it is
>> possible to completely recreate the source from a .hex file (as kids
>> have a habit of not saving the source programs, or not keeping good
>> records as to which source program generated which hex program).
>>
>> So yes, comments take up space.
>>
>> There is a pending question on the area51 proposed stackexchange site
>> at the moment, where I ask how users can know in advance of flashing
>> their micro:bit, whether the program will fit or not. There seems to
>> be no obvious way in any of the editors of getting a read-out of how
>> much of the available memory is used *before* you flash it and find it
>> doesn't fit.
>>
>>
>> The other thing to find out is whether you are running out of flash
>> memory, or running out of runtime memory. I would imagine that
>> Damien's micropython parser ignores comments as it iterates through
>> the flash version of the script file to parse it into bytecode in RAM
>> - but you should check with Damien for clarification of how to work
>> out if this is 'running out of flash' or 'running out of memory while
>> parsing', as I can't find the code for that at the moment
>>
>> Damien?
>>
>>
>>
>> _______________________________________________ Microbit mailing list
>> Microbit at python.org https://mail.python.org/mailman/listinfo/microbit
>>
>>
>> _______________________________________________
>> Microbit mailing list
>> Microbit at python.org
>> https://mail.python.org/mailman/listinfo/microbit
>>
>>
>> No virus found in this message.
>> Checked by AVG - www.avg.com <http://www.avg.com>
>> Version: 2016.0.7639 / Virus Database: 4598/12379 - Release Date: 06/07/16
>>
> 
> 
> 
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
> 
 
 
 

_______________________________________________
Microbit mailing list
Microbit at python.org
https://mail.python.org/mailman/listinfo/microbit 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/microbit/attachments/20160608/2cbaf202/attachment.html>


More information about the Microbit mailing list