[Microbit-Python] The BBC reveal the device to the media

Thu Jul 9 17:41:27 CEST 2015

> 4. The limitation of script size is not about flash but rather RAM.
> The script must be compiled on the device so needs a certain amount of
> RAM to hold the bytecode.

One question I've just realised is that there's 2 versions of the chip out
there - the 16K RAM and 32K RAM, and I seem to recall there possibly being
2 versions of the microbit device being about - one using 16K RAM and the
other having 32K. That leads me into some very specific questions that
spring to mind:

- How much memory has the device got that you've been testing with?

- What is the flash footprint of micropython?

- What is the RAM footprint for a trivial program?

- While the BLE doesn't work in this version for reasons we know, being
realistic is co-existence likely to be realistically possible?

- What if we baked micropython + python program into a custom download?

I know that flashing data and programs on the Cortex range of MCUs is more
granular than with arduino's but I'm not familiar with precisely how much
more granular. Can we store python source and any generated byte code in
flash, rather than RAM? Do you already? If you don't and if you could, how
much of a difference would this make?

I'm still very much in awe of the fact you've got micropython running on
the device at all incidentally, just beginning to start to think of the
practicality questions that may affect user experience. :-)

Best Regards,

Michael.

On 8 July 2015 at 09:17, Damien George <damien.p.george at gmail.com> wrote:

> David, I'd just like to clarify a few points regarding MicroPython and
> its use on the micro:bit:
>
> 1. MicroPython does not aim at all to replace TouchDevelop and all the
> goodness that the existing TouchDevelop environment brings.  Instead
> MicroPython provides a different (and more traditional) way of
> programming the device and therefore gives more options to those who
> have one, and more options to teachers to decide what's the
> best/easiest way for them to teach their students.
>
> 2. If Python is to run on the device then MicroPython is the easiest
> way to make this happen.  The report by Nicholas points out that it's
> going to be very hard to put a Python-like front end on the
> TouchDevelop system.
>
> 3. A lot of the niceties that you bring up about the TouchDevelop
> environment could also be implemented on top of the MicroPython
> paradigm (eg online sharing of code, libraries).  Now that we know
> that the core technology works (ie MicroPython runs), if we get the
> approval from the BBC that this is the way to go then we can get to
> work making the MicroPython+micro:bit ecosystem as easy and enjoyable
> as possible to use.
>
> 4. The limitation of script size is not about flash but rather RAM.
> The script must be compiled on the device so needs a certain amount of
> RAM to hold the bytecode.  Hence the limitation.  An alternative would
> be to compile to bytecode off the device (eg in the cloud) and run the
> bytecode from flash.  Then you would be allowed to write very large
> scripts.  But this means you are relying on internet connectivity and
> an online service.  As per point 1 above, MicroPython tries to bring
> something different to the table in terms of no reliance on the web
> (among other things), and I think it's good to keep this property.
> Also note that with BLE enabled the traditional solutions
> (TouchDevelop, mbed) don't get much RAM/flash to play with and the
> programs you can write are going to be limited.
>
> Cheers,
> Damien.
>
>
> On Wed, Jul 8, 2015 at 8:05 AM, David Whale <david at thinkingbinaries.com>
> wrote:
> > Hi Nicholas,
> >
> > I'm not ignoring you lot, just been *very* busy these last few days, from
> > all angles, and will be still for a week or so, sorry!
> >
> > I'm thinking through the proposals to think what I could add to the
> already
> > excellent comments and observations made by others.
> >
> > I think, still, I'm really drawn to the power of having a blocks like
> > interface with a "show code" button that shows the python, to provide a
> > smooth and natural transition for coders from a visual paradigm to a text
> > paradigm - think of it as the python equivalent of the web "view source"
> > where people look behind the scenes on a web page, work out how it works,
> > start hacking their own html, get into a bit of javascript, get into a
> bit
> > of php, and many get into computing that way.
> >
> > There is a subtle but important difference between a "show-code" option
> > (Michael's origional blockly) and a "convert forwards only" option
> (blocks
> > to touch develop one way conversion) - both with their own benefits and
> > pitfalls and differences.
> >
> >
> > I also need to personally think through whether two pages of code on a
> > 128/256K device ("twice the size of game of life") without the bluetooth
> > connectivity, gives enough opportunity for doing useful and engaging
> things
> > with that amount of code. I'm not sure about that one yet, to be honest.
> It
> > seems we've burnt a large amount of code space to get a tiny amount of
> user
> > app space. One way to frame this might be to roughly calculate what
> > percentage of flash is the interpreter and runtime, and what percentage
> is
> > user code - how does this compare to the existing blocks or touch develop
> > solutions (hard to compare as code density might differ significantly).
> But
> > if it's 95%/5%, interpreter/user app, I'm really not sure about that. Be
> > nice to have a ball park figure on the split at present. Is that all
> > interpreter, or is it libraries too - I''m guessing it's not possible to
> > strip unused libraries due to the dynamic nature of python?
> >
> >
> > Could we show the python experience to a bunch of 11 year olds and a
> bunch
> > of school teachers, perhaps, and see what they think of it - that is the
> > target audience, after all?
> >
> >
> > There's also *something* there that Michael mentioned about the contained
> > experience of working inside the ecosystem of a website with all the
> > interactions and sharing that happens, compared to an offline editor
> with an
> > independent community on a separate page - I've not quite thought through
> > both sides of that yet properly. There definitely is something about the
> > immersive experience of the community and tutorials and examples and
> editor
> > all being in one place, that I hadn't really seen before this BBC
> project -
> > there's a "thing" there I'm trying to form some view on, but it does feel
> > very exciting when you use it.
> >
> > The TouchDevelop shared online library feature is a stroke of genius
> that I
> > hadn't realised until I experienced it first hand this week - perhaps an
> > option to "import" and it does a live search for community contributed
> > libraries and just includes them for use like the TouchDevelop experience
> > does? Just a thought. The immutable published library concept gives
> > educators in particular a way to focus learners on the important
> learning at
> > the top of the app, whilst giving them drill-down to the detail if they
> want
> > it - I've learnt more about TouchDevelop by clicking through the library
> > detail than I have by reading any documentation, to be honest.
> >
> > There is also that thing about teachers have spent a couple of years
> > up-skilling in Python, and something new and different is coming along.
> It
> > would be good to provide a range of directions both in and out of the
> > experience for learners and teachers, so they both be attracted to it,
> and
> > drawn onwards to the next thing, in new and interesting ways. Python
> could
> > be as much a "draw in" to the experience, as well as a "draw out and
> > onwards" to bigger systems like Raspberry Pi, for example.
> >
> > Still thinking, but these are my initial thoughts for now. Sorry to be
> less
> > than helpful at this stage.
> >
> > 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 7 July 2015 at 14:46, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:
> >>
> >> On 07/07/15 14:20, David Whale wrote:
> >> > Tony hall mentioned python several times and so did dara o brien at
> the
> >> > public launch today.
> >> >
> >>
> >> Great stuff! I hope it went well.
> >>
> >> David, would be interesting to get your perspective on the Python work
> >> we're doing.
> >>
> >> *Everyone* - David is the point man for the Institution of Engineering
> >> and Technology (who are also a BBC partner). David also writes awesome
> >> books on Minecraft and Python programming.
> >>
> >> :-)
> >>
> >> N.
> >>
> >>
> >>
> >> _______________________________________________
> >> 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/20150709/6c49f127/attachment.html>