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

[Howard Baker-IF&L]

Hi,
Yep, as far as I understand this is all correct. I’ve recently found out about the Flash self-write; I’m hoping this offers some useful pressure releases plus the ability to store non-volatile data collected by the device.

Howard

From: Microbit [mailto:microbit-bounces+howard.baker=bbc.co.uk at python.org] On Behalf Of David Whale
Sent: 10 July 2015 21:53
To: For Pythonic MicroBit related disucssions
Subject: Re: [Microbit-Python] The BBC reveal the device to the media


I understand from talking to the Bluetooth SIGS guy that  Nordic have a standard FOTA in their chip that they just used, making (1) easy. (2) depends on what BLE Profile is compiled in (capabilities etc).

Also, for info, The BLE stack apparently has a regular service tick that steals CPU time every so often. The upshot is, apparently, with the Bluetooth enabled, the pwm glitches,making tone generation unreliable if BLE is in use. Seems odd to me. This would imply softpwm in use rather than an on chip hardware pwm through a timer peripheral.

If the flash supports self write, could micropython compile to bytecode and then self write to another flash page beyond the interpreter, releasing the RAM requirement a bit?

I think if you deactivate the BLE stack on intervals you'll probably loose device discovery.

D.

Sent from my new HTC
On Jul 10, 2015 3:47 PM, "Michael" <sparks.m at gmail.com<mailto:sparks.m at gmail.com>> wrote:
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.



_______________________________________________
Microbit mailing list
Microbit at python.org<mailto: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/20150711/8c6fed55/attachment-0001.html>