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

Michael sparks.m at gmail.com
Fri Jul 10 16:47:32 CEST 2015


Hi Damien,


[Massive snip]

That's really useful - and really interesting to read. I think you can guess
that the pain points are where I thought they might be based on the
questions, but it's really interesting data.

I think two questions arise generally, and this is pretty much a major long
shot.

Two things that the device has in the non-python environments:

1) - is the ability to reflash the device over the air
2) - the ability to use bluetooth from user programs.

(Both of these are as I understand it - my technical involvement
technically ceased
with the end of the schools' trial using the prototype device/software
stack, and after
delivery of detailed baseline reference tech specs.)

My impression from your comments is that we can probably retain the former.

My impression is that the latter would be ... tricky - at best.

Assuming these two impressions are right, that in itself makes me wonder,
and I'm
thinking of a slightly odd option.

For powersaving on the prototype device, we had a 2032 battery which would
have
its effective voltage drop over time from often just over 3V to below
2.6/2.7V dependent
on current draw (the 32u4's brown out voltage), etc. In the end the power
saving solution
we used was to a) only have 1 LED lit at a time, rapidly cyle through the
display in a raster
fashion, and then b) put the entire device to sleep for a microscopic time
period, on a
watchdog timer, then wake the whole device up, run for a bit, then go back
to sleep.

The reason I mention this is for a possibly bonkers option for item 2. In
this case, rather
than our constraint being power, our constraint is RAM. As I say, it is a
bit bonkers (since
it might cause issues for the flash), but would it be possible to save
micropython state
periodically to flash, activate the bluetooth, check for activity,
deactivate, and then
continue.

That or possibly treat the Freescale chip as a co-processor? Run a minimal
DAL on the
Nordic, but run micropython on the freescale? (This is partly inspired by
the tricks people
used to do with things like the C64 disk drives to use the 6502 CPUs in
those as
coprocessors on the system.

(That's a rather big if... and trying to find the right version of the
Kinetis MKL26 datasheet
at the moment.)

I guess what I'm a bit worried about is whether the lack of BLE will make
the python version
be viewed as less awesome than it is, and I'm just pondering possible
options.

As a personal position, I personally really want to go down this route
because I think as well
as awesome and clever, I think it's a neat and tidy solution, and without
BLE to confuse the
issue I don't think there would be any questions at all. As a result that's
why I'm exploring the
edges and just looking to see what is in the art of the possible, rather
than pre-requisites.

It won't ultimately be my decision at the end of the day though.

Regarding the specific guestimate:

> Note: I don't know what the life span of the flash is, but it might be
> an issue if users reflash many times per day.  10k life span for
> number of rewrites is typical, and that gives 27 erases per day for 1
> year.

If it's helpful, the prototype system stored user programs in a git-like
fashion.

That is each save created a version on the server pointing back to the
earlier
version, and the "program" pointed at the most recent version.

That means we could get data on how many times a program was editted before
being viewed as "done" by a child.

Note: I must admit I think reflashing constantly is a bad idea - and my
suggestion
above of treating flash effectively as swap, for obvious reasons, and I
suspect I'm
not alone there -- but just looking at options really.


> > just beginning to start to think of the
> > practicality questions that may affect user experience. :-)
>
> As I pointed out in a previous message, now that the core works we can
> think about user experience, and make it very usable.
>
> Of course, this all hinges on the BBC supporting this endeavour.
>

Absolutely, just trying to check how this compares to the other dev
platforms - what
you gain is clear, the concern is just what might you lose, and what
*could* be done
to mitigate that.

Many thanks for the detailed feedback,

Best Regards,



Michael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/mailman/private/microbit/attachments/20150710/39248655/attachment-0001.html>


More information about the Microbit mailing list