[Microbit-Python] memory error

Alan alainjackson at hotmail.com
Sat Oct 3 22:28:35 CEST 2015 

Hi Damien,

10KB, that sounds really good, you can do quite a lot of damage in 10KB. 

And microbit.assembler(...).  Wow that is just insanely exciting! That's like some crazy Easter egg in itself. That's the kind of function you want minimal documentation for :)

Cheers,

Alan





> Date: Sat, 3 Oct 2015 17:20:07 +0100
> From: damien.p.george at gmail.com
> To: microbit at python.org
> Subject: Re: [Microbit-Python] memory error
> 
> Yes, I think that at the moment 3kb is too limiting for maximum script
> size.  I honestly didn't think people would be writing such complex
> programs, but agree that it would be very annoying if your efforts
> coding all day lead only to out of memory errors.
> 
> If we can cater for the more advanced coders and provide more memory
> for scripts, then we should.  And I have some ideas (inspired by
> David) of how to do it and might be able to get close to 10kb for
> maximum script.  I'll keep you posted!
> 
> Regarding assembler: actually MicroPython does include an inline
> assembler!  But it's not enabled for the microbit.  I was thinking of
> enabling it but it does take a bit of room (around 6500 bytes of
> flash).  One cute option is to simply create a function that turns a
> byte string into a callable assembler function.  Eg:
> 
> fun = microbit.assembler(num_args=3, code=b'\x12\x34\x56')
> fun(1, 2, 3)
> 
> Then you can write your assembly function in hex (!!) and do arbitrary
> things with the device.
> 
> Regarding David's point about resource contraints leading to learning.
> I totally agree!  Even if in the case of MicroPython you're not
> learning about stacks and pointers, you are learning that making a
> list takes memory, and higher level things like that.  Even writing
> Python on your PC you sometimes need to think about how resource
> intensive it is and how to make it more efficient (eg use a better
> algorithm).
> 
> 
> On Sat, Oct 3, 2015 at 7:41 AM, David Whale <david at thinkingbinaries.com> wrote:
> > :)
> >
> > My point was less about machine code, and more about "if resources are
> > limited, additional learning takes place". I  learnt a lot about how the
> > computer worked, by finding other ways to make my programs fit.
> >
> > I'm not suggesting every 11 year old would be interested in breaking beyond
> > the memory restrictions, some will, some won't. I think as long as we have a
> > view on "what a reasonable sized program is for most users", it will still
> > be a great experience.
> >
> > My follow on point was to not break our backs getting the last byte out of
> > the memory, but something that maps out the memory usage would encourage
> > those persistent souls who want to. That would be far less work than
> > squeezing the last few bytes out of the language design, and possibly a self
> > contained task that someone else could do to one side.
> >
> > Cheers
> >
> > David
> >
> >
> >
> >
> > ___________________________________________________________
> > David Whale, B.Sc (Hons), MIET
> > Software Engineer and IET Schools Liaison Officer, Essex
> >
> > email:  dwhale at theiet.org
> > twitter: @whaleygeek
> > blog:  blog.whaleygeek.co.uk
> >
> > Co-author of the new book "Adventures in Minecraft" - lets get kids coding!
> >
> >
> > On 3 October 2015 at 00:02, Alan <alainjackson at hotmail.com> wrote:
> >>
> >> Hi David,
> >>
> >> I find your argument about resource constraints compelling.
> >>
> >> I never did learn to program my 1K ZX81 in assembler. I blew it up before
> >> then.
> >>
> >> Remember how AWFUL the keyboard was? I soldered a joystick from an old
> >> space invaders game into the keyboard matrix so I could play games better...
> >> but when trying to add more buttons later I dropped the soldering iron on
> >> the CPU. Game over.
> >>
> >> I didn't see assembler until I was at uni... and the moment had passed.
> >> But ever since then I've been in awe of people who can do assembler.
> >>
> >> I would find your argument even more compelling if we were thinking of
> >> python as a gateway drug to assembler. If we had an assembler tool-chain
> >> shipping along with micropython.
> >>
> >> I think we, as a bunch of python people, seeing the device through a
> >> pythonic lens, for us there maybe an objectively optimal memory range, which
> >> I personally think is greater than 3KB.... for python.
> >>
> >> But if we're part of encouraging a descent into assembler, then I could be
> >> convinced that less is more.
> >>
> >> Cheers,
> >>
> >> Alan
> >>
> >>
> >> ________________________________
> >> Date: Fri, 2 Oct 2015 23:09:59 +0100
> >> From: david at thinkingbinaries.com
> >>
> >> To: microbit at python.org
> >> Subject: Re: [Microbit-Python] memory error
> >>
> >> I think it would be useful to have a rough metric or target of the sort of
> >> script/size that would be reasonably expected on a platform of this size. It
> >> might be that on the whole, all the things that people are writing will
> >> basically fit, if some basic good practice in naming and layout is followed.
> >>
> >> I also think back to the earlier discussion about limited memory on the
> >> ZX81, and the fact that I spent most of my working life up until now
> >> squeezing lots of functionality into tiny processors with limited resources,
> >> and the skills I learnt on my 1K ZX81 were vital to enabling that
> >> innovation. The door push on the front of my house has my code in it, it's a
> >> commercial product you can buy off the shelf, and it wouldn't have if I
> >> didn't cut my teeth on a resource limited platform which forced me to
> >> understand how the computer actually worked. I was 11 when I had my ZX81 and
> >> I was writing Z80 assembler as a way to make things fit. On the whole it was
> >> a really exciting experience for an 11 year old!
> >>
> >>
> >> One of the things to remember is that modern computers (even the Raspberry
> >> Pi) mostly allow you to assume infinite resources (or pretty unbounded). The
> >> micro:bit is very much an embedded platform, and having a limit on resources
> >> causes people to understand that nothing is infinite in this world, and
> >> that's a good thing sometimes!
> >>
> >> So, let's not beat ourselves up about it. As long as a good representative
> >> set of engaging and exciting programs can be made to fit, there has to be
> >> some limit. And besides - save some work for version 2!!!
> >>
> >> As an aside, if someone were to develop a toolkit that helped to explain
> >> where the memory usage in a given MicroPython program goes to, it would
> >> enable users to optimise their programs better themselves and gain a better
> >> understanding of how things work. I'm sure Damien is the same, when working
> >> on an embedded platform I spend my life in the map file and often in the
> >> assembly listings too, to understand where all the precious memory is going
> >> to!
> >>
> >> David
> >>
> >>
> >> ___________________________________________________________
> >> David Whale, B.Sc (Hons), MIET
> >> Software Engineer and IET Schools Liaison Officer, Essex
> >>
> >> email:  dwhale at theiet.org
> >> twitter: @whaleygeek
> >> blog:  blog.whaleygeek.co.uk
> >>
> >> Co-author of the new book "Adventures in Minecraft" - lets get kids
> >> coding!
> >>
> >>
> >> On 2 October 2015 at 22:46, Damien George <damien.p.george at gmail.com>
> >> wrote:
> >>
> >> Yes, variable name length will have a small impact on RAM usage.
> >>
> >> Yes, as David says, a given variable is only stored once in RAM and
> >> then referenced by an index (which is usually 16 bits) so it's
> >> relatively efficient.  You need to keep the actual name of the
> >> variable around so that you can given sensible error messages, and
> >> also for lookup of global names in dictionaries.
> >>
> >> There are definitely things that we can do to improve the memory usage
> >> and allow bigger scripts.  Do you think it's a priority?
> >>
> >> On Fri, Oct 2, 2015 at 6:17 PM, David Whale <david at thinkingbinaries.com>
> >> wrote:
> >> > I only had a 1K ZX81 and it forced me to learn machine code so I could
> >> > make
> >> > everything fit :)
> >> >
> >> > I'm *guessing* that MicroPython has a fixup table, so that the variable
> >> > names and function names are only stored in RAM once - i.e. each
> >> > reference
> >> > to a function name or variable name in the bytecode is actually an index
> >> > into a string table with the actual name in it? Perhaps a one-way hash
> >> > could
> >> > be used to turn any given name into a shorter hash that is actually used
> >> > for
> >> > the lookup?
> >> >
> >> > Cheers
> >> >
> >> > D
> >> >
> >> >
> >> > ___________________________________________________________
> >> > David Whale, B.Sc (Hons), MIET
> >> > Software Engineer and IET Schools Liaison Officer, Essex
> >> >
> >> > email:  dwhale at theiet.org
> >> > twitter: @whaleygeek
> >> > blog:  blog.whaleygeek.co.uk
> >> >
> >> > Co-author of the new book "Adventures in Minecraft" - lets get kids
> >> > coding!
> >> >
> >> >
> >> > On 2 October 2015 at 18:06, Alan <alainjackson at hotmail.com> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> Am I right in thinking the size of variable names also makes a
> >> >> difference?
> >> >> It seemed to, although I didn't test that scientifically.
> >> >>
> >> >> 3KB is a bit small. I know, however big the memory we'd always want
> >> >> more.
> >> >> And I did grow up programming a ZX81, so this is 3 times as big! You'd
> >> >> think
> >> >> I'd be happy with that.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Alan
> >> >>
> >> >> > Date: Fri, 2 Oct 2015 16:07:02 +0100
> >> >>
> >> >> > From: damien.p.george at gmail.com
> >> >> > To: microbit at python.org
> >> >> > Subject: Re: [Microbit-Python] memory error
> >> >> >
> >> >> > Hi Alan,
> >> >> >
> >> >> > Yes, doc strings do take up memory, so in our case (when trying to
> >> >> > reduce memory usage) it's better to make them comments (which are
> >> >> > just
> >> >> > skipped over by the tokeniser).
> >> >> >
> >> >> > The example you give with lots of prints does indeed take up all the
> >> >> > memory, so that's why it gives a MemoryError. It's not easy to fix
> >> >> > this, the microbit is just really low on RAM! We could compile the
> >> >> > python script to flash (instead of RAM) but that needs a bit of
> >> >> > effort
> >> >> > to get working.
> >> >> >
> >> >> > Cheers,
> >> >> > Damien.
> >> >> >
> >> >> >
> >> >> > On Thu, Oct 1, 2015 at 2:52 AM, Alan <alainjackson at hotmail.com>
> >> >> > wrote:
> >> >> > > Hi,
> >> >> > >
> >> >> > > Another little trick I've realised is that if I put a large,
> >> >> > > explanatory
> >> >> > > comment at the top of the file using """...""" it of course goes
> >> >> > > into
> >> >> > > a
> >> >> > > docstring... which takes up memory!
> >> >> > >
> >> >> > > If I use # style comments instead, it doesn't seem to take up
> >> >> > > memory.
> >> >> > >
> >> >> > > Cheers,
> >> >> > >
> >> >> > > Alan
> >> >> > >
> >> >> > > ________________________________
> >> >> > > From: alainjackson at hotmail.com
> >> >> > > To: microbit at python.org
> >> >> > > Date: Thu, 1 Oct 2015 00:32:14 +0000
> >> >> > >
> >> >> > > Subject: Re: [Microbit-Python] memory error
> >> >> > >
> >> >> > > Hi,
> >> >> > >
> >> >> > > I didn't save the version of my code that got the memory error.
> >> >> > >
> >> >> > > But I've just now created a small, pathological example.
> >> >> > >
> >> >> > > The code below, which is 3kB on the disk, will create the following
> >> >> > > error:
> >> >> > >
> >> >> > >>>> MemoryError:
> >> >> > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with
> >> >> > > nRF51822
> >> >> > > Type "help()" for more information.
> >> >> > >
> >> >> > > But if you delete the last line, it will run fine.
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > """
> >> >> > > Testing how much memory for python code the microbit has.
> >> >> > > """
> >> >> > >
> >> >> > > from microbit import *
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890")
> >> >> > >
> >> >> > >
> >> >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789")
> >> >> > >
> >> >> > >
> >> >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678")
> >> >> > >
> >> >> > >
> >> >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567")
> >> >> > >
> >> >> > >
> >> >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456")
> >> >> > >
> >> >> > >
> >> >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456")
> >> >> > >
> >> >> > >
> >> >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345")
> >> >> > >
> >> >> > >
> >> >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234")
> >> >> > >
> >> >> > >
> >> >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923")
> >> >> > >
> >> >> > >
> >> >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092")
> >> >> > >
> >> >> > >
> >> >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890")
> >> >> > >
> >> >> > >
> >> >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789")
> >> >> > >
> >> >> > >
> >> >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678")
> >> >> > >
> >> >> > >
> >> >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567")
> >> >> > >
> >> >> > >
> >> >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456")
> >> >> > >
> >> >> > >
> >> >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456")
> >> >> > >
> >> >> > >
> >> >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345")
> >> >> > >
> >> >> > >
> >> >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234")
> >> >> > >
> >> >> > >
> >> >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923")
> >> >> > >
> >> >> > >
> >> >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092")
> >> >> > >
> >> >> > >
> >> >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890")
> >> >> > >
> >> >> > >
> >> >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789")
> >> >> > >
> >> >> > >
> >> >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678")
> >> >> > >
> >> >> > >
> >> >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567")
> >> >> > >
> >> >> > >
> >> >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456")
> >> >> > >
> >> >> > >
> >> >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456")
> >> >> > >
> >> >> > >
> >> >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345")
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >> > >> Date: Wed, 30 Sep 2015 12:01:57 +0100
> >> >> > >> From: damien.p.george at gmail.com
> >> >> > >> To: microbit at python.org
> >> >> > >> Subject: Re: [Microbit-Python] memory error
> >> >> > >>
> >> >> > >> Hi Alan,
> >> >> > >>
> >> >> > >> Can you post your code?
> >> >> > >>
> >> >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan <alainjackson at hotmail.com>
> >> >> > >> wrote:
> >> >> > >> > Hi,
> >> >> > >> >
> >> >> > >> > How much memory does the Microbit have for a python program?
> >> >> > >> >
> >> >> > >> > I've written a small program about 105 lines long. It's 3kB on
> >> >> > >> > my
> >> >> > >> > hard
> >> >> > >> > disk.
> >> >> > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept
> >> >> > >> > getting
> >> >> > >> > memory allocation errors as soon as I pressed the reset button.
> >> >> > >> > If
> >> >> > >> > I
> >> >> > >> > commented about 10 lines out of my program it would run and it
> >> >> > >> > didn't
> >> >> > >> > seem
> >> >> > >> > to matter which 10 lines. So I assumed it was out of program
> >> >> > >> > memory?
> >> >> > >> >
> >> >> > >> > Cheers,
> >> >> > >> >
> >> >> > >> > Alan
> >> >> > >> >
> >> >> > >> > _______________________________________________
> >> >> > >> > 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
> >> >> > >
> >> >> > > _______________________________________________ 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
> >> >> > >
> >> >> > _______________________________________________
> >> >> > 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
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
> >>
> >>
> >>
> >> _______________________________________________ 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
> >>
> >
> >
> > _______________________________________________
> > 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: <https://mail.python.org/mailman/private/microbit/attachments/20151003/8424ce24/attachment-0001.html>

More information about the Microbit mailing list