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

[Howard Baker-IF&L]

Thanks Jonny. I think we'd be keen to take up your offer.

Howard

-----Original Message-----
From: Microbit [mailto:microbit-bounces+howard.baker=bbc.co.uk at python.org] On Behalf Of Jonathan Austin
Sent: 13 July 2015 14:33
To: For Pythonic MicroBit related disucssions
Subject: Re: [Microbit-Python] The BBC reveal the device to the media

Hi all,

Sorry to arrive late to this thread... I've been away ignoring email :)

On 10 Jul 2015, at 20:46, Howard Baker-IF&L <howard.baker at bbc.co.uk> wrote:

>
> Hi,
> Nice thoughts. Interestingly a little while back I suggested to Jonny Austin at ARM
> we use the Freescale chip to help with the BLE issue. He was very against it for
> reasons I couldn't quite understand. However, if it is accessible it is a tantalising
> option.
>

I'm afraid I still don't think this is a useful approach...

The main reason is that the Freescale chip isn't powered when you're not running from USB,
so it creates quite a complex and confusing 'feature matrix' if you require USB to be plugged
in in order to use BLE ;)

I *do* think that we can use the KL26/Interface chip as a way of giving nice python
flashing experience - IE use the interface chip to write python scripts dropped onto the device
(via USB mass storage) into the the NRF51 flash (either by SWD or serial via micro python)
and then reset the NRF51...

We can start a new thread about this if people are interested - Damian, Nick, David an I have
had some initial discussions and I've poked the mbed interface firmware implementation to see
how it would play out. Looks feasible and fun... Also, who *doesn't* want to dust off
X/Y/Zmodem and stream stuff over serial ;)


> Thanks for all this. A lot of food for thought.

Indeed, I'm just reading and digesting the rest of the thread. :)

J
>
> Howard
>
> From: Microbit [mailto:microbit-bounces+howard.baker=bbc.co.uk at python.org] On Behalf Of Michael
> Sent: 10 July 2015 15:48
> To: For Pythonic MicroBit related disucssions; j.finney at lancaster.ac.uk
> Subject: Re: [Microbit-Python] The BBC reveal the device to the media
>
> 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.
>
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

_______________________________________________
Microbit mailing list
Microbit at python.org
https://mail.python.org/mailman/listinfo/microbit