[Microbit-Python] The BBC reveal the device to the media
Nicholas H.Tollervey
ntoll at ntoll.org
Thu Jul 9 19:54:51 CEST 2015
Hi Michael,
This is a quote from an email from Damien in a discussion about BLE on
the micro:bit. I'm pretty certain he's on the 16k version.
"There is 16k RAM. 8k is for the BLE, plus 2k to
communicate with the BLE, leaving 6k for user apps. At the moment
(with the MicroBit driver) that 6k is pretty much completely used up
(it's split into 4k data and 2k stack). So there is no room at all
for MicroPython with the existing BLE+MicroBit drivers."
If there's to be a 32k version I guess BLE could be on the table.
Michael, this is the first I've heard of the 32k version. Is that how
much RAM will be on the device delivered to kids??? If so, where can we
get the hardware?
N.
On 09/07/15 16:41, Michael wrote:
>> 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
> <mailto: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 <mailto: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 <mailto:dwhale at theiet.org>
> > twitter: @whaleygeek
> > blog: blog.whaleygeek.co.uk <http://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
> <mailto: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 <mailto:Microbit at python.org>
> >> https://mail.python.org/mailman/listinfo/microbit
> >>
> >
> >
> > _______________________________________________
> > Microbit mailing list
> > Microbit at python.org <mailto:Microbit at python.org>
> > https://mail.python.org/mailman/listinfo/microbit
> >
> _______________________________________________
> Microbit mailing list
> Microbit at python.org <mailto: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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://mail.python.org/mailman/private/microbit/attachments/20150709/e3e94676/attachment-0001.sig>
More information about the Microbit
mailing list