From alainjackson at hotmail.com Thu Oct 1 02:32:14 2015 From: alainjackson at hotmail.com (Alan) Date: Thu, 1 Oct 2015 00:32:14 +0000 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , <56013703.80902@hastings.org>, , <56014B5B.40606@hastings.org>, , <56016A83.10202@hastings.org>, , , , , , , <5603F7DD.1030407@hastings.org>, , , , , , Message-ID: Hi, I didn't save the version of my code that got the memory error. But I've just now created a small, pathological example. The code below, which is 3kB on the disk, will create the following error: >>> MemoryError: Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with nRF51822 Type "help()" for more information. But if you delete the last line, it will run fine. """ Testing how much memory for python code the microbit has. """ from microbit import * display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > Date: Wed, 30 Sep 2015 12:01:57 +0100 > From: damien.p.george at gmail.com > To: microbit at python.org > Subject: Re: [Microbit-Python] memory error > > Hi Alan, > > Can you post your code? > > On Wed, Sep 30, 2015 at 2:14 AM, Alan wrote: > > Hi, > > > > How much memory does the Microbit have for a python program? > > > > I've written a small program about 105 lines long. It's 3kB on my hard disk. > > It runs ok now but when it was 115 lines long and 3.2kB I kept getting > > memory allocation errors as soon as I pressed the reset button. If I > > commented about 10 lines out of my program it would run and it didn't seem > > to matter which 10 lines. So I assumed it was out of program memory? > > > > Cheers, > > > > Alan > > > > _______________________________________________ > > 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: From alainjackson at hotmail.com Thu Oct 1 03:52:51 2015 From: alainjackson at hotmail.com (Alan) Date: Thu, 1 Oct 2015 01:52:51 +0000 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , , , , <56013703.80902@hastings.org>, , , , <56014B5B.40606@hastings.org>, , , , <56016A83.10202@hastings.org>, , , , , , , , , , , , , , <5603F7DD.1030407@hastings.org>, , , , , , , , , , , , Message-ID: Hi, Another little trick I've realised is that if I put a large, explanatory comment at the top of the file using """...""" it of course goes into a docstring... which takes up memory! If I use # style comments instead, it doesn't seem to take up memory. Cheers, Alan From: alainjackson at hotmail.com To: microbit at python.org Date: Thu, 1 Oct 2015 00:32:14 +0000 Subject: Re: [Microbit-Python] memory error Hi, I didn't save the version of my code that got the memory error. But I've just now created a small, pathological example. The code below, which is 3kB on the disk, will create the following error: >>> MemoryError: Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with nRF51822 Type "help()" for more information. But if you delete the last line, it will run fine. """ Testing how much memory for python code the microbit has. """ from microbit import * display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > Date: Wed, 30 Sep 2015 12:01:57 +0100 > From: damien.p.george at gmail.com > To: microbit at python.org > Subject: Re: [Microbit-Python] memory error > > Hi Alan, > > Can you post your code? > > On Wed, Sep 30, 2015 at 2:14 AM, Alan wrote: > > Hi, > > > > How much memory does the Microbit have for a python program? > > > > I've written a small program about 105 lines long. It's 3kB on my hard disk. > > It runs ok now but when it was 115 lines long and 3.2kB I kept getting > > memory allocation errors as soon as I pressed the reset button. If I > > commented about 10 lines out of my program it would run and it didn't seem > > to matter which 10 lines. So I assumed it was out of program memory? > > > > Cheers, > > > > Alan > > > > _______________________________________________ > > 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: From damien.p.george at gmail.com Fri Oct 2 17:07:02 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 2 Oct 2015 16:07:02 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: Hi Alan, Yes, doc strings do take up memory, so in our case (when trying to reduce memory usage) it's better to make them comments (which are just skipped over by the tokeniser). The example you give with lots of prints does indeed take up all the memory, so that's why it gives a MemoryError. It's not easy to fix this, the microbit is just really low on RAM! We could compile the python script to flash (instead of RAM) but that needs a bit of effort to get working. Cheers, Damien. On Thu, Oct 1, 2015 at 2:52 AM, Alan wrote: > Hi, > > Another little trick I've realised is that if I put a large, explanatory > comment at the top of the file using """...""" it of course goes into a > docstring... which takes up memory! > > If I use # style comments instead, it doesn't seem to take up memory. > > Cheers, > > Alan > > ________________________________ > From: alainjackson at hotmail.com > To: microbit at python.org > Date: Thu, 1 Oct 2015 00:32:14 +0000 > > Subject: Re: [Microbit-Python] memory error > > Hi, > > I didn't save the version of my code that got the memory error. > > But I've just now created a small, pathological example. > > The code below, which is 3kB on the disk, will create the following error: > >>>> MemoryError: > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with nRF51822 > Type "help()" for more information. > > But if you delete the last line, it will run fine. > > > > > """ > Testing how much memory for python code the microbit has. > """ > > from microbit import * > > > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > > > > > > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 >> From: damien.p.george at gmail.com >> To: microbit at python.org >> Subject: Re: [Microbit-Python] memory error >> >> Hi Alan, >> >> Can you post your code? >> >> On Wed, Sep 30, 2015 at 2:14 AM, Alan wrote: >> > Hi, >> > >> > How much memory does the Microbit have for a python program? >> > >> > I've written a small program about 105 lines long. It's 3kB on my hard >> > disk. >> > It runs ok now but when it was 115 lines long and 3.2kB I kept getting >> > memory allocation errors as soon as I pressed the reset button. If I >> > commented about 10 lines out of my program it would run and it didn't >> > seem >> > to matter which 10 lines. So I assumed it was out of program memory? >> > >> > Cheers, >> > >> > Alan >> > >> > _______________________________________________ >> > 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 > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From david at thinkingbinaries.com Fri Oct 2 17:23:47 2015 From: david at thinkingbinaries.com (David Whale) Date: Fri, 2 Oct 2015 16:23:47 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: I understand from Howard that Joe is working on a persistent memory store (simulated EEPROM in flash) - could you use that in the future? Also, did you see my note about AST expansion - do you parse the whole python source script into a complete explicit AST in RAM and then translate that into bytecode in RAM, or do you use an implicit 'AST on the machine stack' style of translation, effectively pipelining AST generation and bytecode generation? The latter is significantly smaller in terms of RAM requirements, and scales better regardless of the script complexity. 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 2 October 2015 at 16:07, Damien George wrote: > Hi Alan, > > Yes, doc strings do take up memory, so in our case (when trying to > reduce memory usage) it's better to make them comments (which are just > skipped over by the tokeniser). > > The example you give with lots of prints does indeed take up all the > memory, so that's why it gives a MemoryError. It's not easy to fix > this, the microbit is just really low on RAM! We could compile the > python script to flash (instead of RAM) but that needs a bit of effort > to get working. > > Cheers, > Damien. > > > On Thu, Oct 1, 2015 at 2:52 AM, Alan wrote: > > Hi, > > > > Another little trick I've realised is that if I put a large, explanatory > > comment at the top of the file using """...""" it of course goes into a > > docstring... which takes up memory! > > > > If I use # style comments instead, it doesn't seem to take up memory. > > > > Cheers, > > > > Alan > > > > ________________________________ > > From: alainjackson at hotmail.com > > To: microbit at python.org > > Date: Thu, 1 Oct 2015 00:32:14 +0000 > > > > Subject: Re: [Microbit-Python] memory error > > > > Hi, > > > > I didn't save the version of my code that got the memory error. > > > > But I've just now created a small, pathological example. > > > > The code below, which is 3kB on the disk, will create the following > error: > > > >>>> MemoryError: > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with nRF51822 > > Type "help()" for more information. > > > > But if you delete the last line, it will run fine. > > > > > > > > > > """ > > Testing how much memory for python code the microbit has. > > """ > > > > from microbit import * > > > > > > > > > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > > > > > > > > > > > > > > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 > >> From: damien.p.george at gmail.com > >> To: microbit at python.org > >> Subject: Re: [Microbit-Python] memory error > >> > >> Hi Alan, > >> > >> Can you post your code? > >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan wrote: > >> > Hi, > >> > > >> > How much memory does the Microbit have for a python program? > >> > > >> > I've written a small program about 105 lines long. It's 3kB on my hard > >> > disk. > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept getting > >> > memory allocation errors as soon as I pressed the reset button. If I > >> > commented about 10 lines out of my program it would run and it didn't > >> > seem > >> > to matter which 10 lines. So I assumed it was out of program memory? > >> > > >> > Cheers, > >> > > >> > Alan > >> > > >> > _______________________________________________ > >> > 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 > > > > _______________________________________________ > > 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: From ericsnowcurrently at gmail.com Fri Oct 2 17:26:04 2015 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Fri, 2 Oct 2015 09:26:04 -0600 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: On Fri, Oct 2, 2015 at 9:07 AM, Damien George wrote: > Yes, doc strings do take up memory, so in our case (when trying to > reduce memory usage) it's better to make them comments (which are just > skipped over by the tokeniser). Why not support an option to strip docstrings, similar to "python -O"? In fact, consider making docstring *preservation* an opt-in option. That would probably suit the embedded space better. -eric > > The example you give with lots of prints does indeed take up all the > memory, so that's why it gives a MemoryError. It's not easy to fix > this, the microbit is just really low on RAM! We could compile the > python script to flash (instead of RAM) but that needs a bit of effort > to get working. I'd be interested in seeing something like this happen, though I can't promise I could help much (for now). Could it leverage the frozen module support that already exists? -eric From damien.p.george at gmail.com Fri Oct 2 17:35:11 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 2 Oct 2015 16:35:11 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: > On Fri, Oct 2, 2015 at 9:07 AM, Damien George wrote: >> Yes, doc strings do take up memory, so in our case (when trying to >> reduce memory usage) it's better to make them comments (which are just >> skipped over by the tokeniser). > > Why not support an option to strip docstrings, similar to "python -O"? > In fact, consider making docstring *preservation* an opt-in option. > That would probably suit the embedded space better. There is already such an option (a compile time option) and in fact the microbit does not have doc strings enabled. Nevertheless, it doesn't know what string is a doc string and what string is a normal string until after it tokenises the string. So it must store the doc string in RAM to begin with, and then it will discard it soon after if it sees that it's a doc string. So you must have enough RAM to temporarily hold the biggest doc string in your source (which can be many kb). >> The example you give with lots of prints does indeed take up all the >> memory, so that's why it gives a MemoryError. It's not easy to fix >> this, the microbit is just really low on RAM! We could compile the >> python script to flash (instead of RAM) but that needs a bit of effort >> to get working. > > I'd be interested in seeing something like this happen, though I can't > promise I could help much (for now). Could it leverage the frozen > module support that already exists? Frozen module won't help here. Basically one needs to do the following: - hook into the bytecode allocation routine to allocate in flash instead of RAM (allocation is done in last compile phase after size of bytecode is known so this is doable) - hook into the bytecode writing routines to write to flash (probably via a small RAM buffer) - return pointers to flash bytecode instead of RAM - make sure this is only done once (ie if the microbit resets then no need to do it again if the script didn't change) From damien.p.george at gmail.com Fri Oct 2 17:37:28 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 2 Oct 2015 16:37:28 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: > I understand from Howard that Joe is working on a persistent memory store > (simulated EEPROM in flash) - could you use that in the future? Yes, definitely. Although it depends on the API that Joe exposes. > Also, did you see my note about AST expansion - do you parse the whole > python source script into a complete explicit AST in RAM and then translate > that into bytecode in RAM, or do you use an implicit 'AST on the machine > stack' style of translation, effectively pipelining AST generation and > bytecode generation? The latter is significantly smaller in terms of RAM > requirements, and scales better regardless of the script complexity. Yes, I'm still thinking about this. It currently parses the whole source into an AST. Will reply fully once I have something sensible to say! From david at thinkingbinaries.com Fri Oct 2 17:54:58 2015 From: david at thinkingbinaries.com (David Whale) Date: Fri, 2 Oct 2015 16:54:58 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: >Yes, I'm still thinking about this. It currently parses the whole source into an AST. Will reply fully once I have something sensible to say! Ok thanks - when I've done this before, you sometimes need a fixup table that you collect along the way, and do a final "tiny pass" to resolve jump targets to things that are not known on the first pass, but the fixup table + implicit AST on machine stack is usually significantly smaller in terms of memory footprint, and generally doesn't expand as the script size expands, it only expands as the parse depth expands (e.g. a complex nested algebraic expression would expand the temporary AST on the stack until the final close bracket is seen). Cheers 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 2 October 2015 at 16:37, Damien George wrote: > > I understand from Howard that Joe is working on a persistent memory store > > (simulated EEPROM in flash) - could you use that in the future? > > Yes, definitely. Although it depends on the API that Joe exposes. > > > Also, did you see my note about AST expansion - do you parse the whole > > python source script into a complete explicit AST in RAM and then > translate > > that into bytecode in RAM, or do you use an implicit 'AST on the machine > > stack' style of translation, effectively pipelining AST generation and > > bytecode generation? The latter is significantly smaller in terms of RAM > > requirements, and scales better regardless of the script complexity. > > Yes, I'm still thinking about this. It currently parses the whole > source into an AST. Will reply fully once I have something sensible > to say! > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alainjackson at hotmail.com Fri Oct 2 19:06:28 2015 From: alainjackson at hotmail.com (Alan) Date: Fri, 2 Oct 2015 17:06:28 +0000 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , <56013703.80902@hastings.org>, , <56014B5B.40606@hastings.org>, , <56016A83.10202@hastings.org>, , , , , , , <5603F7DD.1030407@hastings.org>, , , , , , , , Message-ID: Hi, Am I right in thinking the size of variable names also makes a difference? It seemed to, although I didn't test that scientifically. 3KB is a bit small. I know, however big the memory we'd always want more. And I did grow up programming a ZX81, so this is 3 times as big! You'd think I'd be happy with that. Cheers, Alan > Date: Fri, 2 Oct 2015 16:07:02 +0100 > From: damien.p.george at gmail.com > To: microbit at python.org > Subject: Re: [Microbit-Python] memory error > > Hi Alan, > > Yes, doc strings do take up memory, so in our case (when trying to > reduce memory usage) it's better to make them comments (which are just > skipped over by the tokeniser). > > The example you give with lots of prints does indeed take up all the > memory, so that's why it gives a MemoryError. It's not easy to fix > this, the microbit is just really low on RAM! We could compile the > python script to flash (instead of RAM) but that needs a bit of effort > to get working. > > Cheers, > Damien. > > > On Thu, Oct 1, 2015 at 2:52 AM, Alan wrote: > > Hi, > > > > Another little trick I've realised is that if I put a large, explanatory > > comment at the top of the file using """...""" it of course goes into a > > docstring... which takes up memory! > > > > If I use # style comments instead, it doesn't seem to take up memory. > > > > Cheers, > > > > Alan > > > > ________________________________ > > From: alainjackson at hotmail.com > > To: microbit at python.org > > Date: Thu, 1 Oct 2015 00:32:14 +0000 > > > > Subject: Re: [Microbit-Python] memory error > > > > Hi, > > > > I didn't save the version of my code that got the memory error. > > > > But I've just now created a small, pathological example. > > > > The code below, which is 3kB on the disk, will create the following error: > > > >>>> MemoryError: > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with nRF51822 > > Type "help()" for more information. > > > > But if you delete the last line, it will run fine. > > > > > > > > > > """ > > Testing how much memory for python code the microbit has. > > """ > > > > from microbit import * > > > > > > > > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > > > > > > > > > > > > > > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 > >> From: damien.p.george at gmail.com > >> To: microbit at python.org > >> Subject: Re: [Microbit-Python] memory error > >> > >> Hi Alan, > >> > >> Can you post your code? > >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan wrote: > >> > Hi, > >> > > >> > How much memory does the Microbit have for a python program? > >> > > >> > I've written a small program about 105 lines long. It's 3kB on my hard > >> > disk. > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept getting > >> > memory allocation errors as soon as I pressed the reset button. If I > >> > commented about 10 lines out of my program it would run and it didn't > >> > seem > >> > to matter which 10 lines. So I assumed it was out of program memory? > >> > > >> > Cheers, > >> > > >> > Alan > >> > > >> > _______________________________________________ > >> > 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 > > > > _______________________________________________ > > 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: From david at thinkingbinaries.com Fri Oct 2 19:17:36 2015 From: david at thinkingbinaries.com (David Whale) Date: Fri, 2 Oct 2015 18:17:36 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: I only had a 1K ZX81 and it forced me to learn machine code so I could make everything fit :) I'm *guessing* that MicroPython has a fixup table, so that the variable names and function names are only stored in RAM once - i.e. each reference to a function name or variable name in the bytecode is actually an index into a string table with the actual name in it? Perhaps a one-way hash could be used to turn any given name into a shorter hash that is actually used for the lookup? Cheers D ___________________________________________________________ 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 2 October 2015 at 18:06, Alan wrote: > Hi, > > Am I right in thinking the size of variable names also makes a difference? > It seemed to, although I didn't test that scientifically. > > 3KB is a bit small. I know, however big the memory we'd always want more. > And I did grow up programming a ZX81, so this is 3 times as big! You'd > think I'd be happy with that. > > Cheers, > > Alan > > > Date: Fri, 2 Oct 2015 16:07:02 +0100 > > > From: damien.p.george at gmail.com > > To: microbit at python.org > > Subject: Re: [Microbit-Python] memory error > > > > Hi Alan, > > > > Yes, doc strings do take up memory, so in our case (when trying to > > reduce memory usage) it's better to make them comments (which are just > > skipped over by the tokeniser). > > > > The example you give with lots of prints does indeed take up all the > > memory, so that's why it gives a MemoryError. It's not easy to fix > > this, the microbit is just really low on RAM! We could compile the > > python script to flash (instead of RAM) but that needs a bit of effort > > to get working. > > > > Cheers, > > Damien. > > > > > > On Thu, Oct 1, 2015 at 2:52 AM, Alan wrote: > > > Hi, > > > > > > Another little trick I've realised is that if I put a large, > explanatory > > > comment at the top of the file using """...""" it of course goes into a > > > docstring... which takes up memory! > > > > > > If I use # style comments instead, it doesn't seem to take up memory. > > > > > > Cheers, > > > > > > Alan > > > > > > ________________________________ > > > From: alainjackson at hotmail.com > > > To: microbit at python.org > > > Date: Thu, 1 Oct 2015 00:32:14 +0000 > > > > > > Subject: Re: [Microbit-Python] memory error > > > > > > Hi, > > > > > > I didn't save the version of my code that got the memory error. > > > > > > But I've just now created a small, pathological example. > > > > > > The code below, which is 3kB on the disk, will create the following > error: > > > > > >>>> MemoryError: > > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with nRF51822 > > > Type "help()" for more information. > > > > > > But if you delete the last line, it will run fine. > > > > > > > > > > > > > > > """ > > > Testing how much memory for python code the microbit has. > > > """ > > > > > > from microbit import * > > > > > > > > > > > > > > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > > > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > > > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > > > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > > > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > > > > > > > > > > > > > > > > > > > > > > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 > > >> From: damien.p.george at gmail.com > > >> To: microbit at python.org > > >> Subject: Re: [Microbit-Python] memory error > > >> > > >> Hi Alan, > > >> > > >> Can you post your code? > > >> > > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan > wrote: > > >> > Hi, > > >> > > > >> > How much memory does the Microbit have for a python program? > > >> > > > >> > I've written a small program about 105 lines long. It's 3kB on my > hard > > >> > disk. > > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept > getting > > >> > memory allocation errors as soon as I pressed the reset button. If I > > >> > commented about 10 lines out of my program it would run and it > didn't > > >> > seem > > >> > to matter which 10 lines. So I assumed it was out of program memory? > > >> > > > >> > Cheers, > > >> > > > >> > Alan > > >> > > > >> > _______________________________________________ > > >> > 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 > > > > > > _______________________________________________ > > > 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: From damien.p.george at gmail.com Fri Oct 2 23:46:23 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 2 Oct 2015 22:46:23 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: Yes, variable name length will have a small impact on RAM usage. Yes, as David says, a given variable is only stored once in RAM and then referenced by an index (which is usually 16 bits) so it's relatively efficient. You need to keep the actual name of the variable around so that you can given sensible error messages, and also for lookup of global names in dictionaries. There are definitely things that we can do to improve the memory usage and allow bigger scripts. Do you think it's a priority? On Fri, Oct 2, 2015 at 6:17 PM, David Whale wrote: > I only had a 1K ZX81 and it forced me to learn machine code so I could make > everything fit :) > > I'm *guessing* that MicroPython has a fixup table, so that the variable > names and function names are only stored in RAM once - i.e. each reference > to a function name or variable name in the bytecode is actually an index > into a string table with the actual name in it? Perhaps a one-way hash could > be used to turn any given name into a shorter hash that is actually used for > the lookup? > > Cheers > > D > > > ___________________________________________________________ > 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 2 October 2015 at 18:06, Alan wrote: >> >> Hi, >> >> Am I right in thinking the size of variable names also makes a difference? >> It seemed to, although I didn't test that scientifically. >> >> 3KB is a bit small. I know, however big the memory we'd always want more. >> And I did grow up programming a ZX81, so this is 3 times as big! You'd think >> I'd be happy with that. >> >> Cheers, >> >> Alan >> >> > Date: Fri, 2 Oct 2015 16:07:02 +0100 >> >> > From: damien.p.george at gmail.com >> > To: microbit at python.org >> > Subject: Re: [Microbit-Python] memory error >> > >> > Hi Alan, >> > >> > Yes, doc strings do take up memory, so in our case (when trying to >> > reduce memory usage) it's better to make them comments (which are just >> > skipped over by the tokeniser). >> > >> > The example you give with lots of prints does indeed take up all the >> > memory, so that's why it gives a MemoryError. It's not easy to fix >> > this, the microbit is just really low on RAM! We could compile the >> > python script to flash (instead of RAM) but that needs a bit of effort >> > to get working. >> > >> > Cheers, >> > Damien. >> > >> > >> > On Thu, Oct 1, 2015 at 2:52 AM, Alan wrote: >> > > Hi, >> > > >> > > Another little trick I've realised is that if I put a large, >> > > explanatory >> > > comment at the top of the file using """...""" it of course goes into >> > > a >> > > docstring... which takes up memory! >> > > >> > > If I use # style comments instead, it doesn't seem to take up memory. >> > > >> > > Cheers, >> > > >> > > Alan >> > > >> > > ________________________________ >> > > From: alainjackson at hotmail.com >> > > To: microbit at python.org >> > > Date: Thu, 1 Oct 2015 00:32:14 +0000 >> > > >> > > Subject: Re: [Microbit-Python] memory error >> > > >> > > Hi, >> > > >> > > I didn't save the version of my code that got the memory error. >> > > >> > > But I've just now created a small, pathological example. >> > > >> > > The code below, which is 3kB on the disk, will create the following >> > > error: >> > > >> > >>>> MemoryError: >> > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with nRF51822 >> > > Type "help()" for more information. >> > > >> > > But if you delete the last line, it will run fine. >> > > >> > > >> > > >> > > >> > > """ >> > > Testing how much memory for python code the microbit has. >> > > """ >> > > >> > > from microbit import * >> > > >> > > >> > > >> > > >> > > >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") >> > > >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") >> > > >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") >> > > >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") >> > > >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> > > >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> > > >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") >> > > >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") >> > > >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") >> > > >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") >> > > >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") >> > > >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") >> > > >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") >> > > >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") >> > > >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> > > >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> > > >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") >> > > >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") >> > > >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") >> > > >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") >> > > >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") >> > > >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") >> > > >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") >> > > >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") >> > > >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> > > >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> > > >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 >> > >> From: damien.p.george at gmail.com >> > >> To: microbit at python.org >> > >> Subject: Re: [Microbit-Python] memory error >> > >> >> > >> Hi Alan, >> > >> >> > >> Can you post your code? >> > >> >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan >> > >> wrote: >> > >> > Hi, >> > >> > >> > >> > How much memory does the Microbit have for a python program? >> > >> > >> > >> > I've written a small program about 105 lines long. It's 3kB on my >> > >> > hard >> > >> > disk. >> > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept >> > >> > getting >> > >> > memory allocation errors as soon as I pressed the reset button. If >> > >> > I >> > >> > commented about 10 lines out of my program it would run and it >> > >> > didn't >> > >> > seem >> > >> > to matter which 10 lines. So I assumed it was out of program >> > >> > memory? >> > >> > >> > >> > Cheers, >> > >> > >> > >> > Alan >> > >> > >> > >> > _______________________________________________ >> > >> > 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 >> > > >> > > _______________________________________________ >> > > 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 >> > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From david at thinkingbinaries.com Sat Oct 3 00:09:59 2015 From: david at thinkingbinaries.com (David Whale) Date: Fri, 2 Oct 2015 23:09:59 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: I think it would be useful to have a rough metric or target of the sort of script/size that would be reasonably expected on a platform of this size. It might be that on the whole, all the things that people are writing will basically fit, if some basic good practice in naming and layout is followed. I also think back to the earlier discussion about limited memory on the ZX81, and the fact that I spent most of my working life up until now squeezing lots of functionality into tiny processors with limited resources, and the skills I learnt on my 1K ZX81 were vital to enabling that innovation. The door push on the front of my house has my code in it, it's a commercial product you can buy off the shelf, and it wouldn't have if I didn't cut my teeth on a resource limited platform which forced me to understand how the computer actually worked. I was 11 when I had my ZX81 and I was writing Z80 assembler as a way to make things fit. On the whole it was a really exciting experience for an 11 year old! One of the things to remember is that modern computers (even the Raspberry Pi) mostly allow you to assume infinite resources (or pretty unbounded). The micro:bit is very much an embedded platform, and having a limit on resources causes people to understand that nothing is infinite in this world, and that's a good thing sometimes! So, let's not beat ourselves up about it. As long as a good representative set of engaging and exciting programs can be made to fit, there has to be some limit. And besides - save some work for version 2!!! As an aside, if someone were to develop a toolkit that helped to explain where the memory usage in a given MicroPython program goes to, it would enable users to optimise their programs better themselves and gain a better understanding of how things work. I'm sure Damien is the same, when working on an embedded platform I spend my life in the map file and often in the assembly listings too, to understand where all the precious memory is going to! 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 2 October 2015 at 22:46, Damien George wrote: > Yes, variable name length will have a small impact on RAM usage. > > Yes, as David says, a given variable is only stored once in RAM and > then referenced by an index (which is usually 16 bits) so it's > relatively efficient. You need to keep the actual name of the > variable around so that you can given sensible error messages, and > also for lookup of global names in dictionaries. > > There are definitely things that we can do to improve the memory usage > and allow bigger scripts. Do you think it's a priority? > > On Fri, Oct 2, 2015 at 6:17 PM, David Whale > wrote: > > I only had a 1K ZX81 and it forced me to learn machine code so I could > make > > everything fit :) > > > > I'm *guessing* that MicroPython has a fixup table, so that the variable > > names and function names are only stored in RAM once - i.e. each > reference > > to a function name or variable name in the bytecode is actually an index > > into a string table with the actual name in it? Perhaps a one-way hash > could > > be used to turn any given name into a shorter hash that is actually used > for > > the lookup? > > > > Cheers > > > > D > > > > > > ___________________________________________________________ > > 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 2 October 2015 at 18:06, Alan wrote: > >> > >> Hi, > >> > >> Am I right in thinking the size of variable names also makes a > difference? > >> It seemed to, although I didn't test that scientifically. > >> > >> 3KB is a bit small. I know, however big the memory we'd always want > more. > >> And I did grow up programming a ZX81, so this is 3 times as big! You'd > think > >> I'd be happy with that. > >> > >> Cheers, > >> > >> Alan > >> > >> > Date: Fri, 2 Oct 2015 16:07:02 +0100 > >> > >> > From: damien.p.george at gmail.com > >> > To: microbit at python.org > >> > Subject: Re: [Microbit-Python] memory error > >> > > >> > Hi Alan, > >> > > >> > Yes, doc strings do take up memory, so in our case (when trying to > >> > reduce memory usage) it's better to make them comments (which are just > >> > skipped over by the tokeniser). > >> > > >> > The example you give with lots of prints does indeed take up all the > >> > memory, so that's why it gives a MemoryError. It's not easy to fix > >> > this, the microbit is just really low on RAM! We could compile the > >> > python script to flash (instead of RAM) but that needs a bit of effort > >> > to get working. > >> > > >> > Cheers, > >> > Damien. > >> > > >> > > >> > On Thu, Oct 1, 2015 at 2:52 AM, Alan > wrote: > >> > > Hi, > >> > > > >> > > Another little trick I've realised is that if I put a large, > >> > > explanatory > >> > > comment at the top of the file using """...""" it of course goes > into > >> > > a > >> > > docstring... which takes up memory! > >> > > > >> > > If I use # style comments instead, it doesn't seem to take up > memory. > >> > > > >> > > Cheers, > >> > > > >> > > Alan > >> > > > >> > > ________________________________ > >> > > From: alainjackson at hotmail.com > >> > > To: microbit at python.org > >> > > Date: Thu, 1 Oct 2015 00:32:14 +0000 > >> > > > >> > > Subject: Re: [Microbit-Python] memory error > >> > > > >> > > Hi, > >> > > > >> > > I didn't save the version of my code that got the memory error. > >> > > > >> > > But I've just now created a small, pathological example. > >> > > > >> > > The code below, which is 3kB on the disk, will create the following > >> > > error: > >> > > > >> > >>>> MemoryError: > >> > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with > nRF51822 > >> > > Type "help()" for more information. > >> > > > >> > > But if you delete the last line, it will run fine. > >> > > > >> > > > >> > > > >> > > > >> > > """ > >> > > Testing how much memory for python code the microbit has. > >> > > """ > >> > > > >> > > from microbit import * > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> > > > >> > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> > > > >> > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> > > > >> > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> > > > >> > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> > > > >> > > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > >> > > > >> > > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > >> > > > >> > > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > >> > > > >> > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> > > > >> > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> > > > >> > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> > > > >> > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> > > > >> > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> > > > >> > > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > >> > > > >> > > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > >> > > > >> > > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > >> > > > >> > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> > > > >> > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> > > > >> > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> > > > >> > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> > > > >> > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 > >> > >> From: damien.p.george at gmail.com > >> > >> To: microbit at python.org > >> > >> Subject: Re: [Microbit-Python] memory error > >> > >> > >> > >> Hi Alan, > >> > >> > >> > >> Can you post your code? > >> > >> > >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan > >> > >> wrote: > >> > >> > Hi, > >> > >> > > >> > >> > How much memory does the Microbit have for a python program? > >> > >> > > >> > >> > I've written a small program about 105 lines long. It's 3kB on my > >> > >> > hard > >> > >> > disk. > >> > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept > >> > >> > getting > >> > >> > memory allocation errors as soon as I pressed the reset button. > If > >> > >> > I > >> > >> > commented about 10 lines out of my program it would run and it > >> > >> > didn't > >> > >> > seem > >> > >> > to matter which 10 lines. So I assumed it was out of program > >> > >> > memory? > >> > >> > > >> > >> > Cheers, > >> > >> > > >> > >> > Alan > >> > >> > > >> > >> > _______________________________________________ > >> > >> > 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 > >> > > > >> > > _______________________________________________ > >> > > 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 > >> > > > > > > _______________________________________________ > > 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: From alainjackson at hotmail.com Sat Oct 3 00:49:22 2015 From: alainjackson at hotmail.com (Alan) Date: Fri, 2 Oct 2015 22:49:22 +0000 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , <56013703.80902@hastings.org>, , <56014B5B.40606@hastings.org>, , <56016A83.10202@hastings.org>, , , , , , , <5603F7DD.1030407@hastings.org>, , , , , , , , , , Message-ID: Is it a priority? Well... so far I've only got my own use of the micro:bit as a test case (and I know I'm not the target audience). I thought I'd only been playing around with small ideas and so far I've run out of memory on almost every program I've written. I've had to start doing weird things like un-modularising code - taking the code out of a function and cut-and-pasting it in multiple places, to reduce memory (sounds counter intuitive but does work sometimes). It was a real effort trying to fit my "watch.py" program into memory. All that does is display the time in hours and minutes and lets you set the time. I've also written a stop-watch style timer and count-down timer and imagined they could be modes on my watch... but that would never fit. "Watch" is one line away from the memory limit. I'm trying to write a program I'm calling "hyperdisplay" at the moment. The idea is it tries to fake a higher resolution display by using the accelerometer and changing the pixels as you shake the board (this might not be possible anyway due to speed but it's worth a try!). I was going to try to interpolate five LED positions between each LED, so I'm using a 25 x 25 binary image... but just the image and the code to take a 5X5 sample of it takes up nearly all the memory so I don't think I can fit the accelerometer code in. In any art form it is the constraints that make the medium. That said.. a few more KB would go a long way. Another way of looking at it would be to ask how much time would someone (11 years old) spend writing a program? My programs are small and I'm slow and they're taking me 2 - 4 hours... and then I run out of memory. 6KB for me could mean my programs could take 6+ hours to code. I'm really just talking about myself here, I don't know if this resonates with anyone else. For me a creation that takes 6 - 10 hours is an interesting amount of time in that it generally means multiple sittings. I might start it one day and complete it the next. I've done a lot of computer music and when I was younger for years I would write my pieces in a single sitting, which is fun but ultimately held me back. When I broke through the single-sitting barrier I took a leap forward in skills and creativity. When I come back to code the next day I have to read it, remember what it's doing and then I start renaming things, making it more obvious what's going on. That's when I have the insights that lead to making more generic and re-usable functions. Is this just me finding any excuse to get more memory? Maybe... maybe not. If I could have any amount of memory is there an upper limit? Well... yes. In that there is a size of project that I can't keep in my head and I have to start refactoring, early, or I make spaghetti code. And once the spaghetti starts then it's like doing the washing up, I don't want to go back to it. Refactoring and clean design are great skills to have and promote but are probably beyond the remit of inspiring 11 year olds. A project where I did that recently on the rPi is 1800 lines, about 65KB. It started off as a fun hack over a weekend and then slowly turned to bolognese over the subsequent weeks. My mistake was not noticing when I went over the threshold from "fun hack" to "software engineering". So 65KB is too much. I'd argue over 16KB is too much. Under 16KB and it's going to be hard to get into the kind of mess where I feel despondent about the whole thing and abandon it. Under 16KB and I can remain forever in the ludic hacker mentality. So between 6KB and 16KB works for me. Everyone might be different of course. Cheers, Alan > Date: Fri, 2 Oct 2015 22:46:23 +0100 > From: damien.p.george at gmail.com > To: microbit at python.org > Subject: Re: [Microbit-Python] memory error > > Yes, variable name length will have a small impact on RAM usage. > > Yes, as David says, a given variable is only stored once in RAM and > then referenced by an index (which is usually 16 bits) so it's > relatively efficient. You need to keep the actual name of the > variable around so that you can given sensible error messages, and > also for lookup of global names in dictionaries. > > There are definitely things that we can do to improve the memory usage > and allow bigger scripts. Do you think it's a priority? > > On Fri, Oct 2, 2015 at 6:17 PM, David Whale wrote: > > I only had a 1K ZX81 and it forced me to learn machine code so I could make > > everything fit :) > > > > I'm *guessing* that MicroPython has a fixup table, so that the variable > > names and function names are only stored in RAM once - i.e. each reference > > to a function name or variable name in the bytecode is actually an index > > into a string table with the actual name in it? Perhaps a one-way hash could > > be used to turn any given name into a shorter hash that is actually used for > > the lookup? > > > > Cheers > > > > D > > > > > > ___________________________________________________________ > > 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 2 October 2015 at 18:06, Alan wrote: > >> > >> Hi, > >> > >> Am I right in thinking the size of variable names also makes a difference? > >> It seemed to, although I didn't test that scientifically. > >> > >> 3KB is a bit small. I know, however big the memory we'd always want more. > >> And I did grow up programming a ZX81, so this is 3 times as big! You'd think > >> I'd be happy with that. > >> > >> Cheers, > >> > >> Alan > >> > >> > Date: Fri, 2 Oct 2015 16:07:02 +0100 > >> > >> > From: damien.p.george at gmail.com > >> > To: microbit at python.org > >> > Subject: Re: [Microbit-Python] memory error > >> > > >> > Hi Alan, > >> > > >> > Yes, doc strings do take up memory, so in our case (when trying to > >> > reduce memory usage) it's better to make them comments (which are just > >> > skipped over by the tokeniser). > >> > > >> > The example you give with lots of prints does indeed take up all the > >> > memory, so that's why it gives a MemoryError. It's not easy to fix > >> > this, the microbit is just really low on RAM! We could compile the > >> > python script to flash (instead of RAM) but that needs a bit of effort > >> > to get working. > >> > > >> > Cheers, > >> > Damien. > >> > > >> > > >> > On Thu, Oct 1, 2015 at 2:52 AM, Alan wrote: > >> > > Hi, > >> > > > >> > > Another little trick I've realised is that if I put a large, > >> > > explanatory > >> > > comment at the top of the file using """...""" it of course goes into > >> > > a > >> > > docstring... which takes up memory! > >> > > > >> > > If I use # style comments instead, it doesn't seem to take up memory. > >> > > > >> > > Cheers, > >> > > > >> > > Alan > >> > > > >> > > ________________________________ > >> > > From: alainjackson at hotmail.com > >> > > To: microbit at python.org > >> > > Date: Thu, 1 Oct 2015 00:32:14 +0000 > >> > > > >> > > Subject: Re: [Microbit-Python] memory error > >> > > > >> > > Hi, > >> > > > >> > > I didn't save the version of my code that got the memory error. > >> > > > >> > > But I've just now created a small, pathological example. > >> > > > >> > > The code below, which is 3kB on the disk, will create the following > >> > > error: > >> > > > >> > >>>> MemoryError: > >> > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with nRF51822 > >> > > Type "help()" for more information. > >> > > > >> > > But if you delete the last line, it will run fine. > >> > > > >> > > > >> > > > >> > > > >> > > """ > >> > > Testing how much memory for python code the microbit has. > >> > > """ > >> > > > >> > > from microbit import * > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> > > > >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> > > > >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> > > > >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> > > > >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> > > > >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > >> > > > >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > >> > > > >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > >> > > > >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> > > > >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> > > > >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> > > > >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> > > > >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> > > > >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > >> > > > >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > >> > > > >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > >> > > > >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> > > > >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> > > > >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> > > > >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> > > > >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 > >> > >> From: damien.p.george at gmail.com > >> > >> To: microbit at python.org > >> > >> Subject: Re: [Microbit-Python] memory error > >> > >> > >> > >> Hi Alan, > >> > >> > >> > >> Can you post your code? > >> > >> > >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan > >> > >> wrote: > >> > >> > Hi, > >> > >> > > >> > >> > How much memory does the Microbit have for a python program? > >> > >> > > >> > >> > I've written a small program about 105 lines long. It's 3kB on my > >> > >> > hard > >> > >> > disk. > >> > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept > >> > >> > getting > >> > >> > memory allocation errors as soon as I pressed the reset button. If > >> > >> > I > >> > >> > commented about 10 lines out of my program it would run and it > >> > >> > didn't > >> > >> > seem > >> > >> > to matter which 10 lines. So I assumed it was out of program > >> > >> > memory? > >> > >> > > >> > >> > Cheers, > >> > >> > > >> > >> > Alan > >> > >> > > >> > >> > _______________________________________________ > >> > >> > 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 > >> > > > >> > > _______________________________________________ > >> > > 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 > >> > > > > > > _______________________________________________ > > 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/microbitaa -------------- next part -------------- An HTML attachment was scrubbed... URL: From alainjackson at hotmail.com Sat Oct 3 01:02:34 2015 From: alainjackson at hotmail.com (Alan) Date: Fri, 2 Oct 2015 23:02:34 +0000 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , <56013703.80902@hastings.org>, , <56014B5B.40606@hastings.org>, , <56016A83.10202@hastings.org>, , , , , , , <5603F7DD.1030407@hastings.org>, , , , , , , , , , , Message-ID: Hi David, I find your argument about resource constraints compelling. I never did learn to program my 1K ZX81 in assembler. I blew it up before then. Remember how AWFUL the keyboard was? I soldered a joystick from an old space invaders game into the keyboard matrix so I could play games better... but when trying to add more buttons later I dropped the soldering iron on the CPU. Game over. I didn't see assembler until I was at uni... and the moment had passed. But ever since then I've been in awe of people who can do assembler. I would find your argument even more compelling if we were thinking of python as a gateway drug to assembler. If we had an assembler tool-chain shipping along with micropython. I think we, as a bunch of python people, seeing the device through a pythonic lens, for us there maybe an objectively optimal memory range, which I personally think is greater than 3KB.... for python. But if we're part of encouraging a descent into assembler, then I could be convinced that less is more. Cheers, Alan Date: Fri, 2 Oct 2015 23:09:59 +0100 From: david at thinkingbinaries.com To: microbit at python.org Subject: Re: [Microbit-Python] memory error I think it would be useful to have a rough metric or target of the sort of script/size that would be reasonably expected on a platform of this size. It might be that on the whole, all the things that people are writing will basically fit, if some basic good practice in naming and layout is followed. I also think back to the earlier discussion about limited memory on the ZX81, and the fact that I spent most of my working life up until now squeezing lots of functionality into tiny processors with limited resources, and the skills I learnt on my 1K ZX81 were vital to enabling that innovation. The door push on the front of my house has my code in it, it's a commercial product you can buy off the shelf, and it wouldn't have if I didn't cut my teeth on a resource limited platform which forced me to understand how the computer actually worked. I was 11 when I had my ZX81 and I was writing Z80 assembler as a way to make things fit. On the whole it was a really exciting experience for an 11 year old! One of the things to remember is that modern computers (even the Raspberry Pi) mostly allow you to assume infinite resources (or pretty unbounded). The micro:bit is very much an embedded platform, and having a limit on resources causes people to understand that nothing is infinite in this world, and that's a good thing sometimes! So, let's not beat ourselves up about it. As long as a good representative set of engaging and exciting programs can be made to fit, there has to be some limit. And besides - save some work for version 2!!! As an aside, if someone were to develop a toolkit that helped to explain where the memory usage in a given MicroPython program goes to, it would enable users to optimise their programs better themselves and gain a better understanding of how things work. I'm sure Damien is the same, when working on an embedded platform I spend my life in the map file and often in the assembly listings too, to understand where all the precious memory is going to! 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 2 October 2015 at 22:46, Damien George wrote: Yes, variable name length will have a small impact on RAM usage. Yes, as David says, a given variable is only stored once in RAM and then referenced by an index (which is usually 16 bits) so it's relatively efficient. You need to keep the actual name of the variable around so that you can given sensible error messages, and also for lookup of global names in dictionaries. There are definitely things that we can do to improve the memory usage and allow bigger scripts. Do you think it's a priority? On Fri, Oct 2, 2015 at 6:17 PM, David Whale wrote: > I only had a 1K ZX81 and it forced me to learn machine code so I could make > everything fit :) > > I'm *guessing* that MicroPython has a fixup table, so that the variable > names and function names are only stored in RAM once - i.e. each reference > to a function name or variable name in the bytecode is actually an index > into a string table with the actual name in it? Perhaps a one-way hash could > be used to turn any given name into a shorter hash that is actually used for > the lookup? > > Cheers > > D > > > ___________________________________________________________ > 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 2 October 2015 at 18:06, Alan wrote: >> >> Hi, >> >> Am I right in thinking the size of variable names also makes a difference? >> It seemed to, although I didn't test that scientifically. >> >> 3KB is a bit small. I know, however big the memory we'd always want more. >> And I did grow up programming a ZX81, so this is 3 times as big! You'd think >> I'd be happy with that. >> >> Cheers, >> >> Alan >> >> > Date: Fri, 2 Oct 2015 16:07:02 +0100 >> >> > From: damien.p.george at gmail.com >> > To: microbit at python.org >> > Subject: Re: [Microbit-Python] memory error >> > >> > Hi Alan, >> > >> > Yes, doc strings do take up memory, so in our case (when trying to >> > reduce memory usage) it's better to make them comments (which are just >> > skipped over by the tokeniser). >> > >> > The example you give with lots of prints does indeed take up all the >> > memory, so that's why it gives a MemoryError. It's not easy to fix >> > this, the microbit is just really low on RAM! We could compile the >> > python script to flash (instead of RAM) but that needs a bit of effort >> > to get working. >> > >> > Cheers, >> > Damien. >> > >> > >> > On Thu, Oct 1, 2015 at 2:52 AM, Alan wrote: >> > > Hi, >> > > >> > > Another little trick I've realised is that if I put a large, >> > > explanatory >> > > comment at the top of the file using """...""" it of course goes into >> > > a >> > > docstring... which takes up memory! >> > > >> > > If I use # style comments instead, it doesn't seem to take up memory. >> > > >> > > Cheers, >> > > >> > > Alan >> > > >> > > ________________________________ >> > > From: alainjackson at hotmail.com >> > > To: microbit at python.org >> > > Date: Thu, 1 Oct 2015 00:32:14 +0000 >> > > >> > > Subject: Re: [Microbit-Python] memory error >> > > >> > > Hi, >> > > >> > > I didn't save the version of my code that got the memory error. >> > > >> > > But I've just now created a small, pathological example. >> > > >> > > The code below, which is 3kB on the disk, will create the following >> > > error: >> > > >> > >>>> MemoryError: >> > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with nRF51822 >> > > Type "help()" for more information. >> > > >> > > But if you delete the last line, it will run fine. >> > > >> > > >> > > >> > > >> > > """ >> > > Testing how much memory for python code the microbit has. >> > > """ >> > > >> > > from microbit import * >> > > >> > > >> > > >> > > >> > > >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") >> > > >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") >> > > >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") >> > > >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") >> > > >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> > > >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> > > >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") >> > > >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") >> > > >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") >> > > >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") >> > > >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") >> > > >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") >> > > >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") >> > > >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") >> > > >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> > > >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> > > >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") >> > > >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") >> > > >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") >> > > >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") >> > > >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") >> > > >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") >> > > >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") >> > > >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") >> > > >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> > > >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> > > >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 >> > >> From: damien.p.george at gmail.com >> > >> To: microbit at python.org >> > >> Subject: Re: [Microbit-Python] memory error >> > >> >> > >> Hi Alan, >> > >> >> > >> Can you post your code? >> > >> >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan >> > >> wrote: >> > >> > Hi, >> > >> > >> > >> > How much memory does the Microbit have for a python program? >> > >> > >> > >> > I've written a small program about 105 lines long. It's 3kB on my >> > >> > hard >> > >> > disk. >> > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept >> > >> > getting >> > >> > memory allocation errors as soon as I pressed the reset button. If >> > >> > I >> > >> > commented about 10 lines out of my program it would run and it >> > >> > didn't >> > >> > seem >> > >> > to matter which 10 lines. So I assumed it was out of program >> > >> > memory? >> > >> > >> > >> > Cheers, >> > >> > >> > >> > Alan >> > >> > >> > >> > _______________________________________________ >> > >> > 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 >> > > >> > > _______________________________________________ >> > > 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 >> > > > _______________________________________________ > 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: From david at thinkingbinaries.com Sat Oct 3 08:41:20 2015 From: david at thinkingbinaries.com (David Whale) Date: Sat, 3 Oct 2015 07:41:20 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: :) My point was less about machine code, and more about "if resources are limited, additional learning takes place". I learnt a lot about how the computer worked, by finding other ways to make my programs fit. I'm not suggesting every 11 year old would be interested in breaking beyond the memory restrictions, some will, some won't. I think as long as we have a view on "what a reasonable sized program is for most users", it will still be a great experience. My follow on point was to not break our backs getting the last byte out of the memory, but something that maps out the memory usage would encourage those persistent souls who want to. That would be far less work than squeezing the last few bytes out of the language design, and possibly a self contained task that someone else could do to one side. Cheers 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 3 October 2015 at 00:02, Alan wrote: > Hi David, > > I find your argument about resource constraints compelling. > > I never did learn to program my 1K ZX81 in assembler. I blew it up before > then. > > Remember how AWFUL the keyboard was? I soldered a joystick from an old > space invaders game into the keyboard matrix so I could play games > better... but when trying to add more buttons later I dropped the soldering > iron on the CPU. Game over. > > I didn't see assembler until I was at uni... and the moment had passed. > But ever since then I've been in awe of people who can do assembler. > > I would find your argument even more compelling if we were thinking of > python as a gateway drug to assembler. If we had an assembler tool-chain > shipping along with micropython. > > I think we, as a bunch of python people, seeing the device through a > pythonic lens, for us there maybe an objectively optimal memory range, > which I personally think is greater than 3KB.... for python. > > But if we're part of encouraging a descent into assembler, then I could be > convinced that less is more. > > Cheers, > > Alan > > > ------------------------------ > Date: Fri, 2 Oct 2015 23:09:59 +0100 > From: david at thinkingbinaries.com > > To: microbit at python.org > Subject: Re: [Microbit-Python] memory error > > I think it would be useful to have a rough metric or target of the sort of > script/size that would be reasonably expected on a platform of this size. > It might be that on the whole, all the things that people are writing will > basically fit, if some basic good practice in naming and layout is followed. > > I also think back to the earlier discussion about limited memory on the > ZX81, and the fact that I spent most of my working life up until now > squeezing lots of functionality into tiny processors with limited > resources, and the skills I learnt on my 1K ZX81 were vital to enabling > that innovation. The door push on the front of my house has my code in it, > it's a commercial product you can buy off the shelf, and it wouldn't have > if I didn't cut my teeth on a resource limited platform which forced me to > understand how the computer actually worked. I was 11 when I had my ZX81 > and I was writing Z80 assembler as a way to make things fit. On the whole > it was a really exciting experience for an 11 year old! > > > One of the things to remember is that modern computers (even the Raspberry > Pi) mostly allow you to assume infinite resources (or pretty unbounded). > The micro:bit is very much an embedded platform, and having a limit on > resources causes people to understand that nothing is infinite in this > world, and that's a good thing sometimes! > > So, let's not beat ourselves up about it. As long as a good representative > set of engaging and exciting programs can be made to fit, there has to be > some limit. And besides - save some work for version 2!!! > > As an aside, if someone were to develop a toolkit that helped to explain > where the memory usage in a given MicroPython program goes to, it would > enable users to optimise their programs better themselves and gain a better > understanding of how things work. I'm sure Damien is the same, when working > on an embedded platform I spend my life in the map file and often in the > assembly listings too, to understand where all the precious memory is going > to! > > 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 2 October 2015 at 22:46, Damien George > wrote: > > Yes, variable name length will have a small impact on RAM usage. > > Yes, as David says, a given variable is only stored once in RAM and > then referenced by an index (which is usually 16 bits) so it's > relatively efficient. You need to keep the actual name of the > variable around so that you can given sensible error messages, and > also for lookup of global names in dictionaries. > > There are definitely things that we can do to improve the memory usage > and allow bigger scripts. Do you think it's a priority? > > On Fri, Oct 2, 2015 at 6:17 PM, David Whale > wrote: > > I only had a 1K ZX81 and it forced me to learn machine code so I could > make > > everything fit :) > > > > I'm *guessing* that MicroPython has a fixup table, so that the variable > > names and function names are only stored in RAM once - i.e. each > reference > > to a function name or variable name in the bytecode is actually an index > > into a string table with the actual name in it? Perhaps a one-way hash > could > > be used to turn any given name into a shorter hash that is actually used > for > > the lookup? > > > > Cheers > > > > D > > > > > > ___________________________________________________________ > > 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 2 October 2015 at 18:06, Alan wrote: > >> > >> Hi, > >> > >> Am I right in thinking the size of variable names also makes a > difference? > >> It seemed to, although I didn't test that scientifically. > >> > >> 3KB is a bit small. I know, however big the memory we'd always want > more. > >> And I did grow up programming a ZX81, so this is 3 times as big! You'd > think > >> I'd be happy with that. > >> > >> Cheers, > >> > >> Alan > >> > >> > Date: Fri, 2 Oct 2015 16:07:02 +0100 > >> > >> > From: damien.p.george at gmail.com > >> > To: microbit at python.org > >> > Subject: Re: [Microbit-Python] memory error > >> > > >> > Hi Alan, > >> > > >> > Yes, doc strings do take up memory, so in our case (when trying to > >> > reduce memory usage) it's better to make them comments (which are just > >> > skipped over by the tokeniser). > >> > > >> > The example you give with lots of prints does indeed take up all the > >> > memory, so that's why it gives a MemoryError. It's not easy to fix > >> > this, the microbit is just really low on RAM! We could compile the > >> > python script to flash (instead of RAM) but that needs a bit of effort > >> > to get working. > >> > > >> > Cheers, > >> > Damien. > >> > > >> > > >> > On Thu, Oct 1, 2015 at 2:52 AM, Alan > wrote: > >> > > Hi, > >> > > > >> > > Another little trick I've realised is that if I put a large, > >> > > explanatory > >> > > comment at the top of the file using """...""" it of course goes > into > >> > > a > >> > > docstring... which takes up memory! > >> > > > >> > > If I use # style comments instead, it doesn't seem to take up > memory. > >> > > > >> > > Cheers, > >> > > > >> > > Alan > >> > > > >> > > ________________________________ > >> > > From: alainjackson at hotmail.com > >> > > To: microbit at python.org > >> > > Date: Thu, 1 Oct 2015 00:32:14 +0000 > >> > > > >> > > Subject: Re: [Microbit-Python] memory error > >> > > > >> > > Hi, > >> > > > >> > > I didn't save the version of my code that got the memory error. > >> > > > >> > > But I've just now created a small, pathological example. > >> > > > >> > > The code below, which is 3kB on the disk, will create the following > >> > > error: > >> > > > >> > >>>> MemoryError: > >> > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with > nRF51822 > >> > > Type "help()" for more information. > >> > > > >> > > But if you delete the last line, it will run fine. > >> > > > >> > > > >> > > > >> > > > >> > > """ > >> > > Testing how much memory for python code the microbit has. > >> > > """ > >> > > > >> > > from microbit import * > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> > > > >> > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> > > > >> > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> > > > >> > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> > > > >> > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> > > > >> > > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > >> > > > >> > > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > >> > > > >> > > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > >> > > > >> > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> > > > >> > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> > > > >> > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> > > > >> > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> > > > >> > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> > > > >> > > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > >> > > > >> > > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > >> > > > >> > > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > >> > > > >> > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> > > > >> > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> > > > >> > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> > > > >> > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> > > > >> > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> > > > >> > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 > >> > >> From: damien.p.george at gmail.com > >> > >> To: microbit at python.org > >> > >> Subject: Re: [Microbit-Python] memory error > >> > >> > >> > >> Hi Alan, > >> > >> > >> > >> Can you post your code? > >> > >> > >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan > >> > >> wrote: > >> > >> > Hi, > >> > >> > > >> > >> > How much memory does the Microbit have for a python program? > >> > >> > > >> > >> > I've written a small program about 105 lines long. It's 3kB on my > >> > >> > hard > >> > >> > disk. > >> > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept > >> > >> > getting > >> > >> > memory allocation errors as soon as I pressed the reset button. > If > >> > >> > I > >> > >> > commented about 10 lines out of my program it would run and it > >> > >> > didn't > >> > >> > seem > >> > >> > to matter which 10 lines. So I assumed it was out of program > >> > >> > memory? > >> > >> > > >> > >> > Cheers, > >> > >> > > >> > >> > Alan > >> > >> > > >> > >> > _______________________________________________ > >> > >> > 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 > >> > > > >> > > _______________________________________________ > >> > > 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 > >> > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Sat Oct 3 18:20:07 2015 From: damien.p.george at gmail.com (Damien George) Date: Sat, 3 Oct 2015 17:20:07 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: Yes, I think that at the moment 3kb is too limiting for maximum script size. I honestly didn't think people would be writing such complex programs, but agree that it would be very annoying if your efforts coding all day lead only to out of memory errors. If we can cater for the more advanced coders and provide more memory for scripts, then we should. And I have some ideas (inspired by David) of how to do it and might be able to get close to 10kb for maximum script. I'll keep you posted! Regarding assembler: actually MicroPython does include an inline assembler! But it's not enabled for the microbit. I was thinking of enabling it but it does take a bit of room (around 6500 bytes of flash). One cute option is to simply create a function that turns a byte string into a callable assembler function. Eg: fun = microbit.assembler(num_args=3, code=b'\x12\x34\x56') fun(1, 2, 3) Then you can write your assembly function in hex (!!) and do arbitrary things with the device. Regarding David's point about resource contraints leading to learning. I totally agree! Even if in the case of MicroPython you're not learning about stacks and pointers, you are learning that making a list takes memory, and higher level things like that. Even writing Python on your PC you sometimes need to think about how resource intensive it is and how to make it more efficient (eg use a better algorithm). On Sat, Oct 3, 2015 at 7:41 AM, David Whale wrote: > :) > > My point was less about machine code, and more about "if resources are > limited, additional learning takes place". I learnt a lot about how the > computer worked, by finding other ways to make my programs fit. > > I'm not suggesting every 11 year old would be interested in breaking beyond > the memory restrictions, some will, some won't. I think as long as we have a > view on "what a reasonable sized program is for most users", it will still > be a great experience. > > My follow on point was to not break our backs getting the last byte out of > the memory, but something that maps out the memory usage would encourage > those persistent souls who want to. That would be far less work than > squeezing the last few bytes out of the language design, and possibly a self > contained task that someone else could do to one side. > > Cheers > > 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 3 October 2015 at 00:02, Alan wrote: >> >> Hi David, >> >> I find your argument about resource constraints compelling. >> >> I never did learn to program my 1K ZX81 in assembler. I blew it up before >> then. >> >> Remember how AWFUL the keyboard was? I soldered a joystick from an old >> space invaders game into the keyboard matrix so I could play games better... >> but when trying to add more buttons later I dropped the soldering iron on >> the CPU. Game over. >> >> I didn't see assembler until I was at uni... and the moment had passed. >> But ever since then I've been in awe of people who can do assembler. >> >> I would find your argument even more compelling if we were thinking of >> python as a gateway drug to assembler. If we had an assembler tool-chain >> shipping along with micropython. >> >> I think we, as a bunch of python people, seeing the device through a >> pythonic lens, for us there maybe an objectively optimal memory range, which >> I personally think is greater than 3KB.... for python. >> >> But if we're part of encouraging a descent into assembler, then I could be >> convinced that less is more. >> >> Cheers, >> >> Alan >> >> >> ________________________________ >> Date: Fri, 2 Oct 2015 23:09:59 +0100 >> From: david at thinkingbinaries.com >> >> To: microbit at python.org >> Subject: Re: [Microbit-Python] memory error >> >> I think it would be useful to have a rough metric or target of the sort of >> script/size that would be reasonably expected on a platform of this size. It >> might be that on the whole, all the things that people are writing will >> basically fit, if some basic good practice in naming and layout is followed. >> >> I also think back to the earlier discussion about limited memory on the >> ZX81, and the fact that I spent most of my working life up until now >> squeezing lots of functionality into tiny processors with limited resources, >> and the skills I learnt on my 1K ZX81 were vital to enabling that >> innovation. The door push on the front of my house has my code in it, it's a >> commercial product you can buy off the shelf, and it wouldn't have if I >> didn't cut my teeth on a resource limited platform which forced me to >> understand how the computer actually worked. I was 11 when I had my ZX81 and >> I was writing Z80 assembler as a way to make things fit. On the whole it was >> a really exciting experience for an 11 year old! >> >> >> One of the things to remember is that modern computers (even the Raspberry >> Pi) mostly allow you to assume infinite resources (or pretty unbounded). The >> micro:bit is very much an embedded platform, and having a limit on resources >> causes people to understand that nothing is infinite in this world, and >> that's a good thing sometimes! >> >> So, let's not beat ourselves up about it. As long as a good representative >> set of engaging and exciting programs can be made to fit, there has to be >> some limit. And besides - save some work for version 2!!! >> >> As an aside, if someone were to develop a toolkit that helped to explain >> where the memory usage in a given MicroPython program goes to, it would >> enable users to optimise their programs better themselves and gain a better >> understanding of how things work. I'm sure Damien is the same, when working >> on an embedded platform I spend my life in the map file and often in the >> assembly listings too, to understand where all the precious memory is going >> to! >> >> 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 2 October 2015 at 22:46, Damien George >> wrote: >> >> Yes, variable name length will have a small impact on RAM usage. >> >> Yes, as David says, a given variable is only stored once in RAM and >> then referenced by an index (which is usually 16 bits) so it's >> relatively efficient. You need to keep the actual name of the >> variable around so that you can given sensible error messages, and >> also for lookup of global names in dictionaries. >> >> There are definitely things that we can do to improve the memory usage >> and allow bigger scripts. Do you think it's a priority? >> >> On Fri, Oct 2, 2015 at 6:17 PM, David Whale >> wrote: >> > I only had a 1K ZX81 and it forced me to learn machine code so I could >> > make >> > everything fit :) >> > >> > I'm *guessing* that MicroPython has a fixup table, so that the variable >> > names and function names are only stored in RAM once - i.e. each >> > reference >> > to a function name or variable name in the bytecode is actually an index >> > into a string table with the actual name in it? Perhaps a one-way hash >> > could >> > be used to turn any given name into a shorter hash that is actually used >> > for >> > the lookup? >> > >> > Cheers >> > >> > D >> > >> > >> > ___________________________________________________________ >> > 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 2 October 2015 at 18:06, Alan wrote: >> >> >> >> Hi, >> >> >> >> Am I right in thinking the size of variable names also makes a >> >> difference? >> >> It seemed to, although I didn't test that scientifically. >> >> >> >> 3KB is a bit small. I know, however big the memory we'd always want >> >> more. >> >> And I did grow up programming a ZX81, so this is 3 times as big! You'd >> >> think >> >> I'd be happy with that. >> >> >> >> Cheers, >> >> >> >> Alan >> >> >> >> > Date: Fri, 2 Oct 2015 16:07:02 +0100 >> >> >> >> > From: damien.p.george at gmail.com >> >> > To: microbit at python.org >> >> > Subject: Re: [Microbit-Python] memory error >> >> > >> >> > Hi Alan, >> >> > >> >> > Yes, doc strings do take up memory, so in our case (when trying to >> >> > reduce memory usage) it's better to make them comments (which are >> >> > just >> >> > skipped over by the tokeniser). >> >> > >> >> > The example you give with lots of prints does indeed take up all the >> >> > memory, so that's why it gives a MemoryError. It's not easy to fix >> >> > this, the microbit is just really low on RAM! We could compile the >> >> > python script to flash (instead of RAM) but that needs a bit of >> >> > effort >> >> > to get working. >> >> > >> >> > Cheers, >> >> > Damien. >> >> > >> >> > >> >> > On Thu, Oct 1, 2015 at 2:52 AM, Alan >> >> > wrote: >> >> > > Hi, >> >> > > >> >> > > Another little trick I've realised is that if I put a large, >> >> > > explanatory >> >> > > comment at the top of the file using """...""" it of course goes >> >> > > into >> >> > > a >> >> > > docstring... which takes up memory! >> >> > > >> >> > > If I use # style comments instead, it doesn't seem to take up >> >> > > memory. >> >> > > >> >> > > Cheers, >> >> > > >> >> > > Alan >> >> > > >> >> > > ________________________________ >> >> > > From: alainjackson at hotmail.com >> >> > > To: microbit at python.org >> >> > > Date: Thu, 1 Oct 2015 00:32:14 +0000 >> >> > > >> >> > > Subject: Re: [Microbit-Python] memory error >> >> > > >> >> > > Hi, >> >> > > >> >> > > I didn't save the version of my code that got the memory error. >> >> > > >> >> > > But I've just now created a small, pathological example. >> >> > > >> >> > > The code below, which is 3kB on the disk, will create the following >> >> > > error: >> >> > > >> >> > >>>> MemoryError: >> >> > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with >> >> > > nRF51822 >> >> > > Type "help()" for more information. >> >> > > >> >> > > But if you delete the last line, it will run fine. >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > """ >> >> > > Testing how much memory for python code the microbit has. >> >> > > """ >> >> > > >> >> > > from microbit import * >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") >> >> > > >> >> > > >> >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") >> >> > > >> >> > > >> >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") >> >> > > >> >> > > >> >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") >> >> > > >> >> > > >> >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> >> > > >> >> > > >> >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> >> > > >> >> > > >> >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") >> >> > > >> >> > > >> >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") >> >> > > >> >> > > >> >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") >> >> > > >> >> > > >> >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") >> >> > > >> >> > > >> >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") >> >> > > >> >> > > >> >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") >> >> > > >> >> > > >> >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") >> >> > > >> >> > > >> >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") >> >> > > >> >> > > >> >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> >> > > >> >> > > >> >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> >> > > >> >> > > >> >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") >> >> > > >> >> > > >> >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") >> >> > > >> >> > > >> >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") >> >> > > >> >> > > >> >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") >> >> > > >> >> > > >> >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") >> >> > > >> >> > > >> >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") >> >> > > >> >> > > >> >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") >> >> > > >> >> > > >> >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") >> >> > > >> >> > > >> >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> >> > > >> >> > > >> >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") >> >> > > >> >> > > >> >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 >> >> > >> From: damien.p.george at gmail.com >> >> > >> To: microbit at python.org >> >> > >> Subject: Re: [Microbit-Python] memory error >> >> > >> >> >> > >> Hi Alan, >> >> > >> >> >> > >> Can you post your code? >> >> > >> >> >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan >> >> > >> wrote: >> >> > >> > Hi, >> >> > >> > >> >> > >> > How much memory does the Microbit have for a python program? >> >> > >> > >> >> > >> > I've written a small program about 105 lines long. It's 3kB on >> >> > >> > my >> >> > >> > hard >> >> > >> > disk. >> >> > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept >> >> > >> > getting >> >> > >> > memory allocation errors as soon as I pressed the reset button. >> >> > >> > If >> >> > >> > I >> >> > >> > commented about 10 lines out of my program it would run and it >> >> > >> > didn't >> >> > >> > seem >> >> > >> > to matter which 10 lines. So I assumed it was out of program >> >> > >> > memory? >> >> > >> > >> >> > >> > Cheers, >> >> > >> > >> >> > >> > Alan >> >> > >> > >> >> > >> > _______________________________________________ >> >> > >> > 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 >> >> > > >> >> > > _______________________________________________ >> >> > > 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 >> >> >> > >> > >> > _______________________________________________ >> > 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 >> >> _______________________________________________ >> 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 > From david at thinkingbinaries.com Sat Oct 3 18:26:04 2015 From: david at thinkingbinaries.com (David Whale) Date: Sat, 3 Oct 2015 17:26:04 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: oooo! Inline Assembler! Tell Howard about that - he remembers the inline assembler on the original BBC Micro! Actually, my 11 year old coding exploits were in *machine code* not *assembler* - there was no assembler on the ZX81, I had to look the instructions up in the index of the manual, construct the operands myself, and poke each instruction in by hand and then jump to it! A good trick on my 1K ZX81 was to use only the left half of the screen, because the screen was dynamically sized, using less screen space meant more program space - I wrote a machine code asteroids that worked on the left hand side of the screen in only 1K. Good work, Damien! 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 3 October 2015 at 17:20, Damien George wrote: > Yes, I think that at the moment 3kb is too limiting for maximum script > size. I honestly didn't think people would be writing such complex > programs, but agree that it would be very annoying if your efforts > coding all day lead only to out of memory errors. > > If we can cater for the more advanced coders and provide more memory > for scripts, then we should. And I have some ideas (inspired by > David) of how to do it and might be able to get close to 10kb for > maximum script. I'll keep you posted! > > Regarding assembler: actually MicroPython does include an inline > assembler! But it's not enabled for the microbit. I was thinking of > enabling it but it does take a bit of room (around 6500 bytes of > flash). One cute option is to simply create a function that turns a > byte string into a callable assembler function. Eg: > > fun = microbit.assembler(num_args=3, code=b'\x12\x34\x56') > fun(1, 2, 3) > > Then you can write your assembly function in hex (!!) and do arbitrary > things with the device. > > Regarding David's point about resource contraints leading to learning. > I totally agree! Even if in the case of MicroPython you're not > learning about stacks and pointers, you are learning that making a > list takes memory, and higher level things like that. Even writing > Python on your PC you sometimes need to think about how resource > intensive it is and how to make it more efficient (eg use a better > algorithm). > > > On Sat, Oct 3, 2015 at 7:41 AM, David Whale > wrote: > > :) > > > > My point was less about machine code, and more about "if resources are > > limited, additional learning takes place". I learnt a lot about how the > > computer worked, by finding other ways to make my programs fit. > > > > I'm not suggesting every 11 year old would be interested in breaking > beyond > > the memory restrictions, some will, some won't. I think as long as we > have a > > view on "what a reasonable sized program is for most users", it will > still > > be a great experience. > > > > My follow on point was to not break our backs getting the last byte out > of > > the memory, but something that maps out the memory usage would encourage > > those persistent souls who want to. That would be far less work than > > squeezing the last few bytes out of the language design, and possibly a > self > > contained task that someone else could do to one side. > > > > Cheers > > > > 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 3 October 2015 at 00:02, Alan wrote: > >> > >> Hi David, > >> > >> I find your argument about resource constraints compelling. > >> > >> I never did learn to program my 1K ZX81 in assembler. I blew it up > before > >> then. > >> > >> Remember how AWFUL the keyboard was? I soldered a joystick from an old > >> space invaders game into the keyboard matrix so I could play games > better... > >> but when trying to add more buttons later I dropped the soldering iron > on > >> the CPU. Game over. > >> > >> I didn't see assembler until I was at uni... and the moment had passed. > >> But ever since then I've been in awe of people who can do assembler. > >> > >> I would find your argument even more compelling if we were thinking of > >> python as a gateway drug to assembler. If we had an assembler tool-chain > >> shipping along with micropython. > >> > >> I think we, as a bunch of python people, seeing the device through a > >> pythonic lens, for us there maybe an objectively optimal memory range, > which > >> I personally think is greater than 3KB.... for python. > >> > >> But if we're part of encouraging a descent into assembler, then I could > be > >> convinced that less is more. > >> > >> Cheers, > >> > >> Alan > >> > >> > >> ________________________________ > >> Date: Fri, 2 Oct 2015 23:09:59 +0100 > >> From: david at thinkingbinaries.com > >> > >> To: microbit at python.org > >> Subject: Re: [Microbit-Python] memory error > >> > >> I think it would be useful to have a rough metric or target of the sort > of > >> script/size that would be reasonably expected on a platform of this > size. It > >> might be that on the whole, all the things that people are writing will > >> basically fit, if some basic good practice in naming and layout is > followed. > >> > >> I also think back to the earlier discussion about limited memory on the > >> ZX81, and the fact that I spent most of my working life up until now > >> squeezing lots of functionality into tiny processors with limited > resources, > >> and the skills I learnt on my 1K ZX81 were vital to enabling that > >> innovation. The door push on the front of my house has my code in it, > it's a > >> commercial product you can buy off the shelf, and it wouldn't have if I > >> didn't cut my teeth on a resource limited platform which forced me to > >> understand how the computer actually worked. I was 11 when I had my > ZX81 and > >> I was writing Z80 assembler as a way to make things fit. On the whole > it was > >> a really exciting experience for an 11 year old! > >> > >> > >> One of the things to remember is that modern computers (even the > Raspberry > >> Pi) mostly allow you to assume infinite resources (or pretty > unbounded). The > >> micro:bit is very much an embedded platform, and having a limit on > resources > >> causes people to understand that nothing is infinite in this world, and > >> that's a good thing sometimes! > >> > >> So, let's not beat ourselves up about it. As long as a good > representative > >> set of engaging and exciting programs can be made to fit, there has to > be > >> some limit. And besides - save some work for version 2!!! > >> > >> As an aside, if someone were to develop a toolkit that helped to explain > >> where the memory usage in a given MicroPython program goes to, it would > >> enable users to optimise their programs better themselves and gain a > better > >> understanding of how things work. I'm sure Damien is the same, when > working > >> on an embedded platform I spend my life in the map file and often in the > >> assembly listings too, to understand where all the precious memory is > going > >> to! > >> > >> 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 2 October 2015 at 22:46, Damien George > >> wrote: > >> > >> Yes, variable name length will have a small impact on RAM usage. > >> > >> Yes, as David says, a given variable is only stored once in RAM and > >> then referenced by an index (which is usually 16 bits) so it's > >> relatively efficient. You need to keep the actual name of the > >> variable around so that you can given sensible error messages, and > >> also for lookup of global names in dictionaries. > >> > >> There are definitely things that we can do to improve the memory usage > >> and allow bigger scripts. Do you think it's a priority? > >> > >> On Fri, Oct 2, 2015 at 6:17 PM, David Whale > > >> wrote: > >> > I only had a 1K ZX81 and it forced me to learn machine code so I could > >> > make > >> > everything fit :) > >> > > >> > I'm *guessing* that MicroPython has a fixup table, so that the > variable > >> > names and function names are only stored in RAM once - i.e. each > >> > reference > >> > to a function name or variable name in the bytecode is actually an > index > >> > into a string table with the actual name in it? Perhaps a one-way hash > >> > could > >> > be used to turn any given name into a shorter hash that is actually > used > >> > for > >> > the lookup? > >> > > >> > Cheers > >> > > >> > D > >> > > >> > > >> > ___________________________________________________________ > >> > 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 2 October 2015 at 18:06, Alan wrote: > >> >> > >> >> Hi, > >> >> > >> >> Am I right in thinking the size of variable names also makes a > >> >> difference? > >> >> It seemed to, although I didn't test that scientifically. > >> >> > >> >> 3KB is a bit small. I know, however big the memory we'd always want > >> >> more. > >> >> And I did grow up programming a ZX81, so this is 3 times as big! > You'd > >> >> think > >> >> I'd be happy with that. > >> >> > >> >> Cheers, > >> >> > >> >> Alan > >> >> > >> >> > Date: Fri, 2 Oct 2015 16:07:02 +0100 > >> >> > >> >> > From: damien.p.george at gmail.com > >> >> > To: microbit at python.org > >> >> > Subject: Re: [Microbit-Python] memory error > >> >> > > >> >> > Hi Alan, > >> >> > > >> >> > Yes, doc strings do take up memory, so in our case (when trying to > >> >> > reduce memory usage) it's better to make them comments (which are > >> >> > just > >> >> > skipped over by the tokeniser). > >> >> > > >> >> > The example you give with lots of prints does indeed take up all > the > >> >> > memory, so that's why it gives a MemoryError. It's not easy to fix > >> >> > this, the microbit is just really low on RAM! We could compile the > >> >> > python script to flash (instead of RAM) but that needs a bit of > >> >> > effort > >> >> > to get working. > >> >> > > >> >> > Cheers, > >> >> > Damien. > >> >> > > >> >> > > >> >> > On Thu, Oct 1, 2015 at 2:52 AM, Alan > >> >> > wrote: > >> >> > > Hi, > >> >> > > > >> >> > > Another little trick I've realised is that if I put a large, > >> >> > > explanatory > >> >> > > comment at the top of the file using """...""" it of course goes > >> >> > > into > >> >> > > a > >> >> > > docstring... which takes up memory! > >> >> > > > >> >> > > If I use # style comments instead, it doesn't seem to take up > >> >> > > memory. > >> >> > > > >> >> > > Cheers, > >> >> > > > >> >> > > Alan > >> >> > > > >> >> > > ________________________________ > >> >> > > From: alainjackson at hotmail.com > >> >> > > To: microbit at python.org > >> >> > > Date: Thu, 1 Oct 2015 00:32:14 +0000 > >> >> > > > >> >> > > Subject: Re: [Microbit-Python] memory error > >> >> > > > >> >> > > Hi, > >> >> > > > >> >> > > I didn't save the version of my code that got the memory error. > >> >> > > > >> >> > > But I've just now created a small, pathological example. > >> >> > > > >> >> > > The code below, which is 3kB on the disk, will create the > following > >> >> > > error: > >> >> > > > >> >> > >>>> MemoryError: > >> >> > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with > >> >> > > nRF51822 > >> >> > > Type "help()" for more information. > >> >> > > > >> >> > > But if you delete the last line, it will run fine. > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > """ > >> >> > > Testing how much memory for python code the microbit has. > >> >> > > """ > >> >> > > > >> >> > > from microbit import * > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> >> > > > >> >> > > > >> >> > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> >> > > > >> >> > > > >> >> > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> >> > > > >> >> > > > >> >> > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> >> > > > >> >> > > > >> >> > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> >> > > > >> >> > > > >> >> > > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > >> >> > > > >> >> > > > >> >> > > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > >> >> > > > >> >> > > > >> >> > > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > >> >> > > > >> >> > > > >> >> > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> >> > > > >> >> > > > >> >> > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> >> > > > >> >> > > > >> >> > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> >> > > > >> >> > > > >> >> > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> >> > > > >> >> > > > >> >> > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> >> > > > >> >> > > > >> >> > > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > >> >> > > > >> >> > > > >> >> > > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > >> >> > > > >> >> > > > >> >> > > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > >> >> > > > >> >> > > > >> >> > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> >> > > > >> >> > > > >> >> > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> >> > > > >> >> > > > >> >> > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> >> > > > >> >> > > > >> >> > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> >> > > > >> >> > > > >> >> > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 > >> >> > >> From: damien.p.george at gmail.com > >> >> > >> To: microbit at python.org > >> >> > >> Subject: Re: [Microbit-Python] memory error > >> >> > >> > >> >> > >> Hi Alan, > >> >> > >> > >> >> > >> Can you post your code? > >> >> > >> > >> >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan > > >> >> > >> wrote: > >> >> > >> > Hi, > >> >> > >> > > >> >> > >> > How much memory does the Microbit have for a python program? > >> >> > >> > > >> >> > >> > I've written a small program about 105 lines long. It's 3kB on > >> >> > >> > my > >> >> > >> > hard > >> >> > >> > disk. > >> >> > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept > >> >> > >> > getting > >> >> > >> > memory allocation errors as soon as I pressed the reset > button. > >> >> > >> > If > >> >> > >> > I > >> >> > >> > commented about 10 lines out of my program it would run and it > >> >> > >> > didn't > >> >> > >> > seem > >> >> > >> > to matter which 10 lines. So I assumed it was out of program > >> >> > >> > memory? > >> >> > >> > > >> >> > >> > Cheers, > >> >> > >> > > >> >> > >> > Alan > >> >> > >> > > >> >> > >> > _______________________________________________ > >> >> > >> > 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 > >> >> > > > >> >> > > _______________________________________________ > >> >> > > 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 > >> >> > >> > > >> > > >> > _______________________________________________ > >> > 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 > >> > >> _______________________________________________ > >> 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: From alainjackson at hotmail.com Sat Oct 3 22:28:35 2015 From: alainjackson at hotmail.com (Alan) Date: Sat, 3 Oct 2015 20:28:35 +0000 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , <56013703.80902@hastings.org>, , <56014B5B.40606@hastings.org>, , <56016A83.10202@hastings.org>, , , , , , , <5603F7DD.1030407@hastings.org>, , , , , , , , , , , , , Message-ID: Hi Damien, 10KB, that sounds really good, you can do quite a lot of damage in 10KB. And microbit.assembler(...). Wow that is just insanely exciting! That's like some crazy Easter egg in itself. That's the kind of function you want minimal documentation for :) Cheers, Alan > Date: Sat, 3 Oct 2015 17:20:07 +0100 > From: damien.p.george at gmail.com > To: microbit at python.org > Subject: Re: [Microbit-Python] memory error > > Yes, I think that at the moment 3kb is too limiting for maximum script > size. I honestly didn't think people would be writing such complex > programs, but agree that it would be very annoying if your efforts > coding all day lead only to out of memory errors. > > If we can cater for the more advanced coders and provide more memory > for scripts, then we should. And I have some ideas (inspired by > David) of how to do it and might be able to get close to 10kb for > maximum script. I'll keep you posted! > > Regarding assembler: actually MicroPython does include an inline > assembler! But it's not enabled for the microbit. I was thinking of > enabling it but it does take a bit of room (around 6500 bytes of > flash). One cute option is to simply create a function that turns a > byte string into a callable assembler function. Eg: > > fun = microbit.assembler(num_args=3, code=b'\x12\x34\x56') > fun(1, 2, 3) > > Then you can write your assembly function in hex (!!) and do arbitrary > things with the device. > > Regarding David's point about resource contraints leading to learning. > I totally agree! Even if in the case of MicroPython you're not > learning about stacks and pointers, you are learning that making a > list takes memory, and higher level things like that. Even writing > Python on your PC you sometimes need to think about how resource > intensive it is and how to make it more efficient (eg use a better > algorithm). > > > On Sat, Oct 3, 2015 at 7:41 AM, David Whale wrote: > > :) > > > > My point was less about machine code, and more about "if resources are > > limited, additional learning takes place". I learnt a lot about how the > > computer worked, by finding other ways to make my programs fit. > > > > I'm not suggesting every 11 year old would be interested in breaking beyond > > the memory restrictions, some will, some won't. I think as long as we have a > > view on "what a reasonable sized program is for most users", it will still > > be a great experience. > > > > My follow on point was to not break our backs getting the last byte out of > > the memory, but something that maps out the memory usage would encourage > > those persistent souls who want to. That would be far less work than > > squeezing the last few bytes out of the language design, and possibly a self > > contained task that someone else could do to one side. > > > > Cheers > > > > 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 3 October 2015 at 00:02, Alan wrote: > >> > >> Hi David, > >> > >> I find your argument about resource constraints compelling. > >> > >> I never did learn to program my 1K ZX81 in assembler. I blew it up before > >> then. > >> > >> Remember how AWFUL the keyboard was? I soldered a joystick from an old > >> space invaders game into the keyboard matrix so I could play games better... > >> but when trying to add more buttons later I dropped the soldering iron on > >> the CPU. Game over. > >> > >> I didn't see assembler until I was at uni... and the moment had passed. > >> But ever since then I've been in awe of people who can do assembler. > >> > >> I would find your argument even more compelling if we were thinking of > >> python as a gateway drug to assembler. If we had an assembler tool-chain > >> shipping along with micropython. > >> > >> I think we, as a bunch of python people, seeing the device through a > >> pythonic lens, for us there maybe an objectively optimal memory range, which > >> I personally think is greater than 3KB.... for python. > >> > >> But if we're part of encouraging a descent into assembler, then I could be > >> convinced that less is more. > >> > >> Cheers, > >> > >> Alan > >> > >> > >> ________________________________ > >> Date: Fri, 2 Oct 2015 23:09:59 +0100 > >> From: david at thinkingbinaries.com > >> > >> To: microbit at python.org > >> Subject: Re: [Microbit-Python] memory error > >> > >> I think it would be useful to have a rough metric or target of the sort of > >> script/size that would be reasonably expected on a platform of this size. It > >> might be that on the whole, all the things that people are writing will > >> basically fit, if some basic good practice in naming and layout is followed. > >> > >> I also think back to the earlier discussion about limited memory on the > >> ZX81, and the fact that I spent most of my working life up until now > >> squeezing lots of functionality into tiny processors with limited resources, > >> and the skills I learnt on my 1K ZX81 were vital to enabling that > >> innovation. The door push on the front of my house has my code in it, it's a > >> commercial product you can buy off the shelf, and it wouldn't have if I > >> didn't cut my teeth on a resource limited platform which forced me to > >> understand how the computer actually worked. I was 11 when I had my ZX81 and > >> I was writing Z80 assembler as a way to make things fit. On the whole it was > >> a really exciting experience for an 11 year old! > >> > >> > >> One of the things to remember is that modern computers (even the Raspberry > >> Pi) mostly allow you to assume infinite resources (or pretty unbounded). The > >> micro:bit is very much an embedded platform, and having a limit on resources > >> causes people to understand that nothing is infinite in this world, and > >> that's a good thing sometimes! > >> > >> So, let's not beat ourselves up about it. As long as a good representative > >> set of engaging and exciting programs can be made to fit, there has to be > >> some limit. And besides - save some work for version 2!!! > >> > >> As an aside, if someone were to develop a toolkit that helped to explain > >> where the memory usage in a given MicroPython program goes to, it would > >> enable users to optimise their programs better themselves and gain a better > >> understanding of how things work. I'm sure Damien is the same, when working > >> on an embedded platform I spend my life in the map file and often in the > >> assembly listings too, to understand where all the precious memory is going > >> to! > >> > >> 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 2 October 2015 at 22:46, Damien George > >> wrote: > >> > >> Yes, variable name length will have a small impact on RAM usage. > >> > >> Yes, as David says, a given variable is only stored once in RAM and > >> then referenced by an index (which is usually 16 bits) so it's > >> relatively efficient. You need to keep the actual name of the > >> variable around so that you can given sensible error messages, and > >> also for lookup of global names in dictionaries. > >> > >> There are definitely things that we can do to improve the memory usage > >> and allow bigger scripts. Do you think it's a priority? > >> > >> On Fri, Oct 2, 2015 at 6:17 PM, David Whale > >> wrote: > >> > I only had a 1K ZX81 and it forced me to learn machine code so I could > >> > make > >> > everything fit :) > >> > > >> > I'm *guessing* that MicroPython has a fixup table, so that the variable > >> > names and function names are only stored in RAM once - i.e. each > >> > reference > >> > to a function name or variable name in the bytecode is actually an index > >> > into a string table with the actual name in it? Perhaps a one-way hash > >> > could > >> > be used to turn any given name into a shorter hash that is actually used > >> > for > >> > the lookup? > >> > > >> > Cheers > >> > > >> > D > >> > > >> > > >> > ___________________________________________________________ > >> > 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 2 October 2015 at 18:06, Alan wrote: > >> >> > >> >> Hi, > >> >> > >> >> Am I right in thinking the size of variable names also makes a > >> >> difference? > >> >> It seemed to, although I didn't test that scientifically. > >> >> > >> >> 3KB is a bit small. I know, however big the memory we'd always want > >> >> more. > >> >> And I did grow up programming a ZX81, so this is 3 times as big! You'd > >> >> think > >> >> I'd be happy with that. > >> >> > >> >> Cheers, > >> >> > >> >> Alan > >> >> > >> >> > Date: Fri, 2 Oct 2015 16:07:02 +0100 > >> >> > >> >> > From: damien.p.george at gmail.com > >> >> > To: microbit at python.org > >> >> > Subject: Re: [Microbit-Python] memory error > >> >> > > >> >> > Hi Alan, > >> >> > > >> >> > Yes, doc strings do take up memory, so in our case (when trying to > >> >> > reduce memory usage) it's better to make them comments (which are > >> >> > just > >> >> > skipped over by the tokeniser). > >> >> > > >> >> > The example you give with lots of prints does indeed take up all the > >> >> > memory, so that's why it gives a MemoryError. It's not easy to fix > >> >> > this, the microbit is just really low on RAM! We could compile the > >> >> > python script to flash (instead of RAM) but that needs a bit of > >> >> > effort > >> >> > to get working. > >> >> > > >> >> > Cheers, > >> >> > Damien. > >> >> > > >> >> > > >> >> > On Thu, Oct 1, 2015 at 2:52 AM, Alan > >> >> > wrote: > >> >> > > Hi, > >> >> > > > >> >> > > Another little trick I've realised is that if I put a large, > >> >> > > explanatory > >> >> > > comment at the top of the file using """...""" it of course goes > >> >> > > into > >> >> > > a > >> >> > > docstring... which takes up memory! > >> >> > > > >> >> > > If I use # style comments instead, it doesn't seem to take up > >> >> > > memory. > >> >> > > > >> >> > > Cheers, > >> >> > > > >> >> > > Alan > >> >> > > > >> >> > > ________________________________ > >> >> > > From: alainjackson at hotmail.com > >> >> > > To: microbit at python.org > >> >> > > Date: Thu, 1 Oct 2015 00:32:14 +0000 > >> >> > > > >> >> > > Subject: Re: [Microbit-Python] memory error > >> >> > > > >> >> > > Hi, > >> >> > > > >> >> > > I didn't save the version of my code that got the memory error. > >> >> > > > >> >> > > But I've just now created a small, pathological example. > >> >> > > > >> >> > > The code below, which is 3kB on the disk, will create the following > >> >> > > error: > >> >> > > > >> >> > >>>> MemoryError: > >> >> > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with > >> >> > > nRF51822 > >> >> > > Type "help()" for more information. > >> >> > > > >> >> > > But if you delete the last line, it will run fine. > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > """ > >> >> > > Testing how much memory for python code the microbit has. > >> >> > > """ > >> >> > > > >> >> > > from microbit import * > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> >> > > > >> >> > > > >> >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> >> > > > >> >> > > > >> >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> >> > > > >> >> > > > >> >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> >> > > > >> >> > > > >> >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> >> > > > >> >> > > > >> >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > >> >> > > > >> >> > > > >> >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > >> >> > > > >> >> > > > >> >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > >> >> > > > >> >> > > > >> >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> >> > > > >> >> > > > >> >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> >> > > > >> >> > > > >> >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> >> > > > >> >> > > > >> >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> >> > > > >> >> > > > >> >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> >> > > > >> >> > > > >> >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > >> >> > > > >> >> > > > >> >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > >> >> > > > >> >> > > > >> >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > >> >> > > > >> >> > > > >> >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> >> > > > >> >> > > > >> >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> >> > > > >> >> > > > >> >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> >> > > > >> >> > > > >> >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> >> > > > >> >> > > > >> >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 > >> >> > >> From: damien.p.george at gmail.com > >> >> > >> To: microbit at python.org > >> >> > >> Subject: Re: [Microbit-Python] memory error > >> >> > >> > >> >> > >> Hi Alan, > >> >> > >> > >> >> > >> Can you post your code? > >> >> > >> > >> >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan > >> >> > >> wrote: > >> >> > >> > Hi, > >> >> > >> > > >> >> > >> > How much memory does the Microbit have for a python program? > >> >> > >> > > >> >> > >> > I've written a small program about 105 lines long. It's 3kB on > >> >> > >> > my > >> >> > >> > hard > >> >> > >> > disk. > >> >> > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept > >> >> > >> > getting > >> >> > >> > memory allocation errors as soon as I pressed the reset button. > >> >> > >> > If > >> >> > >> > I > >> >> > >> > commented about 10 lines out of my program it would run and it > >> >> > >> > didn't > >> >> > >> > seem > >> >> > >> > to matter which 10 lines. So I assumed it was out of program > >> >> > >> > memory? > >> >> > >> > > >> >> > >> > Cheers, > >> >> > >> > > >> >> > >> > Alan > >> >> > >> > > >> >> > >> > _______________________________________________ > >> >> > >> > 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 > >> >> > > > >> >> > > _______________________________________________ > >> >> > > 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 > >> >> > >> > > >> > > >> > _______________________________________________ > >> > 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 > >> > >> _______________________________________________ > >> 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: From alainjackson at hotmail.com Sat Oct 3 22:53:36 2015 From: alainjackson at hotmail.com (Alan) Date: Sat, 3 Oct 2015 20:53:36 +0000 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org>, , , , , , <56013703.80902@hastings.org>, , , , <56014B5B.40606@hastings.org>, , , , <56016A83.10202@hastings.org>, , , , , , , , , , , , , , <5603F7DD.1030407@hastings.org>, , , , , , , , , , , , , , , , , , , , , , , , , , Message-ID: If python on the micro:bit has inline assembler - that is like something you can't get on touch develop or blocky, I'm guessing. All the cool kids will be hanging out in python-land... where they can... what could they do? Drive the accelerometer backwards to make a tiny ultrasonic speaker that mimics bat's echolocation and scares off mosquitoes? Cheers, Alan From: alainjackson at hotmail.com To: microbit at python.org Date: Sat, 3 Oct 2015 20:28:35 +0000 Subject: Re: [Microbit-Python] memory error Hi Damien, 10KB, that sounds really good, you can do quite a lot of damage in 10KB. And microbit.assembler(...). Wow that is just insanely exciting! That's like some crazy Easter egg in itself. That's the kind of function you want minimal documentation for :) Cheers, Alan > Date: Sat, 3 Oct 2015 17:20:07 +0100 > From: damien.p.george at gmail.com > To: microbit at python.org > Subject: Re: [Microbit-Python] memory error > > Yes, I think that at the moment 3kb is too limiting for maximum script > size. I honestly didn't think people would be writing such complex > programs, but agree that it would be very annoying if your efforts > coding all day lead only to out of memory errors. > > If we can cater for the more advanced coders and provide more memory > for scripts, then we should. And I have some ideas (inspired by > David) of how to do it and might be able to get close to 10kb for > maximum script. I'll keep you posted! > > Regarding assembler: actually MicroPython does include an inline > assembler! But it's not enabled for the microbit. I was thinking of > enabling it but it does take a bit of room (around 6500 bytes of > flash). One cute option is to simply create a function that turns a > byte string into a callable assembler function. Eg: > > fun = microbit.assembler(num_args=3, code=b'\x12\x34\x56') > fun(1, 2, 3) > > Then you can write your assembly function in hex (!!) and do arbitrary > things with the device. > > Regarding David's point about resource contraints leading to learning. > I totally agree! Even if in the case of MicroPython you're not > learning about stacks and pointers, you are learning that making a > list takes memory, and higher level things like that. Even writing > Python on your PC you sometimes need to think about how resource > intensive it is and how to make it more efficient (eg use a better > algorithm). > > > On Sat, Oct 3, 2015 at 7:41 AM, David Whale wrote: > > :) > > > > My point was less about machine code, and more about "if resources are > > limited, additional learning takes place". I learnt a lot about how the > > computer worked, by finding other ways to make my programs fit. > > > > I'm not suggesting every 11 year old would be interested in breaking beyond > > the memory restrictions, some will, some won't. I think as long as we have a > > view on "what a reasonable sized program is for most users", it will still > > be a great experience. > > > > My follow on point was to not break our backs getting the last byte out of > > the memory, but something that maps out the memory usage would encourage > > those persistent souls who want to. That would be far less work than > > squeezing the last few bytes out of the language design, and possibly a self > > contained task that someone else could do to one side. > > > > Cheers > > > > 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 3 October 2015 at 00:02, Alan wrote: > >> > >> Hi David, > >> > >> I find your argument about resource constraints compelling. > >> > >> I never did learn to program my 1K ZX81 in assembler. I blew it up before > >> then. > >> > >> Remember how AWFUL the keyboard was? I soldered a joystick from an old > >> space invaders game into the keyboard matrix so I could play games better... > >> but when trying to add more buttons later I dropped the soldering iron on > >> the CPU. Game over. > >> > >> I didn't see assembler until I was at uni... and the moment had passed. > >> But ever since then I've been in awe of people who can do assembler. > >> > >> I would find your argument even more compelling if we were thinking of > >> python as a gateway drug to assembler. If we had an assembler tool-chain > >> shipping along with micropython. > >> > >> I think we, as a bunch of python people, seeing the device through a > >> pythonic lens, for us there maybe an objectively optimal memory range, which > >> I personally think is greater than 3KB.... for python. > >> > >> But if we're part of encouraging a descent into assembler, then I could be > >> convinced that less is more. > >> > >> Cheers, > >> > >> Alan > >> > >> > >> ________________________________ > >> Date: Fri, 2 Oct 2015 23:09:59 +0100 > >> From: david at thinkingbinaries.com > >> > >> To: microbit at python.org > >> Subject: Re: [Microbit-Python] memory error > >> > >> I think it would be useful to have a rough metric or target of the sort of > >> script/size that would be reasonably expected on a platform of this size. It > >> might be that on the whole, all the things that people are writing will > >> basically fit, if some basic good practice in naming and layout is followed. > >> > >> I also think back to the earlier discussion about limited memory on the > >> ZX81, and the fact that I spent most of my working life up until now > >> squeezing lots of functionality into tiny processors with limited resources, > >> and the skills I learnt on my 1K ZX81 were vital to enabling that > >> innovation. The door push on the front of my house has my code in it, it's a > >> commercial product you can buy off the shelf, and it wouldn't have if I > >> didn't cut my teeth on a resource limited platform which forced me to > >> understand how the computer actually worked. I was 11 when I had my ZX81 and > >> I was writing Z80 assembler as a way to make things fit. On the whole it was > >> a really exciting experience for an 11 year old! > >> > >> > >> One of the things to remember is that modern computers (even the Raspberry > >> Pi) mostly allow you to assume infinite resources (or pretty unbounded). The > >> micro:bit is very much an embedded platform, and having a limit on resources > >> causes people to understand that nothing is infinite in this world, and > >> that's a good thing sometimes! > >> > >> So, let's not beat ourselves up about it. As long as a good representative > >> set of engaging and exciting programs can be made to fit, there has to be > >> some limit. And besides - save some work for version 2!!! > >> > >> As an aside, if someone were to develop a toolkit that helped to explain > >> where the memory usage in a given MicroPython program goes to, it would > >> enable users to optimise their programs better themselves and gain a better > >> understanding of how things work. I'm sure Damien is the same, when working > >> on an embedded platform I spend my life in the map file and often in the > >> assembly listings too, to understand where all the precious memory is going > >> to! > >> > >> 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 2 October 2015 at 22:46, Damien George > >> wrote: > >> > >> Yes, variable name length will have a small impact on RAM usage. > >> > >> Yes, as David says, a given variable is only stored once in RAM and > >> then referenced by an index (which is usually 16 bits) so it's > >> relatively efficient. You need to keep the actual name of the > >> variable around so that you can given sensible error messages, and > >> also for lookup of global names in dictionaries. > >> > >> There are definitely things that we can do to improve the memory usage > >> and allow bigger scripts. Do you think it's a priority? > >> > >> On Fri, Oct 2, 2015 at 6:17 PM, David Whale > >> wrote: > >> > I only had a 1K ZX81 and it forced me to learn machine code so I could > >> > make > >> > everything fit :) > >> > > >> > I'm *guessing* that MicroPython has a fixup table, so that the variable > >> > names and function names are only stored in RAM once - i.e. each > >> > reference > >> > to a function name or variable name in the bytecode is actually an index > >> > into a string table with the actual name in it? Perhaps a one-way hash > >> > could > >> > be used to turn any given name into a shorter hash that is actually used > >> > for > >> > the lookup? > >> > > >> > Cheers > >> > > >> > D > >> > > >> > > >> > ___________________________________________________________ > >> > 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 2 October 2015 at 18:06, Alan wrote: > >> >> > >> >> Hi, > >> >> > >> >> Am I right in thinking the size of variable names also makes a > >> >> difference? > >> >> It seemed to, although I didn't test that scientifically. > >> >> > >> >> 3KB is a bit small. I know, however big the memory we'd always want > >> >> more. > >> >> And I did grow up programming a ZX81, so this is 3 times as big! You'd > >> >> think > >> >> I'd be happy with that. > >> >> > >> >> Cheers, > >> >> > >> >> Alan > >> >> > >> >> > Date: Fri, 2 Oct 2015 16:07:02 +0100 > >> >> > >> >> > From: damien.p.george at gmail.com > >> >> > To: microbit at python.org > >> >> > Subject: Re: [Microbit-Python] memory error > >> >> > > >> >> > Hi Alan, > >> >> > > >> >> > Yes, doc strings do take up memory, so in our case (when trying to > >> >> > reduce memory usage) it's better to make them comments (which are > >> >> > just > >> >> > skipped over by the tokeniser). > >> >> > > >> >> > The example you give with lots of prints does indeed take up all the > >> >> > memory, so that's why it gives a MemoryError. It's not easy to fix > >> >> > this, the microbit is just really low on RAM! We could compile the > >> >> > python script to flash (instead of RAM) but that needs a bit of > >> >> > effort > >> >> > to get working. > >> >> > > >> >> > Cheers, > >> >> > Damien. > >> >> > > >> >> > > >> >> > On Thu, Oct 1, 2015 at 2:52 AM, Alan > >> >> > wrote: > >> >> > > Hi, > >> >> > > > >> >> > > Another little trick I've realised is that if I put a large, > >> >> > > explanatory > >> >> > > comment at the top of the file using """...""" it of course goes > >> >> > > into > >> >> > > a > >> >> > > docstring... which takes up memory! > >> >> > > > >> >> > > If I use # style comments instead, it doesn't seem to take up > >> >> > > memory. > >> >> > > > >> >> > > Cheers, > >> >> > > > >> >> > > Alan > >> >> > > > >> >> > > ________________________________ > >> >> > > From: alainjackson at hotmail.com > >> >> > > To: microbit at python.org > >> >> > > Date: Thu, 1 Oct 2015 00:32:14 +0000 > >> >> > > > >> >> > > Subject: Re: [Microbit-Python] memory error > >> >> > > > >> >> > > Hi, > >> >> > > > >> >> > > I didn't save the version of my code that got the memory error. > >> >> > > > >> >> > > But I've just now created a small, pathological example. > >> >> > > > >> >> > > The code below, which is 3kB on the disk, will create the following > >> >> > > error: > >> >> > > > >> >> > >>>> MemoryError: > >> >> > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with > >> >> > > nRF51822 > >> >> > > Type "help()" for more information. > >> >> > > > >> >> > > But if you delete the last line, it will run fine. > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > """ > >> >> > > Testing how much memory for python code the microbit has. > >> >> > > """ > >> >> > > > >> >> > > from microbit import * > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> >> > > > >> >> > > > >> >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> >> > > > >> >> > > > >> >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> >> > > > >> >> > > > >> >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> >> > > > >> >> > > > >> >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> >> > > > >> >> > > > >> >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > >> >> > > > >> >> > > > >> >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > >> >> > > > >> >> > > > >> >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > >> >> > > > >> >> > > > >> >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> >> > > > >> >> > > > >> >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> >> > > > >> >> > > > >> >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> >> > > > >> >> > > > >> >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> >> > > > >> >> > > > >> >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> >> > > > >> >> > > > >> >> > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > >> >> > > > >> >> > > > >> >> > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > >> >> > > > >> >> > > > >> >> > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > >> >> > > > >> >> > > > >> >> > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > >> >> > > > >> >> > > > >> >> > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > >> >> > > > >> >> > > > >> >> > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > >> >> > > > >> >> > > > >> >> > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > >> >> > > > >> >> > > > >> >> > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > >> >> > > > >> >> > > > >> >> > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 > >> >> > >> From: damien.p.george at gmail.com > >> >> > >> To: microbit at python.org > >> >> > >> Subject: Re: [Microbit-Python] memory error > >> >> > >> > >> >> > >> Hi Alan, > >> >> > >> > >> >> > >> Can you post your code? > >> >> > >> > >> >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan > >> >> > >> wrote: > >> >> > >> > Hi, > >> >> > >> > > >> >> > >> > How much memory does the Microbit have for a python program? > >> >> > >> > > >> >> > >> > I've written a small program about 105 lines long. It's 3kB on > >> >> > >> > my > >> >> > >> > hard > >> >> > >> > disk. > >> >> > >> > It runs ok now but when it was 115 lines long and 3.2kB I kept > >> >> > >> > getting > >> >> > >> > memory allocation errors as soon as I pressed the reset button. > >> >> > >> > If > >> >> > >> > I > >> >> > >> > commented about 10 lines out of my program it would run and it > >> >> > >> > didn't > >> >> > >> > seem > >> >> > >> > to matter which 10 lines. So I assumed it was out of program > >> >> > >> > memory? > >> >> > >> > > >> >> > >> > Cheers, > >> >> > >> > > >> >> > >> > Alan > >> >> > >> > > >> >> > >> > _______________________________________________ > >> >> > >> > 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 > >> >> > > > >> >> > > _______________________________________________ > >> >> > > 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 > >> >> > >> > > >> > > >> > _______________________________________________ > >> > 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 > >> > >> _______________________________________________ > >> 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 _______________________________________________ Microbit mailing list Microbit at python.org https://mail.python.org/mailman/listinfo/microbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at thinkingbinaries.com Sun Oct 4 00:58:34 2015 From: david at thinkingbinaries.com (David Whale) Date: Sat, 3 Oct 2015 23:58:34 +0100 Subject: [Microbit-Python] memory error In-Reply-To: References: <5600616A.2000107@ntoll.org> <56013703.80902@hastings.org> <56014B5B.40606@hastings.org> <56016A83.10202@hastings.org> <5603F7DD.1030407@hastings.org> Message-ID: The Apple Mac Plus had some spare memory in the ROMs when they upgraded from 64K to 128K, so they scanned pictures of all the team and stored them in the spare space. Also the inside of the case had signatures of all the key developers in the mould. I knew this, because I took the back off mine to upgrade the RAM. I also found the scanned pictures in the ROM one day when disassembling things! D ___________________________________________________________ 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 3 October 2015 at 21:53, Alan wrote: > If python on the micro:bit has inline assembler - that is like something > you can't get on touch develop or blocky, I'm guessing. > > All the cool kids will be hanging out in python-land... where they can... > what could they do? Drive the accelerometer backwards to make a tiny > ultrasonic speaker that mimics bat's echolocation and scares off mosquitoes? > > Cheers, > > Alan > > ------------------------------ > From: alainjackson at hotmail.com > To: microbit at python.org > Date: Sat, 3 Oct 2015 20:28:35 +0000 > > Subject: Re: [Microbit-Python] memory error > > Hi Damien, > > 10KB, that sounds really good, you can do quite a lot of damage in 10KB. > > And microbit.assembler(...). Wow that is just insanely exciting! That's > like some crazy Easter egg in itself. That's the kind of function you want > minimal documentation for :) > > Cheers, > > Alan > > > > > > > Date: Sat, 3 Oct 2015 17:20:07 +0100 > > From: damien.p.george at gmail.com > > To: microbit at python.org > > Subject: Re: [Microbit-Python] memory error > > > > Yes, I think that at the moment 3kb is too limiting for maximum script > > size. I honestly didn't think people would be writing such complex > > programs, but agree that it would be very annoying if your efforts > > coding all day lead only to out of memory errors. > > > > If we can cater for the more advanced coders and provide more memory > > for scripts, then we should. And I have some ideas (inspired by > > David) of how to do it and might be able to get close to 10kb for > > maximum script. I'll keep you posted! > > > > Regarding assembler: actually MicroPython does include an inline > > assembler! But it's not enabled for the microbit. I was thinking of > > enabling it but it does take a bit of room (around 6500 bytes of > > flash). One cute option is to simply create a function that turns a > > byte string into a callable assembler function. Eg: > > > > fun = microbit.assembler(num_args=3, code=b'\x12\x34\x56') > > fun(1, 2, 3) > > > > Then you can write your assembly function in hex (!!) and do arbitrary > > things with the device. > > > > Regarding David's point about resource contraints leading to learning. > > I totally agree! Even if in the case of MicroPython you're not > > learning about stacks and pointers, you are learning that making a > > list takes memory, and higher level things like that. Even writing > > Python on your PC you sometimes need to think about how resource > > intensive it is and how to make it more efficient (eg use a better > > algorithm). > > > > > > On Sat, Oct 3, 2015 at 7:41 AM, David Whale > wrote: > > > :) > > > > > > My point was less about machine code, and more about "if resources are > > > limited, additional learning takes place". I learnt a lot about how the > > > computer worked, by finding other ways to make my programs fit. > > > > > > I'm not suggesting every 11 year old would be interested in breaking > beyond > > > the memory restrictions, some will, some won't. I think as long as we > have a > > > view on "what a reasonable sized program is for most users", it will > still > > > be a great experience. > > > > > > My follow on point was to not break our backs getting the last byte > out of > > > the memory, but something that maps out the memory usage would > encourage > > > those persistent souls who want to. That would be far less work than > > > squeezing the last few bytes out of the language design, and possibly > a self > > > contained task that someone else could do to one side. > > > > > > Cheers > > > > > > 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 3 October 2015 at 00:02, Alan wrote: > > >> > > >> Hi David, > > >> > > >> I find your argument about resource constraints compelling. > > >> > > >> I never did learn to program my 1K ZX81 in assembler. I blew it up > before > > >> then. > > >> > > >> Remember how AWFUL the keyboard was? I soldered a joystick from an old > > >> space invaders game into the keyboard matrix so I could play games > better... > > >> but when trying to add more buttons later I dropped the soldering > iron on > > >> the CPU. Game over. > > >> > > >> I didn't see assembler until I was at uni... and the moment had > passed. > > >> But ever since then I've been in awe of people who can do assembler. > > >> > > >> I would find your argument even more compelling if we were thinking of > > >> python as a gateway drug to assembler. If we had an assembler > tool-chain > > >> shipping along with micropython. > > >> > > >> I think we, as a bunch of python people, seeing the device through a > > >> pythonic lens, for us there maybe an objectively optimal memory > range, which > > >> I personally think is greater than 3KB.... for python. > > >> > > >> But if we're part of encouraging a descent into assembler, then I > could be > > >> convinced that less is more. > > >> > > >> Cheers, > > >> > > >> Alan > > >> > > >> > > >> ________________________________ > > >> Date: Fri, 2 Oct 2015 23:09:59 +0100 > > >> From: david at thinkingbinaries.com > > >> > > >> To: microbit at python.org > > >> Subject: Re: [Microbit-Python] memory error > > >> > > >> I think it would be useful to have a rough metric or target of the > sort of > > >> script/size that would be reasonably expected on a platform of this > size. It > > >> might be that on the whole, all the things that people are writing > will > > >> basically fit, if some basic good practice in naming and layout is > followed. > > >> > > >> I also think back to the earlier discussion about limited memory on > the > > >> ZX81, and the fact that I spent most of my working life up until now > > >> squeezing lots of functionality into tiny processors with limited > resources, > > >> and the skills I learnt on my 1K ZX81 were vital to enabling that > > >> innovation. The door push on the front of my house has my code in it, > it's a > > >> commercial product you can buy off the shelf, and it wouldn't have if > I > > >> didn't cut my teeth on a resource limited platform which forced me to > > >> understand how the computer actually worked. I was 11 when I had my > ZX81 and > > >> I was writing Z80 assembler as a way to make things fit. On the whole > it was > > >> a really exciting experience for an 11 year old! > > >> > > >> > > >> One of the things to remember is that modern computers (even the > Raspberry > > >> Pi) mostly allow you to assume infinite resources (or pretty > unbounded). The > > >> micro:bit is very much an embedded platform, and having a limit on > resources > > >> causes people to understand that nothing is infinite in this world, > and > > >> that's a good thing sometimes! > > >> > > >> So, let's not beat ourselves up about it. As long as a good > representative > > >> set of engaging and exciting programs can be made to fit, there has > to be > > >> some limit. And besides - save some work for version 2!!! > > >> > > >> As an aside, if someone were to develop a toolkit that helped to > explain > > >> where the memory usage in a given MicroPython program goes to, it > would > > >> enable users to optimise their programs better themselves and gain a > better > > >> understanding of how things work. I'm sure Damien is the same, when > working > > >> on an embedded platform I spend my life in the map file and often in > the > > >> assembly listings too, to understand where all the precious memory is > going > > >> to! > > >> > > >> 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 2 October 2015 at 22:46, Damien George > > >> wrote: > > >> > > >> Yes, variable name length will have a small impact on RAM usage. > > >> > > >> Yes, as David says, a given variable is only stored once in RAM and > > >> then referenced by an index (which is usually 16 bits) so it's > > >> relatively efficient. You need to keep the actual name of the > > >> variable around so that you can given sensible error messages, and > > >> also for lookup of global names in dictionaries. > > >> > > >> There are definitely things that we can do to improve the memory usage > > >> and allow bigger scripts. Do you think it's a priority? > > >> > > >> On Fri, Oct 2, 2015 at 6:17 PM, David Whale < > david at thinkingbinaries.com> > > >> wrote: > > >> > I only had a 1K ZX81 and it forced me to learn machine code so I > could > > >> > make > > >> > everything fit :) > > >> > > > >> > I'm *guessing* that MicroPython has a fixup table, so that the > variable > > >> > names and function names are only stored in RAM once - i.e. each > > >> > reference > > >> > to a function name or variable name in the bytecode is actually an > index > > >> > into a string table with the actual name in it? Perhaps a one-way > hash > > >> > could > > >> > be used to turn any given name into a shorter hash that is actually > used > > >> > for > > >> > the lookup? > > >> > > > >> > Cheers > > >> > > > >> > D > > >> > > > >> > > > >> > ___________________________________________________________ > > >> > 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 2 October 2015 at 18:06, Alan wrote: > > >> >> > > >> >> Hi, > > >> >> > > >> >> Am I right in thinking the size of variable names also makes a > > >> >> difference? > > >> >> It seemed to, although I didn't test that scientifically. > > >> >> > > >> >> 3KB is a bit small. I know, however big the memory we'd always want > > >> >> more. > > >> >> And I did grow up programming a ZX81, so this is 3 times as big! > You'd > > >> >> think > > >> >> I'd be happy with that. > > >> >> > > >> >> Cheers, > > >> >> > > >> >> Alan > > >> >> > > >> >> > Date: Fri, 2 Oct 2015 16:07:02 +0100 > > >> >> > > >> >> > From: damien.p.george at gmail.com > > >> >> > To: microbit at python.org > > >> >> > Subject: Re: [Microbit-Python] memory error > > >> >> > > > >> >> > Hi Alan, > > >> >> > > > >> >> > Yes, doc strings do take up memory, so in our case (when trying > to > > >> >> > reduce memory usage) it's better to make them comments (which are > > >> >> > just > > >> >> > skipped over by the tokeniser). > > >> >> > > > >> >> > The example you give with lots of prints does indeed take up all > the > > >> >> > memory, so that's why it gives a MemoryError. It's not easy to > fix > > >> >> > this, the microbit is just really low on RAM! We could compile > the > > >> >> > python script to flash (instead of RAM) but that needs a bit of > > >> >> > effort > > >> >> > to get working. > > >> >> > > > >> >> > Cheers, > > >> >> > Damien. > > >> >> > > > >> >> > > > >> >> > On Thu, Oct 1, 2015 at 2:52 AM, Alan > > >> >> > wrote: > > >> >> > > Hi, > > >> >> > > > > >> >> > > Another little trick I've realised is that if I put a large, > > >> >> > > explanatory > > >> >> > > comment at the top of the file using """...""" it of course > goes > > >> >> > > into > > >> >> > > a > > >> >> > > docstring... which takes up memory! > > >> >> > > > > >> >> > > If I use # style comments instead, it doesn't seem to take up > > >> >> > > memory. > > >> >> > > > > >> >> > > Cheers, > > >> >> > > > > >> >> > > Alan > > >> >> > > > > >> >> > > ________________________________ > > >> >> > > From: alainjackson at hotmail.com > > >> >> > > To: microbit at python.org > > >> >> > > Date: Thu, 1 Oct 2015 00:32:14 +0000 > > >> >> > > > > >> >> > > Subject: Re: [Microbit-Python] memory error > > >> >> > > > > >> >> > > Hi, > > >> >> > > > > >> >> > > I didn't save the version of my code that got the memory error. > > >> >> > > > > >> >> > > But I've just now created a small, pathological example. > > >> >> > > > > >> >> > > The code below, which is 3kB on the disk, will create the > following > > >> >> > > error: > > >> >> > > > > >> >> > >>>> MemoryError: > > >> >> > > Micro Python v1.4.5-68-g3a2171e on 2015-09-04; micro:bit with > > >> >> > > nRF51822 > > >> >> > > Type "help()" for more information. > > >> >> > > > > >> >> > > But if you delete the last line, it will run fine. > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > """ > > >> >> > > Testing how much memory for python code the microbit has. > > >> >> > > """ > > >> >> > > > > >> >> > > from microbit import * > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("gfecba123456789022345678903234567890423456789052345678906234567890723456789082345678909234") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("hgfecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("ihgfecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("123456789022345678903234567890423456789052345678906234567890723456789082345678909234567890") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("a12345678902234567890323456789042345678905234567890623456789072345678908234567890923456789") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("ba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345678") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("cba123456789022345678903234567890423456789052345678906234567890723456789082345678909234567") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("dcba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("ecba12345678902234567890323456789042345678905234567890623456789072345678908234567890923456") > > >> >> > > > > >> >> > > > > >> >> > > > display.print("fecba1234567890223456789032345678904234567890523456789062345678907234567890823456789092345") > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > >> Date: Wed, 30 Sep 2015 12:01:57 +0100 > > >> >> > >> From: damien.p.george at gmail.com > > >> >> > >> To: microbit at python.org > > >> >> > >> Subject: Re: [Microbit-Python] memory error > > >> >> > >> > > >> >> > >> Hi Alan, > > >> >> > >> > > >> >> > >> Can you post your code? > > >> >> > >> > > >> >> > >> On Wed, Sep 30, 2015 at 2:14 AM, Alan < > alainjackson at hotmail.com> > > >> >> > >> wrote: > > >> >> > >> > Hi, > > >> >> > >> > > > >> >> > >> > How much memory does the Microbit have for a python program? > > >> >> > >> > > > >> >> > >> > I've written a small program about 105 lines long. It's 3kB > on > > >> >> > >> > my > > >> >> > >> > hard > > >> >> > >> > disk. > > >> >> > >> > It runs ok now but when it was 115 lines long and 3.2kB I > kept > > >> >> > >> > getting > > >> >> > >> > memory allocation errors as soon as I pressed the reset > button. > > >> >> > >> > If > > >> >> > >> > I > > >> >> > >> > commented about 10 lines out of my program it would run and > it > > >> >> > >> > didn't > > >> >> > >> > seem > > >> >> > >> > to matter which 10 lines. So I assumed it was out of program > > >> >> > >> > memory? > > >> >> > >> > > > >> >> > >> > Cheers, > > >> >> > >> > > > >> >> > >> > Alan > > >> >> > >> > > > >> >> > >> > _______________________________________________ > > >> >> > >> > 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 > > >> >> > > > > >> >> > > _______________________________________________ > > >> >> > > 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 > > >> >> > > >> > > > >> > > > >> > _______________________________________________ > > >> > 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 > > >> > > >> _______________________________________________ > > >> 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 > > _______________________________________________ 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: From larry at hastings.org Mon Oct 5 09:46:03 2015 From: larry at hastings.org (Larry Hastings) Date: Mon, 5 Oct 2015 00:46:03 -0700 Subject: [Microbit-Python] Image is hard to use Message-ID: <56122ABB.1020309@hastings.org> I can only create /so/ many Image objects before I get an 020 / the thing seizes up. But once I've created an Image object, it's painful to change it. My only option is the plodding set_pixel_value(). This is pretty painful if I want to make action-y games. I suggest the following changes to the Image object: * Change the repr so it prints the internal array of pixels. * Remove "_value" from the names of Image object methods (set_pixel_value -> set_pixel, get_pixel_value -> get_pixel). * Add a .clear() method that sets all pixels to 0. * Add a .set(s) method that takes the same string as the constructor. * Add an .update(image) method that sets the image to be a copy of another. (It'd change the dimensions too.) * Add a .copy(image, x, y) method that copies pixels from another image to the current image. (This wouldn't change the dimensions of the original image.) x, y would be the position to write the incoming image to. If it can support optional parameters, it'd be nice to default x and y to 0. It'd also be heavenly to add on: o "mode", which can be either OVERWRITE (set all pixels to the value of the image passed in), or BRIGHTEST (which would set the pixel to the brighter of either the original pixel or the incoming pixel). Default would be OVERWRITE. o width, height, which would restrict the size of the image copied over. I admit, if I only got one of .set(), .update(), or .copy(), I'd be pretty happy. Finally: is that initializer for the Image your doing Damien, or is that from the HAL? It's kind of wonky. It'd be nice if I could have an array of arrays of integers. Or five bytes, though I admit that might be painful for the students. In particular: why is the initializer of the Image a string, but the "value" parameter of set_pixel_value an integer? This is weirdly inconsistent. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at thinkingbinaries.com Mon Oct 5 11:11:17 2015 From: david at thinkingbinaries.com (David Whale) Date: Mon, 5 Oct 2015 10:11:17 +0100 Subject: [Microbit-Python] Image is hard to use In-Reply-To: <56122ABB.1020309@hastings.org> References: <56122ABB.1020309@hastings.org> Message-ID: One of our IET guys wrote a TD library using bresenhams algorithm for line drawing - so that he can programmatically draw shapes and lines. He used it to do a little bar-graph like display. Just an idea. It looked really neat. ___________________________________________________________ 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 5 October 2015 at 08:46, Larry Hastings wrote: > > > I can only create *so* many Image objects before I get an 020 / the thing > seizes up. But once I've created an Image object, it's painful to change > it. My only option is the plodding set_pixel_value(). This is pretty > painful if I want to make action-y games. > > I suggest the following changes to the Image object: > > - Change the repr so it prints the internal array of pixels. > - Remove "_value" from the names of Image object methods > (set_pixel_value -> set_pixel, get_pixel_value -> get_pixel). > - Add a .clear() method that sets all pixels to 0. > - Add a .set(s) method that takes the same string as the constructor. > - Add an .update(image) method that sets the image to be a copy of > another. (It'd change the dimensions too.) > - Add a .copy(image, x, y) method that copies pixels from another > image to the current image. (This wouldn't change the dimensions of the > original image.) x, y would be the position to write the incoming image > to. If it can support optional parameters, it'd be nice to default x and y > to 0. It'd also be heavenly to add on: > - "mode", which can be either OVERWRITE (set all pixels to the value > of the image passed in), or BRIGHTEST (which would set the pixel to the > brighter of either the original pixel or the incoming pixel). Default > would be OVERWRITE. > - width, height, which would restrict the size of the image copied > over. > > I admit, if I only got one of .set(), .update(), or .copy(), I'd be pretty > happy. > > > Finally: is that initializer for the Image your doing Damien, or is that > from the HAL? It's kind of wonky. It'd be nice if I could have an array > of arrays of integers. Or five bytes, though I admit that might be painful > for the students. > > In particular: why is the initializer of the Image a string, but the > "value" parameter of set_pixel_value an integer? This is weirdly > inconsistent. > > > */arry* > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Tue Oct 6 13:09:44 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 6 Oct 2015 04:09:44 -0700 Subject: [Microbit-Python] Failed attempt at Whack-A-Mole Message-ID: <5613ABF8.4080509@hastings.org> Attached is my test harness for my virtual screen technology. Load that in using upyed download firmware and reset. You can now scroll an image around on the screen of four hollow boxes. The full image looks like so: ........... .XXX....... .X.X....... .XXX....... .XXXXXX.... .X.XX.X.... .XXXXXX.... .......XXX. .......X.X. .......XXX. ........... The scrolling is responsive and debounced. Attached also is my attempt to turn that screen scrolling technology into a game of Whack-A-Mole. The game draws one square per second; your goal is to scroll the screen so that the center is pointed at that square and press either button. I run out of memory while compiling. I had some neat ideas for games, but if I'm /this/ limited on RAM, well... sigh. Can anybody get Whack-A-Mole to run? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: whack-a-mole.py Type: text/x-python Size: 3146 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scrolly.image.py Type: text/x-python Size: 2603 bytes Desc: not available URL: From damien.p.george at gmail.com Tue Oct 6 13:24:42 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 6 Oct 2015 12:24:42 +0100 Subject: [Microbit-Python] Failed attempt at Whack-A-Mole In-Reply-To: <5613ABF8.4080509@hastings.org> References: <5613ABF8.4080509@hastings.org> Message-ID: As for RAM limitations... I am working on it! On Tue, Oct 6, 2015 at 12:09 PM, Larry Hastings wrote: > > > Attached is my test harness for my virtual screen technology. Load that in > using upyed download firmware and reset. You can now scroll an image around > on the screen of four hollow boxes. The full image looks like so: > > ........... > .XXX....... > .X.X....... > .XXX....... > .XXXXXX.... > .X.XX.X.... > .XXXXXX.... > .......XXX. > .......X.X. > .......XXX. > ........... > > The scrolling is responsive and debounced. > > > Attached also is my attempt to turn that screen scrolling technology into a > game of Whack-A-Mole. The game draws one square per second; your goal is to > scroll the screen so that the center is pointed at that square and press > either button. I run out of memory while compiling. > > I had some neat ideas for games, but if I'm this limited on RAM, well... > sigh. > > Can anybody get Whack-A-Mole to run? > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From david at thinkingbinaries.com Tue Oct 6 14:49:48 2015 From: david at thinkingbinaries.com (David Whale) Date: Tue, 6 Oct 2015 13:49:48 +0100 Subject: [Microbit-Python] Failed attempt at Whack-A-Mole In-Reply-To: References: <5613ABF8.4080509@hastings.org> Message-ID: Really pleased to see the virtual canvas idea - I was working on one of those for Touch Develop, but there are bugs in the canvas handling at the moment that have not had fixes pushed to the live server, so I paused that activity while I waited for them to catch up (the emulator does not plot pixels outside of [0,0]->[4,4] on an in memory image, but the micro:bit runtime does). I was thinking of accelerometer tilt driven mazes, a bit like a 5x5 window on one of those rolling ball bearing maze games. D ___________________________________________________________ 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 6 October 2015 at 12:24, Damien George wrote: > As for RAM limitations... I am working on it! > > On Tue, Oct 6, 2015 at 12:09 PM, Larry Hastings > wrote: > > > > > > Attached is my test harness for my virtual screen technology. Load that > in > > using upyed download firmware and reset. You can now scroll an image > around > > on the screen of four hollow boxes. The full image looks like so: > > > > ........... > > .XXX....... > > .X.X....... > > .XXX....... > > .XXXXXX.... > > .X.XX.X.... > > .XXXXXX.... > > .......XXX. > > .......X.X. > > .......XXX. > > ........... > > > > The scrolling is responsive and debounced. > > > > > > Attached also is my attempt to turn that screen scrolling technology > into a > > game of Whack-A-Mole. The game draws one square per second; your goal > is to > > scroll the screen so that the center is pointed at that square and press > > either button. I run out of memory while compiling. > > > > I had some neat ideas for games, but if I'm this limited on RAM, well... > > sigh. > > > > Can anybody get Whack-A-Mole to run? > > > > > > /arry > > > > _______________________________________________ > > 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: From damien.p.george at gmail.com Tue Oct 6 15:07:30 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 6 Oct 2015 14:07:30 +0100 Subject: [Microbit-Python] Failed attempt at Whack-A-Mole In-Reply-To: References: <5613ABF8.4080509@hastings.org> Message-ID: > I was thinking of accelerometer tilt driven mazes, a bit like a 5x5 window > on one of those rolling ball bearing maze games. Already written! See examples/maze.py: https://github.com/dpgeorge/microbit-micropython/blob/master/examples/maze.py From mark at hotpy.org Tue Oct 6 22:15:58 2015 From: mark at hotpy.org (Mark Shannon) Date: Tue, 6 Oct 2015 21:15:58 +0100 Subject: [Microbit-Python] What to do about display and images? Message-ID: <56142BFE.5090601@hotpy.org> Hi all, I've been playing with changing the display brightness, modifying images and such like. The current API is, to be honest, a bit of a mess. Here are some examples: The display *has* an image attribute, but acts more like it *is* an image. Modifying an image that is being displayed is different to modifying the display image. The effect of changing the global brightness of the display depends on whether the thing being displayed is an image or a letter. What happens when you combine the above operations is incomprehensible to anyone, let alone an 11 year old. I think that we need a different approach. All the other components on the microbit, which can be manipulated, are modified by writing immutable values (usually integers). For example, to set an analog pin to 500 you call pin.write_analog(500). So, why not do the same for the display? The primary means for modify the display should be writing immutable images or strings. Many images are already immutable, e.g. Image.HEART. Let's make them all immutable. I would like the following: 1. For it to be possible to reason about the behaviour of the display, so we could have a correct implementation (unlike the current situation). 2. To allow easy creation of custom images: >>> three_oclock = Image.CLOCK3 + Image.CLOCK12 * 0.5 #An image with the hour hand at full brightness and the minute hand at half brightness. >>> one_eyed_jake = Image.LEFT_EYE + Image.RIGHT_EYE*0.2 + Image.SMILE 3. For all images to be immutable, so they won't need copying and won't use up any precious RAM. Monochrome 5x5 images should be tiny (the name of the image will often take up more space than the image), so we can have as many pre-created images as we want. To achieve that, here are my concrete suggestions: 1. Drop the display.image attribute. 2. Add a display.as_image() which returns a new Image for what is currently shown on the display. 3. Drop display.set_brightness(). We could add display.change_brightness() to scale up or down the brightness of the display, but I'm not sure about it. Individual pixel brightnesses should be set as before. 4. Make *all* Images immutable. 5. Make the brightness an inherent part of the image. Simple images like HEART should have their pixels set to max or zero. 6. Add a good number of functions to create objects from pre-existing ones. Function such as: roll, rotate, flip, crop. 7. Make it possible to add images to each other. 8. Perhaps allow creating a brighter or darker version of an image by multiplying it with a number. However, this might be being too "clever", we could add dim()/brighten() functions instead. 9. All brightnesses should in terms of perceived brightness, not LED power. Cheers, Mark. P.S. I am willing to implement this and actually have the time to do so this week :) From larry at hastings.org Tue Oct 6 22:53:57 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 6 Oct 2015 13:53:57 -0700 Subject: [Microbit-Python] What to do about display and images? In-Reply-To: <56142BFE.5090601@hotpy.org> References: <56142BFE.5090601@hotpy.org> Message-ID: <561434E5.20106@hastings.org> On 10/06/2015 01:15 PM, Mark Shannon wrote: > 4. Make *all* Images immutable. As a practical matter I don't think this is feasible. Write a quick loop and create a single 5x5 Image inside. del it immediately afterwards. See how long it runs before you get a mysterious :-( 020 error. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Tue Oct 6 23:23:41 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 6 Oct 2015 22:23:41 +0100 Subject: [Microbit-Python] What to do about display and images? In-Reply-To: <561434E5.20106@hastings.org> References: <56142BFE.5090601@hotpy.org> <561434E5.20106@hastings.org> Message-ID: For reference, this is a valid program on the micro:bit prototype: for count in range(10): show_image_offset(make_image(0x6,0x4,0xe,0x4,0x6),0,0) pause(200) show_image_offset(make_image(0xc,0x4,0xe,0x4,0x6),0,0) pause(200) (this is from here: http://bug.iotoy.org/bug/program/2777/Seahorse1 ) Now, the micro:bit prototype was even more ram constrained (2.5K RAM, 32K Flash vs 16KRAM, 128K Flash). As a result, since make_image was a constructor which created an Image object, this has precisely the same problem you're talking about here: On 6 October 2015 at 21:53, Larry Hastings wrote: > On 10/06/2015 01:15 PM, Mark Shannon wrote: > > 4. Make *all* Images immutable. > > > As a practical matter I don't think this is feasible. Write a quick loop > and create a single 5x5 Image inside. del it immediately afterwards. See > how long it runs before you get a mysterious :-( 020 error. > The way this dealt with this was to make the python->C++ compiler micro:bit DAL aware. In particular, if it saw this pattern: show_image_offset(make_image( ------- ), --, --) It transforms it to the equivalent plot/unplot commands: (again copy and paste from the actual generated code for this) for(int count=0; count<10; count= count + 1) { clear_display(); unplot(0 +(0), 0 +(0)); plot(1 + (0), 0 + (0)); plot(2 + (0), 0 + (0)); unplot(3 +(0), 0 +(0)); unplot(4 +(0), 0 +(0)); unplot(0 +(0), 1 +(0)); unplot(1 +(0), 1 +(0)); plot(2 + (0), 1 + (0)); unplot(3 +(0), 1 +(0)); unplot(4 +(0), 1 +(0)); unplot(0 +(0), 2 +(0)); plot(1 + (0), 2 + (0)); plot(2 + (0), 2 + (0)); plot(3 + (0), 2 + (0)); unplot(4 +(0), 2 +(0)); unplot(0 +(0), 3 +(0)); unplot(1 +(0), 3 +(0)); plot(2 + (0), 3 + (0)); unplot(3 +(0), 3 +(0)); unplot(4 +(0), 3 +(0)); unplot(0 +(0), 4 +(0)); plot(1 + (0), 4 + (0)); plot(2 + (0), 4 + (0)); unplot(3 +(0), 4 +(0)); unplot(4 +(0), 4 +(0));; Whether those sorts of transforms are practical for microbit micropython I'm not sure - since it probably also depends on the API too. However mentioning it in case useful. In particular, this allowed things like scrolling images to be practical: - http://bug.iotoy.org/bug/program/870/Scrolling%20Face (Since otherwise that would eat up memory way too fast) Regarding Mark's original point, I'm not sure I can comment on the changed API - but anything that makes things simpler I think is a good thing. Treating a display as a display and an image as an image is a fair idea IMO. I like the idea of "display.as_image()" - though display.snapshot() (or display.selfie() ? :-) returning an image would make sense. (.selfie() might be jarring, but *may* be an instantly obvious thing to an 11 year old :-) ) Having mutable images though is something I think is useful. Having *system* images which are immutable though I think is useful. (If only because it teaches the idea that some things are immutable, which is a python concept) Regards, Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at thinkingbinaries.com Tue Oct 6 23:41:36 2015 From: david at thinkingbinaries.com (David Whale) Date: Tue, 6 Oct 2015 22:41:36 +0100 Subject: [Microbit-Python] What to do about display and images? In-Reply-To: References: <56142BFE.5090601@hotpy.org> <561434E5.20106@hastings.org> Message-ID: Touch develop has a thing similar to display.snapshot(), I saw it in there the other day. D ___________________________________________________________ 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 6 October 2015 at 22:23, Michael wrote: > For reference, this is a valid program on the micro:bit prototype: > > for count in range(10): > show_image_offset(make_image(0x6,0x4,0xe,0x4,0x6),0,0) > pause(200) > show_image_offset(make_image(0xc,0x4,0xe,0x4,0x6),0,0) > pause(200) > > (this is from here: http://bug.iotoy.org/bug/program/2777/Seahorse1 ) > > Now, the micro:bit prototype was even more ram constrained (2.5K RAM, 32K > Flash vs 16KRAM, 128K Flash). As a result, since make_image was a > constructor which created an Image object, this has precisely the same > problem you're talking about here: > > On 6 October 2015 at 21:53, Larry Hastings wrote: > >> On 10/06/2015 01:15 PM, Mark Shannon wrote: >> >> 4. Make *all* Images immutable. >> >> >> As a practical matter I don't think this is feasible. Write a quick loop >> and create a single 5x5 Image inside. del it immediately afterwards. See >> how long it runs before you get a mysterious :-( 020 error. >> > > The way this dealt with this was to make the python->C++ compiler > micro:bit DAL aware. In particular, if it saw this pattern: > > show_image_offset(make_image( ------- ), --, --) > > > It transforms it to the equivalent plot/unplot commands: (again copy and > paste from the actual generated code for this) > > for(int count=0; count<10; count= count + 1) > { > clear_display(); > unplot(0 +(0), 0 +(0)); > plot(1 + (0), 0 + (0)); > plot(2 + (0), 0 + (0)); > unplot(3 +(0), 0 +(0)); > unplot(4 +(0), 0 +(0)); > unplot(0 +(0), 1 +(0)); > unplot(1 +(0), 1 +(0)); > plot(2 + (0), 1 + (0)); > unplot(3 +(0), 1 +(0)); > unplot(4 +(0), 1 +(0)); > unplot(0 +(0), 2 +(0)); > plot(1 + (0), 2 + (0)); > plot(2 + (0), 2 + (0)); > plot(3 + (0), 2 + (0)); > unplot(4 +(0), 2 +(0)); > unplot(0 +(0), 3 +(0)); > unplot(1 +(0), 3 +(0)); > plot(2 + (0), 3 + (0)); > unplot(3 +(0), 3 +(0)); > unplot(4 +(0), 3 +(0)); > unplot(0 +(0), 4 +(0)); > plot(1 + (0), 4 + (0)); > plot(2 + (0), 4 + (0)); > unplot(3 +(0), 4 +(0)); > unplot(4 +(0), 4 +(0));; > > Whether those sorts of transforms are practical for microbit micropython > I'm not sure - since it probably also depends on the API too. However > mentioning it in case useful. > > In particular, this allowed things like scrolling images to be practical: > > - http://bug.iotoy.org/bug/program/870/Scrolling%20Face > > (Since otherwise that would eat up memory way too fast) > > Regarding Mark's original point, I'm not sure I can comment on the changed > API - but anything that makes things simpler I think is a good thing. > Treating a display as a display and an image as an image is a fair idea > IMO. I like the idea of "display.as_image()" - though display.snapshot() > (or display.selfie() ? :-) returning an image would make sense. > > (.selfie() might be jarring, but *may* be an instantly obvious thing to an > 11 year old :-) ) > > Having mutable images though is something I think is useful. Having > *system* images which are immutable though I think is useful. (If only > because it teaches the idea that some things are immutable, which is a > python concept) > > Regards, > > > Michael. > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Wed Oct 7 00:05:40 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 6 Oct 2015 23:05:40 +0100 Subject: [Microbit-Python] Image is hard to use In-Reply-To: <56122ABB.1020309@hastings.org> References: <56122ABB.1020309@hastings.org> Message-ID: Hi Larry, On Mon, Oct 5, 2015 at 8:46 AM, Larry Hastings wrote: > > I can only create so many Image objects before I get an 020 / the thing > seizes up. Yes, this is because the microbit is very low on RAM, as many of us have established by now! In this case the problem is exacerbated by the fact that there are 2 heaps: the DAL heap and the uPy heap. When you create an image in Python it makes an image object on the uPy heap, but then also makes the image C++ object in the DAL heap. Yes this is silly. Ideally we'd combine the 2 heaps, but still then we'd be making 2 separate allocations for the single image. So ideally ideally we'd rewrite the image handling code so that an image object was integrated into the Python object system. But then we'd need to rewrite the display handling code to show the images.... > But once I've created an Image object, it's painful to change > it. My only option is the plodding set_pixel_value(). This is pretty > painful if I want to make action-y games. > > I suggest the following changes to the Image object: > > Change the repr so it prints the internal array of pixels. How exactly do you want it to be printed, like a bytearray? > Remove "_value" from the names of Image object methods (set_pixel_value -> > set_pixel, get_pixel_value -> get_pixel). Already done! > Add a .clear() method that sets all pixels to 0. It's in the DAL, just needs exposing on the Python side. > Add a .set(s) method that takes the same string as the constructor. Yes, sensible thing to add. > Add an .update(image) method that sets the image to be a copy of another. > (It'd change the dimensions too.) There is a "paste(image)" function in the DAL. It does almost what you want, just not resizing the destination. > Add a .copy(image, x, y) method that copies pixels from another image to the > current image. (This wouldn't change the dimensions of the original image.) > x, y would be the position to write the incoming image to. If it can > support optional parameters, it'd be nice to default x and y to 0. It'd > also be heavenly to add on: > > "mode", which can be either OVERWRITE (set all pixels to the value of the > image passed in), or BRIGHTEST (which would set the pixel to the brighter of > either the original pixel or the incoming pixel). Default would be > OVERWRITE. > width, height, which would restrict the size of the image copied over. The DAL paste function has an "alpha" parameter that does pretty much this! > I admit, if I only got one of .set(), .update(), or .copy(), I'd be pretty > happy. Well I think we just expose "paste" and also implement "set" and then we are good! > Finally: is that initializer for the Image your doing Damien, or is that > from the HAL? It's kind of wonky. It'd be nice if I could have an array of > arrays of integers. Or five bytes, though I admit that might be painful for > the students. It's a DAL thing. Personally I'd rather a string without commas, something like "01001:11011:00011:00000:01010". We can also support bytearrays and lists of lists of integers (although the latter would consume a lot of RAM, much more efficient to have just a string). > In particular: why is the initializer of the Image a string, but the "value" > parameter of set_pixel_value an integer? This is weirdly inconsistent. Well, the initialiser is a string of integers :) From damien.p.george at gmail.com Wed Oct 7 00:14:16 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 6 Oct 2015 23:14:16 +0100 Subject: [Microbit-Python] What to do about display and images? In-Reply-To: References: <56142BFE.5090601@hotpy.org> <561434E5.20106@hastings.org> Message-ID: The DAL has display.image and that's why I exposed it on the Python side. Touch Develop does not expose the image attribute. I'm in favour of removing display.image, but then we should add methods to get/set pixels. Ideally: display.set_pixel display.get_pixel (this just mimics an image, ie duck typing) I agree with most of the points above describing changes to the API, except that I don't agree that images should be constant. We need to sort out the brightness stuff and pixel intensity of images, since that is currently leading to confusion. I opened a github issue about it here: https://github.com/lancaster-university/microbit-dal/issues/14 On Tue, Oct 6, 2015 at 10:41 PM, David Whale wrote: > Touch develop has a thing similar to display.snapshot(), I saw it in there > the other day. > > D > > > ___________________________________________________________ > 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 6 October 2015 at 22:23, Michael wrote: >> >> For reference, this is a valid program on the micro:bit prototype: >> >> for count in range(10): >> show_image_offset(make_image(0x6,0x4,0xe,0x4,0x6),0,0) >> pause(200) >> show_image_offset(make_image(0xc,0x4,0xe,0x4,0x6),0,0) >> pause(200) >> >> (this is from here: http://bug.iotoy.org/bug/program/2777/Seahorse1 ) >> >> Now, the micro:bit prototype was even more ram constrained (2.5K RAM, 32K >> Flash vs 16KRAM, 128K Flash). As a result, since make_image was a >> constructor which created an Image object, this has precisely the same >> problem you're talking about here: >> >> On 6 October 2015 at 21:53, Larry Hastings wrote: >>> >>> On 10/06/2015 01:15 PM, Mark Shannon wrote: >>> >>> 4. Make *all* Images immutable. >>> >>> >>> As a practical matter I don't think this is feasible. Write a quick loop >>> and create a single 5x5 Image inside. del it immediately afterwards. See >>> how long it runs before you get a mysterious :-( 020 error. >> >> >> The way this dealt with this was to make the python->C++ compiler >> micro:bit DAL aware. In particular, if it saw this pattern: >> >> show_image_offset(make_image( ------- ), --, --) >> >> >> It transforms it to the equivalent plot/unplot commands: (again copy and >> paste from the actual generated code for this) >> >> for(int count=0; count<10; count= count + 1) >> { >> clear_display(); >> unplot(0 +(0), 0 +(0)); >> plot(1 + (0), 0 + (0)); >> plot(2 + (0), 0 + (0)); >> unplot(3 +(0), 0 +(0)); >> unplot(4 +(0), 0 +(0)); >> unplot(0 +(0), 1 +(0)); >> unplot(1 +(0), 1 +(0)); >> plot(2 + (0), 1 + (0)); >> unplot(3 +(0), 1 +(0)); >> unplot(4 +(0), 1 +(0)); >> unplot(0 +(0), 2 +(0)); >> plot(1 + (0), 2 + (0)); >> plot(2 + (0), 2 + (0)); >> plot(3 + (0), 2 + (0)); >> unplot(4 +(0), 2 +(0)); >> unplot(0 +(0), 3 +(0)); >> unplot(1 +(0), 3 +(0)); >> plot(2 + (0), 3 + (0)); >> unplot(3 +(0), 3 +(0)); >> unplot(4 +(0), 3 +(0)); >> unplot(0 +(0), 4 +(0)); >> plot(1 + (0), 4 + (0)); >> plot(2 + (0), 4 + (0)); >> unplot(3 +(0), 4 +(0)); >> unplot(4 +(0), 4 +(0));; >> >> Whether those sorts of transforms are practical for microbit micropython >> I'm not sure - since it probably also depends on the API too. However >> mentioning it in case useful. >> >> In particular, this allowed things like scrolling images to be practical: >> >> - http://bug.iotoy.org/bug/program/870/Scrolling%20Face >> >> (Since otherwise that would eat up memory way too fast) >> >> Regarding Mark's original point, I'm not sure I can comment on the changed >> API - but anything that makes things simpler I think is a good thing. >> Treating a display as a display and an image as an image is a fair idea IMO. >> I like the idea of "display.as_image()" - though display.snapshot() (or >> display.selfie() ? :-) returning an image would make sense. >> >> (.selfie() might be jarring, but *may* be an instantly obvious thing to an >> 11 year old :-) ) >> >> Having mutable images though is something I think is useful. Having >> *system* images which are immutable though I think is useful. (If only >> because it teaches the idea that some things are immutable, which is a >> python concept) >> >> Regards, >> >> >> Michael. >> >> >> >> _______________________________________________ >> 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 > From larry at hastings.org Wed Oct 7 07:32:13 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 6 Oct 2015 22:32:13 -0700 Subject: [Microbit-Python] What to do about display and images? In-Reply-To: <56142BFE.5090601@hotpy.org> References: <56142BFE.5090601@hotpy.org> Message-ID: <5614AE5D.4050601@hastings.org> So, the ur-operation of all bitmap operations is the "bit blit", as evinced by this Win32 API, unchanged from Win16: BOOL BitBlt( _In_ HDC hdcDest, _In_int nXDest, _In_int nYDest, _In_int nWidth, _In_int nHeight, _In_ HDC hdcSrc, _In_int nXSrc, _In_int nYSrc, _In_ DWORD dwRop ); https://msdn.microsoft.com/en-us/library/windows/desktop/dd183370(v=vs.85).aspx If you have BitBlt you can do anything. You can construct any other operation you need. An "HDC" is a Handle to a Device Context, which we can think of here as a bitmap. So this function copies the bits from one bitmap to another. It takes the X and Y of where to copy from on the source, the width and height of the area we want copied, the X and Y of where we want to copy /to/ on the destination, and the "raster operation" which is the approach to take when copying. There are seventeen (!) possible raster ops with BitBlt() but you only ever use a few. In theory I'd be interested in things like "scale" and "brighten", but in practice a 5x5 screen is so low-resolution I'll never scale anything, and there are only about four brightness levels (including "off"), so it's hard to get excited about those operations. I suppose you could still add these operations but I would put them off until last. I'd be happy to take a crack at designing the API /I'd/ want to use. All I need to know for now is: does MicroPython support a) positional parameters with defaults, b) name-only parameters with defaults? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Wed Oct 7 07:59:07 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 6 Oct 2015 22:59:07 -0700 Subject: [Microbit-Python] Image is hard to use In-Reply-To: References: <56122ABB.1020309@hastings.org> Message-ID: <5614B4AB.9060103@hastings.org> On 10/06/2015 03:05 PM, Damien George wrote: > On Mon, Oct 5, 2015 at 8:46 AM, Larry Hastings wrote: >> I can only create so many Image objects before I get an 020 / the thing >> seizes up. > Yes, this is because the microbit is very low on RAM, as many of us > have established by now! > > In this case the problem is exacerbated by the fact that there are 2 > heaps: the DAL heap and the uPy heap. When you create an image in > Python it makes an image object on the uPy heap, but then also makes > the image C++ object in the DAL heap. I just tried this on a freshly reset micro:bit with stock firmware: import microbit as m initializer = '0,0,0,0,0\n'*5 for i in range(100): print(i) image = m.Image(initializer) del image Any guesses as to the last number printed? 45. So we were able to create 45 bitmap objects before we ran out of memory. What kills me about this is that I'm /cleaning them up./ Why can't I create an image and immediately destroy it in a loop /forever?/ This strongly implies to me that there's something leaking. As for the two heaps: so, you have a stack and two heaps in 16k of memory. >> Change the repr so it prints the internal array of pixels. > How exactly do you want it to be printed, like a bytearray? Right now I get this: >>> import microbit as m >>> m.Image('0,255,0,0,0\n'*5) 0,255,0,0,0 0,255,0,0,0 0,255,0,0,0 0,255,0,0,0 0,255,0,0,0 How about, throw a "" around that. If you expose .clear(), .set(), and .paste() (with the alpha parameter) I'd be pretty happy. I'd also like .fill(value) and an alternate Image constructor form that lets me specify width and height and creates a black (all zeroes) bitmap. If I had all that I could do all sorts of things. For example, I could create my 11x11 window, empty it, draw on the square, then copy it to a second 11x11, shift it left and up, and boom! virtual window is done. .paste() is a bad name there though. But .copy() has a well-established meaning in Python. .stamp(), as in the verb? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Wed Oct 7 10:26:44 2015 From: larry at hastings.org (Larry Hastings) Date: Wed, 7 Oct 2015 01:26:44 -0700 Subject: [Microbit-Python] Game API objects I want Message-ID: <5614D744.1090208@hastings.org> Having written two games on the micro:bit--one of which actually works!--and having some previous experience writing video games, I'd like to get up on my soap box and hold forth. There are a couple of technologies that /nearly //every//game/ will use. (One that /literally every game/ will use!) And given that they're mildly complicated to do properly, and can consume a good chunk of the micro:bit's precious RAM to implement, I strongly suggest they be written in C++ and provided with MicroPython on the micro:bit. I don't know if I'm up to writing (and debugging!) them on the micro:bit itself. Maybe I could make a first pass in normal C++ on Linux, and someone else could port them to the micro:bit? I can name three such technologies, as follows. *1: A debounced accelerometer scaling object* My slalom game simply reads the current accelerometer value, restricts it to a specific range, then scales it down to the range I want to use and uses the resulting value, like so: [-1024 1023] <- accelerometer [ 0 | 1 | 2 | 3 | 4 ] <- slalom column Values lower than -1024 are ceilinged to -1024, values greater than 1023 are floored to 1023. I then add 1024 to the value, multiply by 5, divide by 2048, and call int(). I get a number from 0 to 4 (inclusive). Simple, done. The problem is that it kind of sucks. If you hold the micro:bit /just so/, on the border between two values (say 2 and 3) it quickly and seemingly-randomly bounces back and forth between the two. This can make playing slalom kind of tricky. Most of the code in the scrolly image demo and whack-a-mole game went into writing a debounced accelerometer position reader class. The idea is simple enough: instead of simply taking the range of the accelerometer you're interested in, and scaling it to the range you want, you also establish "dead zones" between regions like so: [-512 511] <- accelerometer [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] <- range with dead zones Here I've labeled the dead zones with lowercase letters (a, b, c, d). Dead zones magnified for illustrative purposes; in practice they're much smaller. The idea is, the value reported when you're in a "dead zone" depends on the previous value. The dead zones establish dynamic low-water and high-water marks for how far you'd have to go to cross over into another zone. For example, if on frame N you were clearly in zone 1: [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] * And on frame N+1 you were in zone b: [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] * the debounced reader would then report that you're still in zone 1. You have to force it all the way past the dead zone for it to report you as being in zone 2. If, on a subsequent frame P, you were definitely in zone 2: [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] * And on frame P+1 you were in zone b: [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] * the debounced reader would then report that you're (still) in zone 2. One way to think of it is that the dead zones prefer the zone nearest to the previous accelerometer reading. So if the accelerometer is currently in the spot marked with an asterisk, we can pretend that the zones map out as follows: * [ 0 | 1 | 2 | 3 | 4 ] * [ 0 | 1 | 2 | 3 | 4 ] * [ 0 | 1 | 2 | 3 | 4 ] * [ 0 | 1 | 2 | 3 | 4 ] * [ 0 | 1 | 2 | 3 | 4 ] Long story short, the reason the scrolly image demo is so pleasant to use is because of this debounced accelerometer class. If I didn't have that, it'd have the same bouncing-between-two-values problem that the slalom game has. I suggest that most games on the micro:bit will use the accelerometer, and if they simply scale it they'll have the bouncing problem. Of course, my debounced accelerometer class appears to consume most of the RAM of the micro:bit. And that's /after/ I hard-coded it to some of the behavior I wanted. A general-purpose debounced accelerometer class might not even fit! I could write a simple class that does this in C++, and let somebody else who understands MicroPython could port it to the runtime and get it working on the micro:bit. I think the API would look something like this: class AccelerometerScalingDebouncer: def __init__(self, fn, input_min, input_max, output_min, output_max, dead_zone=0.08): ... def read(self): ... fn would be the function to call to do a reading (like microbit.accelerometer.get_x). input_min and input_max would establish the range we'd clip the input to. output_min and output_max would establish the range of values returned (inclusive). dead_zone would establish how big the dead zone around each value would be, and we could hide this from the students (or handwave it away, "don't worry about it, it does the right thing for you"). read() would read the current value, clip it, debounce it, scale it, and return the resulting value. Again, you can see a working example of a class like this in my "scrolly image" demo. I've attached it here so you don't have to go hunting for it. It runs on the micro:bit. *2: A debounced reader for all the buttons* A moment's thought suggests: we want a debounced button class, too. Both my games used the buttons, and I had to write debouncing code for both. The basic idea: if the user presses the button, you often want to process the button press exactly once. So code like this doesn't work: next_frame = 0 while True: delta = next_frame - microbit.time() if delta > 0: microbit.sleep(delta) continue next_frame = microbit.time() + 50 if microbit.button_a.is_pressed(): do_thing() The problem: if the user holds down the button, you'll call do_thing() every 50ms. I've seen people mention that there's actually an event queue in the DAL. Maybe just exposing this somehow is sufficient? I think what I want is an object like this: class ButtonDebouncer: def __init__(self, a=True, b=True, both=False, delay=100): ... def poll(self): ... def a_pressed(self): ... def b_pressed(self): ... def both_pressed(self): ... You pass in to the constructor booleans indicating which buttons you care about: a, b, or both. If both=True and either a=True or b=True, "delay" indicates how long to wait after one button is pressed before giving up and assuming we're not getting both buttons pressed. If you press and hold button A, after the next time you call poll(), a_pressed() would return True /once/. After that first time it would return False until you released A, called poll(), then pressed A and called poll().// The object would internally use microbit.time() for time. __init__ would call poll(). I tried to write an example of this in Python for the micro:bit. However my first try hit a MemoryError. (Argh! Double-argh!) So I've attached my attempt, which you can consider a non-working mockup. *3: A simple scheduler* /Every/ realtime game would want this. And I doubt people will write non-realtime games on the micro:bit. The basic idea: we want to do something at future time x. And we also might want to do something every y milliseconds. Python actually ships with a module to do this, "sched". The sched.scheduler class is powerful and general-purpose. But it's way more general than we need, and also it provides an inconvenient callback-based API. ("I don't like callback-based APIs, I always get them wrong." --GvR) How about this: class Scheduler: def __init__(self): ... def schedule(self, event, delta, repeat=False): ... def clear(self): ... def run(self): ... schedule() would add an event to the scheduler. "event" is any object, "delta" is how many ms in the future we want the event to happen, and if repeat is True the event will recur every "delta" ms thereafter. clear() would clear the current events from the schedule. run() would sleep until the next scheduled event. It would return the "event" object associated with the event. If you run() and there are no currently scheduled events, it throws an exception. I mocked this up in normal Python, attached. I also made it easy to port to the micro:bit by simulating the microbit module. To run on the microbit, just return the first couple paragraphs of stuff (it's marked) and add "import microbit" to the top. Works fine. What do you think? Anyone interested enough to work on the micro:bit implementations of these? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: button.debouncer.mockup.py Type: text/x-python Size: 2794 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: simple.scheduler.py Type: text/x-python Size: 3657 bytes Desc: not available URL: From ntoll at ntoll.org Wed Oct 7 10:51:24 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 7 Oct 2015 09:51:24 +0100 Subject: [Microbit-Python] Game API objects I want In-Reply-To: <5614D744.1090208@hastings.org> References: <5614D744.1090208@hastings.org> Message-ID: <5614DD0C.3040307@ntoll.org> My 2c... I've quickly skimmed... (I'm currently at work). Basically, I support Larry's outlook that we should put common / complicated things into a module so kids get to work on fun stuff rather than boilerplate. I'll re-read the details and respond more fully this evening or tomorrow morning depending on how busy I get (bear in mind I've just returned from PyCon India and my in-box is overflowing). I think the process we went through with the music namespace was very useful. Could we do the same again for a microbit.game module (for instance)? Think of this as being like a mini-PEP :-P ... Also, Mark's earlier emails (also on my to-reply-to list) about display/image related things are also in the same sort of problem space (there's this complicated / memory constrained thing, can we do it simpler?) Thoughts..? N. On 07/10/15 09:26, Larry Hastings wrote: > > > Having written two games on the micro:bit--one of which actually > works!--and having some previous experience writing video games, I'd > like to get up on my soap box and hold forth. > > There are a couple of technologies that /nearly //every//game/ will > use. (One that /literally every game/ will use!) And given that > they're mildly complicated to do properly, and can consume a good chunk > of the micro:bit's precious RAM to implement, I strongly suggest they be > written in C++ and provided with MicroPython on the micro:bit. I don't > know if I'm up to writing (and debugging!) them on the micro:bit > itself. Maybe I could make a first pass in normal C++ on Linux, and > someone else could port them to the micro:bit? > > I can name three such technologies, as follows. > > > *1: A debounced accelerometer scaling object* > > My slalom game simply reads the current accelerometer value, restricts > it to a specific range, then scales it down to the range I want to use > and uses the resulting value, like so: > > [-1024 1023] <- accelerometer > [ 0 | 1 | 2 | 3 | 4 ] <- slalom column > > Values lower than -1024 are ceilinged to -1024, values greater than 1023 > are floored to 1023. I then add 1024 to the value, multiply by 5, > divide by 2048, and call int(). I get a number from 0 to 4 > (inclusive). Simple, done. > > The problem is that it kind of sucks. If you hold the micro:bit /just > so/, on the border between two values (say 2 and 3) it quickly and > seemingly-randomly bounces back and forth between the two. This can > make playing slalom kind of tricky. > > Most of the code in the scrolly image demo and whack-a-mole game went > into writing a debounced accelerometer position reader class. The idea > is simple enough: instead of simply taking the range of the > accelerometer you're interested in, and scaling it to the range you > want, you also establish "dead zones" between regions like so: > > [-512 511] <- accelerometer > [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] <- range with dead zones > > Here I've labeled the dead zones with lowercase letters (a, b, c, d). > Dead zones magnified for illustrative purposes; in practice they're much > smaller. > > The idea is, the value reported when you're in a "dead zone" depends on > the previous value. The dead zones establish dynamic low-water and > high-water marks for how far you'd have to go to cross over into another > zone. > > For example, if on frame N you were clearly in zone 1: > > [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] > * > > And on frame N+1 you were in zone b: > > [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] > * > > the debounced reader would then report that you're still in zone 1. You > have to force it all the way past the dead zone for it to report you as > being in zone 2. If, on a subsequent frame P, you were definitely in > zone 2: > > [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] > * > > And on frame P+1 you were in zone b: > > [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] > * > > the debounced reader would then report that you're (still) in zone 2. > > > One way to think of it is that the dead zones prefer the zone nearest to > the previous accelerometer reading. So if the accelerometer is > currently in the spot marked with an asterisk, we can pretend that the > zones map out as follows: > > * > [ 0 | 1 | 2 | 3 | 4 ] > > * > [ 0 | 1 | 2 | 3 | 4 ] > > * > [ 0 | 1 | 2 | 3 | 4 ] > > * > [ 0 | 1 | 2 | 3 | 4 ] > > * > [ 0 | 1 | 2 | 3 | 4 ] > > > Long story short, the reason the scrolly image demo is so pleasant to > use is because of this debounced accelerometer class. If I didn't have > that, it'd have the same bouncing-between-two-values problem that the > slalom game has. I suggest that most games on the micro:bit will use > the accelerometer, and if they simply scale it they'll have the bouncing > problem. > > Of course, my debounced accelerometer class appears to consume most of > the RAM of the micro:bit. And that's /after/ I hard-coded it to some of > the behavior I wanted. A general-purpose debounced accelerometer class > might not even fit! > > I could write a simple class that does this in C++, and let somebody > else who understands MicroPython could port it to the runtime and get it > working on the micro:bit. > > I think the API would look something like this: > > class AccelerometerScalingDebouncer: > def __init__(self, fn, input_min, input_max, output_min, > output_max, dead_zone=0.08): > ... > def read(self): > ... > > fn would be the function to call to do a reading (like > microbit.accelerometer.get_x). input_min and input_max would establish > the range we'd clip the input to. output_min and output_max would > establish the range of values returned (inclusive). dead_zone would > establish how big the dead zone around each value would be, and we could > hide this from the students (or handwave it away, "don't worry about it, > it does the right thing for you"). > > read() would read the current value, clip it, debounce it, scale it, and > return the resulting value. > > Again, you can see a working example of a class like this in my "scrolly > image" demo. I've attached it here so you don't have to go hunting for > it. It runs on the micro:bit. > > > *2: A debounced reader for all the buttons* > > A moment's thought suggests: we want a debounced button class, too. > Both my games used the buttons, and I had to write debouncing code for both. > > The basic idea: if the user presses the button, you often want to > process the button press exactly once. So code like this doesn't work: > > next_frame = 0 > while True: > delta = next_frame - microbit.time() > if delta > 0: > microbit.sleep(delta) > continue > next_frame = microbit.time() + 50 > if microbit.button_a.is_pressed(): > do_thing() > > The problem: if the user holds down the button, you'll call do_thing() > every 50ms. > > I've seen people mention that there's actually an event queue in the > DAL. Maybe just exposing this somehow is sufficient? > > I think what I want is an object like this: > > class ButtonDebouncer: > def __init__(self, a=True, b=True, both=False, delay=100): > ... > def poll(self): > ... > def a_pressed(self): > ... > def b_pressed(self): > ... > def both_pressed(self): > ... > > You pass in to the constructor booleans indicating which buttons you > care about: a, b, or both. If both=True and either a=True or b=True, > "delay" indicates how long to wait after one button is pressed before > giving up and assuming we're not getting both buttons pressed. > > If you press and hold button A, after the next time you call poll(), > a_pressed() would return True /once/. After that first time it would > return False until you released A, called poll(), then pressed A and > called poll().// > > The object would internally use microbit.time() for time. __init__ > would call poll(). > > I tried to write an example of this in Python for the micro:bit. > However my first try hit a MemoryError. (Argh! Double-argh!) So I've > attached my attempt, which you can consider a non-working mockup. > > > *3: A simple scheduler* > > /Every/ realtime game would want this. And I doubt people will write > non-realtime games on the micro:bit. > > The basic idea: we want to do something at future time x. And we also > might want to do something every y milliseconds. > > Python actually ships with a module to do this, "sched". The > sched.scheduler class is powerful and general-purpose. But it's way > more general than we need, and also it provides an inconvenient > callback-based API. ("I don't like callback-based APIs, I always get > them wrong." --GvR) > > How about this: > > class Scheduler: > def __init__(self): > ... > def schedule(self, event, delta, repeat=False): > ... > def clear(self): > ... > def run(self): > ... > > > schedule() would add an event to the scheduler. "event" is any object, > "delta" is how many ms in the future we want the event to happen, and if > repeat is True the event will recur every "delta" ms thereafter. > > clear() would clear the current events from the schedule. > > run() would sleep until the next scheduled event. It would return the > "event" object associated with the event. If you run() and there are no > currently scheduled events, it throws an exception. > > I mocked this up in normal Python, attached. I also made it easy to > port to the micro:bit by simulating the microbit module. To run on the > microbit, just return the first couple paragraphs of stuff (it's marked) > and add "import microbit" to the top. Works fine. > > > What do you think? Anyone interested enough to work on the micro:bit > implementations of these? > > > //arry/ > > > _______________________________________________ > 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: From david at thinkingbinaries.com Wed Oct 7 11:41:11 2015 From: david at thinkingbinaries.com (David Whale) Date: Wed, 7 Oct 2015 10:41:11 +0100 Subject: [Microbit-Python] Game API objects I want In-Reply-To: <5614DD0C.3040307@ntoll.org> References: <5614D744.1090208@hastings.org> <5614DD0C.3040307@ntoll.org> Message-ID: Have we got any way of importing modules yet - that would be a way to provide additional functionality needing to extend the core API. It also means these things could be added and tested *after* release, rather than delaying the release. D ___________________________________________________________ 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 October 2015 at 09:51, Nicholas H.Tollervey wrote: > My 2c... > > I've quickly skimmed... (I'm currently at work). > > Basically, I support Larry's outlook that we should put common / > complicated things into a module so kids get to work on fun stuff rather > than boilerplate. > > I'll re-read the details and respond more fully this evening or tomorrow > morning depending on how busy I get (bear in mind I've just returned > from PyCon India and my in-box is overflowing). > > I think the process we went through with the music namespace was very > useful. Could we do the same again for a microbit.game module (for > instance)? Think of this as being like a mini-PEP :-P ... Also, Mark's > earlier emails (also on my to-reply-to list) about display/image related > things are also in the same sort of problem space (there's this > complicated / memory constrained thing, can we do it simpler?) > > Thoughts..? > > N. > > On 07/10/15 09:26, Larry Hastings wrote: > > > > > > Having written two games on the micro:bit--one of which actually > > works!--and having some previous experience writing video games, I'd > > like to get up on my soap box and hold forth. > > > > There are a couple of technologies that /nearly //every//game/ will > > use. (One that /literally every game/ will use!) And given that > > they're mildly complicated to do properly, and can consume a good chunk > > of the micro:bit's precious RAM to implement, I strongly suggest they be > > written in C++ and provided with MicroPython on the micro:bit. I don't > > know if I'm up to writing (and debugging!) them on the micro:bit > > itself. Maybe I could make a first pass in normal C++ on Linux, and > > someone else could port them to the micro:bit? > > > > I can name three such technologies, as follows. > > > > > > *1: A debounced accelerometer scaling object* > > > > My slalom game simply reads the current accelerometer value, restricts > > it to a specific range, then scales it down to the range I want to use > > and uses the resulting value, like so: > > > > [-1024 1023] <- accelerometer > > [ 0 | 1 | 2 | 3 | 4 ] <- slalom column > > > > Values lower than -1024 are ceilinged to -1024, values greater than 1023 > > are floored to 1023. I then add 1024 to the value, multiply by 5, > > divide by 2048, and call int(). I get a number from 0 to 4 > > (inclusive). Simple, done. > > > > The problem is that it kind of sucks. If you hold the micro:bit /just > > so/, on the border between two values (say 2 and 3) it quickly and > > seemingly-randomly bounces back and forth between the two. This can > > make playing slalom kind of tricky. > > > > Most of the code in the scrolly image demo and whack-a-mole game went > > into writing a debounced accelerometer position reader class. The idea > > is simple enough: instead of simply taking the range of the > > accelerometer you're interested in, and scaling it to the range you > > want, you also establish "dead zones" between regions like so: > > > > [-512 511] <- accelerometer > > [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] <- range with dead zones > > > > Here I've labeled the dead zones with lowercase letters (a, b, c, d). > > Dead zones magnified for illustrative purposes; in practice they're much > > smaller. > > > > The idea is, the value reported when you're in a "dead zone" depends on > > the previous value. The dead zones establish dynamic low-water and > > high-water marks for how far you'd have to go to cross over into another > > zone. > > > > For example, if on frame N you were clearly in zone 1: > > > > [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] > > * > > > > And on frame N+1 you were in zone b: > > > > [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] > > * > > > > the debounced reader would then report that you're still in zone 1. You > > have to force it all the way past the dead zone for it to report you as > > being in zone 2. If, on a subsequent frame P, you were definitely in > > zone 2: > > > > [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] > > * > > > > And on frame P+1 you were in zone b: > > > > [ 0 |a| 1 |b| 2 |c| 3 |d| 4 ] > > * > > > > the debounced reader would then report that you're (still) in zone 2. > > > > > > One way to think of it is that the dead zones prefer the zone nearest to > > the previous accelerometer reading. So if the accelerometer is > > currently in the spot marked with an asterisk, we can pretend that the > > zones map out as follows: > > > > * > > [ 0 | 1 | 2 | 3 | 4 ] > > > > * > > [ 0 | 1 | 2 | 3 | 4 ] > > > > * > > [ 0 | 1 | 2 | 3 | 4 ] > > > > * > > [ 0 | 1 | 2 | 3 | 4 ] > > > > * > > [ 0 | 1 | 2 | 3 | 4 ] > > > > > > Long story short, the reason the scrolly image demo is so pleasant to > > use is because of this debounced accelerometer class. If I didn't have > > that, it'd have the same bouncing-between-two-values problem that the > > slalom game has. I suggest that most games on the micro:bit will use > > the accelerometer, and if they simply scale it they'll have the bouncing > > problem. > > > > Of course, my debounced accelerometer class appears to consume most of > > the RAM of the micro:bit. And that's /after/ I hard-coded it to some of > > the behavior I wanted. A general-purpose debounced accelerometer class > > might not even fit! > > > > I could write a simple class that does this in C++, and let somebody > > else who understands MicroPython could port it to the runtime and get it > > working on the micro:bit. > > > > I think the API would look something like this: > > > > class AccelerometerScalingDebouncer: > > def __init__(self, fn, input_min, input_max, output_min, > > output_max, dead_zone=0.08): > > ... > > def read(self): > > ... > > > > fn would be the function to call to do a reading (like > > microbit.accelerometer.get_x). input_min and input_max would establish > > the range we'd clip the input to. output_min and output_max would > > establish the range of values returned (inclusive). dead_zone would > > establish how big the dead zone around each value would be, and we could > > hide this from the students (or handwave it away, "don't worry about it, > > it does the right thing for you"). > > > > read() would read the current value, clip it, debounce it, scale it, and > > return the resulting value. > > > > Again, you can see a working example of a class like this in my "scrolly > > image" demo. I've attached it here so you don't have to go hunting for > > it. It runs on the micro:bit. > > > > > > *2: A debounced reader for all the buttons* > > > > A moment's thought suggests: we want a debounced button class, too. > > Both my games used the buttons, and I had to write debouncing code for > both. > > > > The basic idea: if the user presses the button, you often want to > > process the button press exactly once. So code like this doesn't work: > > > > next_frame = 0 > > while True: > > delta = next_frame - microbit.time() > > if delta > 0: > > microbit.sleep(delta) > > continue > > next_frame = microbit.time() + 50 > > if microbit.button_a.is_pressed(): > > do_thing() > > > > The problem: if the user holds down the button, you'll call do_thing() > > every 50ms. > > > > I've seen people mention that there's actually an event queue in the > > DAL. Maybe just exposing this somehow is sufficient? > > > > I think what I want is an object like this: > > > > class ButtonDebouncer: > > def __init__(self, a=True, b=True, both=False, delay=100): > > ... > > def poll(self): > > ... > > def a_pressed(self): > > ... > > def b_pressed(self): > > ... > > def both_pressed(self): > > ... > > > > You pass in to the constructor booleans indicating which buttons you > > care about: a, b, or both. If both=True and either a=True or b=True, > > "delay" indicates how long to wait after one button is pressed before > > giving up and assuming we're not getting both buttons pressed. > > > > If you press and hold button A, after the next time you call poll(), > > a_pressed() would return True /once/. After that first time it would > > return False until you released A, called poll(), then pressed A and > > called poll().// > > > > The object would internally use microbit.time() for time. __init__ > > would call poll(). > > > > I tried to write an example of this in Python for the micro:bit. > > However my first try hit a MemoryError. (Argh! Double-argh!) So I've > > attached my attempt, which you can consider a non-working mockup. > > > > > > *3: A simple scheduler* > > > > /Every/ realtime game would want this. And I doubt people will write > > non-realtime games on the micro:bit. > > > > The basic idea: we want to do something at future time x. And we also > > might want to do something every y milliseconds. > > > > Python actually ships with a module to do this, "sched". The > > sched.scheduler class is powerful and general-purpose. But it's way > > more general than we need, and also it provides an inconvenient > > callback-based API. ("I don't like callback-based APIs, I always get > > them wrong." --GvR) > > > > How about this: > > > > class Scheduler: > > def __init__(self): > > ... > > def schedule(self, event, delta, repeat=False): > > ... > > def clear(self): > > ... > > def run(self): > > ... > > > > > > schedule() would add an event to the scheduler. "event" is any object, > > "delta" is how many ms in the future we want the event to happen, and if > > repeat is True the event will recur every "delta" ms thereafter. > > > > clear() would clear the current events from the schedule. > > > > run() would sleep until the next scheduled event. It would return the > > "event" object associated with the event. If you run() and there are no > > currently scheduled events, it throws an exception. > > > > I mocked this up in normal Python, attached. I also made it easy to > > port to the micro:bit by simulating the microbit module. To run on the > > microbit, just return the first couple paragraphs of stuff (it's marked) > > and add "import microbit" to the top. Works fine. > > > > > > What do you think? Anyone interested enough to work on the micro:bit > > implementations of these? > > > > > > //arry/ > > > > > > _______________________________________________ > > 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: From larry at hastings.org Wed Oct 7 15:53:32 2015 From: larry at hastings.org (Larry Hastings) Date: Wed, 7 Oct 2015 06:53:32 -0700 Subject: [Microbit-Python] Game API objects I want In-Reply-To: <5614DD0C.3040307@ntoll.org> References: <5614D744.1090208@hastings.org> <5614DD0C.3040307@ntoll.org> Message-ID: <561523DC.5060207@hastings.org> I got inspired and rewrote my scheduler in C++. Well, C really. Anyway it should be reasonably easy to port to the micro:bit. Attached, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scheduler.cpp Type: text/x-c++src Size: 4346 bytes Desc: not available URL: From Jonathan.Austin at arm.com Thu Oct 8 16:47:17 2015 From: Jonathan.Austin at arm.com (Jonathan Austin) Date: Thu, 8 Oct 2015 14:47:17 +0000 Subject: [Microbit-Python] Game API objects I want In-Reply-To: <561523DC.5060207@hastings.org> References: <5614D744.1090208@hastings.org> <5614DD0C.3040307@ntoll.org> <561523DC.5060207@hastings.org> Message-ID: <9CA61D1B-A9D7-442A-B469-3D02064BED7D@arm.com> Hi Larry, > On 7 Oct 2015, at 14:53, Larry Hastings wrote: > > > I got inspired and rewrote my scheduler in C++. Well, C really. Anyway it should be reasonably easy to port to the micro:bit. > This looks sweet. I wonder, do you guys have access to Joe Finney/Lancaster University?s DAL repository? Joe has a Fiber scheduler in there, and it might be possible just to break out bits from that. Failing that, mbed has a Ticker and a Timeout class, https://developer.mbed.org/handbook/Ticker https://developer.mbed.org/handbook/Timeout that would make a very neat starting point for anyone thinking about porting this to mbed/the micro:bit Jonny > Attached, > > > /arry > _______________________________________________ > 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. From damien.p.george at gmail.com Fri Oct 9 01:02:27 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 9 Oct 2015 00:02:27 +0100 Subject: [Microbit-Python] Failed attempt at Whack-A-Mole In-Reply-To: References: <5613ABF8.4080509@hastings.org> Message-ID: Larry, the latest version of the firmware now uses less RAM and your whack-a-mole script compiles and runs. Hopefully there is enough RAM to extend that script a bit more to get it to a playable state (at the moment I don't think it works because I can't whack anything!). Attached is the firmware.hex image with the changes. Changes to the API: system_time -> running_time set_pixel_value -> set_pixel get_pixel_value -> get_pixel Let me know if you run out of RAM again... :) Cheers, Damien. On Tue, Oct 6, 2015 at 2:07 PM, Damien George wrote: >> I was thinking of accelerometer tilt driven mazes, a bit like a 5x5 window >> on one of those rolling ball bearing maze games. > > Already written! See examples/maze.py: > https://github.com/dpgeorge/microbit-micropython/blob/master/examples/maze.py -------------- next part -------------- A non-text attachment was scrubbed... Name: firmware.hex Type: application/octet-stream Size: 444112 bytes Desc: not available URL: From larry at hastings.org Fri Oct 9 03:15:42 2015 From: larry at hastings.org (Larry Hastings) Date: Thu, 8 Oct 2015 18:15:42 -0700 Subject: [Microbit-Python] Failed attempt at Whack-A-Mole In-Reply-To: References: <5613ABF8.4080509@hastings.org> Message-ID: <5617153E.10201@hastings.org> On 10/08/2015 04:02 PM, Damien George wrote: > Larry, the latest version of the firmware now uses less RAM and your > whack-a-mole script compiles and runs. I hacked your firmware into editor.html and seemingly got it correct; when I reset my micro:bit I am rewarded with Micro Python v1.4.6-56-g02041bf-dirty on 2015-10-08; And I even did the upyed insert-here thing correctly. However, my program doesn't run. Even if I only give upyed one line (print("WORK DAMN YOU")) it doesn't run. Is there some other transformation I need to do to the firmware to get it to work in upyed? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Fri Oct 9 03:30:27 2015 From: larry at hastings.org (Larry Hastings) Date: Thu, 8 Oct 2015 18:30:27 -0700 Subject: [Microbit-Python] Failed attempt at Whack-A-Mole In-Reply-To: References: <5613ABF8.4080509@hastings.org> Message-ID: <561718B3.4010205@hastings.org> p.s. I tried using tools/pyboard to copy it over. But that ran out of RAM. So... On 10/08/2015 04:02 PM, Damien George wrote: > Let me know if you run out of RAM again... :) //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Fri Oct 9 06:04:55 2015 From: larry at hastings.org (Larry Hastings) Date: Thu, 8 Oct 2015 21:04:55 -0700 Subject: [Microbit-Python] Game API objects I want In-Reply-To: <9CA61D1B-A9D7-442A-B469-3D02064BED7D@arm.com> References: <5614D744.1090208@hastings.org> <5614DD0C.3040307@ntoll.org> <561523DC.5060207@hastings.org> <9CA61D1B-A9D7-442A-B469-3D02064BED7D@arm.com> Message-ID: <56173CE7.3040307@hastings.org> On 10/07/2015 02:41 AM, David Whale wrote: > Have we got any way of importing modules yet - that would be a way to > provide additional functionality needing to extend the core API. It > also means these things could be added and tested *after* release, > rather than delaying the release. Is there a reason they shouldn't be added and tested now? On 10/08/2015 07:47 AM, Jonathan Austin wrote: > This looks sweet. I wonder, do you guys have access to Joe Finney/Lancaster > University?s DAL repository? > > Joe has a Fiber scheduler in there, and it might be possible just to break out > bits from that. I don't think I have access to that repository. Unless they're using the terminology in a different way, a Fiber is a completely unrelated concept to an event scheduler. It's a user-scheduled thread, or a continuation, kind of like Python's "yield". > Failing that, mbed has a Ticker and a Timeout class, > > https://developer.mbed.org/handbook/Ticker > https://developer.mbed.org/handbook/Timeout These are also not-exactly related. Those are both interrupt-driven callback functions. Theoretically they could be mis-used for this ability. But note the provisos: "no blocking code", "no print / malloc". I suspect it's impossible to do anything useful in Python in an ISR. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jonathan.Austin at arm.com Fri Oct 9 14:20:33 2015 From: Jonathan.Austin at arm.com (Jonathan Austin) Date: Fri, 9 Oct 2015 12:20:33 +0000 Subject: [Microbit-Python] Game API objects I want In-Reply-To: <56173CE7.3040307@hastings.org> References: <5614D744.1090208@hastings.org> <5614DD0C.3040307@ntoll.org> <561523DC.5060207@hastings.org> <9CA61D1B-A9D7-442A-B469-3D02064BED7D@arm.com> <56173CE7.3040307@hastings.org> Message-ID: > On 9 Oct 2015, at 05:04, Larry Hastings wrote: > >> >> Joe has a Fiber scheduler in there, and it might be possible just to break out >> bits from that. >> > > I don't think I have access to that repository. Hmm. Nicholas, Joe - is there a reason for that? > > Unless they're using the terminology in a different way, a Fiber is a completely unrelated concept to an event scheduler. It's a user-scheduled thread, or a continuation, kind of like Python's "yield?. I?ll let Joe comment more as he wrote all this - you?re right of course that the fibres alone aren?t going to get you the timed events, but I thought that along with the scheduler was a way to request that some work got done in a fiber after some time. I had a poke though, and can?t immediately see that? What I?d like is something that can do: fibersched.schedule_work(&work_callback, delay); fibersched.recurring_work(&work_callback, period); But instead it looks like the expected approach is to do something more like spawn a fiber and then sleep (which sleeps gracefully assuming you?re not in interrupt context), or spawn a fiber that waits for an event on the bus? Joe - what?s the ?right? way to do that in the runtime at the moment? >> Failing that, mbed has a Ticker and a Timeout class, >> >> >> https://developer.mbed.org/handbook/Ticker >> https://developer.mbed.org/handbook/Timeout > > These are also not-exactly related. Those are both interrupt-driven callback functions. Theoretically they could be mis-used for this ability. But note the provisos: "no blocking code", "no print / malloc". I suspect it's impossible to do anything useful in Python in an ISR. > Right, the way people usually build something like the scheduler you describe is to use these classes to schedule work that gets done in the main thread, so those provisos don?t matter - IE you use the ticker/timeout to adding things to a work queue. there?s a nice writeup that implements this on mbed here: https://developer.mbed.org/users/AjK/notebook/regarding-interrupts-use-and-blocking/ J > > /arry > _______________________________________________ > 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. From damien.p.george at gmail.com Fri Oct 9 16:44:17 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 9 Oct 2015 15:44:17 +0100 Subject: [Microbit-Python] Failed attempt at Whack-A-Mole In-Reply-To: <561718B3.4010205@hastings.org> References: <5613ABF8.4080509@hastings.org> <561718B3.4010205@hastings.org> Message-ID: I have added a script to the microbit-micropython repository called makecombinedhex.py; see https://github.com/dpgeorge/microbit-micropython/blob/master/tools/makecombinedhex.py You can use it like this: ./makecombinedhex.py -o combined.hex Then just copy combined.hex to the micro:bit as usual, reset, and it should work! I have tested this script with the firmware.hex I attached to the email yesterday, and with the whack-a-mole script, at it works. I don't know what's wrong with upyed... maby Nicholas can tell us? Regarding running out of RAM using tools/pyboard.py: that's not possible to fix (easily) because pyboard.py will download the entire script into RAM on the microbit first, and then compile it. So if the script is 4k then that uses already half your RAM. On Fri, Oct 9, 2015 at 2:30 AM, Larry Hastings wrote: > > p.s. I tried using tools/pyboard to copy it over. But that ran out of RAM. > So... > > > On 10/08/2015 04:02 PM, Damien George wrote: > > Let me know if you run out of RAM again... :) > > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From ntoll at ntoll.org Fri Oct 9 16:57:09 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 9 Oct 2015 15:57:09 +0100 Subject: [Microbit-Python] Failed attempt at Whack-A-Mole In-Reply-To: References: <5613ABF8.4080509@hastings.org> <561718B3.4010205@hastings.org> Message-ID: <5617D5C5.6020407@ntoll.org> On 09/10/15 15:44, Damien George wrote: > I don't know what's wrong with upyed... maby Nicholas can tell us? Hey hey... many apologies for my silence, since returning from India I've been bombarded with work to do. I intend to catch up on MicroPython / micro:bit things over the weekend. N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From j.finney at lancaster.ac.uk Sat Oct 10 00:30:38 2015 From: j.finney at lancaster.ac.uk (Finney, Joe) Date: Fri, 9 Oct 2015 22:30:38 +0000 Subject: [Microbit-Python] Game API objects I want In-Reply-To: References: <5614D744.1090208@hastings.org> <5614DD0C.3040307@ntoll.org> <561523DC.5060207@hastings.org> <9CA61D1B-A9D7-442A-B469-3D02064BED7D@arm.com> <56173CE7.3040307@hastings.org> Message-ID: <052A0FA2625F4047A69AED33E191ACB023B55E7F@EX-1-MB1.lancs.local> Hi Folks, If I understand what you're after correctly, you're looking to schedule some work to be done in the future (either as a one shot or recurring condition). Normally, most folks have done this as Jonny has described - just launch a fiber and perform a sleep, and put this in a loop for a recurring condition. Having functionality to scheduke a callback in the future would be quite compelling though, as it's a very clean abstraction and provides a more absolute notion of time compared to the approach above, and it's not very hard to achieve. We don't have any specific APIs for this at the moment, but some of the underlying mechanisms (fiber scheduler + message bus/eventing) should make this fairly straightforward to implement. The easiest way to do this on top of the micro:bit DAL API would be to write our handler as a standard message bus listener, and register it with the message bus to receive user defined event. This will handle all the callback functionality for you, and support multiple callbacks on the same event timer. e.g. void work_callback(MicroBitEvent e) { // do stuff. } We could then write a function or two for the fiber scheduler that keep queue of times at which to send events (there are wait queue much like this in there already). Then, during the period fiber scheduler timer interrupt, fire off the appropriate event which then triggers the event handler. If you think this would add value for you guys, do shout and we'll see if we can help out. p.s. I don't always have time to read all the mailing lists I'm on I'm afraid - if you want to grab me, please just cite my github username @finneyj in the email somewhere, and it'll get flagged up in my inbox. :-) best, joe -----Original Message----- From: Microbit [mailto:microbit-bounces+j.finney=lancaster.ac.uk at python.org] On Behalf Of Jonathan Austin Sent: 09 October 2015 13:21 To: For Pythonic MicroBit related disucssions Subject: Re: [Microbit-Python] Game API objects I want > On 9 Oct 2015, at 05:04, Larry Hastings wrote: > >> >> Joe has a Fiber scheduler in there, and it might be possible just to >> break out bits from that. >> > > I don't think I have access to that repository. Hmm. Nicholas, Joe - is there a reason for that? > > Unless they're using the terminology in a different way, a Fiber is a completely unrelated concept to an event scheduler. It's a user-scheduled thread, or a continuation, kind of like Python's "yield". I'll let Joe comment more as he wrote all this - you're right of course that the fibres alone aren't going to get you the timed events, but I thought that along with the scheduler was a way to request that some work got done in a fiber after some time. I had a poke though, and can't immediately see that... What I'd like is something that can do: fibersched.schedule_work(&work_callback, delay); fibersched.recurring_work(&work_callback, period); But instead it looks like the expected approach is to do something more like spawn a fiber and then sleep (which sleeps gracefully assuming you're not in interrupt context), or spawn a fiber that waits for an event on the bus... Joe - what's the 'right' way to do that in the runtime at the moment? >> Failing that, mbed has a Ticker and a Timeout class, >> >> >> https://developer.mbed.org/handbook/Ticker >> https://developer.mbed.org/handbook/Timeout > > These are also not-exactly related. Those are both interrupt-driven callback functions. Theoretically they could be mis-used for this ability. But note the provisos: "no blocking code", "no print / malloc". I suspect it's impossible to do anything useful in Python in an ISR. > Right, the way people usually build something like the scheduler you describe is to use these classes to schedule work that gets done in the main thread, so those provisos don't matter - IE you use the ticker/timeout to adding things to a work queue. there's a nice writeup that implements this on mbed here: https://developer.mbed.org/users/AjK/notebook/regarding-interrupts-use-and-blocking/ J > > /arry > _______________________________________________ > 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. _______________________________________________ Microbit mailing list Microbit at python.org https://mail.python.org/mailman/listinfo/microbit From damien.p.george at gmail.com Sat Oct 10 00:59:37 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 9 Oct 2015 23:59:37 +0100 Subject: [Microbit-Python] Game API objects I want In-Reply-To: <052A0FA2625F4047A69AED33E191ACB023B55E7F@EX-1-MB1.lancs.local> References: <5614D744.1090208@hastings.org> <5614DD0C.3040307@ntoll.org> <561523DC.5060207@hastings.org> <9CA61D1B-A9D7-442A-B469-3D02064BED7D@arm.com> <56173CE7.3040307@hastings.org> <052A0FA2625F4047A69AED33E191ACB023B55E7F@EX-1-MB1.lancs.local> Message-ID: We can't use fibers in MicroPython because there is not enough RAM to swap the stack out. The best we can do is run the system tick handler on an interrupt, or the idle handlers within the same stack as the main fiber (and only to run C-level code, not Python code). We have discussed tasks/fibers/multitasking a few times already and I think the consensus is that MicroPython will expose a pure sequential execution model. Anything more than that is too difficult considering the target audience, and also not necessary. We can of course do event scheduling in pure Python, or even with some help from C-land for efficiency. Larry's proposed Scheduler class is, I think, a great idea and does not introduce complexity of multitasking. Please see https://github.com/dpgeorge/microbit-micropython/issues/36 for further discussion on this topic. On Fri, Oct 9, 2015 at 11:30 PM, Finney, Joe wrote: > Hi Folks, > > If I understand what you're after correctly, you're looking to schedule some work to be done in the future (either as a one shot or recurring condition). Normally, most folks have done this as Jonny has described - just launch a fiber and perform a sleep, and put this in a loop for a recurring condition. > > Having functionality to scheduke a callback in the future would be quite compelling though, as it's a very clean abstraction and provides a more absolute notion of time compared to the approach above, and it's not very hard to achieve. We don't have any specific APIs for this at the moment, but some of the underlying mechanisms (fiber scheduler + message bus/eventing) should make this fairly straightforward to implement. > > The easiest way to do this on top of the micro:bit DAL API would be to write our handler as a standard message bus listener, and register it with the message bus to receive user defined event. This will handle all the callback functionality for you, and support multiple callbacks on the same event timer. > e.g. > > void work_callback(MicroBitEvent e) > { > // do stuff. > } > > We could then write a function or two for the fiber scheduler that keep queue of times at which to send events (there are wait queue much like this in there already). Then, during the period fiber scheduler timer interrupt, fire off the appropriate event which then triggers the event handler. > > If you think this would add value for you guys, do shout and we'll see if we can help out. > > p.s. I don't always have time to read all the mailing lists I'm on I'm afraid - if you want to grab me, please just cite my github username @finneyj in the email somewhere, and it'll get flagged up in my inbox. :-) > > best, > joe > > > -----Original Message----- > From: Microbit [mailto:microbit-bounces+j.finney=lancaster.ac.uk at python.org] On Behalf Of Jonathan Austin > Sent: 09 October 2015 13:21 > To: For Pythonic MicroBit related disucssions > Subject: Re: [Microbit-Python] Game API objects I want > > >> On 9 Oct 2015, at 05:04, Larry Hastings wrote: >> >>> >>> Joe has a Fiber scheduler in there, and it might be possible just to >>> break out bits from that. >>> >> >> I don't think I have access to that repository. > > Hmm. Nicholas, Joe - is there a reason for that? > >> >> Unless they're using the terminology in a different way, a Fiber is a completely unrelated concept to an event scheduler. It's a user-scheduled thread, or a continuation, kind of like Python's "yield". > > I'll let Joe comment more as he wrote all this - you're right of course that the fibres alone aren't going to get you the timed events, but I thought that along with the scheduler was a way to request that some work got done in a fiber after some time. > > I had a poke though, and can't immediately see that... What I'd like is something that can do: > > fibersched.schedule_work(&work_callback, delay); fibersched.recurring_work(&work_callback, period); > > But instead it looks like the expected approach is to do something more like spawn a fiber and then sleep (which sleeps gracefully assuming you're not in interrupt context), or spawn a fiber that waits for an event on the bus... > > Joe - what's the 'right' way to do that in the runtime at the moment? > >>> Failing that, mbed has a Ticker and a Timeout class, >>> >>> >>> https://developer.mbed.org/handbook/Ticker >>> https://developer.mbed.org/handbook/Timeout >> >> These are also not-exactly related. Those are both interrupt-driven callback functions. Theoretically they could be mis-used for this ability. But note the provisos: "no blocking code", "no print / malloc". I suspect it's impossible to do anything useful in Python in an ISR. >> > > Right, the way people usually build something like the scheduler you describe is to use these classes to schedule work that gets done in the main thread, so those provisos don't matter - IE you use the ticker/timeout to adding things to a work queue. > > there's a nice writeup that implements this on mbed here: > https://developer.mbed.org/users/AjK/notebook/regarding-interrupts-use-and-blocking/ > > J >> >> /arry >> _______________________________________________ >> 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. > > _______________________________________________ > 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 From j.finney at lancaster.ac.uk Sat Oct 10 01:29:03 2015 From: j.finney at lancaster.ac.uk (Finney, Joe) Date: Fri, 9 Oct 2015 23:29:03 +0000 Subject: [Microbit-Python] Game API objects I want In-Reply-To: References: <5614D744.1090208@hastings.org> <5614DD0C.3040307@ntoll.org> <561523DC.5060207@hastings.org> <9CA61D1B-A9D7-442A-B469-3D02064BED7D@arm.com> <56173CE7.3040307@hastings.org> <052A0FA2625F4047A69AED33E191ACB023B55E7F@EX-1-MB1.lancs.local> Message-ID: <052A0FA2625F4047A69AED33E191ACB023B55F90@EX-1-MB1.lancs.local> Thanks Damien, Apologies - didn't mean to re-open a can of worms that you guys have neatly put a lid on. I agree that a scheduler class seems like a fine approach. Purely for info though - an event listener in the micro:bit runtime isn't necessarily concurrent. There's an optional flag at the end of the listen() method when it is registered that defines the behaviour - basically either 're-entrant', 'queue' or 'drop' in the case of events being fired whilst a handler is busy... It sounds like one of the last options might help. Best, joe -----Original Message----- From: Microbit [mailto:microbit-bounces+j.finney=lancaster.ac.uk at python.org] On Behalf Of Damien George Sent: 10 October 2015 00:00 To: For Pythonic MicroBit related disucssions Subject: Re: [Microbit-Python] Game API objects I want We can't use fibers in MicroPython because there is not enough RAM to swap the stack out. The best we can do is run the system tick handler on an interrupt, or the idle handlers within the same stack as the main fiber (and only to run C-level code, not Python code). We have discussed tasks/fibers/multitasking a few times already and I think the consensus is that MicroPython will expose a pure sequential execution model. Anything more than that is too difficult considering the target audience, and also not necessary. We can of course do event scheduling in pure Python, or even with some help from C-land for efficiency. Larry's proposed Scheduler class is, I think, a great idea and does not introduce complexity of multitasking. Please see https://github.com/dpgeorge/microbit-micropython/issues/36 for further discussion on this topic. On Fri, Oct 9, 2015 at 11:30 PM, Finney, Joe wrote: > Hi Folks, > > If I understand what you're after correctly, you're looking to schedule some work to be done in the future (either as a one shot or recurring condition). Normally, most folks have done this as Jonny has described - just launch a fiber and perform a sleep, and put this in a loop for a recurring condition. > > Having functionality to scheduke a callback in the future would be quite compelling though, as it's a very clean abstraction and provides a more absolute notion of time compared to the approach above, and it's not very hard to achieve. We don't have any specific APIs for this at the moment, but some of the underlying mechanisms (fiber scheduler + message bus/eventing) should make this fairly straightforward to implement. > > The easiest way to do this on top of the micro:bit DAL API would be to write our handler as a standard message bus listener, and register it with the message bus to receive user defined event. This will handle all the callback functionality for you, and support multiple callbacks on the same event timer. > e.g. > > void work_callback(MicroBitEvent e) > { > // do stuff. > } > > We could then write a function or two for the fiber scheduler that keep queue of times at which to send events (there are wait queue much like this in there already). Then, during the period fiber scheduler timer interrupt, fire off the appropriate event which then triggers the event handler. > > If you think this would add value for you guys, do shout and we'll see if we can help out. > > p.s. I don't always have time to read all the mailing lists I'm on I'm afraid - if you want to grab me, please just cite my github username @finneyj in the email somewhere, and it'll get flagged up in my inbox. :-) > > best, > joe > > > -----Original Message----- > From: Microbit [mailto:microbit-bounces+j.finney=lancaster.ac.uk at python.org] On Behalf Of Jonathan Austin > Sent: 09 October 2015 13:21 > To: For Pythonic MicroBit related disucssions > Subject: Re: [Microbit-Python] Game API objects I want > > >> On 9 Oct 2015, at 05:04, Larry Hastings wrote: >> >>> >>> Joe has a Fiber scheduler in there, and it might be possible just to >>> break out bits from that. >>> >> >> I don't think I have access to that repository. > > Hmm. Nicholas, Joe - is there a reason for that? > >> >> Unless they're using the terminology in a different way, a Fiber is a completely unrelated concept to an event scheduler. It's a user-scheduled thread, or a continuation, kind of like Python's "yield". > > I'll let Joe comment more as he wrote all this - you're right of course that the fibres alone aren't going to get you the timed events, but I thought that along with the scheduler was a way to request that some work got done in a fiber after some time. > > I had a poke though, and can't immediately see that... What I'd like is something that can do: > > fibersched.schedule_work(&work_callback, delay); fibersched.recurring_work(&work_callback, period); > > But instead it looks like the expected approach is to do something more like spawn a fiber and then sleep (which sleeps gracefully assuming you're not in interrupt context), or spawn a fiber that waits for an event on the bus... > > Joe - what's the 'right' way to do that in the runtime at the moment? > >>> Failing that, mbed has a Ticker and a Timeout class, >>> >>> >>> https://developer.mbed.org/handbook/Ticker >>> https://developer.mbed.org/handbook/Timeout >> >> These are also not-exactly related. Those are both interrupt-driven callback functions. Theoretically they could be mis-used for this ability. But note the provisos: "no blocking code", "no print / malloc". I suspect it's impossible to do anything useful in Python in an ISR. >> > > Right, the way people usually build something like the scheduler you describe is to use these classes to schedule work that gets done in the main thread, so those provisos don't matter - IE you use the ticker/timeout to adding things to a work queue. > > there's a nice writeup that implements this on mbed here: > https://developer.mbed.org/users/AjK/notebook/regarding-interrupts-use-and-blocking/ > > J >> >> /arry >> _______________________________________________ >> 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. > > _______________________________________________ > 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 From larry at hastings.org Sat Oct 10 09:06:30 2015 From: larry at hastings.org (Larry Hastings) Date: Sat, 10 Oct 2015 00:06:30 -0700 Subject: [Microbit-Python] Game API objects I want In-Reply-To: References: <5614D744.1090208@hastings.org> <5614DD0C.3040307@ntoll.org> <561523DC.5060207@hastings.org> <9CA61D1B-A9D7-442A-B469-3D02064BED7D@arm.com> <56173CE7.3040307@hastings.org> <052A0FA2625F4047A69AED33E191ACB023B55E7F@EX-1-MB1.lancs.local> Message-ID: <5618B8F6.5030209@hastings.org> On 10/09/2015 03:59 PM, Damien George wrote: > Larry's proposed Scheduler class is, > I think, a great idea and does not introduce complexity of > multitasking. > I'm glad to hear it! Because... it's done! And so are the other two classes I proposed. https://bitbucket.org/larry/microbit_game Has documentation and tests. For those of you unfamiliar with Mercurial, use % hg clone https://bitbucket.org/larry/microbit_game to make a local clone. Cheers, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Mon Oct 12 02:07:16 2015 From: larry at hastings.org (Larry Hastings) Date: Sun, 11 Oct 2015 17:07:16 -0700 Subject: [Microbit-Python] Interval boundaries... what did we decide? Message-ID: <561AF9B4.2020309@hastings.org> I remember a discussion about how micro:bit APIs should expect/describe intervals. What did we decide? Should they be closed? Or should they be left-closed right-open like the Python convention? I'm not trying to reopen the debate, I just want to know what we decided. (Though I'd be interested to re-read the debate if anybody remembers where it is...) Cheers, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Mon Oct 12 03:18:56 2015 From: sparks.m at gmail.com (Michael) Date: Mon, 12 Oct 2015 02:18:56 +0100 Subject: [Microbit-Python] Interval boundaries... what did we decide? In-Reply-To: <561AF9B4.2020309@hastings.org> References: <561AF9B4.2020309@hastings.org> Message-ID: IMO they should match range(5), list_things[5:], etc - ie left-closed right-open like the Python convention - otherwise people will be forever thinking "why is this one like this and that one like that". (I don't remember seeing a written debate about this fwiw) That said, I think any given system is could allowed one exception (and just one, so you really have to be picky :) ) that proves the rule though. Otherwise you end up with my "favourite" - ie most loathed - example of a rule with exceptions -- "i before e except after c". Since, aside from this ... $ egrep ^[^c]*ie /usr/share/dict/words|wc -l 3597 $ egrep ^[^c]*ei /usr/share/dict/words|wc -l 730 $ egrep c.*ie /usr/share/dict/words|wc -l 907 $ egrep c.*ei /usr/share/dict/words|wc -l 119 $ egrep cei /usr/share/dict/words|wc -l 65 $ egrep cie /usr/share/dict/words|wc -l 181 ... proving just how bad the rule is, "science" disagrees with it too... Michael. On 12 October 2015 at 01:07, Larry Hastings wrote: > > > I remember a discussion about how micro:bit APIs should expect/describe > intervals. What did we decide? Should they be closed? Or should they be > left-closed right-open like the Python convention? > > I'm not trying to reopen the debate, I just want to know what we decided. > (Though I'd be interested to re-read the debate if anybody remembers where > it is...) > > Cheers, > > > */arry* > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Mon Oct 12 05:09:48 2015 From: larry at hastings.org (Larry Hastings) Date: Sun, 11 Oct 2015 20:09:48 -0700 Subject: [Microbit-Python] Resolution on micro:bit timer is, uh, not great Message-ID: <561B247C.8070000@hastings.org> I just measured the granularity of microbit.system_time(). Consider this program: import microbit as m start = m.system_time() t = start trials = 300 for i in range(trials): while True: t2 = m.system_time() if t2 != t: break print(i, "delta", t2 - t) t = t2 end = m.system_time() print(trials, "calls to system_time took", end - start) That prints "delta 6" 300 times. And the final line says "300 calls to system_time took 1800". In short: if you call microbit.system_time(), and it returns X, the next time you call it it will either return X or X + 6. Similarly, microbit.sleep() has a granularity of 6ms. If you call it with a random number, it will never be early, but it will on average be 3ms late. Is this fixable? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Mon Oct 12 05:46:35 2015 From: larry at hastings.org (Larry Hastings) Date: Sun, 11 Oct 2015 20:46:35 -0700 Subject: [Microbit-Python] Resolution on micro:bit timer is, uh, not great In-Reply-To: <561B247C.8070000@hastings.org> References: <561B247C.8070000@hastings.org> Message-ID: <561B2D1B.2070305@hastings.org> On 10/11/2015 08:09 PM, Larry Hastings wrote: > In short: if you call microbit.system_time(), and it returns X, the > next time you call it it will either return X or X + 6. > > Similarly, microbit.sleep() has a granularity of 6ms. If you call it > with a random number, it will never be early, but it will on average > be 3ms late. > > > Is this fixable? The answer: yes. Apparently on the micro:bit, the "fiber" scheduler is running. And there's a configuration variable: FIBER_TICK_PERIOD_MS. Default value: 6. So the ISR that services the fiber scheduler wakes up every 6ms. I guess we can't turn off the fiber scheduler, because that's how we do background animations. Could we change system_time from just returning "ticks" to returning us_ticker_read()? Could we change the frequency of the fiber scheduler ISR to 1ms while performing a sleep()? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Mon Oct 12 05:53:09 2015 From: larry at hastings.org (Larry Hastings) Date: Sun, 11 Oct 2015 20:53:09 -0700 Subject: [Microbit-Python] Resolution on micro:bit timer is, uh, not great In-Reply-To: <561B2D1B.2070305@hastings.org> References: <561B247C.8070000@hastings.org> <561B2D1B.2070305@hastings.org> Message-ID: <561B2EA5.2050303@hastings.org> On 10/11/2015 08:46 PM, Larry Hastings wrote: > Could we change system_time from just returning "ticks" to returning > us_ticker_read()? > > Could we change the frequency of the fiber scheduler ISR to 1ms while > performing a sleep()? If the answer is "sure" and "nope", then I (or we) can change sleep() to sleep until 6ms before the wakeup time, then busy-sleep until we've completed the interval. (By busy-sleep I mean checking the time in a tight loop until it's time to wake up, without actually sleeping.) //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Mon Oct 12 09:08:06 2015 From: larry at hastings.org (Larry Hastings) Date: Mon, 12 Oct 2015 00:08:06 -0700 Subject: [Microbit-Python] How does GC work in micro:bit MicroPython? Message-ID: <561B5C56.8030703@hastings.org> I don't see any registration for gc finalizers. No __del__ anywhere. So how do objects get cleaned up? For example, the constructor for microbit.Image creates a "new MicroBitImage()" object. Where is this object deleted? Does it just walk the /entire/ heap, use a heuristic to find things that "look" like pointers, and recycle anything that it believes isn't reachable? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at hotpy.org Mon Oct 12 10:12:48 2015 From: mark at hotpy.org (Mark Shannon) Date: Mon, 12 Oct 2015 09:12:48 +0100 Subject: [Microbit-Python] Interval boundaries... what did we decide? In-Reply-To: References: <561AF9B4.2020309@hastings.org> Message-ID: <561B6B80.2060609@hotpy.org> There is another way to express a range: (start, length). For example, I have followed the DAL API for Image.crop() which is Image.crop(x, y, width, height). I think that API is easier to understand (if a little clumsier in practice) than Image.crop(xstart, ystart, xend, yend). If I recall correctly, we also decided to avoid using square brackets in the API, which makes consistency with list[], a bit less important. If you do need a range, however, it should definitely be left-closed, right-open. Cheers, Mark. On 12/10/15 02:18, Michael wrote: > IMO they should match range(5), list_things[5:], etc - ie left-closed > right-open like the Python convention - otherwise people will be forever > thinking "why is this one like this and that one like that". (I don't > remember seeing a written debate about this fwiw) That said, I think any > given system is could allowed one exception (and just one, so you really > have to be picky :) ) that proves the rule though. > > > > Otherwise you end up with my "favourite" - ie most loathed - example of > a rule with exceptions -- "i before e except after c". > > Since, aside from this ... > > $ egrep ^[^c]*ie /usr/share/dict/words|wc -l > 3597 > $ egrep ^[^c]*ei /usr/share/dict/words|wc -l > 730 > $ egrep c.*ie /usr/share/dict/words|wc -l > 907 > $ egrep c.*ei /usr/share/dict/words|wc -l > 119 > $ egrep cei /usr/share/dict/words|wc -l > 65 > $ egrep cie /usr/share/dict/words|wc -l > 181 > > ... proving just how bad the rule is, "science" disagrees with it too... > > > Michael. > > On 12 October 2015 at 01:07, Larry Hastings > wrote: > > > > I remember a discussion about how micro:bit APIs should > expect/describe intervals. What did we decide? Should they be > closed? Or should they be left-closed right-open like the Python > convention? > > I'm not trying to reopen the debate, I just want to know what we > decided. (Though I'd be interested to re-read the debate if anybody > remembers where it is...) > > Cheers, > > > //arry/ > > _______________________________________________ > 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 > From mark at hotpy.org Mon Oct 12 10:19:08 2015 From: mark at hotpy.org (Mark Shannon) Date: Mon, 12 Oct 2015 09:19:08 +0100 Subject: [Microbit-Python] How does GC work in micro:bit MicroPython? In-Reply-To: <561B5C56.8030703@hastings.org> References: <561B5C56.8030703@hastings.org> Message-ID: <561B6CFC.4080005@hotpy.org> Any Python objects that allocate memory on the C++ heap are just trouble. Explicitly freeing them in the finalizer would mostly work, but it is expensive and error prone. It is much better to make sure that we don't use malloc and/or new in any objects in the first place. I've got a PR that fixes Image and the display, but there other cases where this still happens. Mark. On 12/10/15 08:08, Larry Hastings wrote: > > > I don't see any registration for gc finalizers. No __del__ anywhere. > So how do objects get cleaned up? > > For example, the constructor for microbit.Image creates a "new > MicroBitImage()" object. Where is this object deleted? > > Does it just walk the /entire/ heap, use a heuristic to find things that > "look" like pointers, and recycle anything that it believes isn't reachable? > > > //arry/ > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From larry at hastings.org Mon Oct 12 10:23:00 2015 From: larry at hastings.org (Larry Hastings) Date: Mon, 12 Oct 2015 01:23:00 -0700 Subject: [Microbit-Python] How does GC work in micro:bit MicroPython? In-Reply-To: <561B6CFC.4080005@hotpy.org> References: <561B5C56.8030703@hastings.org> <561B6CFC.4080005@hotpy.org> Message-ID: <561B6DE4.5010607@hastings.org> On 10/12/2015 01:19 AM, Mark Shannon wrote: > Any Python objects that allocate memory on the C++ heap are just > trouble. Explicitly freeing them in the finalizer would mostly work, > but it is expensive and error prone. It is much better to make sure > that we don't use malloc and/or new in any objects in the first place. > > I've got a PR that fixes Image and the display, but there other cases > where this still happens. My button minder also has two dynamically-allocated internal button objects, but I could switch those to statically-allocated structures inside if I have to. I can deal with that. But: my scheduler has a dynamically allocated list of event structures. That really can't be a fixed size. What do you suggest? I could make it a MP list of MP tuples but now we're allocating loads more objects. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Mon Oct 12 10:30:49 2015 From: larry at hastings.org (Larry Hastings) Date: Mon, 12 Oct 2015 01:30:49 -0700 Subject: [Microbit-Python] Interval boundaries... what did we decide? In-Reply-To: <561B6B80.2060609@hotpy.org> References: <561AF9B4.2020309@hastings.org> <561B6B80.2060609@hotpy.org> Message-ID: <561B6FB9.3010108@hastings.org> On 10/12/2015 01:12 AM, Mark Shannon wrote: > > There is another way to express a range: (start, length). > For example, I have followed the DAL API for Image.crop() which is > Image.crop(x, y, width, height). > I think that API is easier to understand (if a little clumsier in > practice) than Image.crop(xstart, ystart, xend, yend). > > If I recall correctly, we also decided to avoid using square brackets > in the API, which makes consistency with list[], a bit less important. > > If you do need a range, however, it should definitely be left-closed, > right-open. Consistency with Python slicing is not important, perhaps, but microbit.random(x) returns a number [0, x), and of course we have range(x) iterating over the interval [0, x). It's all over the place in Python, and it's snuck into MicroPython too, and I just wanted to confirm that we had our story straight and we weren't trying to hide this detail from the kids for fear of confusing them. I thought I remembered a conversation where we said "ranges should include both endpoints as that's less confusing for kids". But it sounds like we're all in agreement: it should all be left-closed right-open intervals. (Anyway, surely it'd be /more/ confusing if some functions took left-closed right-open intervals and others took closed intervals?) My accelerator-scaler device takes two ranges: the start & end for the input (from the accelerometer), and the start & end for the output (what will be returned). Therefore this: scaler = microbit.game.Scaler(-512, 512, 0, 5) should say "take the input from [512, 512) and map it to the range [0, 5)". As in, it will ignore inputs less than -512 and greater than 511, and will return 0, 1, 2, 3, or 4, but never -1 or 5. Yes? Your lack of reply will be interpreted as silent assent. //arry/ p.s. (x, y, width, height) is pretty common for image APIs. You see (xstart, ystart, xend, yend) now and then too but it's less common. And yes I generally prefer the former. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at hotpy.org Mon Oct 12 10:36:19 2015 From: mark at hotpy.org (Mark Shannon) Date: Mon, 12 Oct 2015 09:36:19 +0100 Subject: [Microbit-Python] How does GC work in micro:bit MicroPython? In-Reply-To: <561B6DE4.5010607@hastings.org> References: <561B5C56.8030703@hastings.org> <561B6CFC.4080005@hotpy.org> <561B6DE4.5010607@hastings.org> Message-ID: <561B7103.8030308@hotpy.org> On 12/10/15 09:23, Larry Hastings wrote: > On 10/12/2015 01:19 AM, Mark Shannon wrote: >> Any Python objects that allocate memory on the C++ heap are just >> trouble. Explicitly freeing them in the finalizer would mostly work, >> but it is expensive and error prone. It is much better to make sure >> that we don't use malloc and/or new in any objects in the first place. >> >> I've got a PR that fixes Image and the display, but there other cases >> where this still happens. > > My button minder also has two dynamically-allocated internal button > objects, but I could switch those to statically-allocated structures > inside if I have to. I can deal with that. You'll need to make your button minder a MicroPython object anyway, so it should be allocated on the MicroPython heap instead. OOI, would it be possible to add the additional functionality to the pre-existing button object? > > But: my scheduler has a dynamically allocated list of event structures. > That really can't be a fixed size. What do you suggest? I could make > it a MP list of MP tuples but now we're allocating loads more objects. Perhaps a list of custom events objects would be more efficient. Whether custom object or tuple, it should be MicroPython objects all the way down :) Mark. > > > //arry/ > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From ntoll at ntoll.org Mon Oct 12 10:41:34 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Mon, 12 Oct 2015 09:41:34 +0100 Subject: [Microbit-Python] Interval boundaries... what did we decide? In-Reply-To: <561B6FB9.3010108@hastings.org> References: <561AF9B4.2020309@hastings.org> <561B6B80.2060609@hotpy.org> <561B6FB9.3010108@hastings.org> Message-ID: <561B723E.4040505@ntoll.org> My 2c... MicroPython is an implementation of Python 3 - ergo we should do what Python does. This is important because part of the selling point for using MicroPython is that kids are learning the habits of a real programming language they can graduate to on, say, a RPi. It's more confusing for kids to learn one thing, then have to change because "reasons". N. On 12/10/15 09:30, Larry Hastings wrote: > On 10/12/2015 01:12 AM, Mark Shannon wrote: >> >> There is another way to express a range: (start, length). >> For example, I have followed the DAL API for Image.crop() which is >> Image.crop(x, y, width, height). >> I think that API is easier to understand (if a little clumsier in >> practice) than Image.crop(xstart, ystart, xend, yend). >> >> If I recall correctly, we also decided to avoid using square brackets >> in the API, which makes consistency with list[], a bit less important. >> >> If you do need a range, however, it should definitely be left-closed, >> right-open. > > Consistency with Python slicing is not important, perhaps, but > microbit.random(x) returns a number [0, x), and of course we have > range(x) iterating over the interval [0, x). It's all over the place in > Python, and it's snuck into MicroPython too, and I just wanted to > confirm that we had our story straight and we weren't trying to hide > this detail from the kids for fear of confusing them. > > I thought I remembered a conversation where we said "ranges should > include both endpoints as that's less confusing for kids". But it > sounds like we're all in agreement: it should all be left-closed > right-open intervals. (Anyway, surely it'd be /more/ confusing if some > functions took left-closed right-open intervals and others took closed > intervals?) > > My accelerator-scaler device takes two ranges: the start & end for the > input (from the accelerometer), and the start & end for the output (what > will be returned). Therefore this: > scaler = microbit.game.Scaler(-512, 512, 0, 5) > should say "take the input from [512, 512) and map it to the range [0, > 5)". As in, it will ignore inputs less than -512 and greater than 511, > and will return 0, 1, 2, 3, or 4, but never -1 or 5. > > > Yes? Your lack of reply will be interpreted as silent assent. > > > //arry/ > > p.s. (x, y, width, height) is pretty common for image APIs. You see > (xstart, ystart, xend, yend) now and then too but it's less common. And > yes I generally prefer the former. > > > _______________________________________________ > 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: From larry at hastings.org Mon Oct 12 10:52:44 2015 From: larry at hastings.org (Larry Hastings) Date: Mon, 12 Oct 2015 01:52:44 -0700 Subject: [Microbit-Python] How does GC work in micro:bit MicroPython? In-Reply-To: <561B7103.8030308@hotpy.org> References: <561B5C56.8030703@hastings.org> <561B6CFC.4080005@hotpy.org> <561B6DE4.5010607@hastings.org> <561B7103.8030308@hotpy.org> Message-ID: <561B74DC.1000002@hastings.org> On 10/12/2015 01:36 AM, Mark Shannon wrote: > You'll need to make your button minder a MicroPython object anyway, so > it should be allocated on the MicroPython heap instead. My plan, at least initially, was to keep the internal implementation details a secret from MicroPython. The MP object stores a pointer to an opaque type (scheduler_t, etc) which is managed in my implementation. This makes debugging my classes on my Linux desktop feasible. I wouldn't mind merging my objects irrevocably into MicroPython objects once everything is completely settled. > OOI, would it be possible to add the additional functionality to the > pre-existing button object? The thing is, there's a bit of logic in there that I don't know if we want to stain the button object with. My button minder can handle watching three buttons for you: A, B, and "both". Handling "both" means incurring a slight delay before recognizing a solo button press on A or B, because humans are slow. Recognizing "both" is optional, and if you don't have it turned on there's no delay. If we don't mind permanently incurring that delay, I could add a was_pressed() method to button_a and button_b, and add a separate button_both (button_ab?) object that behaved like a virtual both-buttons button. FYI we could make it so the delay only affected was_pressed(), is_pressed() could still report in real-time. In case you haven't looked at it, the rationale and API for my three objects is all up on the Bitbucket page. That URL again: https://bitbucket.org/larry/microbit_game > Perhaps a list of custom events objects would be more efficient. > Whether custom object or tuple, it should be MicroPython objects all > the way down :) A MicroPython list of custom event objects might be many things, but "more efficient" I sincerely doubt. My current implementation has a packed C array of structs. How could a MicroPython list of custom event objects possibly be more efficient, in any measurable dimension? The Scheduler object really just contains that list of events. So I wouldn't mind making it a subclass of the MP list, if that'd work... would it? It really just needs a couple of extra methods on top of what list already provides. Failing is-a, we're back to has-a, which is where we started. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Mon Oct 12 10:53:49 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 12 Oct 2015 09:53:49 +0100 Subject: [Microbit-Python] How does GC work in micro:bit MicroPython? In-Reply-To: <561B5C56.8030703@hastings.org> References: <561B5C56.8030703@hastings.org> Message-ID: Finalisers are supported by MicroPython (although not enabled in the microbit version but that's a 1 line config change), your (C) type just needs to define the __del__ method. To trace live objects the GC starts at the root pointers. These are: stack, registers, micropython state (mp_state_ctx object, see inc/py/mpconfig.h) and the port-specific root pointers defined in inc/microbit/mpconfigport.h, line 99 (search for MICROPY_PORT_ROOT_POINTERS). It is a problem that we have a separate C++ heap and it should be combined into the micropython GC heap. Because at the moment it's not possible to reclaim stuff allocated using the C++ "new" keyword. Unless you write a finaliser and do a "delete". On Mon, Oct 12, 2015 at 8:08 AM, Larry Hastings wrote: > > > I don't see any registration for gc finalizers. No __del__ anywhere. So > how do objects get cleaned up? > > For example, the constructor for microbit.Image creates a "new > MicroBitImage()" object. Where is this object deleted? > > Does it just walk the entire heap, use a heuristic to find things that > "look" like pointers, and recycle anything that it believes isn't reachable? > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From damien.p.george at gmail.com Mon Oct 12 10:55:57 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 12 Oct 2015 09:55:57 +0100 Subject: [Microbit-Python] How does GC work in micro:bit MicroPython? In-Reply-To: <561B74DC.1000002@hastings.org> References: <561B5C56.8030703@hastings.org> <561B6CFC.4080005@hotpy.org> <561B6DE4.5010607@hastings.org> <561B7103.8030308@hotpy.org> <561B74DC.1000002@hastings.org> Message-ID: > My plan, at least initially, was to keep the internal implementation details a secret from MicroPython. The MP object stores a pointer to an opaque type (scheduler_t, etc) which is managed in my implementation. This is entirely feasible: if you're writing sheduler_t in C (not C++) then just use m_malloc instead of malloc to allocate your data and it'll go on the GC heap. Just be sure to keep a root pointer to it somewhere (if you store the pointer in a micropython object then that's good enough). On Mon, Oct 12, 2015 at 9:52 AM, Larry Hastings wrote: > > On 10/12/2015 01:36 AM, Mark Shannon wrote: > > You'll need to make your button minder a MicroPython object anyway, so it > should be allocated on the MicroPython heap instead. > > > My plan, at least initially, was to keep the internal implementation details > a secret from MicroPython. The MP object stores a pointer to an opaque type > (scheduler_t, etc) which is managed in my implementation. This makes > debugging my classes on my Linux desktop feasible. > > I wouldn't mind merging my objects irrevocably into MicroPython objects once > everything is completely settled. > > > OOI, would it be possible to add the additional functionality to the > pre-existing button object? > > > The thing is, there's a bit of logic in there that I don't know if we want > to stain the button object with. My button minder can handle watching three > buttons for you: A, B, and "both". Handling "both" means incurring a slight > delay before recognizing a solo button press on A or B, because humans are > slow. Recognizing "both" is optional, and if you don't have it turned on > there's no delay. > > If we don't mind permanently incurring that delay, I could add a > was_pressed() method to button_a and button_b, and add a separate > button_both (button_ab?) object that behaved like a virtual both-buttons > button. > > FYI we could make it so the delay only affected was_pressed(), is_pressed() > could still report in real-time. > > In case you haven't looked at it, the rationale and API for my three objects > is all up on the Bitbucket page. That URL again: > > https://bitbucket.org/larry/microbit_game > > > Perhaps a list of custom events objects would be more efficient. > Whether custom object or tuple, it should be MicroPython objects all the way > down :) > > > A MicroPython list of custom event objects might be many things, but "more > efficient" I sincerely doubt. My current implementation has a packed C > array of structs. How could a MicroPython list of custom event objects > possibly be more efficient, in any measurable dimension? > > The Scheduler object really just contains that list of events. So I > wouldn't mind making it a subclass of the MP list, if that'd work... would > it? It really just needs a couple of extra methods on top of what list > already provides. Failing is-a, we're back to has-a, which is where we > started. > > > /arry > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From larry at hastings.org Mon Oct 12 10:57:06 2015 From: larry at hastings.org (Larry Hastings) Date: Mon, 12 Oct 2015 01:57:06 -0700 Subject: [Microbit-Python] How does GC work in micro:bit MicroPython? In-Reply-To: References: <561B5C56.8030703@hastings.org> Message-ID: <561B75E2.4090308@hastings.org> On 10/12/2015 01:53 AM, Damien George wrote: > Finalisers are supported by MicroPython (although not enabled in the > microbit version but that's a 1 line config change), your (C) type > just needs to define the __del__ method. I'm guessing there's a reason you didn't turn on finalisers for the micro:bit build though. Why not? Does __del__ go in the dict_table, or is it a member of the type? > It is a problem that we have a separate C++ heap and it should be > combined into the micropython GC heap. Because at the moment it's not > possible to reclaim stuff allocated using the C++ "new" keyword. > Unless you write a finaliser and do a "delete". Aha! So that explains why I was only able to create 50 or so Image objects before I got an 020. The Image constructor calls new MicroBitImage and there is no matching delete. Is that really how we want to live our lives? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Mon Oct 12 11:03:05 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 12 Oct 2015 10:03:05 +0100 Subject: [Microbit-Python] Resolution on micro:bit timer is, uh, not great In-Reply-To: <561B2EA5.2050303@hastings.org> References: <561B247C.8070000@hastings.org> <561B2D1B.2070305@hastings.org> <561B2EA5.2050303@hastings.org> Message-ID: Hi Larry, The answers are indeed "sure" and "nope" :) The reason for 6ms is to keep the device low-power. The idea is that it'll run on a battery for ages (weeks, months) and sleeping for 1ms instead of 6ms would increase battery use. Is it really necessary to have better accuracy? What's the use case? I agree that a good "fix" would be to use us_ticker_read for system_time (actually now called running_time) and then do busy waiting for the (desired_time % 6) piece (although probably only need to do that for short-ish times like less than 100ms, since large times won't need precision..?). Cheers, Damien. On Mon, Oct 12, 2015 at 4:53 AM, Larry Hastings wrote: > On 10/11/2015 08:46 PM, Larry Hastings wrote: > > Could we change system_time from just returning "ticks" to returning > us_ticker_read()? > > Could we change the frequency of the fiber scheduler ISR to 1ms while > performing a sleep()? > > > If the answer is "sure" and "nope", then I (or we) can change sleep() to > sleep until 6ms before the wakeup time, then busy-sleep until we've > completed the interval. (By busy-sleep I mean checking the time in a tight > loop until it's time to wake up, without actually sleeping.) > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From damien.p.george at gmail.com Mon Oct 12 11:06:07 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 12 Oct 2015 10:06:07 +0100 Subject: [Microbit-Python] How does GC work in micro:bit MicroPython? In-Reply-To: <561B75E2.4090308@hastings.org> References: <561B5C56.8030703@hastings.org> <561B75E2.4090308@hastings.org> Message-ID: I didn't turn on finalisers because from experience they are rarely needed. But they are not expensive to turn on so we can if needed. __del__ goes in the dict_table. I think we should fix this properly instead of monkey patching here and there. Properly means combining the 2 heaps (uPy GC and C++). This would also give more RAM overall because then there's not a hard, fixed barrier between the 2 heaps which is currently 9.5k and 2k. On Mon, Oct 12, 2015 at 9:57 AM, Larry Hastings wrote: > On 10/12/2015 01:53 AM, Damien George wrote: > > Finalisers are supported by MicroPython (although not enabled in the > microbit version but that's a 1 line config change), your (C) type > just needs to define the __del__ method. > > > I'm guessing there's a reason you didn't turn on finalisers for the > micro:bit build though. Why not? > > Does __del__ go in the dict_table, or is it a member of the type? > > > It is a problem that we have a separate C++ heap and it should be > combined into the micropython GC heap. Because at the moment it's not > possible to reclaim stuff allocated using the C++ "new" keyword. > Unless you write a finaliser and do a "delete". > > > Aha! So that explains why I was only able to create 50 or so Image objects > before I got an 020. The Image constructor calls new MicroBitImage and > there is no matching delete. > > Is that really how we want to live our lives? > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From damien.p.george at gmail.com Mon Oct 12 11:10:42 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 12 Oct 2015 10:10:42 +0100 Subject: [Microbit-Python] Interval boundaries... what did we decide? In-Reply-To: <561B723E.4040505@ntoll.org> References: <561AF9B4.2020309@hastings.org> <561B6B80.2060609@hotpy.org> <561B6FB9.3010108@hastings.org> <561B723E.4040505@ntoll.org> Message-ID: Yes, Larry, I agree with [..) ranges. We originally discussed having [0..100] as return values for the read_analog() method, but then eventually decided on [0,..1023] = [0..1024) = range(1024) because of "reasons" discussed here: https://github.com/dpgeorge/microbit-micropython/pull/24 On Mon, Oct 12, 2015 at 9:41 AM, Nicholas H.Tollervey wrote: > My 2c... > > MicroPython is an implementation of Python 3 - ergo we should do what > Python does. > > This is important because part of the selling point for using > MicroPython is that kids are learning the habits of a real programming > language they can graduate to on, say, a RPi. > > It's more confusing for kids to learn one thing, then have to change > because "reasons". > > N. > > On 12/10/15 09:30, Larry Hastings wrote: >> On 10/12/2015 01:12 AM, Mark Shannon wrote: >>> >>> There is another way to express a range: (start, length). >>> For example, I have followed the DAL API for Image.crop() which is >>> Image.crop(x, y, width, height). >>> I think that API is easier to understand (if a little clumsier in >>> practice) than Image.crop(xstart, ystart, xend, yend). >>> >>> If I recall correctly, we also decided to avoid using square brackets >>> in the API, which makes consistency with list[], a bit less important. >>> >>> If you do need a range, however, it should definitely be left-closed, >>> right-open. >> >> Consistency with Python slicing is not important, perhaps, but >> microbit.random(x) returns a number [0, x), and of course we have >> range(x) iterating over the interval [0, x). It's all over the place in >> Python, and it's snuck into MicroPython too, and I just wanted to >> confirm that we had our story straight and we weren't trying to hide >> this detail from the kids for fear of confusing them. >> >> I thought I remembered a conversation where we said "ranges should >> include both endpoints as that's less confusing for kids". But it >> sounds like we're all in agreement: it should all be left-closed >> right-open intervals. (Anyway, surely it'd be /more/ confusing if some >> functions took left-closed right-open intervals and others took closed >> intervals?) >> >> My accelerator-scaler device takes two ranges: the start & end for the >> input (from the accelerometer), and the start & end for the output (what >> will be returned). Therefore this: >> scaler = microbit.game.Scaler(-512, 512, 0, 5) >> should say "take the input from [512, 512) and map it to the range [0, >> 5)". As in, it will ignore inputs less than -512 and greater than 511, >> and will return 0, 1, 2, 3, or 4, but never -1 or 5. >> >> >> Yes? Your lack of reply will be interpreted as silent assent. >> >> >> //arry/ >> >> p.s. (x, y, width, height) is pretty common for image APIs. You see >> (xstart, ystart, xend, yend) now and then too but it's less common. And >> yes I generally prefer the former. >> >> >> _______________________________________________ >> 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 > From larry at hastings.org Mon Oct 12 11:11:44 2015 From: larry at hastings.org (Larry Hastings) Date: Mon, 12 Oct 2015 02:11:44 -0700 Subject: [Microbit-Python] How does GC work in micro:bit MicroPython? In-Reply-To: References: <561B5C56.8030703@hastings.org> <561B75E2.4090308@hastings.org> Message-ID: <561B7950.7030208@hastings.org> On 10/12/2015 02:06 AM, Damien George wrote: > I didn't turn on finalisers because from experience they are rarely > needed. But they are not expensive to turn on so we can if needed. > > __del__ goes in the dict_table. > > I think we should fix this properly instead of monkey patching here > and there. Properly means combining the 2 heaps (uPy GC and C++). > This would also give more RAM overall because then there's not a hard, > fixed barrier between the 2 heaps which is currently 9.5k and 2k. When you say "we should fix this properly", I suspect you mostly mean you. I don't know if I can be of much help. What should I do for now? Just not worry about it? I expect few people will create more than one scheduler, one button minder, and at most three accelerometer scalers, and these objects will live for the duration of the program. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Mon Oct 12 11:16:06 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 12 Oct 2015 10:16:06 +0100 Subject: [Microbit-Python] How does GC work in micro:bit MicroPython? In-Reply-To: <561B7950.7030208@hastings.org> References: <561B5C56.8030703@hastings.org> <561B75E2.4090308@hastings.org> <561B7950.7030208@hastings.org> Message-ID: For now I would not do anything about it, especially if it's not a show stopper at this point. I would follow these principles: - make it easy to change the allocation/realloc/free functions - make as much stuff dynamically allocated as possible (ie put as little in the bss/data area as possible, ie as few global variables as possible); this is because some people might not use your classes/features and you don't want to take away their precious RAM for unused features On Mon, Oct 12, 2015 at 10:11 AM, Larry Hastings wrote: > On 10/12/2015 02:06 AM, Damien George wrote: > > I didn't turn on finalisers because from experience they are rarely > needed. But they are not expensive to turn on so we can if needed. > > __del__ goes in the dict_table. > > I think we should fix this properly instead of monkey patching here > and there. Properly means combining the 2 heaps (uPy GC and C++). > This would also give more RAM overall because then there's not a hard, > fixed barrier between the 2 heaps which is currently 9.5k and 2k. > > > When you say "we should fix this properly", I suspect you mostly mean you. > I don't know if I can be of much help. > > What should I do for now? Just not worry about it? I expect few people > will create more than one scheduler, one button minder, and at most three > accelerometer scalers, and these objects will live for the duration of the > program. > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From larry at hastings.org Mon Oct 12 11:18:35 2015 From: larry at hastings.org (Larry Hastings) Date: Mon, 12 Oct 2015 02:18:35 -0700 Subject: [Microbit-Python] How does GC work in micro:bit MicroPython? In-Reply-To: References: <561B5C56.8030703@hastings.org> <561B75E2.4090308@hastings.org> <561B7950.7030208@hastings.org> Message-ID: <561B7AEB.4060004@hastings.org> On 10/12/2015 02:16 AM, Damien George wrote: > - make as much stuff dynamically allocated as possible (ie put as > little in the bss/data area as possible, ie as few global variables as > possible); I have zero global variables anywhere in my module. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Mon Oct 12 11:45:49 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Mon, 12 Oct 2015 10:45:49 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man Message-ID: <561B814D.6080002@ntoll.org> Hi Folks, For the sake of clarity I want to list all the different things I remember people are working on so we have some sort of a grasp of what's going on, where there's a chance for crossover between such things and a sense of the whole offering. This is helpful to me since I need to communicate with the BBC what we're doing - they're starting to get interested in us and want to film things such as how to use the Python editor and want to provide training for teachers. Off the top of my head we have... * Music API - first draft of Matthew's native API is merged into master. Requires further development to allow it to work in the background. I'll be adding musical examples over the course of this week and testing it from a musician's perspective. * Larry's game related work - I think this is hugely important. Kids love games and showing off their work to each other. If we can make it super easy to facilitate such hacking then we're doing something marvellous. I'd also add that Daniel Pope's work on PyGame Zero is something should be aware of (https://pygame-zero.readthedocs.org/en/latest/) since this is how many kids will start writing games on the RPi. Facilitating smooth progression from micro:bit -> other Python is simply a good thing to do. While this may not be reflected in the different API's I believe we could conceptually show some progression (if that makes sense). * Marks' image related work - again, this is hugely important because being able to see the result of your code is a great inspiration to kids. The easier and more capable we make this the better it'll be for all concerned. * Damien's suggestion of inline assembler which sounds like it'd be a wonderful thing for the hacker/maker audience the BBC are also hoping to tempt as a secondary market. * David's MIDI related suggestions. I'm not clear what would be involved for this - I presume we could use USB/serial to send MIDI information to a MIDI device running elsewhere. David, it'd be helpful to learn how you see this working. * Damien and I discussed turning the display into some sort of generic graphical equaliser for arbitrary data. Please reply and correct me. If there's something I've missed then give me a kick. My intention is to write the results up and publish them somewhere obvious (such as the wiki). I hope to manoeuvre the BBC by the end of this week so we're able to open-source the work we're doing (and thus engage with the wider Python community). I think it important that we frame our intentions, projects and desired outcomes before others turn up. As always, comments, constructive critique and idea most welcome! Best wishes, Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From larry at hastings.org Mon Oct 12 10:57:59 2015 From: larry at hastings.org (Larry Hastings) Date: Mon, 12 Oct 2015 01:57:59 -0700 Subject: [Microbit-Python] Measuring LED brightness Message-ID: <561B7617.7080706@hastings.org> I was ruminating over how we don't really know the valid distinguishable brightnesses of the micro:bit LEDs. But! I figured out a way we could maybe test it. Set up an HDR camera with a remote shutter control in a pitch-black room pointed at a micro:bit. Get the micro:bit in focus, and close enough that the LED matrix fills a significant portion of the frame. Run a program on the micro:bit that sets all the pixels to the same value, from 0 to 255, triggered on a key or something. Then sit there and take a picture, and advance to the next brightness, 256 times. The next step would be image analysis to find the brightest pixels in the image and measures their brightness. My guess is one of two things: 1. The micro:bit is displaying wonderful, amazing graduated levels of brightness, but human beings are really bad at discerning one bright object from another. 2. The micro:bit is terrible at displaying levels of brightness, and we'd quickly discover its few, lousy, fetid brightness increments. Anybody want to run an experiment? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Mon Oct 12 15:20:11 2015 From: larry at hastings.org (Larry Hastings) Date: Mon, 12 Oct 2015 06:20:11 -0700 Subject: [Microbit-Python] Resolution on micro:bit timer is, uh, not great In-Reply-To: References: <561B247C.8070000@hastings.org> <561B2D1B.2070305@hastings.org> <561B2EA5.2050303@hastings.org> Message-ID: <561BB38B.80003@hastings.org> On 10/12/2015 02:03 AM, Damien George wrote: > Is it really necessary to have better accuracy? What's the use case? Games. It should be possible to write fast-twitch games on the micro:bit. For example, "reaction timer": sit staring at the screen, and the very MOMENT you see an LED light up press a button. > I agree that a good "fix" would be to use us_ticker_read for > system_time (actually now called running_time) and then do busy > waiting for the (desired_time % 6) piece (although probably only need > to do that for short-ish times like less than 100ms, since large times > won't need precision..?). I don't know why I would write a scheduler that was accurate for short periods but inaccurate for long periods. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at thinkingbinaries.com Mon Oct 12 18:56:01 2015 From: david at thinkingbinaries.com (David Whale) Date: Mon, 12 Oct 2015 17:56:01 +0100 Subject: [Microbit-Python] Measuring LED brightness In-Reply-To: <561B7617.7080706@hastings.org> References: <561B7617.7080706@hastings.org> Message-ID: Beware that you'll need to run with a slow shutter speed - the micro:bit uses BCM (Binary Coded Modulation) to drive the LED multiplex and brightness taking advantage of persistence of vision, if your frame rate is too slow, you won't get a full image :) (speaking from experience of taking stills of the micro:bit and getting half a display!) 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 12 October 2015 at 09:57, Larry Hastings wrote: > > > I was ruminating over how we don't really know the valid distinguishable > brightnesses of the micro:bit LEDs. But! I figured out a way we could > maybe test it. > > Set up an HDR camera with a remote shutter control in a pitch-black room > pointed at a micro:bit. Get the micro:bit in focus, and close enough that > the LED matrix fills a significant portion of the frame. Run a program > on the micro:bit that sets all the pixels to the same value, from 0 to 255, > triggered on a key or something. Then sit there and take a picture, and > advance to the next brightness, 256 times. > > The next step would be image analysis to find the brightest pixels in the > image and measures their brightness. My guess is one of two things: > > 1. The micro:bit is displaying wonderful, amazing graduated levels of > brightness, but human beings are really bad at discerning one bright object > from another. > 2. The micro:bit is terrible at displaying levels of brightness, and > we'd quickly discover its few, lousy, fetid brightness increments. > > > Anybody want to run an experiment? > > > */arry* > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Mon Oct 12 23:59:43 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 12 Oct 2015 22:59:43 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: <561B814D.6080002@ntoll.org> References: <561B814D.6080002@ntoll.org> Message-ID: Yes, I think we need some direction and goals to get uPy on the microbit to a "v1.0" state. We've had a lot of good ideas, discussion and contributions. I think we are close to having a very usable API. > * Music API - first draft of Matthew's native API is merged into master. > Requires further development to allow it to work in the background. I'll > be adding musical examples over the course of this week and testing it > from a musician's perspective. I think the music module is wonderful. It's so easy at the REPL to do: music.tune(pin0, ['c', 'd', 'e', 'f', 'g', 'a', 'b', 'c']) or even: music.tune(pin0, [chr(ord('c') + i) for i in range(8)]) or better still: music.tune(pin0, list('cdefgabc')) Yes it needs work to have non-blocking mode. And builtin tunes would be awesome. > * Larry's game related work - I think this is hugely important. Kids > love games and showing off their work to each other. If we can make it > super easy to facilitate such hacking then we're doing something > marvellous. Yes, it's great to have Larry's experience with game writing to make a good API. > * Marks' image related work - again, this is hugely important because > being able to see the result of your code is a great inspiration to > kids. The easier and more capable we make this the better it'll be for > all concerned. Yep. Even with the additional features added here, we still have a really easy entry point to simply scroll a message or animate a sequence of images. > * Damien's suggestion of inline assembler which sounds like it'd be a > wonderful thing for the hacker/maker audience the BBC are also hoping to > tempt as a secondary market. I can add this if we think it'll be attractive. There are 2 options: 1. A simple "machine_code" function that takes raw bytes and turns them into a function. Very hard to use, eg: fun = machine_code(b'\x12\x34\x56') and you have to find out the correct byte values by assembling offline with an arm assembler, then looking at the output. Really hard to use (but then that might give it a cool factor!). 2. The proper inline assembler that already exists, where you write code like: @micropython.asm_thumb def f(r0, r1): label(loop) add(r0, r1) bne(loop) This is easier to hack, but since it's verbose you'll run out of memory (in the compile stage) if you try to write long functions. It also takes up flash space (not too much though) and maybe in the future we need this flash space for other things? Regarding attracting the hacker/maker audience: I think it's important to point out that starting with the microbit is an entry point to learning MicroPython, and then people who want more can buy a more capable board that runs uPy (eg pyboard). Oh, and uPy on the microbit also supports I2C and UART interfaces, for those that want to interface with other electronic components (temp sensors, etc). > * David's MIDI related suggestions. I'm not clear what would be involved > for this - I presume we could use USB/serial to send MIDI information to > a MIDI device running elsewhere. David, it'd be helpful to learn how you > see this working. I don't have any experience with MIDI, so also don't see how this would work (and can't really test it...). > * Damien and I discussed turning the display into some sort of generic > graphical equaliser for arbitrary data. It would be neat, but I think this would be a lower priority (unless the BBC really likes the idea...). From david at thinkingbinaries.com Tue Oct 13 00:49:35 2015 From: david at thinkingbinaries.com (David Whale) Date: Mon, 12 Oct 2015 23:49:35 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: References: <561B814D.6080002@ntoll.org> Message-ID: Regarding MIDI All the MIDI needs to connect to an external MIDI synth (e.g. a keyboard with a MIDI IN port) is a UART Tx on one of the pins running at 31250bps,n,8,1. Damien, is there a DAL api or something in the MicroPython that exposes the on-pins UART? This would be a MIDI-OUT from the micro:bit MIDI-IN could be interesting, it would mean you could press a button on an external keyboard synth, and a note-on message would come into the micro:bit - what you would do with it then I'm not sure, so perhaps this is less valuable? The messages are very simple and well defined (mostly 2 byte messages). There is a small single chip circuit (opto isolator) that is required to make the electrical connection. You can then play any note and change any controller (e.g. shake the micro:bit to do a pitch bend could be real fun!) MIDI over USB (e.g. so the micro:bit is presented as a MIDI device to the PC/Mac) is much harder, because it requires the USB descriptor in the interface chip to be reprogrammed and we don't have access to that, so I think we should forget that idea. I spoke to Martin Wooley about perhaps MIDI over bluetooth (there is a profile for it), but he didn't seem keen in making any changes to the existing profiles, preferring the innovation to happen at the PC end. So, plug your micro:bit into a small chip and then into a 5-pin DIN plug in the back of your synthesiser could be really great, it might also open up SonicPi access by using a MIDI/USB adaptor into the PC/Mac/Pi. Mostly the code would be a set of constants for the message types and note numbers, perhaps with a few wrapper functions in python (note_on, note_off, play, set_patch, control_change, sysex). I sense the only way to make this happen would be for me or someone to write a quick spec for the API, then anyone could actually write the code. Given the API is so thin, if there is a good API for UART, this could easily be a python frozen module as it's then easy for anyone to write and test and contribute to the mix. It does beg the question whether we should consider a 'redirect' option from the music module Matthew is writing, so you can either play beeps through the speaker, OR send MIDI note messages, using the same lovely API. Note MIDI has controllers (like pitch bend) that would be excellent to expose for things like 'accelerometer tilt varies pitch bend or modulation wheel'. If timing is tight, it would be possible I think to write this as an example py program instead, and bring it in as a frozen module later perhaps. I have a huge amount on at the moment I'm not sure I could commit to making all this work in time for a V1 release window. 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 12 October 2015 at 22:59, Damien George wrote: > Yes, I think we need some direction and goals to get uPy on the > microbit to a "v1.0" state. > > We've had a lot of good ideas, discussion and contributions. I think > we are close to having a very usable API. > > > * Music API - first draft of Matthew's native API is merged into master. > > Requires further development to allow it to work in the background. I'll > > be adding musical examples over the course of this week and testing it > > from a musician's perspective. > > I think the music module is wonderful. It's so easy at the REPL to do: > > music.tune(pin0, ['c', 'd', 'e', 'f', 'g', 'a', 'b', 'c']) > > or even: > > music.tune(pin0, [chr(ord('c') + i) for i in range(8)]) > > or better still: > > music.tune(pin0, list('cdefgabc')) > > Yes it needs work to have non-blocking mode. And builtin tunes would > be awesome. > > > * Larry's game related work - I think this is hugely important. Kids > > love games and showing off their work to each other. If we can make it > > super easy to facilitate such hacking then we're doing something > > marvellous. > > Yes, it's great to have Larry's experience with game writing to make a > good API. > > > * Marks' image related work - again, this is hugely important because > > being able to see the result of your code is a great inspiration to > > kids. The easier and more capable we make this the better it'll be for > > all concerned. > > Yep. Even with the additional features added here, we still have a > really easy entry point to simply scroll a message or animate a > sequence of images. > > > * Damien's suggestion of inline assembler which sounds like it'd be a > > wonderful thing for the hacker/maker audience the BBC are also hoping to > > tempt as a secondary market. > > I can add this if we think it'll be attractive. There are 2 options: > > 1. A simple "machine_code" function that takes raw bytes and turns > them into a function. Very hard to use, eg: fun = > machine_code(b'\x12\x34\x56') and you have to find out the correct > byte values by assembling offline with an arm assembler, then looking > at the output. Really hard to use (but then that might give it a cool > factor!). > > 2. The proper inline assembler that already exists, where you write code > like: > > @micropython.asm_thumb > def f(r0, r1): > label(loop) > add(r0, r1) > bne(loop) > > This is easier to hack, but since it's verbose you'll run out of > memory (in the compile stage) if you try to write long functions. It > also takes up flash space (not too much though) and maybe in the > future we need this flash space for other things? > > Regarding attracting the hacker/maker audience: I think it's important > to point out that starting with the microbit is an entry point to > learning MicroPython, and then people who want more can buy a more > capable board that runs uPy (eg pyboard). > > Oh, and uPy on the microbit also supports I2C and UART interfaces, for > those that want to interface with other electronic components (temp > sensors, etc). > > > * David's MIDI related suggestions. I'm not clear what would be involved > > for this - I presume we could use USB/serial to send MIDI information to > > a MIDI device running elsewhere. David, it'd be helpful to learn how you > > see this working. > > I don't have any experience with MIDI, so also don't see how this > would work (and can't really test it...). > > > * Damien and I discussed turning the display into some sort of generic > > graphical equaliser for arbitrary data. > > It would be neat, but I think this would be a lower priority (unless > the BBC really likes the idea...). > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Tue Oct 13 12:46:58 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 13 Oct 2015 11:46:58 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: References: <561B814D.6080002@ntoll.org> Message-ID: <561CE122.3080902@ntoll.org> Hi, On 12/10/15 22:59, Damien George wrote: > Yes, I think we need some direction and goals to get uPy on the > microbit to a "v1.0" state. > Exactly. Something to aim for, and given that we're (hopefully) going to be working in the open very soon it'd be good to have this specified in some way. > We've had a lot of good ideas, discussion and contributions. I think > we are close to having a very usable API. > I agree... it's just important that we're clear and frame what we intend to achieve so that as we attract more contributors they have an easy/obvious path to finding out what we're up to. >> * Music API - first draft of Matthew's native API is merged into master. >> Requires further development to allow it to work in the background. I'll >> be adding musical examples over the course of this week and testing it >> from a musician's perspective. > > I think the music module is wonderful. It's so easy at the REPL to do: > > music.tune(pin0, ['c', 'd', 'e', 'f', 'g', 'a', 'b', 'c']) > > or even: > > music.tune(pin0, [chr(ord('c') + i) for i in range(8)]) > > or better still: > > music.tune(pin0, list('cdefgabc')) > > Yes it needs work to have non-blocking mode. And builtin tunes would > be awesome. > I'm going to be playing with this today. ;-) >> * Larry's game related work - I think this is hugely important. Kids >> love games and showing off their work to each other. If we can make it >> super easy to facilitate such hacking then we're doing something >> marvellous. > > Yes, it's great to have Larry's experience with game writing to make a good API. > Larry, would it be possible to write up how you see this API working? Something along the lines of the work I did for the music API (here: https://github.com/dpgeorge/microbit-micropython/wiki/music-API) perhaps? >> * Marks' image related work - again, this is hugely important because >> being able to see the result of your code is a great inspiration to >> kids. The easier and more capable we make this the better it'll be for >> all concerned. > > Yep. Even with the additional features added here, we still have a > really easy entry point to simply scroll a message or animate a > sequence of images. > +1 It'd be great to take Mark's work and add Mariia's images. :-) >> * Damien's suggestion of inline assembler which sounds like it'd be a >> wonderful thing for the hacker/maker audience the BBC are also hoping to >> tempt as a secondary market. > > I can add this if we think it'll be attractive. There are 2 options: > Yes please. It also differentiates MicroPython from the other solutions. > 1. A simple "machine_code" function that takes raw bytes and turns > them into a function. Very hard to use, eg: fun = > machine_code(b'\x12\x34\x56') and you have to find out the correct > byte values by assembling offline with an arm assembler, then looking > at the output. Really hard to use (but then that might give it a cool > factor!). > Cutting and pasting bytes... I like it. If this is documented in baby-steps fashion then it's certainly suddenly a lot more accessible. > 2. The proper inline assembler that already exists, where you write code like: > > @micropython.asm_thumb > def f(r0, r1): > label(loop) > add(r0, r1) > bne(loop) > > This is easier to hack, but since it's verbose you'll run out of > memory (in the compile stage) if you try to write long functions. It > also takes up flash space (not too much though) and maybe in the > future we need this flash space for other things? > I like this too. Take a look at this - http://peter-cockerell.net/aalp/ from 1987!!!! My first programming language was BBC BASIC. Can we do both. My reason for asking is that there appears to be a clear progression from the inline assembler to the cut'n'paste bytes solution. Both have a geeky "that's cool" aspect to them and reveal the machinations of the device at quite a fundamental level which is also cool from an educational perspective. > Regarding attracting the hacker/maker audience: I think it's important > to point out that starting with the microbit is an entry point to > learning MicroPython, and then people who want more can buy a more > capable board that runs uPy (eg pyboard). > Yes... micro:bit = first step on a journey. > Oh, and uPy on the microbit also supports I2C and UART interfaces, for > those that want to interface with other electronic components (temp > sensors, etc). > So this makes me wonder about documentation for the device / MicroPython. It's all very well having all this cool stuff, but if it's not explained then people won't use it. I've thoughts on how we tackle this and will post them soon. >> * David's MIDI related suggestions. I'm not clear what would be involved >> for this - I presume we could use USB/serial to send MIDI information to >> a MIDI device running elsewhere. David, it'd be helpful to learn how you >> see this working. > > I don't have any experience with MIDI, so also don't see how this > would work (and can't really test it...). > I'll answer David separately. >> * Damien and I discussed turning the display into some sort of generic >> graphical equaliser for arbitrary data. > > It would be neat, but I think this would be a lower priority (unless > the BBC really likes the idea...). I think it would be another great differentiator for MicroPython. It's a generic means of displaying data. Given that the device will likely be used as a sensor it makes sense to be able to quickly draw a bar graph or realtime "equalizer" with cool fading effects. As always, comments, constructive critique and ideas most welcome! N. > _______________________________________________ > 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: From ntoll at ntoll.org Tue Oct 13 13:11:23 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 13 Oct 2015 12:11:23 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: References: <561B814D.6080002@ntoll.org> Message-ID: <561CE6DB.4010005@ntoll.org> Hi David, On 12/10/15 23:49, David Whale wrote: > Regarding MIDI > > All the MIDI needs to connect to an external MIDI synth (e.g. a keyboard > with a MIDI IN port) is a UART Tx on one of the pins running at > 31250bps,n,8,1. Damien, is there a DAL api or something in the > MicroPython that exposes the on-pins UART? This would be a MIDI-OUT from > the micro:bit > Damien states in his reply the MicroPython supports UART. Not sure what information you need to start playing around. > MIDI-IN could be interesting, it would mean you could press a button on > an external keyboard synth, and a note-on message would come into the > micro:bit - what you would do with it then I'm not sure, so perhaps this > is less valuable? > This is VERY valuable since MIDI is used by VJ / DJ type people to signal all sorts of events in multimedia displays. Someone at the BBC got very excited when I mentioned we were only looking at MIDI. > > The messages are very simple and well defined (mostly 2 byte messages). > There is a small single chip circuit (opto isolator) that is required to > make the electrical connection. You can then play any note and change > any controller (e.g. shake the micro:bit to do a pitch bend could be > real fun!) > > MIDI over USB (e.g. so the micro:bit is presented as a MIDI device to > the PC/Mac) is much harder, because it requires the USB descriptor in > the interface chip to be reprogrammed and we don't have access to that, > so I think we should forget that idea. > > I spoke to Martin Wooley about perhaps MIDI over bluetooth (there is a > profile for it), but he didn't seem keen in making any changes to the > existing profiles, preferring the innovation to happen at the PC end. > > So, plug your micro:bit into a small chip and then into a 5-pin DIN plug > in the back of your synthesiser could be really great, it might also > open up SonicPi access by using a MIDI/USB adaptor into the PC/Mac/Pi. > > Mostly the code would be a set of constants for the message types and > note numbers, perhaps with a few wrapper functions in python (note_on, > note_off, play, set_patch, control_change, sysex). > > I sense the only way to make this happen would be for me or someone to > write a quick spec for the API, then anyone could actually write the code. > > Given the API is so thin, if there is a good API for UART, this could > easily be a python frozen module as it's then easy for anyone to write > and test and contribute to the mix. > Exactly, although making it "native" would be better. > > It does beg the question whether we should consider a 'redirect' option > from the music module Matthew is writing, so you can either play beeps > through the speaker, OR send MIDI note messages, using the same lovely > API. Note MIDI has controllers (like pitch bend) that would be excellent > to expose for things like 'accelerometer tilt varies pitch bend or > modulation wheel'. > Agreed. > If timing is tight, it would be possible I think to write this as an > example py program instead, and bring it in as a frozen module later > perhaps. I have a huge amount on at the moment I'm not sure I could > commit to making all this work in time for a V1 release window. > Hmm... ok. What can we do to help make this happen? N. > 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 12 October 2015 at 22:59, Damien George > wrote: > > Yes, I think we need some direction and goals to get uPy on the > microbit to a "v1.0" state. > > We've had a lot of good ideas, discussion and contributions. I think > we are close to having a very usable API. > > > * Music API - first draft of Matthew's native API is merged into master. > > Requires further development to allow it to work in the background. I'll > > be adding musical examples over the course of this week and testing it > > from a musician's perspective. > > I think the music module is wonderful. It's so easy at the REPL to do: > > music.tune(pin0, ['c', 'd', 'e', 'f', 'g', 'a', 'b', 'c']) > > or even: > > music.tune(pin0, [chr(ord('c') + i) for i in range(8)]) > > or better still: > > music.tune(pin0, list('cdefgabc')) > > Yes it needs work to have non-blocking mode. And builtin tunes would > be awesome. > > > * Larry's game related work - I think this is hugely important. Kids > > love games and showing off their work to each other. If we can make it > > super easy to facilitate such hacking then we're doing something > > marvellous. > > Yes, it's great to have Larry's experience with game writing to make > a good API. > > > * Marks' image related work - again, this is hugely important because > > being able to see the result of your code is a great inspiration to > > kids. The easier and more capable we make this the better it'll be for > > all concerned. > > Yep. Even with the additional features added here, we still have a > really easy entry point to simply scroll a message or animate a > sequence of images. > > > * Damien's suggestion of inline assembler which sounds like it'd be a > > wonderful thing for the hacker/maker audience the BBC are also hoping to > > tempt as a secondary market. > > I can add this if we think it'll be attractive. There are 2 options: > > 1. A simple "machine_code" function that takes raw bytes and turns > them into a function. Very hard to use, eg: fun = > machine_code(b'\x12\x34\x56') and you have to find out the correct > byte values by assembling offline with an arm assembler, then looking > at the output. Really hard to use (but then that might give it a cool > factor!). > > 2. The proper inline assembler that already exists, where you write > code like: > > @micropython.asm_thumb > def f(r0, r1): > label(loop) > add(r0, r1) > bne(loop) > > This is easier to hack, but since it's verbose you'll run out of > memory (in the compile stage) if you try to write long functions. It > also takes up flash space (not too much though) and maybe in the > future we need this flash space for other things? > > Regarding attracting the hacker/maker audience: I think it's important > to point out that starting with the microbit is an entry point to > learning MicroPython, and then people who want more can buy a more > capable board that runs uPy (eg pyboard). > > Oh, and uPy on the microbit also supports I2C and UART interfaces, for > those that want to interface with other electronic components (temp > sensors, etc). > > > * David's MIDI related suggestions. I'm not clear what would be involved > > for this - I presume we could use USB/serial to send MIDI information to > > a MIDI device running elsewhere. David, it'd be helpful to learn how you > > see this working. > > I don't have any experience with MIDI, so also don't see how this > would work (and can't really test it...). > > > * Damien and I discussed turning the display into some sort of generic > > graphical equaliser for arbitrary data. > > It would be neat, but I think this would be a lower priority (unless > the BBC really likes the idea...). > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From sparks.m at gmail.com Tue Oct 13 13:33:39 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 13 Oct 2015 12:33:39 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: <561CE122.3080902@ntoll.org> References: <561B814D.6080002@ntoll.org> <561CE122.3080902@ntoll.org> Message-ID: On 13 October 2015 at 11:46, Nicholas H.Tollervey wrote: ... > > 2. The proper inline assembler that already exists, where you write code > like: > > > > @micropython.asm_thumb > > def f(r0, r1): > > label(loop) > > add(r0, r1) > > bne(loop) > > > > This is easier to hack, but since it's verbose you'll run out of > > memory (in the compile stage) if you try to write long functions. It > > also takes up flash space (not too much though) and maybe in the > > future we need this flash space for other things? > > > > I like this too. Take a look at this - http://peter-cockerell.net/aalp/ > from 1987!!!! My first programming language was BBC BASIC. > > Can we do both. My reason for asking is that there appears to be a clear > progression from the inline assembler to the cut'n'paste bytes solution. > While the primary audience for the micro:bit is obviously the kids, it's worth noting that the GCSE computing curriculum (depending on which one you read), still has references to using assembler & machine code. Having an actual device that is something the kids can use (rather use a web page simulator) and put even limited amounts of assembler into - even to switch on/off leds or pins - would probably be a major thing for teachers. (at least the ones that grasp the potential) For kids, it also puts in reach getting access to the lowest layers of the device, which makes this really cool. (I have a copy of "machine code for beginners" at home - http://boingboing.net/2013/05/16/1983s-wonderful-introducti.html - so anyone who says it's not for kids is just silly :-) ) Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Tue Oct 13 13:44:04 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 13 Oct 2015 04:44:04 -0700 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: <561CE122.3080902@ntoll.org> References: <561B814D.6080002@ntoll.org> <561CE122.3080902@ntoll.org> Message-ID: <561CEE84.5050501@hastings.org> On 10/13/2015 03:46 AM, Nicholas H.Tollervey wrote: > Larry, would it be possible to write up how you see this API working? > Something along the lines of the work I did for the music API (here: > https://github.com/dpgeorge/microbit-micropython/wiki/music-API) perhaps? The C API is documented on my Bitbucket page, and the Python API won't be very different. I also describe the problems the objects are meant to solve. Is that sufficient for now? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Tue Oct 13 13:46:21 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 13 Oct 2015 12:46:21 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: <561CEE84.5050501@hastings.org> References: <561B814D.6080002@ntoll.org> <561CE122.3080902@ntoll.org> <561CEE84.5050501@hastings.org> Message-ID: <561CEF0D.2000600@ntoll.org> On 13/10/15 12:44, Larry Hastings wrote: > The C API is documented on my Bitbucket page, and the Python API won't > be very different. I also describe the problems the objects are meant > to solve. Is that sufficient for now? > URL..? (I did try https://bitbucket.org/larryhastings/ but get a 404 and I presume your repos is private anyway!) N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From larry at hastings.org Tue Oct 13 13:48:10 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 13 Oct 2015 04:48:10 -0700 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: <561CEF0D.2000600@ntoll.org> References: <561B814D.6080002@ntoll.org> <561CE122.3080902@ntoll.org> <561CEE84.5050501@hastings.org> <561CEF0D.2000600@ntoll.org> Message-ID: <561CEF7A.5040203@hastings.org> On 10/13/2015 04:46 AM, Nicholas H.Tollervey wrote: > On 13/10/15 12:44, Larry Hastings wrote: >> The C API is documented on my Bitbucket page, and the Python API won't >> be very different. I also describe the problems the objects are meant >> to solve. Is that sufficient for now? >> > URL..? (I did try https://bitbucket.org/larryhastings/ but get a 404 and > I presume your repos is private anyway!) It's public--hidden in plain sight. Here's the URL, posted to the list for the third time. https://bitbucket.org/larry/microbit_game //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at thinkingbinaries.com Tue Oct 13 13:53:59 2015 From: david at thinkingbinaries.com (David Whale) Date: Tue, 13 Oct 2015 12:53:59 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: References: <561B814D.6080002@ntoll.org> <561CE122.3080902@ntoll.org> Message-ID: Most, if not all, schools teach LMC (Little Man Computer).Those who do use real hardware for assembly tend to use Microchip PIC's because they have a tiny instruction set you can teach completely in 1 or two lessons. I have a clean room implementation of an extensible LMC simulator written in Python here: https://github.com/whaleygeek/MyLittleComputer I was considering using the extendable IO instruction to expose GPIO on raspberry pi, but now I think of it, running LMC on the micro:bit would be fun, and directly applicable to what schools already teach. D ___________________________________________________________ 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 13 October 2015 at 12:33, Michael wrote: > On 13 October 2015 at 11:46, Nicholas H.Tollervey wrote: > ... > >> > 2. The proper inline assembler that already exists, where you write >> code like: >> > >> > @micropython.asm_thumb >> > def f(r0, r1): >> > label(loop) >> > add(r0, r1) >> > bne(loop) >> > >> > This is easier to hack, but since it's verbose you'll run out of >> > memory (in the compile stage) if you try to write long functions. It >> > also takes up flash space (not too much though) and maybe in the >> > future we need this flash space for other things? >> > >> >> I like this too. Take a look at this - http://peter-cockerell.net/aalp/ >> from 1987!!!! My first programming language was BBC BASIC. >> >> Can we do both. My reason for asking is that there appears to be a clear >> progression from the inline assembler to the cut'n'paste bytes solution. >> > > While the primary audience for the micro:bit is obviously the kids, it's > worth noting that the GCSE computing curriculum (depending on which one you > read), still has references to using assembler & machine code. Having an > actual device that is something the kids can use (rather use a web page > simulator) and put even limited amounts of assembler into - even to switch > on/off leds or pins - would probably be a major thing for teachers. (at > least the ones that grasp the potential) > > For kids, it also puts in reach getting access to the lowest layers of the > device, which makes this really cool. > > (I have a copy of "machine code for beginners" at home - > http://boingboing.net/2013/05/16/1983s-wonderful-introducti.html - so > anyone who says it's not for kids is just silly :-) ) > > > Michael. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at thinkingbinaries.com Tue Oct 13 13:56:34 2015 From: david at thinkingbinaries.com (David Whale) Date: Tue, 13 Oct 2015 12:56:34 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: <561CE6DB.4010005@ntoll.org> References: <561B814D.6080002@ntoll.org> <561CE6DB.4010005@ntoll.org> Message-ID: If we could get this module built into the build, it would probably work out of the box over USB, which would be a complete game changer for things like SonicPi (which apparently supports MIDI). https://developer.mbed.org/cookbook/USBMIDI 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 13 October 2015 at 12:11, Nicholas H.Tollervey wrote: > Hi David, > > On 12/10/15 23:49, David Whale wrote: > > Regarding MIDI > > > > All the MIDI needs to connect to an external MIDI synth (e.g. a keyboard > > with a MIDI IN port) is a UART Tx on one of the pins running at > > 31250bps,n,8,1. Damien, is there a DAL api or something in the > > MicroPython that exposes the on-pins UART? This would be a MIDI-OUT from > > the micro:bit > > > > Damien states in his reply the MicroPython supports UART. Not sure what > information you need to start playing around. > > > MIDI-IN could be interesting, it would mean you could press a button on > > an external keyboard synth, and a note-on message would come into the > > micro:bit - what you would do with it then I'm not sure, so perhaps this > > is less valuable? > > > > This is VERY valuable since MIDI is used by VJ / DJ type people to > signal all sorts of events in multimedia displays. Someone at the BBC > got very excited when I mentioned we were only looking at MIDI. > > > > > The messages are very simple and well defined (mostly 2 byte messages). > > There is a small single chip circuit (opto isolator) that is required to > > make the electrical connection. You can then play any note and change > > any controller (e.g. shake the micro:bit to do a pitch bend could be > > real fun!) > > > > MIDI over USB (e.g. so the micro:bit is presented as a MIDI device to > > the PC/Mac) is much harder, because it requires the USB descriptor in > > the interface chip to be reprogrammed and we don't have access to that, > > so I think we should forget that idea. > > > > I spoke to Martin Wooley about perhaps MIDI over bluetooth (there is a > > profile for it), but he didn't seem keen in making any changes to the > > existing profiles, preferring the innovation to happen at the PC end. > > > > So, plug your micro:bit into a small chip and then into a 5-pin DIN plug > > in the back of your synthesiser could be really great, it might also > > open up SonicPi access by using a MIDI/USB adaptor into the PC/Mac/Pi. > > > > Mostly the code would be a set of constants for the message types and > > note numbers, perhaps with a few wrapper functions in python (note_on, > > note_off, play, set_patch, control_change, sysex). > > > > I sense the only way to make this happen would be for me or someone to > > write a quick spec for the API, then anyone could actually write the > code. > > > > Given the API is so thin, if there is a good API for UART, this could > > easily be a python frozen module as it's then easy for anyone to write > > and test and contribute to the mix. > > > > Exactly, although making it "native" would be better. > > > > > It does beg the question whether we should consider a 'redirect' option > > from the music module Matthew is writing, so you can either play beeps > > through the speaker, OR send MIDI note messages, using the same lovely > > API. Note MIDI has controllers (like pitch bend) that would be excellent > > to expose for things like 'accelerometer tilt varies pitch bend or > > modulation wheel'. > > > > Agreed. > > > If timing is tight, it would be possible I think to write this as an > > example py program instead, and bring it in as a frozen module later > > perhaps. I have a huge amount on at the moment I'm not sure I could > > commit to making all this work in time for a V1 release window. > > > > Hmm... ok. What can we do to help make this happen? > > N. > > > 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 12 October 2015 at 22:59, Damien George > > wrote: > > > > Yes, I think we need some direction and goals to get uPy on the > > microbit to a "v1.0" state. > > > > We've had a lot of good ideas, discussion and contributions. I think > > we are close to having a very usable API. > > > > > * Music API - first draft of Matthew's native API is merged into > master. > > > Requires further development to allow it to work in the > background. I'll > > > be adding musical examples over the course of this week and > testing it > > > from a musician's perspective. > > > > I think the music module is wonderful. It's so easy at the REPL to > do: > > > > music.tune(pin0, ['c', 'd', 'e', 'f', 'g', 'a', 'b', 'c']) > > > > or even: > > > > music.tune(pin0, [chr(ord('c') + i) for i in range(8)]) > > > > or better still: > > > > music.tune(pin0, list('cdefgabc')) > > > > Yes it needs work to have non-blocking mode. And builtin tunes would > > be awesome. > > > > > * Larry's game related work - I think this is hugely important. > Kids > > > love games and showing off their work to each other. If we can > make it > > > super easy to facilitate such hacking then we're doing something > > > marvellous. > > > > Yes, it's great to have Larry's experience with game writing to make > > a good API. > > > > > * Marks' image related work - again, this is hugely important > because > > > being able to see the result of your code is a great inspiration to > > > kids. The easier and more capable we make this the better it'll be > for > > > all concerned. > > > > Yep. Even with the additional features added here, we still have a > > really easy entry point to simply scroll a message or animate a > > sequence of images. > > > > > * Damien's suggestion of inline assembler which sounds like it'd > be a > > > wonderful thing for the hacker/maker audience the BBC are also > hoping to > > > tempt as a secondary market. > > > > I can add this if we think it'll be attractive. There are 2 options: > > > > 1. A simple "machine_code" function that takes raw bytes and turns > > them into a function. Very hard to use, eg: fun = > > machine_code(b'\x12\x34\x56') and you have to find out the correct > > byte values by assembling offline with an arm assembler, then looking > > at the output. Really hard to use (but then that might give it a > cool > > factor!). > > > > 2. The proper inline assembler that already exists, where you write > > code like: > > > > @micropython.asm_thumb > > def f(r0, r1): > > label(loop) > > add(r0, r1) > > bne(loop) > > > > This is easier to hack, but since it's verbose you'll run out of > > memory (in the compile stage) if you try to write long functions. It > > also takes up flash space (not too much though) and maybe in the > > future we need this flash space for other things? > > > > Regarding attracting the hacker/maker audience: I think it's > important > > to point out that starting with the microbit is an entry point to > > learning MicroPython, and then people who want more can buy a more > > capable board that runs uPy (eg pyboard). > > > > Oh, and uPy on the microbit also supports I2C and UART interfaces, > for > > those that want to interface with other electronic components (temp > > sensors, etc). > > > > > * David's MIDI related suggestions. I'm not clear what would be > involved > > > for this - I presume we could use USB/serial to send MIDI > information to > > > a MIDI device running elsewhere. David, it'd be helpful to learn > how you > > > see this working. > > > > I don't have any experience with MIDI, so also don't see how this > > would work (and can't really test it...). > > > > > * Damien and I discussed turning the display into some sort of > generic > > > graphical equaliser for arbitrary data. > > > > It would be neat, but I think this would be a lower priority (unless > > the BBC really likes the idea...). > > _______________________________________________ > > 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: From matthewelse1997 at gmail.com Tue Oct 13 13:58:21 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Tue, 13 Oct 2015 12:58:21 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: References: <561B814D.6080002@ntoll.org> <561CE6DB.4010005@ntoll.org> Message-ID: That would be great, but unfortunately this wouldn?t work with the way that the NRF51822 chip is connected up on the board (the Freescale chip on the micro:bit does all of the USB communication), so getting this to work would be for all intents and purposes impossible. From: Microbit on behalf of David Whale Reply-To: For Pythonic MicroBit related disucssions Date: Tuesday, 13 October 2015 at 12:56 To: For Pythonic MicroBit related disucssions Subject: Re: [Microbit-Python] Current state of play - a summary and straw man If we could get this module built into the build, it would probably work out of the box over USB, which would be a complete game changer for things like SonicPi (which apparently supports MIDI). https://developer.mbed.org/cookbook/USBMIDI 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 13 October 2015 at 12:11, Nicholas H.Tollervey wrote: Hi David, On 12/10/15 23:49, David Whale wrote: > Regarding MIDI > > All the MIDI needs to connect to an external MIDI synth (e.g. a keyboard > with a MIDI IN port) is a UART Tx on one of the pins running at > 31250bps,n,8,1. Damien, is there a DAL api or something in the > MicroPython that exposes the on-pins UART? This would be a MIDI-OUT from > the micro:bit > Damien states in his reply the MicroPython supports UART. Not sure what information you need to start playing around. > MIDI-IN could be interesting, it would mean you could press a button on > an external keyboard synth, and a note-on message would come into the > micro:bit - what you would do with it then I'm not sure, so perhaps this > is less valuable? > This is VERY valuable since MIDI is used by VJ / DJ type people to signal all sorts of events in multimedia displays. Someone at the BBC got very excited when I mentioned we were only looking at MIDI. > > The messages are very simple and well defined (mostly 2 byte messages). > There is a small single chip circuit (opto isolator) that is required to > make the electrical connection. You can then play any note and change > any controller (e.g. shake the micro:bit to do a pitch bend could be > real fun!) > > MIDI over USB (e.g. so the micro:bit is presented as a MIDI device to > the PC/Mac) is much harder, because it requires the USB descriptor in > the interface chip to be reprogrammed and we don't have access to that, > so I think we should forget that idea. > > I spoke to Martin Wooley about perhaps MIDI over bluetooth (there is a > profile for it), but he didn't seem keen in making any changes to the > existing profiles, preferring the innovation to happen at the PC end. > > So, plug your micro:bit into a small chip and then into a 5-pin DIN plug > in the back of your synthesiser could be really great, it might also > open up SonicPi access by using a MIDI/USB adaptor into the PC/Mac/Pi. > > Mostly the code would be a set of constants for the message types and > note numbers, perhaps with a few wrapper functions in python (note_on, > note_off, play, set_patch, control_change, sysex). > > I sense the only way to make this happen would be for me or someone to > write a quick spec for the API, then anyone could actually write the code. > > Given the API is so thin, if there is a good API for UART, this could > easily be a python frozen module as it's then easy for anyone to write > and test and contribute to the mix. > Exactly, although making it "native" would be better. > > It does beg the question whether we should consider a 'redirect' option > from the music module Matthew is writing, so you can either play beeps > through the speaker, OR send MIDI note messages, using the same lovely > API. Note MIDI has controllers (like pitch bend) that would be excellent > to expose for things like 'accelerometer tilt varies pitch bend or > modulation wheel'. > Agreed. > If timing is tight, it would be possible I think to write this as an > example py program instead, and bring it in as a frozen module later > perhaps. I have a huge amount on at the moment I'm not sure I could > commit to making all this work in time for a V1 release window. > Hmm... ok. What can we do to help make this happen? N. > 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 12 October 2015 at 22:59, Damien George > wrote: > > Yes, I think we need some direction and goals to get uPy on the > microbit to a "v1.0" state. > > We've had a lot of good ideas, discussion and contributions. I think > we are close to having a very usable API. > > > * Music API - first draft of Matthew's native API is merged into master. > > Requires further development to allow it to work in the background. I'll > > be adding musical examples over the course of this week and testing it > > from a musician's perspective. > > I think the music module is wonderful. It's so easy at the REPL to do: > > music.tune(pin0, ['c', 'd', 'e', 'f', 'g', 'a', 'b', 'c']) > > or even: > > music.tune(pin0, [chr(ord('c') + i) for i in range(8)]) > > or better still: > > music.tune(pin0, list('cdefgabc')) > > Yes it needs work to have non-blocking mode. And builtin tunes would > be awesome. > > > * Larry's game related work - I think this is hugely important. Kids > > love games and showing off their work to each other. If we can make it > > super easy to facilitate such hacking then we're doing something > > marvellous. > > Yes, it's great to have Larry's experience with game writing to make > a good API. > > > * Marks' image related work - again, this is hugely important because > > being able to see the result of your code is a great inspiration to > > kids. The easier and more capable we make this the better it'll be for > > all concerned. > > Yep. Even with the additional features added here, we still have a > really easy entry point to simply scroll a message or animate a > sequence of images. > > > * Damien's suggestion of inline assembler which sounds like it'd be a > > wonderful thing for the hacker/maker audience the BBC are also hoping to > > tempt as a secondary market. > > I can add this if we think it'll be attractive. There are 2 options: > > 1. A simple "machine_code" function that takes raw bytes and turns > them into a function. Very hard to use, eg: fun = > machine_code(b'\x12\x34\x56') and you have to find out the correct > byte values by assembling offline with an arm assembler, then looking > at the output. Really hard to use (but then that might give it a cool > factor!). > > 2. The proper inline assembler that already exists, where you write > code like: > > @micropython.asm_thumb > def f(r0, r1): > label(loop) > add(r0, r1) > bne(loop) > > This is easier to hack, but since it's verbose you'll run out of > memory (in the compile stage) if you try to write long functions. It > also takes up flash space (not too much though) and maybe in the > future we need this flash space for other things? > > Regarding attracting the hacker/maker audience: I think it's important > to point out that starting with the microbit is an entry point to > learning MicroPython, and then people who want more can buy a more > capable board that runs uPy (eg pyboard). > > Oh, and uPy on the microbit also supports I2C and UART interfaces, for > those that want to interface with other electronic components (temp > sensors, etc). > > > * David's MIDI related suggestions. I'm not clear what would be involved > > for this - I presume we could use USB/serial to send MIDI information to > > a MIDI device running elsewhere. David, it'd be helpful to learn how you > > see this working. > > I don't have any experience with MIDI, so also don't see how this > would work (and can't really test it...). > > > * Damien and I discussed turning the display into some sort of generic > > graphical equaliser for arbitrary data. > > It would be neat, but I think this would be a lower priority (unless > the BBC really likes the idea...). > _______________________________________________ > 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 _______________________________________________ Microbit mailing list Microbit at python.org https://mail.python.org/mailman/listinfo/microbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Tue Oct 13 14:01:58 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 13 Oct 2015 13:01:58 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: <561CEF7A.5040203@hastings.org> References: <561B814D.6080002@ntoll.org> <561CE122.3080902@ntoll.org> <561CEE84.5050501@hastings.org> <561CEF0D.2000600@ntoll.org> <561CEF7A.5040203@hastings.org> Message-ID: In response to "regarding MIDI": yes I've implemented UART recently and I just checked that it supports 31250 baud, 8n1. So it would be pretty trivial to write MIDI in and out code directly in Python right now. Eg: from microbit import * uart.init(31250, pins=(pin0, pin1)) # setup uart, tx=pin0, rx=pin1 uart.write(b'\x90\x10\x25') # note on cmd = uart.read(3) # read whole command A caveat: there is only 1 uart on the nrf51 and so configuring it to go to pins 0 and 1 (tx,rx respectively) disables the REPL. I don't have any midi devices so someone else will need to pick up the ball on this if it is to proceed further. Regarding MIDI USB: we would need help from ARM to do that, since they 'd have to write the code for the freescale host chip. On Tue, Oct 13, 2015 at 12:48 PM, Larry Hastings wrote: > > > On 10/13/2015 04:46 AM, Nicholas H.Tollervey wrote: > > On 13/10/15 12:44, Larry Hastings wrote: > > The C API is documented on my Bitbucket page, and the Python API won't > be very different. I also describe the problems the objects are meant > to solve. Is that sufficient for now? > > URL..? (I did try https://bitbucket.org/larryhastings/ but get a 404 and > I presume your repos is private anyway!) > > > It's public--hidden in plain sight. Here's the URL, posted to the list for > the third time. > > https://bitbucket.org/larry/microbit_game > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From matthewelse1997 at gmail.com Tue Oct 13 14:03:48 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Tue, 13 Oct 2015 13:03:48 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: References: <561B814D.6080002@ntoll.org> <561CE6DB.4010005@ntoll.org> Message-ID: Actually impossible isn?t the most accurate, perhaps decidedly non-trivial would be better. From: Microbit on behalf of David Whale Reply-To: For Pythonic MicroBit related disucssions Date: Tuesday, 13 October 2015 at 12:56 To: For Pythonic MicroBit related disucssions Subject: Re: [Microbit-Python] Current state of play - a summary and straw man If we could get this module built into the build, it would probably work out of the box over USB, which would be a complete game changer for things like SonicPi (which apparently supports MIDI). https://developer.mbed.org/cookbook/USBMIDI 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 13 October 2015 at 12:11, Nicholas H.Tollervey wrote: Hi David, On 12/10/15 23:49, David Whale wrote: > Regarding MIDI > > All the MIDI needs to connect to an external MIDI synth (e.g. a keyboard > with a MIDI IN port) is a UART Tx on one of the pins running at > 31250bps,n,8,1. Damien, is there a DAL api or something in the > MicroPython that exposes the on-pins UART? This would be a MIDI-OUT from > the micro:bit > Damien states in his reply the MicroPython supports UART. Not sure what information you need to start playing around. > MIDI-IN could be interesting, it would mean you could press a button on > an external keyboard synth, and a note-on message would come into the > micro:bit - what you would do with it then I'm not sure, so perhaps this > is less valuable? > This is VERY valuable since MIDI is used by VJ / DJ type people to signal all sorts of events in multimedia displays. Someone at the BBC got very excited when I mentioned we were only looking at MIDI. > > The messages are very simple and well defined (mostly 2 byte messages). > There is a small single chip circuit (opto isolator) that is required to > make the electrical connection. You can then play any note and change > any controller (e.g. shake the micro:bit to do a pitch bend could be > real fun!) > > MIDI over USB (e.g. so the micro:bit is presented as a MIDI device to > the PC/Mac) is much harder, because it requires the USB descriptor in > the interface chip to be reprogrammed and we don't have access to that, > so I think we should forget that idea. > > I spoke to Martin Wooley about perhaps MIDI over bluetooth (there is a > profile for it), but he didn't seem keen in making any changes to the > existing profiles, preferring the innovation to happen at the PC end. > > So, plug your micro:bit into a small chip and then into a 5-pin DIN plug > in the back of your synthesiser could be really great, it might also > open up SonicPi access by using a MIDI/USB adaptor into the PC/Mac/Pi. > > Mostly the code would be a set of constants for the message types and > note numbers, perhaps with a few wrapper functions in python (note_on, > note_off, play, set_patch, control_change, sysex). > > I sense the only way to make this happen would be for me or someone to > write a quick spec for the API, then anyone could actually write the code. > > Given the API is so thin, if there is a good API for UART, this could > easily be a python frozen module as it's then easy for anyone to write > and test and contribute to the mix. > Exactly, although making it "native" would be better. > > It does beg the question whether we should consider a 'redirect' option > from the music module Matthew is writing, so you can either play beeps > through the speaker, OR send MIDI note messages, using the same lovely > API. Note MIDI has controllers (like pitch bend) that would be excellent > to expose for things like 'accelerometer tilt varies pitch bend or > modulation wheel'. > Agreed. > If timing is tight, it would be possible I think to write this as an > example py program instead, and bring it in as a frozen module later > perhaps. I have a huge amount on at the moment I'm not sure I could > commit to making all this work in time for a V1 release window. > Hmm... ok. What can we do to help make this happen? N. > 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 12 October 2015 at 22:59, Damien George > wrote: > > Yes, I think we need some direction and goals to get uPy on the > microbit to a "v1.0" state. > > We've had a lot of good ideas, discussion and contributions. I think > we are close to having a very usable API. > > > * Music API - first draft of Matthew's native API is merged into master. > > Requires further development to allow it to work in the background. I'll > > be adding musical examples over the course of this week and testing it > > from a musician's perspective. > > I think the music module is wonderful. It's so easy at the REPL to do: > > music.tune(pin0, ['c', 'd', 'e', 'f', 'g', 'a', 'b', 'c']) > > or even: > > music.tune(pin0, [chr(ord('c') + i) for i in range(8)]) > > or better still: > > music.tune(pin0, list('cdefgabc')) > > Yes it needs work to have non-blocking mode. And builtin tunes would > be awesome. > > > * Larry's game related work - I think this is hugely important. Kids > > love games and showing off their work to each other. If we can make it > > super easy to facilitate such hacking then we're doing something > > marvellous. > > Yes, it's great to have Larry's experience with game writing to make > a good API. > > > * Marks' image related work - again, this is hugely important because > > being able to see the result of your code is a great inspiration to > > kids. The easier and more capable we make this the better it'll be for > > all concerned. > > Yep. Even with the additional features added here, we still have a > really easy entry point to simply scroll a message or animate a > sequence of images. > > > * Damien's suggestion of inline assembler which sounds like it'd be a > > wonderful thing for the hacker/maker audience the BBC are also hoping to > > tempt as a secondary market. > > I can add this if we think it'll be attractive. There are 2 options: > > 1. A simple "machine_code" function that takes raw bytes and turns > them into a function. Very hard to use, eg: fun = > machine_code(b'\x12\x34\x56') and you have to find out the correct > byte values by assembling offline with an arm assembler, then looking > at the output. Really hard to use (but then that might give it a cool > factor!). > > 2. The proper inline assembler that already exists, where you write > code like: > > @micropython.asm_thumb > def f(r0, r1): > label(loop) > add(r0, r1) > bne(loop) > > This is easier to hack, but since it's verbose you'll run out of > memory (in the compile stage) if you try to write long functions. It > also takes up flash space (not too much though) and maybe in the > future we need this flash space for other things? > > Regarding attracting the hacker/maker audience: I think it's important > to point out that starting with the microbit is an entry point to > learning MicroPython, and then people who want more can buy a more > capable board that runs uPy (eg pyboard). > > Oh, and uPy on the microbit also supports I2C and UART interfaces, for > those that want to interface with other electronic components (temp > sensors, etc). > > > * David's MIDI related suggestions. I'm not clear what would be involved > > for this - I presume we could use USB/serial to send MIDI information to > > a MIDI device running elsewhere. David, it'd be helpful to learn how you > > see this working. > > I don't have any experience with MIDI, so also don't see how this > would work (and can't really test it...). > > > * Damien and I discussed turning the display into some sort of generic > > graphical equaliser for arbitrary data. > > It would be neat, but I think this would be a lower priority (unless > the BBC really likes the idea...). > _______________________________________________ > 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 _______________________________________________ Microbit mailing list Microbit at python.org https://mail.python.org/mailman/listinfo/microbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Tue Oct 13 14:10:34 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 13 Oct 2015 13:10:34 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: <561CEF7A.5040203@hastings.org> References: <561B814D.6080002@ntoll.org> <561CE122.3080902@ntoll.org> <561CEE84.5050501@hastings.org> <561CEF0D.2000600@ntoll.org> <561CEF7A.5040203@hastings.org> Message-ID: <561CF4BA.8070105@ntoll.org> On 13/10/15 12:48, Larry Hastings wrote: > Here's the URL, posted to the list for the third time. Apologies, Larry... that looks great..! I'll try to write up what I imagine this may look like as a Python module for use by kids on the micro:bit. It'll be a straw man and everyone is more than welcome to burn it to the ground. ;-) N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From david at thinkingbinaries.com Tue Oct 13 15:19:01 2015 From: david at thinkingbinaries.com (David Whale) Date: Tue, 13 Oct 2015 14:19:01 +0100 Subject: [Microbit-Python] Current state of play - a summary and straw man In-Reply-To: References: <561B814D.6080002@ntoll.org> <561CE6DB.4010005@ntoll.org> Message-ID: I had expected that would be the case with the interface chip. I was excited when I read about USBMidi on the mbed forums. So, using the onboard uart is the only way then. The circuitry and code are really simple to be honest. 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 13 October 2015 at 12:58, Matthew Else wrote: > That would be great, but unfortunately this wouldn?t work with the way > that the NRF51822 chip is connected up on the board (the Freescale chip on > the micro:bit does all of the USB communication), so getting this to work > would be for all intents and purposes impossible. > > > From: Microbit on behalf of David Whale > Reply-To: For Pythonic MicroBit related disucssions > Date: Tuesday, 13 October 2015 at 12:56 > To: For Pythonic MicroBit related disucssions > Subject: Re: [Microbit-Python] Current state of play - a summary and > straw man > > If we could get this module built into the build, it would probably work > out of the box over USB, which would be a complete game changer for things > like SonicPi (which apparently supports MIDI). > > https://developer.mbed.org/cookbook/USBMIDI > > 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 13 October 2015 at 12:11, Nicholas H.Tollervey wrote: > >> Hi David, >> >> On 12/10/15 23:49, David Whale wrote: >> > Regarding MIDI >> > >> > All the MIDI needs to connect to an external MIDI synth (e.g. a keyboard >> > with a MIDI IN port) is a UART Tx on one of the pins running at >> > 31250bps,n,8,1. Damien, is there a DAL api or something in the >> > MicroPython that exposes the on-pins UART? This would be a MIDI-OUT from >> > the micro:bit >> > >> >> Damien states in his reply the MicroPython supports UART. Not sure what >> information you need to start playing around. >> >> > MIDI-IN could be interesting, it would mean you could press a button on >> > an external keyboard synth, and a note-on message would come into the >> > micro:bit - what you would do with it then I'm not sure, so perhaps this >> > is less valuable? >> > >> >> This is VERY valuable since MIDI is used by VJ / DJ type people to >> signal all sorts of events in multimedia displays. Someone at the BBC >> got very excited when I mentioned we were only looking at MIDI. >> >> > >> > The messages are very simple and well defined (mostly 2 byte messages). >> > There is a small single chip circuit (opto isolator) that is required to >> > make the electrical connection. You can then play any note and change >> > any controller (e.g. shake the micro:bit to do a pitch bend could be >> > real fun!) >> > >> > MIDI over USB (e.g. so the micro:bit is presented as a MIDI device to >> > the PC/Mac) is much harder, because it requires the USB descriptor in >> > the interface chip to be reprogrammed and we don't have access to that, >> > so I think we should forget that idea. >> > >> > I spoke to Martin Wooley about perhaps MIDI over bluetooth (there is a >> > profile for it), but he didn't seem keen in making any changes to the >> > existing profiles, preferring the innovation to happen at the PC end. >> > >> > So, plug your micro:bit into a small chip and then into a 5-pin DIN plug >> > in the back of your synthesiser could be really great, it might also >> > open up SonicPi access by using a MIDI/USB adaptor into the PC/Mac/Pi. >> > >> > Mostly the code would be a set of constants for the message types and >> > note numbers, perhaps with a few wrapper functions in python (note_on, >> > note_off, play, set_patch, control_change, sysex). >> > >> > I sense the only way to make this happen would be for me or someone to >> > write a quick spec for the API, then anyone could actually write the >> code. >> > >> > Given the API is so thin, if there is a good API for UART, this could >> > easily be a python frozen module as it's then easy for anyone to write >> > and test and contribute to the mix. >> > >> >> Exactly, although making it "native" would be better. >> >> > >> > It does beg the question whether we should consider a 'redirect' option >> > from the music module Matthew is writing, so you can either play beeps >> > through the speaker, OR send MIDI note messages, using the same lovely >> > API. Note MIDI has controllers (like pitch bend) that would be excellent >> > to expose for things like 'accelerometer tilt varies pitch bend or >> > modulation wheel'. >> > >> >> Agreed. >> >> > If timing is tight, it would be possible I think to write this as an >> > example py program instead, and bring it in as a frozen module later >> > perhaps. I have a huge amount on at the moment I'm not sure I could >> > commit to making all this work in time for a V1 release window. >> > >> >> Hmm... ok. What can we do to help make this happen? >> >> N. >> >> > 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 12 October 2015 at 22:59, Damien George > > > wrote: >> > >> > Yes, I think we need some direction and goals to get uPy on the >> > microbit to a "v1.0" state. >> > >> > We've had a lot of good ideas, discussion and contributions. I >> think >> > we are close to having a very usable API. >> > >> > > * Music API - first draft of Matthew's native API is merged into >> master. >> > > Requires further development to allow it to work in the >> background. I'll >> > > be adding musical examples over the course of this week and >> testing it >> > > from a musician's perspective. >> > >> > I think the music module is wonderful. It's so easy at the REPL to >> do: >> > >> > music.tune(pin0, ['c', 'd', 'e', 'f', 'g', 'a', 'b', 'c']) >> > >> > or even: >> > >> > music.tune(pin0, [chr(ord('c') + i) for i in range(8)]) >> > >> > or better still: >> > >> > music.tune(pin0, list('cdefgabc')) >> > >> > Yes it needs work to have non-blocking mode. And builtin tunes >> would >> > be awesome. >> > >> > > * Larry's game related work - I think this is hugely important. >> Kids >> > > love games and showing off their work to each other. If we can >> make it >> > > super easy to facilitate such hacking then we're doing something >> > > marvellous. >> > >> > Yes, it's great to have Larry's experience with game writing to make >> > a good API. >> > >> > > * Marks' image related work - again, this is hugely important >> because >> > > being able to see the result of your code is a great inspiration >> to >> > > kids. The easier and more capable we make this the better it'll >> be for >> > > all concerned. >> > >> > Yep. Even with the additional features added here, we still have a >> > really easy entry point to simply scroll a message or animate a >> > sequence of images. >> > >> > > * Damien's suggestion of inline assembler which sounds like it'd >> be a >> > > wonderful thing for the hacker/maker audience the BBC are also >> hoping to >> > > tempt as a secondary market. >> > >> > I can add this if we think it'll be attractive. There are 2 >> options: >> > >> > 1. A simple "machine_code" function that takes raw bytes and turns >> > them into a function. Very hard to use, eg: fun = >> > machine_code(b'\x12\x34\x56') and you have to find out the correct >> > byte values by assembling offline with an arm assembler, then >> looking >> > at the output. Really hard to use (but then that might give it a >> cool >> > factor!). >> > >> > 2. The proper inline assembler that already exists, where you write >> > code like: >> > >> > @micropython.asm_thumb >> > def f(r0, r1): >> > label(loop) >> > add(r0, r1) >> > bne(loop) >> > >> > This is easier to hack, but since it's verbose you'll run out of >> > memory (in the compile stage) if you try to write long functions. >> It >> > also takes up flash space (not too much though) and maybe in the >> > future we need this flash space for other things? >> > >> > Regarding attracting the hacker/maker audience: I think it's >> important >> > to point out that starting with the microbit is an entry point to >> > learning MicroPython, and then people who want more can buy a more >> > capable board that runs uPy (eg pyboard). >> > >> > Oh, and uPy on the microbit also supports I2C and UART interfaces, >> for >> > those that want to interface with other electronic components (temp >> > sensors, etc). >> > >> > > * David's MIDI related suggestions. I'm not clear what would be >> involved >> > > for this - I presume we could use USB/serial to send MIDI >> information to >> > > a MIDI device running elsewhere. David, it'd be helpful to learn >> how you >> > > see this working. >> > >> > I don't have any experience with MIDI, so also don't see how this >> > would work (and can't really test it...). >> > >> > > * Damien and I discussed turning the display into some sort of >> generic >> > > graphical equaliser for arbitrary data. >> > >> > It would be neat, but I think this would be a lower priority (unless >> > the BBC really likes the idea...). >> > _______________________________________________ >> > 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 >> >> > _______________________________________________ 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: From damien.p.george at gmail.com Tue Oct 13 16:34:58 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 13 Oct 2015 15:34:58 +0100 Subject: [Microbit-Python] Resolution on micro:bit timer is, uh, not great In-Reply-To: <561BB38B.80003@hastings.org> References: <561B247C.8070000@hastings.org> <561B2D1B.2070305@hastings.org> <561B2EA5.2050303@hastings.org> <561BB38B.80003@hastings.org> Message-ID: Hi Larry, I had a look at us_ticker_read(). It runs off the 32768Hz RTC so that's its ultimate resolution. Being 32 bits it has a maximum time of 71.6 minutes, which is not very long. Can you think of a way to provide a 1ms accurate counter using both the fiber 6ms timer and us_ticker_read()? I do like your idea of making a proper ms sleep that uses 6ms sleep + polling for the last bit. Will you be able to implemente it? Cheers, Damien. On Mon, Oct 12, 2015 at 2:20 PM, Larry Hastings wrote: > On 10/12/2015 02:03 AM, Damien George wrote: > > Is it really necessary to have better accuracy? What's the use case? > > > Games. It should be possible to write fast-twitch games on the micro:bit. > For example, "reaction timer": sit staring at the screen, and the very > MOMENT you see an LED light up press a button. > > > I agree that a good "fix" would be to use us_ticker_read for > system_time (actually now called running_time) and then do busy > waiting for the (desired_time % 6) piece (although probably only need > to do that for short-ish times like less than 100ms, since large times > won't need precision..?). > > > I don't know why I would write a scheduler that was accurate for short > periods but inaccurate for long periods. > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From david at thinkingbinaries.com Tue Oct 13 16:48:01 2015 From: david at thinkingbinaries.com (David Whale) Date: Tue, 13 Oct 2015 15:48:01 +0100 Subject: [Microbit-Python] Resolution on micro:bit timer is, uh, not great In-Reply-To: <561BB38B.80003@hastings.org> References: <561B247C.8070000@hastings.org> <561B2D1B.2070305@hastings.org> <561B2EA5.2050303@hastings.org> <561BB38B.80003@hastings.org> Message-ID: Do you *need* more than 6ms accuracy for a reaction timer? That's faster than a typical button debounce time. http://www.ganssle.com/debouncing.htm D ___________________________________________________________ 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 12 October 2015 at 14:20, Larry Hastings wrote: > On 10/12/2015 02:03 AM, Damien George wrote: > > Is it really necessary to have better accuracy? What's the use case? > > > Games. It should be possible to write fast-twitch games on the > micro:bit. For example, "reaction timer": sit staring at the screen, and > the very MOMENT you see an LED light up press a button. > > > I agree that a good "fix" would be to use us_ticker_read for > system_time (actually now called running_time) and then do busy > waiting for the (desired_time % 6) piece (although probably only need > to do that for short-ish times like less than 100ms, since large times > won't need precision..?). > > > I don't know why I would write a scheduler that was accurate for short > periods but inaccurate for long periods. > > > */arry* > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Tue Oct 13 17:55:33 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 13 Oct 2015 16:55:33 +0100 Subject: [Microbit-Python] Built in tunes.... enjoy..! Message-ID: <561D2975.2000404@ntoll.org> Hi Folks, I've just spent half an hour collating these tunes for inclusion in the music module (yet to be implemented). Please try them out like this: >>> from microbit import music >>> from microbit import pin0 >>> DADADADUM = ['r3:2', 'g', 'g', 'g', 'eb:8', 'r:2', 'f', 'f', 'f', 'd:8'] >>> music.tune(pin0, DADADADUM) Make sure you have a speaker connected to GND and pin0 via crocodile clips for the full force of the pathos of such fragments... ;-) All of them are either out of copyright, composed by me and released to the public domain or, in the case of nyan-cat, composer untraceable. As you can see, I've tried to include different genres, music for different occasions and some familiar tunes that could be re-used in games. ;-) Ultimately (once I've figured things out) you'll be able to do this: >>> import microbit >>> microbit.music.tune(microbit.pin0, microbit.music.NYAN) The __repr__ for each melodic fragment will be the list of notes as defined below (so people can see how they could re-create or adapt them). Given a non-blocking music API (that Matthew is currently working on), Mark's new image implementation and Larry's game related classes I think we could implement a micro:nyan quite easily as a cool example. ;-) Here they are in full: DADADADUM = ['r3:2', 'g', 'g', 'g', 'eb:8', 'r:2', 'f', 'f', 'f', 'd:8'] ENTERTAINER = ['d3:1', 'd#', 'e', 'c4:2', 'e3:1', 'c4:2', 'e3:1', 'c4:3', 'c:1', 'd', 'd#', 'e', 'c', 'd', 'e:2', 'b3:1', 'd4:2', 'c:4'] PRELUDE = [ 'c3:1', 'e', 'g', 'c4', 'e', 'g3', 'c4', 'e', 'c3', 'e', 'g', 'c4', 'e', 'g3', 'c4', 'e', 'c3', 'd', 'g', 'd4', 'f', 'g3', 'd4', 'f', 'c3', 'd', 'g', 'd4', 'f', 'g3', 'd4', 'f', 'b2', 'd3', 'g', 'd4', 'f', 'g3', 'd4', 'f', 'b2', 'd3', 'g', 'd4', 'f', 'g3', 'd4', 'f', 'c3', 'e', 'g', 'c4', 'e', 'g3', 'c4', 'e', 'c3', 'e', 'g', 'c4', 'e', 'g3', 'c4', 'e', ] ODE = ['e4', 'e', 'f', 'g', 'g', 'f', 'e', 'd', 'c', 'c', 'd', 'e', 'e:6', 'd:2', 'd:8', 'e:4', 'e', 'f', 'g', 'g', 'f', 'e', 'd', 'c', 'c', 'd', 'e', 'd:6', 'c:2', 'c:8'] NYAN = ['f#4:2', 'g#', 'c#:1', 'd#:2', 'b3:1', 'd4:1', 'c#', 'b3:2', 'b', 'c#4', 'd', 'd:1', 'c#', 'b3:1', 'c#4:1', 'd#', 'f#', 'g#', 'd#', 'f#', 'c#', 'd', 'b3', 'c#4', 'b3', 'd#4:2', 'f#', 'g#:1', 'd#', 'f#', 'c#', 'd#', 'b3', 'd4', 'd#', 'd', 'c#', 'b3', 'c#4', 'd:2', 'b3:1', 'c#4', 'd#', 'f#', 'c#', 'd', 'c#', 'b3', 'c#4:2', 'b3', 'c#4', 'b3', 'f#:1', 'g#', 'b:2', 'f#:1', 'g#', 'b', 'c#4', 'd#', 'b3', 'e4', 'd#', 'e', 'f#', 'b3:2', 'b', 'f#:1', 'g#', 'b', 'f#', 'e4', 'd#', 'c#', 'b3', 'f#', 'd#', 'e', 'f#', 'b3:2', 'f#:1', 'g#', 'b:2', 'f#:1', 'g#', 'b', 'b', 'c#4', 'd#', 'b3', 'f#', 'g#', 'f#', 'b:2', 'b:1', 'a#', 'b', 'f#', 'g#', 'b', 'e4', 'd#', 'e', 'f#', 'b3:2', 'c#4'] RINGTONE = ['c3:1', 'd', 'e:2', 'g', 'd:1', 'e', 'f:2', 'a', 'e:1', 'f', 'g:2', 'b', 'c4:4'] FUNK = ['c2:2', 'c', 'd#', 'c:1', 'f:2', 'c:1', 'f:2', 'f#', 'g', 'c', 'c', 'g', 'c:1', 'f#:2', 'c:1', 'f#:2', 'f', 'd#'] BLUES = ['c2:2', 'e', 'g', 'a', 'a#', 'a', 'g', 'e', 'c2:2', 'e', 'g', 'a', 'a#', 'a', 'g', 'e', 'f', 'a', 'c3', 'd', 'd#', 'd', 'c', 'a2', 'c2:2', 'e', 'g', 'a', 'a#', 'a', 'g', 'e', 'g', 'b', 'd3', 'f', 'f2', 'a', 'c3', 'd#', 'c2:2', 'e', 'g', 'e', 'g', 'f', 'e', 'd'] BIRTHDAY = ['c3:3', 'c:1', 'd:4', 'c:4', 'f', 'e:8', 'c:3', 'c:1', 'd:4', 'c:4', 'g', 'f:8', 'c3:3', 'c:1', 'c4:4', 'a3', 'f', 'e', 'd', 'a#:3', 'a#:1', 'a:4', 'f', 'g', 'f:8'] WEDDING = ['c4:4', 'f:3', 'f:1', 'f:8', 'c:4', 'g:3', 'e:1', 'f:8', 'c:4', 'f:3', 'a:1', 'c5:4', 'a4:3', 'f:1', 'f:4', 'e:3', 'f:1', 'g:8'] FUNERAL = ['c3:4', 'c:3', 'c:1', 'c:4', 'd#:3', 'd:1', 'd:3', 'c:1', 'c:3', 'b2:1', 'c3:4'] PUNCHLINE = ['c4:3', 'g3:1', 'f#', 'g', 'g#:3', 'g', 'r', 'b', 'c4'] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From larry at hastings.org Tue Oct 13 19:21:24 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 13 Oct 2015 10:21:24 -0700 Subject: [Microbit-Python] Resolution on micro:bit timer is, uh, not great In-Reply-To: References: <561B247C.8070000@hastings.org> <561B2D1B.2070305@hastings.org> <561B2EA5.2050303@hastings.org> <561BB38B.80003@hastings.org> Message-ID: <561D3D94.2070402@hastings.org> On 10/13/2015 07:34 AM, Damien George wrote: > Hi Larry, > > I had a look at us_ticker_read(). It runs off the 32768Hz RTC so > that's its ultimate resolution. Being 32 bits it has a maximum time > of 71.6 minutes, which is not very long. > > Can you think of a way to provide a 1ms accurate counter using both > the fiber 6ms timer and us_ticker_read()? > > I do like your idea of making a proper ms sleep that uses 6ms sleep + > polling for the last bit. Will you be able to implemente it? I was playing around with it, here's how I left it: STATIC mp_obj_t microbit_running_time(void) { return MP_OBJ_NEW_SMALL_INT(us_ticker_read() / 1000); } STATIC mp_obj_t microbit_sleep(mp_obj_t ms_in) { uint32_t delay = mp_obj_get_int(ms_in); uint32_t time = us_ticker_read(); uint32_t wake_up_at = ((time / 1000) + delay) * 1000; if (delay > (FIBER_TICK_PERIOD_MS + 1)) uBit.sleep(delay - (FIBER_TICK_PERIOD_MS + 1)); if (time > wake_up_at) { /* ** at 1 million ticks per second, ** stored in uint32_t, ** we wrap every 72 minutes */ while (us_ticker_read() > wake_up_at) ; } while (us_ticker_read() < wake_up_at) ; return mp_const_none; } Feeding it random intervals (30 + random(50)) it was dead on 50% of the time and 1ms late 50% of the time. So the code is a little funny-looking because I was playing around with it, trying to figure out what was causing those late wakeups. (Not done yet--though it might just be a built-in measurement error.) If we use a uint32 to store time at 1ms precision, then yes we simply don't have a clock that goes for longer than 72 minutes. Do we need, for example, an API that lets the device sleep for 2 hours? It's doable, we just have to change our implementation a little. (Add a separate "seconds" global, and then when we increment ticks, while (ticks > 1000) { ticks -= 1000; seconds += 1; }.) //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Wed Oct 14 09:57:58 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 14 Oct 2015 08:57:58 +0100 Subject: [Microbit-Python] Gestures in the DAL or not..? Message-ID: <561E0B06.1090302@ntoll.org> Hi, I'm trying to recollect what the final status of this aspect of the micro:bit was. IIRC it's going to be in the DAL but I've not seen any evidence that it's coming sometime soon. It'd be good to have a gestures module a la: >>> import gestures >>> dir(gestures) [ 'shaken', 'dropped', 'tapped', ...etc...] >>> gestures.shaken() False etc... It strikes me that these are related, in some way, to Larry's acceleration_scaler work in that such gestures would consist of measurements made using something like the acceleration_scaler. Also, given such gestures perhaps we need a gesture_minder thingamabob that kids could use to track the state of such gestures and react appropriately (for example, a game where you reset the state by shaking the device). Thoughts? Ideas? Comments? N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ntoll at ntoll.org Thu Oct 15 00:07:45 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 14 Oct 2015 23:07:45 +0100 Subject: [Microbit-Python] Musical silliness... Message-ID: <561ED231.7080602@ntoll.org> https://www.youtube.com/watch?v=0ce6yJOaFcc Only a few things needed for the music module to be complete. :-) N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From tom at viner.tv Thu Oct 15 00:25:27 2015 From: tom at viner.tv (Tom Viner) Date: Wed, 14 Oct 2015 23:25:27 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561ED231.7080602@ntoll.org> References: <561ED231.7080602@ntoll.org> Message-ID: Very well done Nic. I want to hear NYAN! (maybe at the dojo...) On 14 October 2015 at 23:07, Nicholas H.Tollervey wrote: > https://www.youtube.com/watch?v=0ce6yJOaFcc > > Only a few things needed for the music module to be complete. :-) > > N. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at raspberrypi.org Thu Oct 15 00:35:33 2015 From: ben at raspberrypi.org (Ben Nuttall) Date: Wed, 14 Oct 2015 23:35:33 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: References: <561ED231.7080602@ntoll.org> Message-ID: Amazing Nic! Ben --- Ben Nuttall Education Developer Advocate Raspberry Pi Foundation www.raspberrypi.org UK registered charity 1129409 On 14 October 2015 at 23:25, Tom Viner wrote: > Very well done Nic. I want to hear NYAN! (maybe at the dojo...) > > On 14 October 2015 at 23:07, Nicholas H.Tollervey wrote: > >> https://www.youtube.com/watch?v=0ce6yJOaFcc >> >> Only a few things needed for the music module to be complete. :-) >> >> N. >> >> >> _______________________________________________ >> Microbit mailing list >> Microbit at python.org >> https://mail.python.org/mailman/listinfo/microbit >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Thu Oct 15 00:38:10 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 14 Oct 2015 23:38:10 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561ED231.7080602@ntoll.org> References: <561ED231.7080602@ntoll.org> Message-ID: <561ED952.50502@ntoll.org> On 14/10/15 23:07, Nicholas H.Tollervey wrote: > https://www.youtube.com/watch?v=0ce6yJOaFcc > > Only a few things needed for the music module to be complete. :-) > > N. > It should be mentioned that much of this is thanks to Matthew and Damien's hard work too. I just wrote the tunes and typed in the code. N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From sparks.m at gmail.com Thu Oct 15 00:38:16 2015 From: sparks.m at gmail.com (Michael) Date: Wed, 14 Oct 2015 23:38:16 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561ED231.7080602@ntoll.org> References: <561ED231.7080602@ntoll.org> Message-ID: That's really, really fun :-) Top tip - "The Works" have a cardboard speaker for ?2 at the moment. Might show how to rip that apart to use with this. :-) (I like scavenging places like The Works and Poundland for resources for this sort of thing because it's closer to the budget of kids :-) ) Michael. On 14 October 2015 at 23:07, Nicholas H.Tollervey wrote: > https://www.youtube.com/watch?v=0ce6yJOaFcc > > Only a few things needed for the music module to be complete. :-) > > N. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Thu Oct 15 00:45:08 2015 From: larry at hastings.org (Larry Hastings) Date: Wed, 14 Oct 2015 15:45:08 -0700 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561ED231.7080602@ntoll.org> References: <561ED231.7080602@ntoll.org> Message-ID: <561EDAF4.5030900@hastings.org> On 10/14/2015 03:07 PM, Nicholas H.Tollervey wrote: > https://www.youtube.com/watch?v=0ce6yJOaFcc > > Only a few things needed for the music module to be complete. :-) One observation: watching the video, I was surprised that the first parameter to microbit.tune was the output pin. I would have expected the first parameter to be the tune, and the second parameter to be the output pin with a /default/ of pin0. Yes? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Thu Oct 15 00:47:31 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 14 Oct 2015 23:47:31 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561EDAF4.5030900@hastings.org> References: <561ED231.7080602@ntoll.org> <561EDAF4.5030900@hastings.org> Message-ID: <561EDB83.507@ntoll.org> On 14/10/15 23:45, Larry Hastings wrote: > On 10/14/2015 03:07 PM, Nicholas H.Tollervey wrote: >> https://www.youtube.com/watch?v=0ce6yJOaFcc >> >> Only a few things needed for the music module to be complete. :-) > > One observation: watching the video, I was surprised that the first > parameter to microbit.tune was the output pin. I would have expected > the first parameter to be the tune, and the second parameter to be the > output pin with a /default/ of pin0. Yes? > > > //arry/ > We discussed this a few weeks ago. To cut a long story short, in music you always specify the instrument then notes - just look at any orchestral score. That's sort of what we're doing here (play pin0 with these notes). Make sense? N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From damien.p.george at gmail.com Thu Oct 15 00:47:33 2015 From: damien.p.george at gmail.com (Damien George) Date: Wed, 14 Oct 2015 23:47:33 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561EDAF4.5030900@hastings.org> References: <561ED231.7080602@ntoll.org> <561EDAF4.5030900@hastings.org> Message-ID: Cool! I like having to specify pin0 first. It makes it completely obvious where the sound is going. It's not going to some magic internal speaker, but rather out to the pin, and it needs to be hooked up to something. On Wed, Oct 14, 2015 at 11:45 PM, Larry Hastings wrote: > On 10/14/2015 03:07 PM, Nicholas H.Tollervey wrote: > > https://www.youtube.com/watch?v=0ce6yJOaFcc > > Only a few things needed for the music module to be complete. :-) > > > One observation: watching the video, I was surprised that the first > parameter to microbit.tune was the output pin. I would have expected the > first parameter to be the tune, and the second parameter to be the output > pin with a default of pin0. Yes? > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From ntoll at ntoll.org Thu Oct 15 00:50:07 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 14 Oct 2015 23:50:07 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: References: <561ED231.7080602@ntoll.org> Message-ID: <561EDC1F.2070808@ntoll.org> Yeah... my speaker is a cheapo ?5 job from Maplin. David has plugged in something a bit beefier and tells me that it sounds "epic". :-) N. On 14/10/15 23:38, Michael wrote: > That's really, really fun :-) > > Top tip - "The Works" have a cardboard speaker for ?2 at the moment. > Might show how to rip that apart to use with this. :-) (I like > scavenging places like The Works and Poundland for resources for this > sort of thing because it's closer to the budget of kids :-) ) > > > Michael. > > On 14 October 2015 at 23:07, Nicholas H.Tollervey > wrote: > > https://www.youtube.com/watch?v=0ce6yJOaFcc > > Only a few things needed for the music module to be complete. :-) > > 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 > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From larry at hastings.org Thu Oct 15 01:10:40 2015 From: larry at hastings.org (Larry Hastings) Date: Wed, 14 Oct 2015 16:10:40 -0700 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561EDB83.507@ntoll.org> References: <561ED231.7080602@ntoll.org> <561EDAF4.5030900@hastings.org> <561EDB83.507@ntoll.org> Message-ID: <561EE0F0.6040802@hastings.org> On 10/14/2015 03:47 PM, Nicholas H.Tollervey wrote: > We discussed this a few weeks ago. To cut a long story short, in music > you always specify the instrument then notes - just look at any > orchestral score. > > That's sort of what we're doing here (play pin0 with these notes). > > Make sense? I grant that it has a logical perspective and internal consistency, so yes it makes a certain sense. But I don't agree with it. Put it this way: how often are people going to use different pins? I feel like you're forcing the caller to make an uninteresting choice. The kid isn't interested in pin0, they're interested in WEDDING or NYAN or DADADADUM. And since the pin is the /first/ parameter you're forcing that uninteresting choice to be front and center. I think this is exactly analogous to saying "when you print, you need to specify where the output is going to, right? how can you print without knowing where the output is going? and /then/ you specify /what/ to print." and making the first parameter to print() be the file-like object to print to. Well, no--99% of the time you're printing to stdout, so that should be the default, and since it has a sensible default it's demoted from first parameter. I'm convinced the same is true here: 99% of the time, the music will be rendered to pin0. So why force the user to specify it every time? That's what default values for paramaters are /for,/ dad gum it. Also, musical scores need to be divvied up between multiple instruments and played simultaneously. AFAIK nobody will ever play notes out of multiple pins simultaneously. Also, every score I've seen specifies the /title/ first, then the instrument, then the composer, and then the notes. And by golly DADADADUM sure looks like the title of the song to me. Finally, why is musical score convention so important here? This is not a musical score, this is a computer program. I think it's fine to draw inspiration from musical score convention, but not to the degree of, say, making the incantation the kids learn to play tunes require them specifying a pin number every time. I've now said my peace. If my arguments don't sway you then nothing I say will, and I shan't stand between you and this API design. //arry/ p.s. The only way I'd want to see pin0 involved in a nominal call to tune is if tune was a method on an output pin, e.g. microbit.pin0.tune(microbit.DADADADUM). But I suspect that's a bad place for it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Thu Oct 15 09:54:36 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 15 Oct 2015 08:54:36 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561EE0F0.6040802@hastings.org> References: <561ED231.7080602@ntoll.org> <561EDAF4.5030900@hastings.org> <561EDB83.507@ntoll.org> <561EE0F0.6040802@hastings.org> Message-ID: <561F5BBC.3010300@ntoll.org> Good morning! On 15/10/15 00:10, Larry Hastings wrote: > On 10/14/2015 03:47 PM, Nicholas H.Tollervey wrote: >> We discussed this a few weeks ago. To cut a long story short, in music >> you always specify the instrument then notes - just look at any >> orchestral score. >> >> That's sort of what we're doing here (play pin0 with these notes). >> >> Make sense? > > I grant that it has a logical perspective and internal consistency, so > yes it makes a certain sense. But I don't agree with it. > > Put it this way: how often are people going to use different pins? I > feel like you're forcing the caller to make an uninteresting choice. > The kid isn't interested in pin0, they're interested in WEDDING or NYAN > or DADADADUM. And since the pin is the /first/ parameter you're forcing > that uninteresting choice to be front and center. > OK... > I think this is exactly analogous to saying "when you print, you need to > specify where the output is going to, right? how can you print without > knowing where the output is going? and /then/ you specify /what/ to > print." and making the first parameter to print() be the file-like > object to print to. Well, no--99% of the time you're printing to > stdout, so that should be the default, and since it has a sensible > default it's demoted from first parameter. I'm convinced the same is > true here: 99% of the time, the music will be rendered to pin0. So why > force the user to specify it every time? That's what default values for > paramaters are /for,/ dad gum it. > OK... > Also, musical scores need to be divvied up between multiple instruments > and played simultaneously. AFAIK nobody will ever play notes out of > multiple pins simultaneously. > There was talk of this *maybe* being possible, but upon reflection I believe this is overkill on such a small device. If you really want polyphony you shouldn't be using a micro:bit (you should perhaps use a midi library on a RPi and learn to do it properly). > Also, every score I've seen specifies the /title/ first, then the > instrument, then the composer, and then the notes. And by golly > DADADADUM sure looks like the title of the song to me. > Sure... but each part is named / specified for an instrument before you get to the notes. DADADADUM is the name of a list of notes rather than a title of a piece but I can see what you mean. > Finally, why is musical score convention so important here? This is not > a musical score, this is a computer program. I think it's fine to draw > inspiration from musical score convention, but not to the degree of, > say, making the incantation the kids learn to play tunes require them > specifying a pin number every time. > Right... so Damien also pushed back about this and I stuck to my guns simply because it's usually good from an educational perspective to have some sort of conceptual/conventional overlap between related fields. Nevertheless, now that I've had this pointed out twice, given your compelling examples about "print" above and given that I was getting a bit annoyed faffing about with passing in pins yesterday evening when I was checking the melodies then I believe I should throw in the towel and concede to Damien and yourself. It's also made me reflect on the name of the function for playing melodies. In a musical context, to "tune" is to make sure an instrument is *in tune*. We *play* melodies. For the life of me, I'm trying to remember why we didn't choose the rather obvious name, "play" for playing melodies. Ergo, I'd like to propose the following changes: * Specification of the pin is done via a named parameter called "pin" that has the default value of microbit.pin0. * music.tune should be renamed to music.play So we get code like this: >>> from microbit import music >>> music.play(music.NYAN) >>> import microbit >>> music.note('c4:4', pin=microbit.pin1) etc... > > I've now said my peace. If my arguments don't sway you then nothing I > say will, and I shan't stand between you and this API design. > Thanks for pushing and apologies to Damien for being such a stick in the mud about this at the start. If everyone is in agreement I'll update the wiki this evening to reflect this proposal. I'll also ensure I add some clarification of how octaves are measured and numbered too. Best wishes, N. > > //arry/ > > p.s. The only way I'd want to see pin0 involved in a nominal call to > tune is if tune was a method on an output pin, e.g. > microbit.pin0.tune(microbit.DADADADUM). But I suspect that's a bad > place for it. > > > _______________________________________________ > 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: From mail at timgolden.me.uk Thu Oct 15 10:04:18 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Thu, 15 Oct 2015 09:04:18 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561F5BBC.3010300@ntoll.org> References: <561ED231.7080602@ntoll.org> <561EDAF4.5030900@hastings.org> <561EDB83.507@ntoll.org> <561EE0F0.6040802@hastings.org> <561F5BBC.3010300@ntoll.org> Message-ID: <561F5E02.1020008@timgolden.me.uk> On 15/10/2015 08:54, Nicholas H.Tollervey wrote: > Ergo, I'd like to propose the following changes: > > * Specification of the pin is done via a named parameter called "pin" > that has the default value of microbit.pin0. > * music.tune should be renamed to music.play +1 from me. I was staying out of the debate because too many voices already, but I definitely prefer .play and I also agree that the pin0 should be pushed to an optional param. TJG From sparks.m at gmail.com Thu Oct 15 11:49:47 2015 From: sparks.m at gmail.com (Michael) Date: Thu, 15 Oct 2015 10:49:47 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561EDC1F.2070808@ntoll.org> References: <561ED231.7080602@ntoll.org> <561EDC1F.2070808@ntoll.org> Message-ID: FWIW, ?2 is the magic price point for materials for programmes that tend to say "and here's one I made earlier" and use "sticky backed plastic" apparently... Michael. On 14 October 2015 at 23:50, Nicholas H.Tollervey wrote: > Yeah... my speaker is a cheapo ?5 job from Maplin. David has plugged in > something a bit beefier and tells me that it sounds "epic". :-) > > N. > > On 14/10/15 23:38, Michael wrote: > > That's really, really fun :-) > > > > Top tip - "The Works" have a cardboard speaker for ?2 at the moment. > > Might show how to rip that apart to use with this. :-) (I like > > scavenging places like The Works and Poundland for resources for this > > sort of thing because it's closer to the budget of kids :-) ) > > > > > > Michael. > > > > On 14 October 2015 at 23:07, Nicholas H.Tollervey > > wrote: > > > > https://www.youtube.com/watch?v=0ce6yJOaFcc > > > > Only a few things needed for the music module to be complete. :-) > > > > 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: From larry at hastings.org Thu Oct 15 13:22:59 2015 From: larry at hastings.org (Larry Hastings) Date: Thu, 15 Oct 2015 04:22:59 -0700 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561F5BBC.3010300@ntoll.org> References: <561ED231.7080602@ntoll.org> <561EDAF4.5030900@hastings.org> <561EDB83.507@ntoll.org> <561EE0F0.6040802@hastings.org> <561F5BBC.3010300@ntoll.org> Message-ID: <561F8C93.30709@hastings.org> On 10/15/2015 12:54 AM, Nicholas H.Tollervey wrote: > * Specification of the pin is done via a named parameter called "pin" > that has the default value of microbit.pin0. > * music.tune should be renamed to music.play > > So we get code like this: > >>>> from microbit import music >>>> music.play(music.NYAN) >>>> import microbit >>>> music.note('c4:4', pin=microbit.pin1) > LGTM. I appreciate your open-mindedness! I was worried I was resurrecting an old talked-to-death topic that only you still had the stamina to argue about. ;-) One tiny bit of bikeshedding. "output=" instead of "pin=" for the named parameter? Yes? No? Just a thought, I'm not wedded to it. Cheers, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Thu Oct 15 13:30:28 2015 From: sparks.m at gmail.com (Michael) Date: Thu, 15 Oct 2015 12:30:28 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561F8C93.30709@hastings.org> References: <561ED231.7080602@ntoll.org> <561EDAF4.5030900@hastings.org> <561EDB83.507@ntoll.org> <561EE0F0.6040802@hastings.org> <561F5BBC.3010300@ntoll.org> <561F8C93.30709@hastings.org> Message-ID: -0 on output rather than pin. Pin is concrete, output is just that touch more abstract. (If the output could be anything other than a pin I'd agree though) It's worth bearing in mind that kids will have to construct an external device to hear stuff using this (or use one provided by someone else). Having the name as "pin" is just that bit clearer -- it reminds them on some level that something (however simple) will actually need to be connected to a pin :-) Sounds silly perhaps, but kids are :-) Michael. On 15 October 2015 at 12:22, Larry Hastings wrote: > > > On 10/15/2015 12:54 AM, Nicholas H.Tollervey wrote: > > * Specification of the pin is done via a named parameter called "pin" > that has the default value of microbit.pin0. > * music.tune should be renamed to music.play > > So we get code like this: > > > from microbit import music > music.play(music.NYAN) > import microbit > music.note('c4:4', pin=microbit.pin1) > > > > LGTM. I appreciate your open-mindedness! I was worried I was > resurrecting an old talked-to-death topic that only you still had the > stamina to argue about. ;-) > > One tiny bit of bikeshedding. "output=" instead of "pin=" for the named > parameter? Yes? No? Just a thought, I'm not wedded to it. > > Cheers, > > > */arry* > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewelse1997 at gmail.com Thu Oct 15 13:25:05 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Thu, 15 Oct 2015 12:25:05 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561F8C93.30709@hastings.org> References: <561ED231.7080602@ntoll.org> <561EDAF4.5030900@hastings.org> <561EDB83.507@ntoll.org> <561EE0F0.6040802@hastings.org> <561F5BBC.3010300@ntoll.org> <561F8C93.30709@hastings.org> Message-ID: <291A0149-3B80-4DE8-AD35-C5B16B338612@gmail.com> I think it makes more sense to be consistent with what?s being used elsewhere in micro python on the micro:bit, where we use pinX, since it?s easy to associate a parameter named ?pin? with microbit.pinX. From: Microbit on behalf of Larry Hastings Reply-To: For Pythonic MicroBit related disucssions Date: Thursday, 15 October 2015 at 12:22 To: Subject: Re: [Microbit-Python] Musical silliness... On 10/15/2015 12:54 AM, Nicholas H.Tollervey wrote: * Specification of the pin is done via a named parameter called "pin" that has the default value of microbit.pin0. * music.tune should be renamed to music.play So we get code like this: from microbit import music music.play(music.NYAN) import microbit music.note('c4:4', pin=microbit.pin1) LGTM. I appreciate your open-mindedness! I was worried I was resurrecting an old talked-to-death topic that only you still had the stamina to argue about. ;-) One tiny bit of bikeshedding. "output=" instead of "pin=" for the named parameter? Yes? No? Just a thought, I'm not wedded to it. Cheers, /arry _______________________________________________ Microbit mailing list Microbit at python.org https://mail.python.org/mailman/listinfo/microbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Thu Oct 15 13:39:14 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 15 Oct 2015 12:39:14 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561F8C93.30709@hastings.org> References: <561ED231.7080602@ntoll.org> <561EDAF4.5030900@hastings.org> <561EDB83.507@ntoll.org> <561EE0F0.6040802@hastings.org> <561F5BBC.3010300@ntoll.org> <561F8C93.30709@hastings.org> Message-ID: <561F9062.70206@ntoll.org> On 15/10/15 12:22, Larry Hastings wrote: > > > On 10/15/2015 12:54 AM, Nicholas H.Tollervey wrote: >> * Specification of the pin is done via a named parameter called "pin" >> that has the default value of microbit.pin0. >> * music.tune should be renamed to music.play >> >> So we get code like this: >> >>>>> from microbit import music >>>>> music.play(music.NYAN) >>>>> import microbit >>>>> music.note('c4:4', pin=microbit.pin1) >> > > LGTM. I appreciate your open-mindedness! I was worried I was > resurrecting an old talked-to-death topic that only you still had the > stamina to argue about. ;-) > My default setting is, "I'm probably wrong" and I *enjoy* constructive critique. I'm not precious about my opinions and would rather people knock holes in them. My feeling is that an API needs to earn its design through some sort of Socratic / devil's advocate like process of poking holes in it. Anything that makes an API simpler, easier and clearer is a good thing - even if it takes longer or requires people to change position. > One tiny bit of bikeshedding. "output=" instead of "pin=" for the named > parameter? Yes? No? Just a thought, I'm not wedded to it. > I agree with Michael and Matthew. It's unambiguous and kid friendly. N. > Cheers, > > > //arry/ > > > _______________________________________________ > 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: From damien.p.george at gmail.com Thu Oct 15 14:20:08 2015 From: damien.p.george at gmail.com (Damien George) Date: Thu, 15 Oct 2015 13:20:08 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561F9062.70206@ntoll.org> References: <561ED231.7080602@ntoll.org> <561EDAF4.5030900@hastings.org> <561EDB83.507@ntoll.org> <561EE0F0.6040802@hastings.org> <561F5BBC.3010300@ntoll.org> <561F8C93.30709@hastings.org> <561F9062.70206@ntoll.org> Message-ID: I agree to renaming "tune" to "play" and having the pin parameter named "pin" and second position and optional (with default pin0). But, at the risk of openning a can of worms: 1. Why not play_note, play_pitch, play_tune? The original reason for calling tune tune is that "play" was implicit, like it is implicit in note and pitch. 2. Why not merge note and tune and let "play" take either a string (an individual note) or a list of strings (a tune)? 3. If we are giving up polyphony (which is fine) why not have a method set_pin which sets the output pin to use for all operations (including stop)? On Thu, Oct 15, 2015 at 12:39 PM, Nicholas H.Tollervey wrote: > On 15/10/15 12:22, Larry Hastings wrote: >> >> >> On 10/15/2015 12:54 AM, Nicholas H.Tollervey wrote: >>> * Specification of the pin is done via a named parameter called "pin" >>> that has the default value of microbit.pin0. >>> * music.tune should be renamed to music.play >>> >>> So we get code like this: >>> >>>>>> from microbit import music >>>>>> music.play(music.NYAN) >>>>>> import microbit >>>>>> music.note('c4:4', pin=microbit.pin1) >>> >> >> LGTM. I appreciate your open-mindedness! I was worried I was >> resurrecting an old talked-to-death topic that only you still had the >> stamina to argue about. ;-) >> > > My default setting is, "I'm probably wrong" and I *enjoy* constructive > critique. I'm not precious about my opinions and would rather people > knock holes in them. > > My feeling is that an API needs to earn its design through some sort of > Socratic / devil's advocate like process of poking holes in it. Anything > that makes an API simpler, easier and clearer is a good thing - even if > it takes longer or requires people to change position. > >> One tiny bit of bikeshedding. "output=" instead of "pin=" for the named >> parameter? Yes? No? Just a thought, I'm not wedded to it. >> > > I agree with Michael and Matthew. It's unambiguous and kid friendly. > > N. > >> Cheers, >> >> >> //arry/ >> >> >> _______________________________________________ >> 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 > From ntoll at ntoll.org Thu Oct 15 15:34:34 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 15 Oct 2015 14:34:34 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: References: <561ED231.7080602@ntoll.org> <561EDAF4.5030900@hastings.org> <561EDB83.507@ntoll.org> <561EE0F0.6040802@hastings.org> <561F5BBC.3010300@ntoll.org> <561F8C93.30709@hastings.org> <561F9062.70206@ntoll.org> Message-ID: <561FAB6A.2030706@ntoll.org> :-) On 15/10/15 13:20, Damien George wrote: > I agree to renaming "tune" to "play" and having the pin parameter > named "pin" and second position and optional (with default pin0). > > But, at the risk of openning a can of worms: > > 1. Why not play_note, play_pitch, play_tune? The original reason for > calling tune tune is that "play" was implicit, like it is implicit in > note and pitch. > > 2. Why not merge note and tune and let "play" take either a string (an > individual note) or a list of strings (a tune)? > I like this idea because it solves 1 and feels natural. on any instrument you can play just a single note or a melody - the same verb is used. If we can override the function then it'd further simplify things. > 3. If we are giving up polyphony (which is fine) why not have a method > set_pin which sets the output pin to use for all operations (including > stop)? > I guess because there is a chance someone *could* still do polyphony if they were more of a maker/hacker type rather than a kid and it'd be cool. We'd be closing down that option if we didn't allow people to specify the pin. I'll have a go at updating the API specification on the wiki this evening and ping people when it's good for feedback. I'd like to add that such conversations are one of the reasons I love software development. It feels good to think about and implement things like this. Best wishes, N. > > On Thu, Oct 15, 2015 at 12:39 PM, Nicholas H.Tollervey wrote: >> On 15/10/15 12:22, Larry Hastings wrote: >>> >>> >>> On 10/15/2015 12:54 AM, Nicholas H.Tollervey wrote: >>>> * Specification of the pin is done via a named parameter called "pin" >>>> that has the default value of microbit.pin0. >>>> * music.tune should be renamed to music.play >>>> >>>> So we get code like this: >>>> >>>>>>> from microbit import music >>>>>>> music.play(music.NYAN) >>>>>>> import microbit >>>>>>> music.note('c4:4', pin=microbit.pin1) >>>> >>> >>> LGTM. I appreciate your open-mindedness! I was worried I was >>> resurrecting an old talked-to-death topic that only you still had the >>> stamina to argue about. ;-) >>> >> >> My default setting is, "I'm probably wrong" and I *enjoy* constructive >> critique. I'm not precious about my opinions and would rather people >> knock holes in them. >> >> My feeling is that an API needs to earn its design through some sort of >> Socratic / devil's advocate like process of poking holes in it. Anything >> that makes an API simpler, easier and clearer is a good thing - even if >> it takes longer or requires people to change position. >> >>> One tiny bit of bikeshedding. "output=" instead of "pin=" for the named >>> parameter? Yes? No? Just a thought, I'm not wedded to it. >>> >> >> I agree with Michael and Matthew. It's unambiguous and kid friendly. >> >> N. >> >>> Cheers, >>> >>> >>> //arry/ >>> >>> >>> _______________________________________________ >>> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From damien.p.george at gmail.com Thu Oct 15 15:46:16 2015 From: damien.p.george at gmail.com (Damien George) Date: Thu, 15 Oct 2015 14:46:16 +0100 Subject: [Microbit-Python] Musical silliness... In-Reply-To: <561FAB6A.2030706@ntoll.org> References: <561ED231.7080602@ntoll.org> <561EDAF4.5030900@hastings.org> <561EDB83.507@ntoll.org> <561EE0F0.6040802@hastings.org> <561F5BBC.3010300@ntoll.org> <561F8C93.30709@hastings.org> <561F9062.70206@ntoll.org> <561FAB6A.2030706@ntoll.org> Message-ID: >> 3. If we are giving up polyphony (which is fine) why not have a method >> set_pin which sets the output pin to use for all operations (including >> stop)? >> > > I guess because there is a chance someone *could* still do polyphony if > they were more of a maker/hacker type rather than a kid and it'd be > cool. We'd be closing down that option if we didn't allow people to > specify the pin. We could support polyphony by creating multiple "music" instances, eg: music0 = microbit.Music(pin=pin0) music1 = microbit.Music(pin=pin1) The current music "module" is then simply a precreated Music object that uses pin0 by default. We anyway store tempo as state in the music instance, so why not pin? > I'd like to add that such conversations are one of the reasons I love > software development. It feels good to think about and implement things > like this. I love to code. But desiging APIs is really hard, so it is great to have a big discussion and then know you are implementing a solid and thought-out idea :) From ntoll at ntoll.org Thu Oct 15 22:48:04 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 15 Oct 2015 21:48:04 +0100 Subject: [Microbit-Python] Update to the music API specification Message-ID: <56201104.1040104@ntoll.org> Hi Folks, As promised I've updated the music API specification to reflect our recent stimulating conversations. The only significant change to the API that'll need fixing is that the pin argument is made optional and the "tune" and "note" functions are consolidated into a single "play" function. By the looks of it these are not onerous changes - obviously I understand what needs to be done but given my complete lack of C/C++ experience I'm unsure how best to go about it since I don't have other similar functions upon which to base a solution. Anyone fancy stacking this onto my music-updates branch..? I've also added the Monty Python theme tune because Python programming can't have enough MP references (no matter how obvious they appear to be). Matthew, how's the non-blocking work going..? Once that's in we have a complete and rather wonderful music API. Best wishes, N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From larry at hastings.org Thu Oct 15 21:02:43 2015 From: larry at hastings.org (Larry Hastings) Date: Thu, 15 Oct 2015 12:02:43 -0700 Subject: [Microbit-Python] More musical silliness Message-ID: <561FF853.6090900@hastings.org> This guy wrote a simple MOD tracker for the TI 82 calculator: https://www.youtube.com/watch?v=I6G0CnBSWVk I'll save you a trip to Wikipedia: that's got a 6Mhz Z80, an 8-bit processor. And he's getting /four/ voices out of it, not to mention effects. Gentlemen, our monophonic bleeping and blooping just got TOLD. Anybody know an audio rendering specialist? //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Thu Oct 15 23:03:16 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 15 Oct 2015 22:03:16 +0100 Subject: [Microbit-Python] More musical silliness In-Reply-To: <561FF853.6090900@hastings.org> References: <561FF853.6090900@hastings.org> Message-ID: <56201494.8050008@ntoll.org> On 15/10/15 20:02, Larry Hastings wrote: > > > This guy wrote a simple MOD tracker for the TI 82 calculator: > > https://www.youtube.com/watch?v=I6G0CnBSWVk > > I'll save you a trip to Wikipedia: that's got a 6Mhz Z80, an 8-bit > processor. And he's getting /four/ voices out of it, not to mention > effects. > > Gentlemen, our monophonic bleeping and blooping just got TOLD. > > > Anybody know an audio rendering specialist? > That thud you heard in the distance... that was my jaw hitting the floor. ZOMG etc... :-) Nice find Larry, nice find..! I wonder if/how this is possible on the micro:bit... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From matthewelse1997 at gmail.com Thu Oct 15 22:58:44 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Thu, 15 Oct 2015 21:58:44 +0100 Subject: [Microbit-Python] Update to the music API specification In-Reply-To: <56201104.1040104@ntoll.org> References: <56201104.1040104@ntoll.org> Message-ID: <2B53D675-1EAB-48C1-A7AC-5860CFFDE799@gmail.com> Hi Nicholas I started having a look at non-blocking a day or two ago, but since then I?ve been dealing with uni work/lectures/university shenanigans - I should have some free time tomorrow afternoon, so I?ll try and get it done then. From what I can tell, it shouldn?t be particularly taxing, it?s just a matter of working out where we can and can?t get away with simplifying things to save on RAM in some cases. Matthew On 15/10/2015, 21:48, "Microbit on behalf of Nicholas H.Tollervey" wrote: >Hi Folks, > >As promised I've updated the music API specification to reflect our >recent stimulating conversations. > >The only significant change to the API that'll need fixing is that the >pin argument is made optional and the "tune" and "note" functions are >consolidated into a single "play" function. > >By the looks of it these are not onerous changes - obviously I >understand what needs to be done but given my complete lack of C/C++ >experience I'm unsure how best to go about it since I don't have other >similar functions upon which to base a solution. Anyone fancy stacking >this onto my music-updates branch..? > >I've also added the Monty Python theme tune because Python programming >can't have enough MP references (no matter how obvious they appear to be). > >Matthew, how's the non-blocking work going..? Once that's in we have a >complete and rather wonderful music API. > >Best wishes, > >N. > >_______________________________________________ >Microbit mailing list >Microbit at python.org >https://mail.python.org/mailman/listinfo/microbit From ntoll at ntoll.org Thu Oct 15 23:46:58 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 15 Oct 2015 22:46:58 +0100 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events Message-ID: <56201ED2.5000302@ntoll.org> Hi Folks, More status updates... I've been making myself available to various UK based PUGs to demo what we've been up to in the hope that people will get involved in writing fun projects and contributing educational resources. So far I have: Oxford - 22/Oct: http://www.meetup.com/oxfordpython/events/225877957/ Cambridge - 3/Nov: http://www.meetup.com/CamPUG/events/225157789/ London - 12/Nov: https://twitter.com/ldnpydojo Sheffield - 22/Nov: https://twitter.com/pysheff I hope there will be more. I have 17 devices "loaned" from the BBC for such workshops. Very cool. Also, it appears the BBC are very very close to removing blockers for us to open source our MicroPython work on the micro:bit. This is yet another encumbrance out of our way and will help us engage with the wider community. I can feel a post to HN or Slashdot coming on. ;-) Finally, many of you will know Steve Hawkes who does the amazing design work for PyCon UK. He's agreed to volunteer some time to "tart up" our rather grey and boring TouchDevelop based editor. He's been asked to make it look "obviously Pythonic" and appeal to 11yo kids. I've just seen a first draft which he claims has plenty wrong with it - I have a huge grin on my face. It shows the direction he's moving in and will definitely improve (see http://ntoll.org/static/images/pythoneditor_1st_draft.png). We're going to try to make the snakes in the border of the instructions on the RHS animated GIFs a la the O'Reilly logo (http://www.oreilly.com/ watch the creature for about 10 seconds). They'll blink and stick out forked tongues. Perhaps they should turn their heads when you click "Download", fix syntax errors or something. Ideas welcome..! Best wishes, N. P.S. A Dutch feller appears to have got hold of a micro:bit from somewhere and has been tweeting about it... https://twitter.com/gvanrossum/status/653975453691080704 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From sparks.m at gmail.com Fri Oct 16 00:10:31 2015 From: sparks.m at gmail.com (Michael) Date: Thu, 15 Oct 2015 23:10:31 +0100 Subject: [Microbit-Python] More musical silliness In-Reply-To: <56201494.8050008@ntoll.org> References: <561FF853.6090900@hastings.org> <56201494.8050008@ntoll.org> Message-ID: It's possible. The micro:bit as it stands now is much more capable than the prototype device that I built. However the prototype I built was built around the Atmel 32u4 for the simple reason that it's a very similar to the Atmel 328P. The reason I mention that is because for that I created a singing "cat piano" for my daughter a few years ago. That used PCM encoded WAV files - one per key, hard coded in program data. The wav files were 8Khz 8bit mono files, which then output to a speaker. I reused the same technique to make a Harry Potter sorting hat for a Harry Potter themed birthday party later the same year. Videos of these things aren't online for personal reasons. I don't have the time at this instant to rewrite these for micro:bit, and haven't raised these previously because I didn't want to derail the really cool stuff going on here. (This list will go public at some point, so I don't really want to post a link to the video for the cat piano here, but happy to send it directly to those curious) In case it's useful to anyone, I've pushed the code for the cat piano here: https://github.com/sparkslabs/catastrophene The code for the harry potter sorting hat is here: https://github.com/sparkslabs/sortinghat If useful, cool. If useful just as inspiration for *later* (and I really would suggest *later* :o), that's cool. It's worth noting that it should be possible to directly drive a composite video display as well, since that's possible to do with the Atmel 32C4 which is again lower power than we have available for the micro:bit. All that said though, on the Computing At School forums I saw the following query today: > The game could do with having sound effects. Anyone know > of an easy way to attach a small speaker to a Micro:bit and > generate sound effects? The only thing I?ve seen so far is the > Kitronik ?Don?t Steal My Micro:bit Alarm? project which uses a > buzzer with simple ?on? or ?off? control. When micropython gets out there, people are going to be excited by what's already working here. (I know I am :-) ) We don't need to make it perfect immediately, just leave the door open to the possible. For example, in Star Trek 2, when just before Spock goes into the engine room, Leonard Nimoy was asked by the director Nick Meyer to say "Remember" in a mind meld fashion to DeForest Kelley (McCoy). (I'm carefully avoiding spoilers for those who haven't seen these things :-) ) That wasn't actually in the script, but Nick Meyer had done enough TV to understand how to add a place where a wedge could be placed to open new doors. Likewise, I don't think we need to worry about bit banging wav files at this stage or implementing polyphony, but leaving the door open, that's cool. Michael. On 15 October 2015 at 22:03, Nicholas H.Tollervey wrote: > On 15/10/15 20:02, Larry Hastings wrote: > > > > > > This guy wrote a simple MOD tracker for the TI 82 calculator: > > > > https://www.youtube.com/watch?v=I6G0CnBSWVk > > > > I'll save you a trip to Wikipedia: that's got a 6Mhz Z80, an 8-bit > > processor. And he's getting /four/ voices out of it, not to mention > > effects. > > > > Gentlemen, our monophonic bleeping and blooping just got TOLD. > > > > > > Anybody know an audio rendering specialist? > > > > That thud you heard in the distance... that was my jaw hitting the floor. > > ZOMG etc... :-) > > Nice find Larry, nice find..! I wonder if/how this is possible on the > micro:bit... > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Fri Oct 16 00:35:46 2015 From: damien.p.george at gmail.com (Damien George) Date: Thu, 15 Oct 2015 23:35:46 +0100 Subject: [Microbit-Python] More musical silliness In-Reply-To: References: <561FF853.6090900@hastings.org> <56201494.8050008@ntoll.org> Message-ID: Wow, that TI-82 tracker is beautiful! I actually did try to play proper audio samples using the microbit right at the start of all this music module stuff (as Michael says, it's entirely possible). But, the problem is you need an external low pass filter and amplifier for it work. You use PWM at a very high frequency (say 1MHz) and then change the duty cycle to match the current sample, samples which are output at the sampling rate, say 8kHz. Coupled with an external low pass filter, this gives a proper analog output. So that means you can play an arbitrary sound. You can use a capacitor and resistor to make a low pass filter. But then there isn't enough power left to drive a speaker, so you need an active amplifier (or use headphones). Since this scheme required more external hardware than most students would be comfortable with, I abandoned the idea. I think currently the music stuff is pretty cool, and accessible: any old speaker will work and give you a decent volume. But, of course, always room for improvement! On Thu, Oct 15, 2015 at 11:10 PM, Michael wrote: > It's possible. The micro:bit as it stands now is much more capable than the > prototype device that I built. However the prototype I built was built > around the Atmel 32u4 for the simple reason that it's a very similar to the > Atmel 328P. The reason I mention that is because for that I created a > singing "cat piano" for my daughter a few years ago. That used PCM encoded > WAV files - one per key, hard coded in program data. The wav files were 8Khz > 8bit mono files, which then output to a speaker. > > I reused the same technique to make a Harry Potter sorting hat for a Harry > Potter themed birthday party later the same year. Videos of these things > aren't online for personal reasons. > > I don't have the time at this instant to rewrite these for micro:bit, and > haven't raised these previously because I didn't want to derail the really > cool stuff going on here. > > (This list will go public at some point, so I don't really want to post a > link to the video for the cat piano here, but happy to send it directly to > those curious) > > In case it's useful to anyone, I've pushed the code for the cat piano here: > > https://github.com/sparkslabs/catastrophene > > The code for the harry potter sorting hat is here: > > https://github.com/sparkslabs/sortinghat > > If useful, cool. If useful just as inspiration for *later* (and I really > would suggest *later* :o), that's cool. > > It's worth noting that it should be possible to directly drive a composite > video display as well, since that's possible to do with the Atmel 32C4 which > is again lower power than we have available for the micro:bit. > > All that said though, on the Computing At School forums I saw the following > query today: > >> The game could do with having sound effects. Anyone know >> of an easy way to attach a small speaker to a Micro:bit and >> generate sound effects? The only thing I?ve seen so far is the >> Kitronik ?Don?t Steal My Micro:bit Alarm? project which uses a >> buzzer with simple ?on? or ?off? control. > > When micropython gets out there, people are going to be excited by what's > already working here. (I know I am :-) ) > > We don't need to make it perfect immediately, just leave the door open to > the possible. > > For example, in Star Trek 2, when just before Spock goes into the engine > room, Leonard Nimoy was asked by the director Nick Meyer to say "Remember" > in a mind meld fashion to DeForest Kelley (McCoy). (I'm carefully avoiding > spoilers for those who haven't seen these things :-) ) > > That wasn't actually in the script, but Nick Meyer had done enough TV to > understand how to add a place where a wedge could be placed to open new > doors. Likewise, I don't think we need to worry about bit banging wav files > at this stage or implementing polyphony, but leaving the door open, that's > cool. > > > Michael. > > On 15 October 2015 at 22:03, Nicholas H.Tollervey wrote: >> >> On 15/10/15 20:02, Larry Hastings wrote: >> > >> > >> > This guy wrote a simple MOD tracker for the TI 82 calculator: >> > >> > https://www.youtube.com/watch?v=I6G0CnBSWVk >> > >> > I'll save you a trip to Wikipedia: that's got a 6Mhz Z80, an 8-bit >> > processor. And he's getting /four/ voices out of it, not to mention >> > effects. >> > >> > Gentlemen, our monophonic bleeping and blooping just got TOLD. >> > >> > >> > Anybody know an audio rendering specialist? >> > >> >> That thud you heard in the distance... that was my jaw hitting the floor. >> >> ZOMG etc... :-) >> >> Nice find Larry, nice find..! I wonder if/how this is possible on the >> micro:bit... >> >> >> >> _______________________________________________ >> 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 > From sparks.m at gmail.com Fri Oct 16 00:59:48 2015 From: sparks.m at gmail.com (Michael) Date: Thu, 15 Oct 2015 23:59:48 +0100 Subject: [Microbit-Python] More musical silliness In-Reply-To: References: <561FF853.6090900@hastings.org> <56201494.8050008@ntoll.org> Message-ID: Yep, the catastrophone (and sorting hat) required a basic low pass filter and single transistor amplifier circuit - which is a bit of a barrier. Leaving the door open though is good. (The cat piano/catastrophene came out of my daughter seeing this Jools Holland's Hootenanny : https://www.youtube.com/watch?v=fkZp_uTbIKk abd asking me if I could make her one...) Getting it loud enough for a public performance is harder than you might expect, so the approach taken at present is really cool. Michael. On 15 October 2015 at 23:35, Damien George wrote: > Wow, that TI-82 tracker is beautiful! > > I actually did try to play proper audio samples using the microbit > right at the start of all this music module stuff (as Michael says, > it's entirely possible). But, the problem is you need an external low > pass filter and amplifier for it work. You use PWM at a very high > frequency (say 1MHz) and then change the duty cycle to match the > current sample, samples which are output at the sampling rate, say > 8kHz. Coupled with an external low pass filter, this gives a proper > analog output. So that means you can play an arbitrary sound. > > You can use a capacitor and resistor to make a low pass filter. But > then there isn't enough power left to drive a speaker, so you need an > active amplifier (or use headphones). > > Since this scheme required more external hardware than most students > would be comfortable with, I abandoned the idea. > > I think currently the music stuff is pretty cool, and accessible: any > old speaker will work and give you a decent volume. > > But, of course, always room for improvement! > > > On Thu, Oct 15, 2015 at 11:10 PM, Michael wrote: > > It's possible. The micro:bit as it stands now is much more capable than > the > > prototype device that I built. However the prototype I built was built > > around the Atmel 32u4 for the simple reason that it's a very similar to > the > > Atmel 328P. The reason I mention that is because for that I created a > > singing "cat piano" for my daughter a few years ago. That used PCM > encoded > > WAV files - one per key, hard coded in program data. The wav files were > 8Khz > > 8bit mono files, which then output to a speaker. > > > > I reused the same technique to make a Harry Potter sorting hat for a > Harry > > Potter themed birthday party later the same year. Videos of these things > > aren't online for personal reasons. > > > > I don't have the time at this instant to rewrite these for micro:bit, and > > haven't raised these previously because I didn't want to derail the > really > > cool stuff going on here. > > > > (This list will go public at some point, so I don't really want to post a > > link to the video for the cat piano here, but happy to send it directly > to > > those curious) > > > > In case it's useful to anyone, I've pushed the code for the cat piano > here: > > > > https://github.com/sparkslabs/catastrophene > > > > The code for the harry potter sorting hat is here: > > > > https://github.com/sparkslabs/sortinghat > > > > If useful, cool. If useful just as inspiration for *later* (and I really > > would suggest *later* :o), that's cool. > > > > It's worth noting that it should be possible to directly drive a > composite > > video display as well, since that's possible to do with the Atmel 32C4 > which > > is again lower power than we have available for the micro:bit. > > > > All that said though, on the Computing At School forums I saw the > following > > query today: > > > >> The game could do with having sound effects. Anyone know > >> of an easy way to attach a small speaker to a Micro:bit and > >> generate sound effects? The only thing I?ve seen so far is the > >> Kitronik ?Don?t Steal My Micro:bit Alarm? project which uses a > >> buzzer with simple ?on? or ?off? control. > > > > When micropython gets out there, people are going to be excited by what's > > already working here. (I know I am :-) ) > > > > We don't need to make it perfect immediately, just leave the door open to > > the possible. > > > > For example, in Star Trek 2, when just before Spock goes into the engine > > room, Leonard Nimoy was asked by the director Nick Meyer to say > "Remember" > > in a mind meld fashion to DeForest Kelley (McCoy). (I'm carefully > avoiding > > spoilers for those who haven't seen these things :-) ) > > > > That wasn't actually in the script, but Nick Meyer had done enough TV to > > understand how to add a place where a wedge could be placed to open new > > doors. Likewise, I don't think we need to worry about bit banging wav > files > > at this stage or implementing polyphony, but leaving the door open, > that's > > cool. > > > > > > Michael. > > > > On 15 October 2015 at 22:03, Nicholas H.Tollervey > wrote: > >> > >> On 15/10/15 20:02, Larry Hastings wrote: > >> > > >> > > >> > This guy wrote a simple MOD tracker for the TI 82 calculator: > >> > > >> > https://www.youtube.com/watch?v=I6G0CnBSWVk > >> > > >> > I'll save you a trip to Wikipedia: that's got a 6Mhz Z80, an 8-bit > >> > processor. And he's getting /four/ voices out of it, not to mention > >> > effects. > >> > > >> > Gentlemen, our monophonic bleeping and blooping just got TOLD. > >> > > >> > > >> > Anybody know an audio rendering specialist? > >> > > >> > >> That thud you heard in the distance... that was my jaw hitting the > floor. > >> > >> ZOMG etc... :-) > >> > >> Nice find Larry, nice find..! I wonder if/how this is possible on the > >> micro:bit... > >> > >> > >> > >> _______________________________________________ > >> 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: From damien.p.george at gmail.com Fri Oct 16 01:17:48 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 16 Oct 2015 00:17:48 +0100 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events In-Reply-To: <56201ED2.5000302@ntoll.org> References: <56201ED2.5000302@ntoll.org> Message-ID: Hi Nicholas, Sounds great, you've been working hard! The mock-up for the TD editor looks super awesome! One think I would like to request is that it mentions MicroPython somewhere on the UI. Perhaps in the bottom right corner it can say "MicroPython powered"? Or "Built with MicroPython". And maybe the Python-on-a-snake logo can be used, we have a vector graphics version here: https://github.com/micropython/micropython/blob/master/logo/vector-logo-inkscape_master.svg Cheers, Damien. On Thu, Oct 15, 2015 at 10:46 PM, Nicholas H.Tollervey wrote: > Hi Folks, > > More status updates... > > I've been making myself available to various UK based PUGs to demo what > we've been up to in the hope that people will get involved in writing > fun projects and contributing educational resources. > > So far I have: > > Oxford - 22/Oct: http://www.meetup.com/oxfordpython/events/225877957/ > Cambridge - 3/Nov: http://www.meetup.com/CamPUG/events/225157789/ > London - 12/Nov: https://twitter.com/ldnpydojo > Sheffield - 22/Nov: https://twitter.com/pysheff > > I hope there will be more. I have 17 devices "loaned" from the BBC for > such workshops. Very cool. > > Also, it appears the BBC are very very close to removing blockers for us > to open source our MicroPython work on the micro:bit. This is yet > another encumbrance out of our way and will help us engage with the > wider community. I can feel a post to HN or Slashdot coming on. ;-) > > Finally, many of you will know Steve Hawkes who does the amazing design > work for PyCon UK. He's agreed to volunteer some time to "tart up" our > rather grey and boring TouchDevelop based editor. He's been asked to > make it look "obviously Pythonic" and appeal to 11yo kids. I've just > seen a first draft which he claims has plenty wrong with it - I have a > huge grin on my face. It shows the direction he's moving in and will > definitely improve (see > http://ntoll.org/static/images/pythoneditor_1st_draft.png). We're going > to try to make the snakes in the border of the instructions on the RHS > animated GIFs a la the O'Reilly logo (http://www.oreilly.com/ watch the > creature for about 10 seconds). They'll blink and stick out forked > tongues. Perhaps they should turn their heads when you click "Download", > fix syntax errors or something. Ideas welcome..! > > Best wishes, > > N. > > P.S. A Dutch feller appears to have got hold of a micro:bit from > somewhere and has been tweeting about it... > > https://twitter.com/gvanrossum/status/653975453691080704 > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From damien.p.george at gmail.com Fri Oct 16 01:27:26 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 16 Oct 2015 00:27:26 +0100 Subject: [Microbit-Python] More musical silliness In-Reply-To: References: <561FF853.6090900@hastings.org> <56201494.8050008@ntoll.org> Message-ID: Given more time, it would be possible to double the loudness of the current music output. It can be done by connecting the speaker to pin0 and pin1 (instead of pin0 and gnd) and driving pin1 opposite to pin0 (so pin0 high would have pin1 low, and vice versa). This gives double the voltage swing on the speaker. The nRF chip is capable of doing this. It just requires some coding. On Thu, Oct 15, 2015 at 11:59 PM, Michael wrote: > Yep, the catastrophone (and sorting hat) required a basic low pass filter > and single transistor amplifier circuit - which is a bit of a barrier. > Leaving the door open though is good. > > (The cat piano/catastrophene came out of my daughter seeing this Jools > Holland's Hootenanny : https://www.youtube.com/watch?v=fkZp_uTbIKk abd > asking me if I could make her one...) > > Getting it loud enough for a public performance is harder than you might > expect, so the approach taken at present is really cool. > > > Michael. > > On 15 October 2015 at 23:35, Damien George > wrote: >> >> Wow, that TI-82 tracker is beautiful! >> >> I actually did try to play proper audio samples using the microbit >> right at the start of all this music module stuff (as Michael says, >> it's entirely possible). But, the problem is you need an external low >> pass filter and amplifier for it work. You use PWM at a very high >> frequency (say 1MHz) and then change the duty cycle to match the >> current sample, samples which are output at the sampling rate, say >> 8kHz. Coupled with an external low pass filter, this gives a proper >> analog output. So that means you can play an arbitrary sound. >> >> You can use a capacitor and resistor to make a low pass filter. But >> then there isn't enough power left to drive a speaker, so you need an >> active amplifier (or use headphones). >> >> Since this scheme required more external hardware than most students >> would be comfortable with, I abandoned the idea. >> >> I think currently the music stuff is pretty cool, and accessible: any >> old speaker will work and give you a decent volume. >> >> But, of course, always room for improvement! >> >> >> On Thu, Oct 15, 2015 at 11:10 PM, Michael wrote: >> > It's possible. The micro:bit as it stands now is much more capable than >> > the >> > prototype device that I built. However the prototype I built was built >> > around the Atmel 32u4 for the simple reason that it's a very similar to >> > the >> > Atmel 328P. The reason I mention that is because for that I created a >> > singing "cat piano" for my daughter a few years ago. That used PCM >> > encoded >> > WAV files - one per key, hard coded in program data. The wav files were >> > 8Khz >> > 8bit mono files, which then output to a speaker. >> > >> > I reused the same technique to make a Harry Potter sorting hat for a >> > Harry >> > Potter themed birthday party later the same year. Videos of these things >> > aren't online for personal reasons. >> > >> > I don't have the time at this instant to rewrite these for micro:bit, >> > and >> > haven't raised these previously because I didn't want to derail the >> > really >> > cool stuff going on here. >> > >> > (This list will go public at some point, so I don't really want to post >> > a >> > link to the video for the cat piano here, but happy to send it directly >> > to >> > those curious) >> > >> > In case it's useful to anyone, I've pushed the code for the cat piano >> > here: >> > >> > https://github.com/sparkslabs/catastrophene >> > >> > The code for the harry potter sorting hat is here: >> > >> > https://github.com/sparkslabs/sortinghat >> > >> > If useful, cool. If useful just as inspiration for *later* (and I really >> > would suggest *later* :o), that's cool. >> > >> > It's worth noting that it should be possible to directly drive a >> > composite >> > video display as well, since that's possible to do with the Atmel 32C4 >> > which >> > is again lower power than we have available for the micro:bit. >> > >> > All that said though, on the Computing At School forums I saw the >> > following >> > query today: >> > >> >> The game could do with having sound effects. Anyone know >> >> of an easy way to attach a small speaker to a Micro:bit and >> >> generate sound effects? The only thing I?ve seen so far is the >> >> Kitronik ?Don?t Steal My Micro:bit Alarm? project which uses a >> >> buzzer with simple ?on? or ?off? control. >> > >> > When micropython gets out there, people are going to be excited by >> > what's >> > already working here. (I know I am :-) ) >> > >> > We don't need to make it perfect immediately, just leave the door open >> > to >> > the possible. >> > >> > For example, in Star Trek 2, when just before Spock goes into the engine >> > room, Leonard Nimoy was asked by the director Nick Meyer to say >> > "Remember" >> > in a mind meld fashion to DeForest Kelley (McCoy). (I'm carefully >> > avoiding >> > spoilers for those who haven't seen these things :-) ) >> > >> > That wasn't actually in the script, but Nick Meyer had done enough TV to >> > understand how to add a place where a wedge could be placed to open new >> > doors. Likewise, I don't think we need to worry about bit banging wav >> > files >> > at this stage or implementing polyphony, but leaving the door open, >> > that's >> > cool. >> > >> > >> > Michael. >> > >> > On 15 October 2015 at 22:03, Nicholas H.Tollervey >> > wrote: >> >> >> >> On 15/10/15 20:02, Larry Hastings wrote: >> >> > >> >> > >> >> > This guy wrote a simple MOD tracker for the TI 82 calculator: >> >> > >> >> > https://www.youtube.com/watch?v=I6G0CnBSWVk >> >> > >> >> > I'll save you a trip to Wikipedia: that's got a 6Mhz Z80, an 8-bit >> >> > processor. And he's getting /four/ voices out of it, not to mention >> >> > effects. >> >> > >> >> > Gentlemen, our monophonic bleeping and blooping just got TOLD. >> >> > >> >> > >> >> > Anybody know an audio rendering specialist? >> >> > >> >> >> >> That thud you heard in the distance... that was my jaw hitting the >> >> floor. >> >> >> >> ZOMG etc... :-) >> >> >> >> Nice find Larry, nice find..! I wonder if/how this is possible on the >> >> micro:bit... >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From david at thinkingbinaries.com Fri Oct 16 07:31:00 2015 From: david at thinkingbinaries.com (David Whale) Date: Fri, 16 Oct 2015 06:31:00 +0100 Subject: [Microbit-Python] More musical silliness In-Reply-To: References: <561FF853.6090900@hastings.org> <56201494.8050008@ntoll.org> Message-ID: I have a relatively cheap (?10) powered bluetooth speaker plugged directly into my micro:bit and using the Touch Develop pins->analog write() method, I get *really loud* tones from it. 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 16 October 2015 at 00:27, Damien George wrote: > Given more time, it would be possible to double the loudness of the > current music output. It can be done by connecting the speaker to > pin0 and pin1 (instead of pin0 and gnd) and driving pin1 opposite to > pin0 (so pin0 high would have pin1 low, and vice versa). This gives > double the voltage swing on the speaker. > > The nRF chip is capable of doing this. It just requires some coding. > > On Thu, Oct 15, 2015 at 11:59 PM, Michael wrote: > > Yep, the catastrophone (and sorting hat) required a basic low pass filter > > and single transistor amplifier circuit - which is a bit of a barrier. > > Leaving the door open though is good. > > > > (The cat piano/catastrophene came out of my daughter seeing this Jools > > Holland's Hootenanny : https://www.youtube.com/watch?v=fkZp_uTbIKk abd > > asking me if I could make her one...) > > > > Getting it loud enough for a public performance is harder than you might > > expect, so the approach taken at present is really cool. > > > > > > Michael. > > > > On 15 October 2015 at 23:35, Damien George > > wrote: > >> > >> Wow, that TI-82 tracker is beautiful! > >> > >> I actually did try to play proper audio samples using the microbit > >> right at the start of all this music module stuff (as Michael says, > >> it's entirely possible). But, the problem is you need an external low > >> pass filter and amplifier for it work. You use PWM at a very high > >> frequency (say 1MHz) and then change the duty cycle to match the > >> current sample, samples which are output at the sampling rate, say > >> 8kHz. Coupled with an external low pass filter, this gives a proper > >> analog output. So that means you can play an arbitrary sound. > >> > >> You can use a capacitor and resistor to make a low pass filter. But > >> then there isn't enough power left to drive a speaker, so you need an > >> active amplifier (or use headphones). > >> > >> Since this scheme required more external hardware than most students > >> would be comfortable with, I abandoned the idea. > >> > >> I think currently the music stuff is pretty cool, and accessible: any > >> old speaker will work and give you a decent volume. > >> > >> But, of course, always room for improvement! > >> > >> > >> On Thu, Oct 15, 2015 at 11:10 PM, Michael wrote: > >> > It's possible. The micro:bit as it stands now is much more capable > than > >> > the > >> > prototype device that I built. However the prototype I built was built > >> > around the Atmel 32u4 for the simple reason that it's a very similar > to > >> > the > >> > Atmel 328P. The reason I mention that is because for that I created a > >> > singing "cat piano" for my daughter a few years ago. That used PCM > >> > encoded > >> > WAV files - one per key, hard coded in program data. The wav files > were > >> > 8Khz > >> > 8bit mono files, which then output to a speaker. > >> > > >> > I reused the same technique to make a Harry Potter sorting hat for a > >> > Harry > >> > Potter themed birthday party later the same year. Videos of these > things > >> > aren't online for personal reasons. > >> > > >> > I don't have the time at this instant to rewrite these for micro:bit, > >> > and > >> > haven't raised these previously because I didn't want to derail the > >> > really > >> > cool stuff going on here. > >> > > >> > (This list will go public at some point, so I don't really want to > post > >> > a > >> > link to the video for the cat piano here, but happy to send it > directly > >> > to > >> > those curious) > >> > > >> > In case it's useful to anyone, I've pushed the code for the cat piano > >> > here: > >> > > >> > https://github.com/sparkslabs/catastrophene > >> > > >> > The code for the harry potter sorting hat is here: > >> > > >> > https://github.com/sparkslabs/sortinghat > >> > > >> > If useful, cool. If useful just as inspiration for *later* (and I > really > >> > would suggest *later* :o), that's cool. > >> > > >> > It's worth noting that it should be possible to directly drive a > >> > composite > >> > video display as well, since that's possible to do with the Atmel 32C4 > >> > which > >> > is again lower power than we have available for the micro:bit. > >> > > >> > All that said though, on the Computing At School forums I saw the > >> > following > >> > query today: > >> > > >> >> The game could do with having sound effects. Anyone know > >> >> of an easy way to attach a small speaker to a Micro:bit and > >> >> generate sound effects? The only thing I?ve seen so far is the > >> >> Kitronik ?Don?t Steal My Micro:bit Alarm? project which uses a > >> >> buzzer with simple ?on? or ?off? control. > >> > > >> > When micropython gets out there, people are going to be excited by > >> > what's > >> > already working here. (I know I am :-) ) > >> > > >> > We don't need to make it perfect immediately, just leave the door open > >> > to > >> > the possible. > >> > > >> > For example, in Star Trek 2, when just before Spock goes into the > engine > >> > room, Leonard Nimoy was asked by the director Nick Meyer to say > >> > "Remember" > >> > in a mind meld fashion to DeForest Kelley (McCoy). (I'm carefully > >> > avoiding > >> > spoilers for those who haven't seen these things :-) ) > >> > > >> > That wasn't actually in the script, but Nick Meyer had done enough TV > to > >> > understand how to add a place where a wedge could be placed to open > new > >> > doors. Likewise, I don't think we need to worry about bit banging wav > >> > files > >> > at this stage or implementing polyphony, but leaving the door open, > >> > that's > >> > cool. > >> > > >> > > >> > Michael. > >> > > >> > On 15 October 2015 at 22:03, Nicholas H.Tollervey > >> > wrote: > >> >> > >> >> On 15/10/15 20:02, Larry Hastings wrote: > >> >> > > >> >> > > >> >> > This guy wrote a simple MOD tracker for the TI 82 calculator: > >> >> > > >> >> > https://www.youtube.com/watch?v=I6G0CnBSWVk > >> >> > > >> >> > I'll save you a trip to Wikipedia: that's got a 6Mhz Z80, an 8-bit > >> >> > processor. And he's getting /four/ voices out of it, not to > mention > >> >> > effects. > >> >> > > >> >> > Gentlemen, our monophonic bleeping and blooping just got TOLD. > >> >> > > >> >> > > >> >> > Anybody know an audio rendering specialist? > >> >> > > >> >> > >> >> That thud you heard in the distance... that was my jaw hitting the > >> >> floor. > >> >> > >> >> ZOMG etc... :-) > >> >> > >> >> Nice find Larry, nice find..! I wonder if/how this is possible on the > >> >> micro:bit... > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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 > > > > > > > > _______________________________________________ > > 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: From ntoll at ntoll.org Fri Oct 16 09:32:43 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 16 Oct 2015 08:32:43 +0100 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events In-Reply-To: References: <56201ED2.5000302@ntoll.org> Message-ID: <5620A81B.9000001@ntoll.org> Hi Damien, I've fed that back to Steve (who I'm inviting to this mailing list anyway because I think he'd find it useful). I suggested the following text: "MicroPython Powered", "Built with MicroPython" or "MicroPython FTW!". ;-) Steve is a talented guy with an eye for playful catch-phrases and humorous design. I can't wait to see what he comes up with. Best wishes, N. On 16/10/15 00:17, Damien George wrote: > Hi Nicholas, > > Sounds great, you've been working hard! > > The mock-up for the TD editor looks super awesome! One think I would > like to request is that it mentions MicroPython somewhere on the UI. > Perhaps in the bottom right corner it can say "MicroPython powered"? > Or "Built with MicroPython". And maybe the Python-on-a-snake logo can > be used, we have a vector graphics version here: > https://github.com/micropython/micropython/blob/master/logo/vector-logo-inkscape_master.svg > > Cheers, > Damien. > > > On Thu, Oct 15, 2015 at 10:46 PM, Nicholas H.Tollervey wrote: >> Hi Folks, >> >> More status updates... >> >> I've been making myself available to various UK based PUGs to demo what >> we've been up to in the hope that people will get involved in writing >> fun projects and contributing educational resources. >> >> So far I have: >> >> Oxford - 22/Oct: http://www.meetup.com/oxfordpython/events/225877957/ >> Cambridge - 3/Nov: http://www.meetup.com/CamPUG/events/225157789/ >> London - 12/Nov: https://twitter.com/ldnpydojo >> Sheffield - 22/Nov: https://twitter.com/pysheff >> >> I hope there will be more. I have 17 devices "loaned" from the BBC for >> such workshops. Very cool. >> >> Also, it appears the BBC are very very close to removing blockers for us >> to open source our MicroPython work on the micro:bit. This is yet >> another encumbrance out of our way and will help us engage with the >> wider community. I can feel a post to HN or Slashdot coming on. ;-) >> >> Finally, many of you will know Steve Hawkes who does the amazing design >> work for PyCon UK. He's agreed to volunteer some time to "tart up" our >> rather grey and boring TouchDevelop based editor. He's been asked to >> make it look "obviously Pythonic" and appeal to 11yo kids. I've just >> seen a first draft which he claims has plenty wrong with it - I have a >> huge grin on my face. It shows the direction he's moving in and will >> definitely improve (see >> http://ntoll.org/static/images/pythoneditor_1st_draft.png). We're going >> to try to make the snakes in the border of the instructions on the RHS >> animated GIFs a la the O'Reilly logo (http://www.oreilly.com/ watch the >> creature for about 10 seconds). They'll blink and stick out forked >> tongues. Perhaps they should turn their heads when you click "Download", >> fix syntax errors or something. Ideas welcome..! >> >> Best wishes, >> >> N. >> >> P.S. A Dutch feller appears to have got hold of a micro:bit from >> somewhere and has been tweeting about it... >> >> https://twitter.com/gvanrossum/status/653975453691080704 >> >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail at timgolden.me.uk Fri Oct 16 09:37:34 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Fri, 16 Oct 2015 08:37:34 +0100 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events In-Reply-To: <5620A81B.9000001@ntoll.org> References: <56201ED2.5000302@ntoll.org> <5620A81B.9000001@ntoll.org> Message-ID: <5620A93E.6000402@timgolden.me.uk> On 16/10/2015 08:32, Nicholas H.Tollervey wrote: > I've fed that back to Steve (who I'm inviting to this mailing list > anyway because I think he'd find it useful). > > I suggested the following text: "MicroPython Powered", "Built with > MicroPython" or "MicroPython FTW!". ;-) Just in case you're actually serious about that last one... I wouldn't. :) TJG From ntoll at ntoll.org Fri Oct 16 09:44:24 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 16 Oct 2015 08:44:24 +0100 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events In-Reply-To: <5620A93E.6000402@timgolden.me.uk> References: <56201ED2.5000302@ntoll.org> <5620A81B.9000001@ntoll.org> <5620A93E.6000402@timgolden.me.uk> Message-ID: <5620AAD8.8090005@ntoll.org> Quite... I'm trying to work out what would appeal to 11yo without sounding like an adult trying too hard. Given that it's way too long a time since I was 11yo I'm coming to realise that simple / less is more is perhaps the way to go. N. On 16/10/15 08:37, Tim Golden wrote: > On 16/10/2015 08:32, Nicholas H.Tollervey wrote: >> I've fed that back to Steve (who I'm inviting to this mailing list >> anyway because I think he'd find it useful). >> >> I suggested the following text: "MicroPython Powered", "Built with >> MicroPython" or "MicroPython FTW!". ;-) > > Just in case you're actually serious about that last one... I wouldn't. > > :) > > TJG > _______________________________________________ > 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: From mail at timgolden.me.uk Fri Oct 16 09:53:15 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Fri, 16 Oct 2015 08:53:15 +0100 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events In-Reply-To: <5620AAD8.8090005@ntoll.org> References: <56201ED2.5000302@ntoll.org> <5620A81B.9000001@ntoll.org> <5620A93E.6000402@timgolden.me.uk> <5620AAD8.8090005@ntoll.org> Message-ID: <5620ACEB.3000601@timgolden.me.uk> Speaking frankly, I doubt if the 11-year-old cares a whit whether it's built with MicroPython or not. It's more about advertising to the wider audience. TJG On 16/10/2015 08:44, Nicholas H.Tollervey wrote: > Quite... I'm trying to work out what would appeal to 11yo without > sounding like an adult trying too hard. Given that it's way too long a > time since I was 11yo I'm coming to realise that simple / less is more > is perhaps the way to go. > > N. > > On 16/10/15 08:37, Tim Golden wrote: >> On 16/10/2015 08:32, Nicholas H.Tollervey wrote: >>> I've fed that back to Steve (who I'm inviting to this mailing list >>> anyway because I think he'd find it useful). >>> >>> I suggested the following text: "MicroPython Powered", "Built with >>> MicroPython" or "MicroPython FTW!". ;-) >> >> Just in case you're actually serious about that last one... I wouldn't. >> >> :) >> >> TJG >> _______________________________________________ >> 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 > From ntoll at ntoll.org Fri Oct 16 09:56:20 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 16 Oct 2015 08:56:20 +0100 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events In-Reply-To: <5620ACEB.3000601@timgolden.me.uk> References: <56201ED2.5000302@ntoll.org> <5620A81B.9000001@ntoll.org> <5620A93E.6000402@timgolden.me.uk> <5620AAD8.8090005@ntoll.org> <5620ACEB.3000601@timgolden.me.uk> Message-ID: <5620ADA4.2060206@ntoll.org> On 16/10/15 08:53, Tim Golden wrote: > Speaking frankly, I doubt if the 11-year-old cares a whit whether it's > built with MicroPython or not. It's more about advertising to the wider > audience. > You should go into brand-management Tim... :-P -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From larry at hastings.org Fri Oct 16 09:57:24 2015 From: larry at hastings.org (Larry Hastings) Date: Fri, 16 Oct 2015 00:57:24 -0700 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events In-Reply-To: <5620ACEB.3000601@timgolden.me.uk> References: <56201ED2.5000302@ntoll.org> <5620A81B.9000001@ntoll.org> <5620A93E.6000402@timgolden.me.uk> <5620AAD8.8090005@ntoll.org> <5620ACEB.3000601@timgolden.me.uk> Message-ID: <5620ADE4.50507@hastings.org> On 10/16/2015 12:53 AM, Tim Golden wrote: > Speaking frankly, I doubt if the 11-year-old cares a whit whether it's > built with MicroPython or not. It's more about advertising to the wider > audience. This is like wondering if 11-year-olds care what oil and gas companies sponsor a particular race car driver. How should we present the logo on the car, to best speak to the 11-year-olds watching? ;-) //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewelse1997 at gmail.com Fri Oct 16 10:00:55 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Fri, 16 Oct 2015 09:00:55 +0100 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events In-Reply-To: <5620ADE4.50507@hastings.org> References: <56201ED2.5000302@ntoll.org> <5620A81B.9000001@ntoll.org> <5620A93E.6000402@timgolden.me.uk> <5620AAD8.8090005@ntoll.org> <5620ACEB.3000601@timgolden.me.uk> <5620ADE4.50507@hastings.org> Message-ID: Maybe a good way to appeal to the eleven year olds who care that it?s built using micropython, or have never heard of micropython and wonder what it is (I?d have been one of those), maybe there should be a link to something 11y/o friendly with the text ?made possible by micropython? or words to that effect? Matthew From: Microbit on behalf of Larry Hastings Reply-To: For Pythonic MicroBit related disucssions Date: Friday, 16 October 2015 at 08:57 To: Subject: Re: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events On 10/16/2015 12:53 AM, Tim Golden wrote: Speaking frankly, I doubt if the 11-year-old cares a whit whether it's built with MicroPython or not. It's more about advertising to the wider audience. This is like wondering if 11-year-olds care what oil and gas companies sponsor a particular race car driver. How should we present the logo on the car, to best speak to the 11-year-olds watching? ;-) /arry _______________________________________________ Microbit mailing list Microbit at python.org https://mail.python.org/mailman/listinfo/microbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at timgolden.me.uk Fri Oct 16 10:04:31 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Fri, 16 Oct 2015 09:04:31 +0100 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events In-Reply-To: <5620ADA4.2060206@ntoll.org> References: <56201ED2.5000302@ntoll.org> <5620A81B.9000001@ntoll.org> <5620A93E.6000402@timgolden.me.uk> <5620AAD8.8090005@ntoll.org> <5620ACEB.3000601@timgolden.me.uk> <5620ADA4.2060206@ntoll.org> Message-ID: <5620AF8F.2090609@timgolden.me.uk> On 16/10/2015 08:56, Nicholas H.Tollervey wrote: > On 16/10/15 08:53, Tim Golden wrote: >> Speaking frankly, I doubt if the 11-year-old cares a whit whether it's >> built with MicroPython or not. It's more about advertising to the wider >> audience. >> > > You should go into brand-management Tim... :-P Funnily enough, I do work in brand-management: http://www.exterionmedia.com/uk/ TJG From ntoll at ntoll.org Fri Oct 16 10:12:22 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 16 Oct 2015 09:12:22 +0100 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events In-Reply-To: <5620AF8F.2090609@timgolden.me.uk> References: <56201ED2.5000302@ntoll.org> <5620A81B.9000001@ntoll.org> <5620A93E.6000402@timgolden.me.uk> <5620AAD8.8090005@ntoll.org> <5620ACEB.3000601@timgolden.me.uk> <5620ADA4.2060206@ntoll.org> <5620AF8F.2090609@timgolden.me.uk> Message-ID: <5620B166.3020805@ntoll.org> On 16/10/15 09:04, Tim Golden wrote: >> You should go into brand-management Tim... :-P > > Funnily enough, I do work in brand-management: > > http://www.exterionmedia.com/uk/ > I KNOW!!!!! :-D b'dum tish thankyouverymuch... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail at timgolden.me.uk Fri Oct 16 10:14:47 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Fri, 16 Oct 2015 09:14:47 +0100 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events In-Reply-To: <5620B166.3020805@ntoll.org> References: <56201ED2.5000302@ntoll.org> <5620A81B.9000001@ntoll.org> <5620A93E.6000402@timgolden.me.uk> <5620AAD8.8090005@ntoll.org> <5620ACEB.3000601@timgolden.me.uk> <5620ADA4.2060206@ntoll.org> <5620AF8F.2090609@timgolden.me.uk> <5620B166.3020805@ntoll.org> Message-ID: <5620B1F7.1020706@timgolden.me.uk> On 16/10/2015 09:12, Nicholas H.Tollervey wrote: > On 16/10/15 09:04, Tim Golden wrote: >>> You should go into brand-management Tim... :-P >> >> Funnily enough, I do work in brand-management: >> >> http://www.exterionmedia.com/uk/ >> > > I KNOW!!!!! :-D > > b'dum tish thankyouverymuch... (Where's that recall-email button....?) Dim-wittedly-yours, TJG From ntoll at ntoll.org Fri Oct 16 10:21:02 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 16 Oct 2015 09:21:02 +0100 Subject: [Microbit-Python] Status updates... Open Source and upcoming Python user group MicroPython / micro:bit events In-Reply-To: References: <56201ED2.5000302@ntoll.org> <5620A81B.9000001@ntoll.org> <5620A93E.6000402@timgolden.me.uk> <5620AAD8.8090005@ntoll.org> <5620ACEB.3000601@timgolden.me.uk> <5620ADE4.50507@hastings.org> Message-ID: <5620B36E.4030604@ntoll.org> Quite... what Matthew says is more what I had in mind... click on the interesting looking logo and it rewards you by taking you into a place you can explore further. It's sort of an 11yo's version of this tweet: https://twitter.com/JustHadOneJob/status/653303929363525632 Totally get the cynicism about marketing to 11yo. ;-) N. On 16/10/15 09:00, Matthew Else wrote: > Maybe a good way to appeal to the eleven year olds who care that it?s > built using micropython, or have never heard of micropython and wonder > what it is (I?d have been one of those), maybe there should be a link to > something 11y/o friendly with the text ?made possible by micropython? or > words to that effect? > > Matthew > > From: Microbit on behalf of Larry Hastings > Reply-To: For Pythonic MicroBit related disucssions > Date: Friday, 16 October 2015 at 08:57 > To: > > Subject: Re: [Microbit-Python] Status updates... Open Source and > upcoming Python user group MicroPython / micro:bit events > > On 10/16/2015 12:53 AM, Tim Golden wrote: >> Speaking frankly, I doubt if the 11-year-old cares a whit whether it's >> built with MicroPython or not. It's more about advertising to the wider >> audience. > > This is like wondering if 11-year-olds care what oil and gas companies > sponsor a particular race car driver. How should we present the logo on > the car, to best speak to the 11-year-olds watching? ;-) > > > //arry/ > _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ntoll at ntoll.org Fri Oct 16 14:23:11 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 16 Oct 2015 13:23:11 +0100 Subject: [Microbit-Python] A sound related long shot... Message-ID: <5620EC2F.50501@ntoll.org> Hi Folks, So I was thinking about the amazing example Larry posted yesterday of the 20yo calculator turned into a multi-part sequencer with effects etc... Could we do something just as amazing... would we even want to try..? Then I remembered - as a child of the 1980s I had an original BBC B at home and one of the most amazing feats Superior Software pulled off was a 7.5k program called, simply, "Speech!". To give you an idea of what it was like I found this on YouTube: https://www.youtube.com/watch?v=t8wyUsaDAyI I think the Dalek like timbre of the voice gives it a certain "death to all humans" charm, don't you think..? This article briefly explains how it works: http://bbc.nvg.org/doc/Speech.html Given that we already can "do" music, I wonder if we can do a very simple speech synthesiser such as the "Speech!" utility of yore. I know that the BBC want kids to relate to their devices and making it able to say Dalek-esque "EX TERM IN ATE" like vocalisations would knock people's socks off. It would also be yet another differentiator that puts MicroPython in a positive light. I also imagine some rather interesting educational resources being written to explain how it works. So, thoughts..? Is this even possible..? I imagine a very simple API such as this: >>> import microbit >>> microbit.say("Hello, World") >>> microbit.say("Hello, World", pin=microbit.pin1) # Lke music API Perhaps specify pitch of voice using an arbitrary range from 0 (lowest) - 9 (highest) with 4 being the default setting: >>> microbit.say("Hello, World", pitch=9) # Castrato >>> microbit.say("Hello, World", pitch=0) # Basso Profundo A similar range may also work for speed of delivery of speech: >>> microbit.say("Hello, World", speed=9) # Presto! >>> microbit.say("Hello, World", speed=0) # Molto Lento Combinations would be fun: >>> microbit.say("Hello, World", speed=9, pitch=9) # Chipmunks >>> microbit.say("Hello, World", speed=0, pitch=0) # Death of HAL9000 I realise all of the above is VERY SPECULATIVE and hand-wavy on my part. Could this be done? Would we want to do it? What would need to happen if it were possible? Thoughts, constructive critique and ideas most welcome! Best wishes, Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From damien.p.george at gmail.com Fri Oct 16 14:33:24 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 16 Oct 2015 13:33:24 +0100 Subject: [Microbit-Python] A sound related long shot... In-Reply-To: <5620EC2F.50501@ntoll.org> References: <5620EC2F.50501@ntoll.org> Message-ID: The moons are many and the sticks are long... I will see what can be done :) On Fri, Oct 16, 2015 at 1:23 PM, Nicholas H.Tollervey wrote: > Hi Folks, > > So I was thinking about the amazing example Larry posted yesterday of > the 20yo calculator turned into a multi-part sequencer with effects etc... > > Could we do something just as amazing... would we even want to try..? > > Then I remembered - as a child of the 1980s I had an original BBC B at > home and one of the most amazing feats Superior Software pulled off was > a 7.5k program called, simply, "Speech!". To give you an idea of what it > was like I found this on YouTube: > > https://www.youtube.com/watch?v=t8wyUsaDAyI > > I think the Dalek like timbre of the voice gives it a certain "death to > all humans" charm, don't you think..? This article briefly explains how > it works: > > http://bbc.nvg.org/doc/Speech.html > > Given that we already can "do" music, I wonder if we can do a very > simple speech synthesiser such as the "Speech!" utility of yore. I know > that the BBC want kids to relate to their devices and making it able to > say Dalek-esque "EX TERM IN ATE" like vocalisations would knock people's > socks off. > > It would also be yet another differentiator that puts MicroPython in a > positive light. I also imagine some rather interesting educational > resources being written to explain how it works. > > So, thoughts..? Is this even possible..? I imagine a very simple API > such as this: > >>>> import microbit >>>> microbit.say("Hello, World") >>>> microbit.say("Hello, World", pin=microbit.pin1) # Lke music API > > Perhaps specify pitch of voice using an arbitrary range from 0 (lowest) > - 9 (highest) with 4 being the default setting: > >>>> microbit.say("Hello, World", pitch=9) # Castrato >>>> microbit.say("Hello, World", pitch=0) # Basso Profundo > > A similar range may also work for speed of delivery of speech: > >>>> microbit.say("Hello, World", speed=9) # Presto! >>>> microbit.say("Hello, World", speed=0) # Molto Lento > > Combinations would be fun: > >>>> microbit.say("Hello, World", speed=9, pitch=9) # Chipmunks >>>> microbit.say("Hello, World", speed=0, pitch=0) # Death of HAL9000 > > I realise all of the above is VERY SPECULATIVE and hand-wavy on my part. > > Could this be done? Would we want to do it? What would need to happen if > it were possible? > > Thoughts, constructive critique and ideas most welcome! > > Best wishes, > > Nicholas. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From ntoll at ntoll.org Fri Oct 16 14:36:29 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 16 Oct 2015 13:36:29 +0100 Subject: [Microbit-Python] A sound related long shot... In-Reply-To: References: <5620EC2F.50501@ntoll.org> Message-ID: <5620EF4D.1060007@ntoll.org> On 16/10/15 13:33, Damien George wrote: > The moons are many and the sticks are long... I will see what can be done :) > You're a poet. :-) N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From larry at hastings.org Fri Oct 16 14:37:12 2015 From: larry at hastings.org (Larry Hastings) Date: Fri, 16 Oct 2015 05:37:12 -0700 Subject: [Microbit-Python] A sound related long shot... In-Reply-To: <5620EC2F.50501@ntoll.org> References: <5620EC2F.50501@ntoll.org> Message-ID: <5620EF78.1050105@hastings.org> On 10/16/2015 05:23 AM, Nicholas H.Tollervey wrote: > Hi Folks, > > So I was thinking about the amazing example Larry posted yesterday of > the 20yo calculator turned into a multi-part sequencer with effects etc... > > Could we do something just as amazing... would we even want to try..? > > Then I remembered - as a child of the 1980s I had an original BBC B at > home and one of the most amazing feats Superior Software pulled off was > a 7.5k program called, simply, "Speech!". To give you an idea of what it > was like I found this on YouTube: > > https://www.youtube.com/watch?v=t8wyUsaDAyI The equivalent for computers manufactured outside Britain was "Software Automatic Mouth", or "SAM", available for the Apple ][, Atari 400/800, and Commodore 64. Some enterprising hacker has taken the C=64 version, compiled the assembler into messy C, cleaned it up (some), and put it up on Github: https://github.com/s-macke/SAM He then used Emscript to translate /that/ into Javascript, and behold: web page demo. http://simulationcorner.net/index.php?page=sam (Aside: cripes, modern computers are fast. Just imagine how awful this code is, and what a Rube Goldberg machine its runtime must be like. Yet it runs in the tiniest fraction of a second.) > So, thoughts..? Is this even possible..? I imagine a very simple API > such as this: > >>>> import microbit >>>> microbit.say("Hello, World") >>>> microbit.say("Hello, World", pin=microbit.pin1) # Lke music API Possible, yes. But I don't know anything about voice synthesis, so I could hardly write one myself. And even if SAM is "abandonware", legally /somebody/ still owns the copyright, so I wouldn't ship that specific implementation. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Fri Oct 16 15:48:26 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 16 Oct 2015 14:48:26 +0100 Subject: [Microbit-Python] A sound related long shot... In-Reply-To: <5620EF78.1050105@hastings.org> References: <5620EC2F.50501@ntoll.org> <5620EF78.1050105@hastings.org> Message-ID: I have managed to get proper synthesised audio out of the microbit, using a hand-written PWM loop. As a proof of principle, it can play a short recorded sample. Attached is the firmware. I won't tell you what the sample is, so see if you can find out! Here are instructions: 1. download firmware.hex to the microbit 2. attach a speaker to pin0 and pin1 (don't use ground) 3. load up the serial terminal 4. execute: synth_run(10, 31, 3) 5. listen in awe! You can adjust the numbers passed to synth_run to muck about with the sample. With this we can basically play any audio, from a mod tracker to a speech synth. The only caveat is that it can't run in the background. The loop needs full control of the CPU to get the audio to play properly. To answer Nicholas' questions: 1. Could this be done? Yes. 2. Would we want to do it? It would be cool if it (speech synth, or a mod tracker, or ...) was implemented. 3. What would need to happen? We need to find someone with the time to implement it! It's a fair bit of work (but there are no barriers except time). The SAM software would be ideal, if only it were properly licensed. Otherwise there's a fair bit of work to record all the 49 phonemes, etc. Maybe we can just provide some prerecorded samples (eg "exterminate") and provide functions to adjust the pitch, echo, etc, and combine sounds, and then play them? D. On Fri, Oct 16, 2015 at 1:37 PM, Larry Hastings wrote: > > > On 10/16/2015 05:23 AM, Nicholas H.Tollervey wrote: > > Hi Folks, > > So I was thinking about the amazing example Larry posted yesterday of > the 20yo calculator turned into a multi-part sequencer with effects etc... > > Could we do something just as amazing... would we even want to try..? > > Then I remembered - as a child of the 1980s I had an original BBC B at > home and one of the most amazing feats Superior Software pulled off was > a 7.5k program called, simply, "Speech!". To give you an idea of what it > was like I found this on YouTube: > > https://www.youtube.com/watch?v=t8wyUsaDAyI > > > The equivalent for computers manufactured outside Britain was "Software > Automatic Mouth", or "SAM", available for the Apple ][, Atari 400/800, and > Commodore 64. > > Some enterprising hacker has taken the C=64 version, compiled the assembler > into messy C, cleaned it up (some), and put it up on Github: > > https://github.com/s-macke/SAM > > > He then used Emscript to translate that into Javascript, and behold: web > page demo. > > http://simulationcorner.net/index.php?page=sam > > > (Aside: cripes, modern computers are fast. Just imagine how awful this code > is, and what a Rube Goldberg machine its runtime must be like. Yet it runs > in the tiniest fraction of a second.) > > So, thoughts..? Is this even possible..? I imagine a very simple API > such as this: > > import microbit > microbit.say("Hello, World") > microbit.say("Hello, World", pin=microbit.pin1) # Lke music API > > > Possible, yes. But I don't know anything about voice synthesis, so I could > hardly write one myself. And even if SAM is "abandonware", legally somebody > still owns the copyright, so I wouldn't ship that specific implementation. > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- A non-text attachment was scrubbed... Name: firmware.hex Type: application/octet-stream Size: 474172 bytes Desc: not available URL: From matthewelse1997 at gmail.com Fri Oct 16 17:08:47 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Fri, 16 Oct 2015 16:08:47 +0100 Subject: [Microbit-Python] A sound related long shot... In-Reply-To: References: <5620EC2F.50501@ntoll.org> <5620EF78.1050105@hastings.org> Message-ID: <1484782E-F8A0-4AC8-A011-1F874C26934A@gmail.com> That?s awesome! What samples were you using for the sound/where are they from? Matthew On 16/10/2015, 14:48, "Microbit on behalf of Damien George" wrote: >I have managed to get proper synthesised audio out of the microbit, >using a hand-written PWM loop. As a proof of principle, it can play a >short recorded sample. > >Attached is the firmware. I won't tell you what the sample is, so see >if you can find out! Here are instructions: > >1. download firmware.hex to the microbit >2. attach a speaker to pin0 and pin1 (don't use ground) >3. load up the serial terminal >4. execute: synth_run(10, 31, 3) >5. listen in awe! > >You can adjust the numbers passed to synth_run to muck about with the sample. > >With this we can basically play any audio, from a mod tracker to a >speech synth. The only caveat is that it can't run in the background. >The loop needs full control of the CPU to get the audio to play >properly. > >To answer Nicholas' questions: > >1. Could this be done? Yes. >2. Would we want to do it? It would be cool if it (speech synth, or a >mod tracker, or ...) was implemented. >3. What would need to happen? We need to find someone with the time to >implement it! It's a fair bit of work (but there are no barriers >except time). > >The SAM software would be ideal, if only it were properly licensed. >Otherwise there's a fair bit of work to record all the 49 phonemes, >etc. > >Maybe we can just provide some prerecorded samples (eg "exterminate") >and provide functions to adjust the pitch, echo, etc, and combine >sounds, and then play them? > >D. > > > > >On Fri, Oct 16, 2015 at 1:37 PM, Larry Hastings wrote: >> >> >> On 10/16/2015 05:23 AM, Nicholas H.Tollervey wrote: >> >> Hi Folks, >> >> So I was thinking about the amazing example Larry posted yesterday of >> the 20yo calculator turned into a multi-part sequencer with effects etc... >> >> Could we do something just as amazing... would we even want to try..? >> >> Then I remembered - as a child of the 1980s I had an original BBC B at >> home and one of the most amazing feats Superior Software pulled off was >> a 7.5k program called, simply, "Speech!". To give you an idea of what it >> was like I found this on YouTube: >> >> https://www.youtube.com/watch?v=t8wyUsaDAyI >> >> >> The equivalent for computers manufactured outside Britain was "Software >> Automatic Mouth", or "SAM", available for the Apple ][, Atari 400/800, and >> Commodore 64. >> >> Some enterprising hacker has taken the C=64 version, compiled the assembler >> into messy C, cleaned it up (some), and put it up on Github: >> >> https://github.com/s-macke/SAM >> >> >> He then used Emscript to translate that into Javascript, and behold: web >> page demo. >> >> http://simulationcorner.net/index.php?page=sam >> >> >> (Aside: cripes, modern computers are fast. Just imagine how awful this code >> is, and what a Rube Goldberg machine its runtime must be like. Yet it runs >> in the tiniest fraction of a second.) >> >> So, thoughts..? Is this even possible..? I imagine a very simple API >> such as this: >> >> import microbit >> microbit.say("Hello, World") >> microbit.say("Hello, World", pin=microbit.pin1) # Lke music API >> >> >> Possible, yes. But I don't know anything about voice synthesis, so I could >> hardly write one myself. And even if SAM is "abandonware", legally somebody >> still owns the copyright, so I wouldn't ship that specific implementation. >> >> >> /arry >> >> _______________________________________________ >> 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 From damien.p.george at gmail.com Fri Oct 16 17:22:14 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 16 Oct 2015 16:22:14 +0100 Subject: [Microbit-Python] A sound related long shot... In-Reply-To: <1484782E-F8A0-4AC8-A011-1F874C26934A@gmail.com> References: <5620EC2F.50501@ntoll.org> <5620EF78.1050105@hastings.org> <1484782E-F8A0-4AC8-A011-1F874C26934A@gmail.com> Message-ID: I recorded the sample myself, and turned it into an array of bytes. On Fri, Oct 16, 2015 at 4:08 PM, Matthew Else wrote: > That?s awesome! What samples were you using for the sound/where are they from? > > Matthew > > > > On 16/10/2015, 14:48, "Microbit on behalf of Damien George" wrote: > >>I have managed to get proper synthesised audio out of the microbit, >>using a hand-written PWM loop. As a proof of principle, it can play a >>short recorded sample. >> >>Attached is the firmware. I won't tell you what the sample is, so see >>if you can find out! Here are instructions: >> >>1. download firmware.hex to the microbit >>2. attach a speaker to pin0 and pin1 (don't use ground) >>3. load up the serial terminal >>4. execute: synth_run(10, 31, 3) >>5. listen in awe! >> >>You can adjust the numbers passed to synth_run to muck about with the sample. >> >>With this we can basically play any audio, from a mod tracker to a >>speech synth. The only caveat is that it can't run in the background. >>The loop needs full control of the CPU to get the audio to play >>properly. >> >>To answer Nicholas' questions: >> >>1. Could this be done? Yes. >>2. Would we want to do it? It would be cool if it (speech synth, or a >>mod tracker, or ...) was implemented. >>3. What would need to happen? We need to find someone with the time to >>implement it! It's a fair bit of work (but there are no barriers >>except time). >> >>The SAM software would be ideal, if only it were properly licensed. >>Otherwise there's a fair bit of work to record all the 49 phonemes, >>etc. >> >>Maybe we can just provide some prerecorded samples (eg "exterminate") >>and provide functions to adjust the pitch, echo, etc, and combine >>sounds, and then play them? >> >>D. >> >> >> >> >>On Fri, Oct 16, 2015 at 1:37 PM, Larry Hastings wrote: >>> >>> >>> On 10/16/2015 05:23 AM, Nicholas H.Tollervey wrote: >>> >>> Hi Folks, >>> >>> So I was thinking about the amazing example Larry posted yesterday of >>> the 20yo calculator turned into a multi-part sequencer with effects etc... >>> >>> Could we do something just as amazing... would we even want to try..? >>> >>> Then I remembered - as a child of the 1980s I had an original BBC B at >>> home and one of the most amazing feats Superior Software pulled off was >>> a 7.5k program called, simply, "Speech!". To give you an idea of what it >>> was like I found this on YouTube: >>> >>> https://www.youtube.com/watch?v=t8wyUsaDAyI >>> >>> >>> The equivalent for computers manufactured outside Britain was "Software >>> Automatic Mouth", or "SAM", available for the Apple ][, Atari 400/800, and >>> Commodore 64. >>> >>> Some enterprising hacker has taken the C=64 version, compiled the assembler >>> into messy C, cleaned it up (some), and put it up on Github: >>> >>> https://github.com/s-macke/SAM >>> >>> >>> He then used Emscript to translate that into Javascript, and behold: web >>> page demo. >>> >>> http://simulationcorner.net/index.php?page=sam >>> >>> >>> (Aside: cripes, modern computers are fast. Just imagine how awful this code >>> is, and what a Rube Goldberg machine its runtime must be like. Yet it runs >>> in the tiniest fraction of a second.) >>> >>> So, thoughts..? Is this even possible..? I imagine a very simple API >>> such as this: >>> >>> import microbit >>> microbit.say("Hello, World") >>> microbit.say("Hello, World", pin=microbit.pin1) # Lke music API >>> >>> >>> Possible, yes. But I don't know anything about voice synthesis, so I could >>> hardly write one myself. And even if SAM is "abandonware", legally somebody >>> still owns the copyright, so I wouldn't ship that specific implementation. >>> >>> >>> /arry >>> >>> _______________________________________________ >>> 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 From ntoll at ntoll.org Fri Oct 16 17:57:15 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 16 Oct 2015 16:57:15 +0100 Subject: [Microbit-Python] A sound related long shot... In-Reply-To: References: <5620EC2F.50501@ntoll.org> <5620EF78.1050105@hastings.org> Message-ID: <56211E5B.1080803@ntoll.org> Damien, That's brilliant. :-) See comments in-line below. On 16/10/15 14:48, Damien George wrote: > I have managed to get proper synthesised audio out of the microbit, > using a hand-written PWM loop. As a proof of principle, it can play a > short recorded sample. > > Attached is the firmware. I won't tell you what the sample is, so see > if you can find out! Here are instructions: > > 1. download firmware.hex to the microbit > 2. attach a speaker to pin0 and pin1 (don't use ground) > 3. load up the serial terminal > 4. execute: synth_run(10, 31, 3) > 5. listen in awe! > Awestruck. I especially like that I can make it work with just a couple of crocodile clips and a cheap speaker. > You can adjust the numbers passed to synth_run to muck about with the sample. > I'll try that when I get home (I tested this by surreptitiously sneaking off to the staff canteen with my laptop). ;-) > With this we can basically play any audio, from a mod tracker to a > speech synth. The only caveat is that it can't run in the background. > The loop needs full control of the CPU to get the audio to play > properly. > IMHO that's an acceptable trade-off given the awesomeness of the end result. > To answer Nicholas' questions: > > 1. Could this be done? Yes. AMEN! > 2. Would we want to do it? It would be cool if it (speech synth, or a > mod tracker, or ...) was implemented. I agree. In terms of inspiration, fun and ZOMG factors this is quite high up there. > 3. What would need to happen? We need to find someone with the time to > implement it! It's a fair bit of work (but there are no barriers > except time). > Understood... this is why I'm pushing the BBC so hard to allow us to work in the open. There is bound to be someone, somewhere who could help. > The SAM software would be ideal, if only it were properly licensed. > Otherwise there's a fair bit of work to record all the 49 phonemes, > etc. > Surely, there are unencumbered digital assets for the 49 phonemes. Could we not re-use stuff from free software projects such as rsynth, mbrola, KTTS or festival? Alternatively (and rather foolishly) how hard can it be to record all 49 phonemes..? :-) > Maybe we can just provide some prerecorded samples (eg "exterminate") > and provide functions to adjust the pitch, echo, etc, and combine > sounds, and then play them? > The problem is that it limits what you can get the device to say. :-/ Mind you... it's still pretty amazing. N. > D. > > > > > On Fri, Oct 16, 2015 at 1:37 PM, Larry Hastings wrote: >> >> >> On 10/16/2015 05:23 AM, Nicholas H.Tollervey wrote: >> >> Hi Folks, >> >> So I was thinking about the amazing example Larry posted yesterday of >> the 20yo calculator turned into a multi-part sequencer with effects etc... >> >> Could we do something just as amazing... would we even want to try..? >> >> Then I remembered - as a child of the 1980s I had an original BBC B at >> home and one of the most amazing feats Superior Software pulled off was >> a 7.5k program called, simply, "Speech!". To give you an idea of what it >> was like I found this on YouTube: >> >> https://www.youtube.com/watch?v=t8wyUsaDAyI >> >> >> The equivalent for computers manufactured outside Britain was "Software >> Automatic Mouth", or "SAM", available for the Apple ][, Atari 400/800, and >> Commodore 64. >> >> Some enterprising hacker has taken the C=64 version, compiled the assembler >> into messy C, cleaned it up (some), and put it up on Github: >> >> https://github.com/s-macke/SAM >> >> >> He then used Emscript to translate that into Javascript, and behold: web >> page demo. >> >> http://simulationcorner.net/index.php?page=sam >> >> >> (Aside: cripes, modern computers are fast. Just imagine how awful this code >> is, and what a Rube Goldberg machine its runtime must be like. Yet it runs >> in the tiniest fraction of a second.) >> >> So, thoughts..? Is this even possible..? I imagine a very simple API >> such as this: >> >> import microbit >> microbit.say("Hello, World") >> microbit.say("Hello, World", pin=microbit.pin1) # Lke music API >> >> >> Possible, yes. But I don't know anything about voice synthesis, so I could >> hardly write one myself. And even if SAM is "abandonware", legally somebody >> still owns the copyright, so I wouldn't ship that specific implementation. >> >> >> /arry >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From sparks.m at gmail.com Fri Oct 16 18:50:59 2015 From: sparks.m at gmail.com (Michael) Date: Fri, 16 Oct 2015 17:50:59 +0100 Subject: [Microbit-Python] A sound related long shot... In-Reply-To: <56211E5B.1080803@ntoll.org> References: <5620EC2F.50501@ntoll.org> <5620EF78.1050105@hastings.org> <56211E5B.1080803@ntoll.org> Message-ID: I've done some digging and found this: https://code.google.com/p/tinkerit/wiki/Cantarino This appears to be a pure software phoneme based synthesizer. Which has a video of an arduino singing "Daisy Daisy"... https://vimeo.com/5577046 I've had a little poke, and after exporting it to github, I've found it's actually just one quite short file: https://github.com/sparkslabs/tinkerit/blob/master/Cantarino/speech_daisybell.pde I might see what I can get out of this. Michael. Michael. On 16 October 2015 at 16:57, Nicholas H.Tollervey wrote: > Damien, > > That's brilliant. :-) > > See comments in-line below. > > On 16/10/15 14:48, Damien George wrote: > > I have managed to get proper synthesised audio out of the microbit, > > using a hand-written PWM loop. As a proof of principle, it can play a > > short recorded sample. > > > > Attached is the firmware. I won't tell you what the sample is, so see > > if you can find out! Here are instructions: > > > > 1. download firmware.hex to the microbit > > 2. attach a speaker to pin0 and pin1 (don't use ground) > > 3. load up the serial terminal > > 4. execute: synth_run(10, 31, 3) > > 5. listen in awe! > > > > Awestruck. I especially like that I can make it work with just a couple > of crocodile clips and a cheap speaker. > > > You can adjust the numbers passed to synth_run to muck about with the > sample. > > > > I'll try that when I get home (I tested this by surreptitiously sneaking > off to the staff canteen with my laptop). ;-) > > > With this we can basically play any audio, from a mod tracker to a > > speech synth. The only caveat is that it can't run in the background. > > The loop needs full control of the CPU to get the audio to play > > properly. > > > > IMHO that's an acceptable trade-off given the awesomeness of the end > result. > > > To answer Nicholas' questions: > > > > 1. Could this be done? Yes. > > AMEN! > > > 2. Would we want to do it? It would be cool if it (speech synth, or a > > mod tracker, or ...) was implemented. > > I agree. In terms of inspiration, fun and ZOMG factors this is quite > high up there. > > > 3. What would need to happen? We need to find someone with the time to > > implement it! It's a fair bit of work (but there are no barriers > > except time). > > > > Understood... this is why I'm pushing the BBC so hard to allow us to > work in the open. There is bound to be someone, somewhere who could help. > > > The SAM software would be ideal, if only it were properly licensed. > > Otherwise there's a fair bit of work to record all the 49 phonemes, > > etc. > > > > Surely, there are unencumbered digital assets for the 49 phonemes. Could > we not re-use stuff from free software projects such as rsynth, mbrola, > KTTS or festival? > > Alternatively (and rather foolishly) how hard can it be to record all 49 > phonemes..? > > :-) > > > Maybe we can just provide some prerecorded samples (eg "exterminate") > > and provide functions to adjust the pitch, echo, etc, and combine > > sounds, and then play them? > > > > The problem is that it limits what you can get the device to say. :-/ > > Mind you... it's still pretty amazing. > > N. > > > D. > > > > > > > > > > On Fri, Oct 16, 2015 at 1:37 PM, Larry Hastings > wrote: > >> > >> > >> On 10/16/2015 05:23 AM, Nicholas H.Tollervey wrote: > >> > >> Hi Folks, > >> > >> So I was thinking about the amazing example Larry posted yesterday of > >> the 20yo calculator turned into a multi-part sequencer with effects > etc... > >> > >> Could we do something just as amazing... would we even want to try..? > >> > >> Then I remembered - as a child of the 1980s I had an original BBC B at > >> home and one of the most amazing feats Superior Software pulled off was > >> a 7.5k program called, simply, "Speech!". To give you an idea of what it > >> was like I found this on YouTube: > >> > >> https://www.youtube.com/watch?v=t8wyUsaDAyI > >> > >> > >> The equivalent for computers manufactured outside Britain was "Software > >> Automatic Mouth", or "SAM", available for the Apple ][, Atari 400/800, > and > >> Commodore 64. > >> > >> Some enterprising hacker has taken the C=64 version, compiled the > assembler > >> into messy C, cleaned it up (some), and put it up on Github: > >> > >> https://github.com/s-macke/SAM > >> > >> > >> He then used Emscript to translate that into Javascript, and behold: web > >> page demo. > >> > >> http://simulationcorner.net/index.php?page=sam > >> > >> > >> (Aside: cripes, modern computers are fast. Just imagine how awful this > code > >> is, and what a Rube Goldberg machine its runtime must be like. Yet it > runs > >> in the tiniest fraction of a second.) > >> > >> So, thoughts..? Is this even possible..? I imagine a very simple API > >> such as this: > >> > >> import microbit > >> microbit.say("Hello, World") > >> microbit.say("Hello, World", pin=microbit.pin1) # Lke music API > >> > >> > >> Possible, yes. But I don't know anything about voice synthesis, so I > could > >> hardly write one myself. And even if SAM is "abandonware", legally > somebody > >> still owns the copyright, so I wouldn't ship that specific > implementation. > >> > >> > >> /arry > >> > >> _______________________________________________ > >> 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: From ntoll at ntoll.org Fri Oct 16 23:37:58 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 16 Oct 2015 22:37:58 +0100 Subject: [Microbit-Python] A sound related long shot... In-Reply-To: References: <5620EC2F.50501@ntoll.org> <5620EF78.1050105@hastings.org> Message-ID: <56216E35.1080602@ntoll.org> On 16/10/15 14:48, Damien George wrote: > The SAM software would be ideal, if only it were properly licensed. > Otherwise there's a fair bit of work to record all the 49 phonemes, > etc. https://www.freesound.org/people/margo_heston/packs/12249/ ???? N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From larry at hastings.org Sat Oct 17 01:53:25 2015 From: larry at hastings.org (Larry Hastings) Date: Fri, 16 Oct 2015 16:53:25 -0700 Subject: [Microbit-Python] Secrecy And The BBC micro:bit In-Reply-To: <56211E5B.1080803@ntoll.org> References: <5620EC2F.50501@ntoll.org> <5620EF78.1050105@hastings.org> <56211E5B.1080803@ntoll.org> Message-ID: <56218DF5.1060504@hastings.org> On 10/16/2015 08:57 AM, Nicholas H.Tollervey wrote: > Understood... this is why I'm pushing the BBC so hard to allow us to > work in the open. There is bound to be someone, somewhere who could help. That reminds me. What is the rule that is going to keep people happy wrt to showing the micro:bit in public? About a week from now I'll be at PyCon Ireland with my micro:bit, and last I heard Mark Shannon is going too (and I bet he'd bring his too). I plan to sprint on the micro:bit while there. I could also give a lightning talk, holding the little darling up in front of the crowd. I could let folks gawk at it and hold it and press its darling little buttons, maybe even play a game of slalom. Is that all okay? Or do I need to cower from the light, programming it in secret, snarling at passersby to leave my precious alone? Seeking guidance, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Sat Oct 17 01:57:38 2015 From: larry at hastings.org (Larry Hastings) Date: Fri, 16 Oct 2015 16:57:38 -0700 Subject: [Microbit-Python] The well-dressed micro:bit on the go Message-ID: <56218EF2.8070404@hastings.org> Speaking of traveling with the micro:bit, when I brought it home from PyCon UK I literally stowed it in a Costa to-go coffee cup which I mashed closed with my brutish fists. I thought, it might be nice to travel with a little more style this time. The right thing here I figure is a good-sized business card case. This is the one that's worked best so far: http://www.amazon.com/gp/product/B013OZ2UJ6 It's velvet-lined and roomy enough to maybe even fit a USB cable. And it looks like a miniature briefcase, thus enhancing the secure atmosphere surrounding the micro:bit. Now if only it came with a teensy handcuff so I could attach it to my wrist! //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Sun Oct 18 16:55:31 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Sun, 18 Oct 2015 15:55:31 +0100 Subject: [Microbit-Python] Secrecy And The BBC micro:bit In-Reply-To: <56218DF5.1060504@hastings.org> References: <5620EC2F.50501@ntoll.org> <5620EF78.1050105@hastings.org> <56211E5B.1080803@ntoll.org> <56218DF5.1060504@hastings.org> Message-ID: <5623B2E3.90504@ntoll.org> Hi Larry, Here's the current situation: * Anything in the public domain is repeatable, for example, anything I said during my presentation at PyCon UK. * On Monday, we hope to be able to open up our MicroPython repository for all the micro:bit specific things. This is SUBJECT TO CONFIRMATION but my weekend has been spent preparing various blog posts etc... ready for this. * Anything *you* produce yourself is yours and you can do what you want with it! Basically, the BBC would love positive publicity. The more tweets you can generate that mention microbit, the BBC and MicroPython in a positive framing the better! The PSF is part of a partnership so it is important to frame the device in this context. It would be a terrible faux-pas to claim we're sole "platform" for the device (i.e. there's Microsoft's TouchDevelop). Does this make sense? Happy to answer questions or offer clarifications. Best wishes, Nicholas. On 17/10/15 00:53, Larry Hastings wrote: > On 10/16/2015 08:57 AM, Nicholas H.Tollervey wrote: >> Understood... this is why I'm pushing the BBC so hard to allow us to >> work in the open. There is bound to be someone, somewhere who could help. > > That reminds me. What is the rule that is going to keep people happy > wrt to showing the micro:bit in public? About a week from now I'll be > at PyCon Ireland with my micro:bit, and last I heard Mark Shannon is > going too (and I bet he'd bring his too). I plan to sprint on the > micro:bit while there. I could also give a lightning talk, holding the > little darling up in front of the crowd. I could let folks gawk at it > and hold it and press its darling little buttons, maybe even play a game > of slalom. Is that all okay? Or do I need to cower from the light, > programming it in secret, snarling at passersby to leave my precious alone? > > Seeking guidance, > > > //arry/ > > > _______________________________________________ > 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: From damien.p.george at gmail.com Tue Oct 20 01:06:19 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 20 Oct 2015 00:06:19 +0100 Subject: [Microbit-Python] Update to the music API specification In-Reply-To: <2B53D675-1EAB-48C1-A7AC-5860CFFDE799@gmail.com> References: <56201104.1040104@ntoll.org> <2B53D675-1EAB-48C1-A7AC-5860CFFDE799@gmail.com> Message-ID: I updated the code to combine "note" and "tune" into the single "play" function. But I now see a problem: since reset is called before "play" starts playing, there is no way to change the tempo! There is now no use for get_tempo and set_tempo! Or am I missing something? So I think "play" should reset only the default octave and duration of a note, but not the tempo parameters. On Thu, Oct 15, 2015 at 9:58 PM, Matthew Else wrote: > Hi Nicholas > > I started having a look at non-blocking a day or two ago, but since then I?ve been dealing with uni work/lectures/university shenanigans - I should have some free time tomorrow afternoon, so I?ll try and get it done then. From what I can tell, it shouldn?t be particularly taxing, it?s just a matter of working out where we can and can?t get away with simplifying things to save on RAM in some cases. > > Matthew > > > > On 15/10/2015, 21:48, "Microbit on behalf of Nicholas H.Tollervey" wrote: > >>Hi Folks, >> >>As promised I've updated the music API specification to reflect our >>recent stimulating conversations. >> >>The only significant change to the API that'll need fixing is that the >>pin argument is made optional and the "tune" and "note" functions are >>consolidated into a single "play" function. >> >>By the looks of it these are not onerous changes - obviously I >>understand what needs to be done but given my complete lack of C/C++ >>experience I'm unsure how best to go about it since I don't have other >>similar functions upon which to base a solution. Anyone fancy stacking >>this onto my music-updates branch..? >> >>I've also added the Monty Python theme tune because Python programming >>can't have enough MP references (no matter how obvious they appear to be). >> >>Matthew, how's the non-blocking work going..? Once that's in we have a >>complete and rather wonderful music API. >> >>Best wishes, >> >>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 From larry at hastings.org Tue Oct 20 07:38:52 2015 From: larry at hastings.org (Larry Hastings) Date: Tue, 20 Oct 2015 07:38:52 +0200 Subject: [Microbit-Python] Update to the music API specification In-Reply-To: References: <56201104.1040104@ntoll.org> <2B53D675-1EAB-48C1-A7AC-5860CFFDE799@gmail.com> Message-ID: <5625D36C.10001@hastings.org> On 10/20/2015 01:06 AM, Damien George wrote: > I updated the code to combine "note" and "tune" into the single "play" function. > > But I now see a problem: since reset is called before "play" starts > playing, there is no way to change the tempo! There is now no use for > get_tempo and set_tempo! > > Or am I missing something? > > So I think "play" should reset only the default octave and duration of > a note, but not the tempo parameters. And I think tempo should be an argument to play. //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Tue Oct 20 08:36:20 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 20 Oct 2015 07:36:20 +0100 Subject: [Microbit-Python] Update to the music API specification In-Reply-To: <5625D36C.10001@hastings.org> References: <56201104.1040104@ntoll.org> <2B53D675-1EAB-48C1-A7AC-5860CFFDE799@gmail.com> <5625D36C.10001@hastings.org> Message-ID: <5625E0E4.3000507@ntoll.org> On 20/10/15 06:38, Larry Hastings wrote: > > > On 10/20/2015 01:06 AM, Damien George wrote: >> I updated the code to combine "note" and "tune" into the single "play" function. >> >> But I now see a problem: since reset is called before "play" starts >> playing, there is no way to change the tempo! There is now no use for >> get_tempo and set_tempo! >> >> Or am I missing something? >> >> So I think "play" should reset only the default octave and duration of >> a note, but not the tempo parameters. > > And I think tempo should be an argument to play. > Damien, yes. Larry, as optional arguments, yes. When I get the chance, I'll update the wiki. N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ntoll at ntoll.org Tue Oct 20 09:46:48 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 20 Oct 2015 08:46:48 +0100 Subject: [Microbit-Python] Open sourcing the code Message-ID: <5625F168.8050707@ntoll.org> Hi Folks, We're very please that the BBC have finally allowed us to open source our repos. As a result we're going to have to change the permissions on it now that it's vaguely public. The new repository is here: https://github.com/bbcmicrobit/micropython Its hosted under the auspices of the BBC because that gives us legitimacy and acknowledges we're actually part of the "official" micro:bit effort (which we've always been, but because of NDA have been unable to talk about). Damien has announced MicroPython's involvement in the project here: http://forum.micropython.org/viewtopic.php?f=8&t=1042 I have blogged the historical context here: http://ntoll.org/article/story-micropython-on-microbit I'll be submitting something to tech news places later. Here's hoping people get interested. As a starter, here's the link to my submission on Hacker News: https://news.ycombinator.com/item?id=10417919 Please up-vote..! Because we're now "open" we're going to use the standard GitHub fork->branch->PR methodology that people are used to. Ergo, we're going to revoke push access for everyone except for Damien (and probably me as backup) - who will act as official gatekeeper. Please fork the repos! If this is a real pain in the neck for you we'll re-add you if you let us know. Best wishes, Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mark at hotpy.org Tue Oct 20 20:34:04 2015 From: mark at hotpy.org (Mark Shannon) Date: Tue, 20 Oct 2015 19:34:04 +0100 Subject: [Microbit-Python] Open sourcing the code In-Reply-To: <5625F168.8050707@ntoll.org> References: <5625F168.8050707@ntoll.org> Message-ID: <5626891C.1050008@hotpy.org> On 20/10/15 08:46, Nicholas H.Tollervey wrote: > Hi Folks, > > We're very please that the BBC have finally allowed us to open source > our repos. As a result we're going to have to change the permissions on > it now that it's vaguely public. > > The new repository is here: > > https://github.com/bbcmicrobit/micropython > > Its hosted under the auspices of the BBC because that gives us > legitimacy and acknowledges we're actually part of the "official" > micro:bit effort (which we've always been, but because of NDA have been > unable to talk about). > > Damien has announced MicroPython's involvement in the project here: > > http://forum.micropython.org/viewtopic.php?f=8&t=1042 > > I have blogged the historical context here: > > http://ntoll.org/article/story-micropython-on-microbit > > I'll be submitting something to tech news places later. Here's hoping > people get interested. As a starter, here's the link to my submission on > Hacker News: > > https://news.ycombinator.com/item?id=10417919 > > Please up-vote..! > > Because we're now "open" we're going to use the standard GitHub > fork->branch->PR methodology that people are used to. Aren't we already doing that? Ergo, we're going > to revoke push access for everyone except for Damien (and probably me as > backup) - who will act as official gatekeeper. Given that this is a nominally a BBC and/or PSF project (please correct me if I'm wrong) wouldn't be better if we had a flatter hierarchy. What I would suggest is that most people should have push access, but that everyone (including Damien and yourself) should submit PRs which are then merged by the reviewer. That way all code gets at least two pairs of eyes on it before it is merged. I'm happy to review any PRs. > > Please fork the repos! > > If this is a real pain in the neck for you we'll re-add you if you let > us know. > > Best wishes, > > Nicholas. > Cheers, Mark. From damien.p.george at gmail.com Wed Oct 21 00:21:34 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 20 Oct 2015 23:21:34 +0100 Subject: [Microbit-Python] Open sourcing the code In-Reply-To: <5626891C.1050008@hotpy.org> References: <5625F168.8050707@ntoll.org> <5626891C.1050008@hotpy.org> Message-ID: Hi Mark, We can't have too flat a hierarchy because then we'd lose control. Who/what do you mean by "most" in "most people should have push access"? The great thing about git(hub) is that anyone can clone the repo and hack on it themselves, without concent from the original author(s)/owner(s). And then they can use such firmware on their microbit. Also, the real issue here is that the firmware generated from bbcmicrobit/micropython will be the firmware that kids use, and so it needs strict control as to what is commited. That's going to be the controlling factor when it comes to push rights. Cheers, Damien. On Tue, Oct 20, 2015 at 7:34 PM, Mark Shannon wrote: > > > On 20/10/15 08:46, Nicholas H.Tollervey wrote: >> >> Hi Folks, >> >> We're very please that the BBC have finally allowed us to open source >> our repos. As a result we're going to have to change the permissions on >> it now that it's vaguely public. >> >> The new repository is here: >> >> https://github.com/bbcmicrobit/micropython >> >> Its hosted under the auspices of the BBC because that gives us >> legitimacy and acknowledges we're actually part of the "official" >> micro:bit effort (which we've always been, but because of NDA have been >> unable to talk about). >> >> Damien has announced MicroPython's involvement in the project here: >> >> http://forum.micropython.org/viewtopic.php?f=8&t=1042 >> >> I have blogged the historical context here: >> >> http://ntoll.org/article/story-micropython-on-microbit >> >> I'll be submitting something to tech news places later. Here's hoping >> people get interested. As a starter, here's the link to my submission on >> Hacker News: >> >> https://news.ycombinator.com/item?id=10417919 >> >> Please up-vote..! >> >> Because we're now "open" we're going to use the standard GitHub >> fork->branch->PR methodology that people are used to. > > > Aren't we already doing that? > > Ergo, we're going >> >> to revoke push access for everyone except for Damien (and probably me as >> backup) - who will act as official gatekeeper. > > > Given that this is a nominally a BBC and/or PSF project (please correct me > if I'm wrong) wouldn't be better if we had a flatter hierarchy. > What I would suggest is that most people should have push access, but that > everyone (including Damien and yourself) should submit PRs which are then > merged by the reviewer. > That way all code gets at least two pairs of eyes on it before it is merged. > > I'm happy to review any PRs. > >> >> Please fork the repos! >> >> If this is a real pain in the neck for you we'll re-add you if you let >> us know. >> >> Best wishes, >> >> Nicholas. >> > > Cheers, > Mark. > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit From mark at hotpy.org Wed Oct 21 00:29:58 2015 From: mark at hotpy.org (Mark Shannon) Date: Tue, 20 Oct 2015 23:29:58 +0100 Subject: [Microbit-Python] Open sourcing the code In-Reply-To: References: <5625F168.8050707@ntoll.org> <5626891C.1050008@hotpy.org> Message-ID: <5626C066.3060708@hotpy.org> Hi Damien, The way GitHub works is that in order to review and then merge code, the reviewer needs push rights. As I said, I don't think anyone should merge their own code. Ideally all code gets reviewed and merged by someone other than the author, after all we can all make mistakes. But to do that, you need to give more people push access. A bit of trust goes a long way. Cheers, Mark. On 20/10/15 23:21, Damien George wrote: > Hi Mark, > > We can't have too flat a hierarchy because then we'd lose control. > Who/what do you mean by "most" in "most people should have push > access"? > > The great thing about git(hub) is that anyone can clone the repo and > hack on it themselves, without concent from the original > author(s)/owner(s). And then they can use such firmware on their > microbit. > > Also, the real issue here is that the firmware generated from > bbcmicrobit/micropython will be the firmware that kids use, and so it > needs strict control as to what is commited. That's going to be the > controlling factor when it comes to push rights. > > Cheers, > Damien. > > > > > On Tue, Oct 20, 2015 at 7:34 PM, Mark Shannon wrote: >> >> >> On 20/10/15 08:46, Nicholas H.Tollervey wrote: >>> >>> Hi Folks, >>> >>> We're very please that the BBC have finally allowed us to open source >>> our repos. As a result we're going to have to change the permissions on >>> it now that it's vaguely public. >>> >>> The new repository is here: >>> >>> https://github.com/bbcmicrobit/micropython >>> >>> Its hosted under the auspices of the BBC because that gives us >>> legitimacy and acknowledges we're actually part of the "official" >>> micro:bit effort (which we've always been, but because of NDA have been >>> unable to talk about). >>> >>> Damien has announced MicroPython's involvement in the project here: >>> >>> http://forum.micropython.org/viewtopic.php?f=8&t=1042 >>> >>> I have blogged the historical context here: >>> >>> http://ntoll.org/article/story-micropython-on-microbit >>> >>> I'll be submitting something to tech news places later. Here's hoping >>> people get interested. As a starter, here's the link to my submission on >>> Hacker News: >>> >>> https://news.ycombinator.com/item?id=10417919 >>> >>> Please up-vote..! >>> >>> Because we're now "open" we're going to use the standard GitHub >>> fork->branch->PR methodology that people are used to. >> >> >> Aren't we already doing that? >> >> Ergo, we're going >>> >>> to revoke push access for everyone except for Damien (and probably me as >>> backup) - who will act as official gatekeeper. >> >> >> Given that this is a nominally a BBC and/or PSF project (please correct me >> if I'm wrong) wouldn't be better if we had a flatter hierarchy. >> What I would suggest is that most people should have push access, but that >> everyone (including Damien and yourself) should submit PRs which are then >> merged by the reviewer. >> That way all code gets at least two pairs of eyes on it before it is merged. >> >> I'm happy to review any PRs. >> >>> >>> Please fork the repos! >>> >>> If this is a real pain in the neck for you we'll re-add you if you let >>> us know. >>> >>> Best wishes, >>> >>> Nicholas. >>> >> >> Cheers, >> Mark. >> _______________________________________________ >> 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 > From damien.p.george at gmail.com Wed Oct 21 00:43:45 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 20 Oct 2015 23:43:45 +0100 Subject: [Microbit-Python] Open sourcing the code In-Reply-To: <5626C066.3060708@hotpy.org> References: <5625F168.8050707@ntoll.org> <5626891C.1050008@hotpy.org> <5626C066.3060708@hotpy.org> Message-ID: Hi Mark, I think everyone has their own way of using github in a collaborative way. For example, in MicroPython (upstream) we have 3 people with push rights and we trust each other to just push changes they consider minor, and put larger changes up as a PR for comment/review. Usually then it is the author that merges their own PR after taking feedback. We find this works very well (we have CI to keep us honest) and means we can move very fast with updates and features. I'm happy to use a different work-flow for the microbit, and certainly happy to have you (and others) with push rights. But we need Nicholas' input here regarding the administration side of things. Cheers, Damien. On Tue, Oct 20, 2015 at 11:29 PM, Mark Shannon wrote: > Hi Damien, > > The way GitHub works is that in order to review and then merge code, the > reviewer needs push rights. > > As I said, I don't think anyone should merge their own code. > Ideally all code gets reviewed and merged by someone other than the author, > after all we can all make mistakes. > But to do that, you need to give more people push access. > > A bit of trust goes a long way. > > Cheers, > Mark. > > > > On 20/10/15 23:21, Damien George wrote: >> >> Hi Mark, >> >> We can't have too flat a hierarchy because then we'd lose control. >> Who/what do you mean by "most" in "most people should have push >> access"? >> >> The great thing about git(hub) is that anyone can clone the repo and >> hack on it themselves, without concent from the original >> author(s)/owner(s). And then they can use such firmware on their >> microbit. >> >> Also, the real issue here is that the firmware generated from >> bbcmicrobit/micropython will be the firmware that kids use, and so it >> needs strict control as to what is commited. That's going to be the >> controlling factor when it comes to push rights. >> >> Cheers, >> Damien. >> >> >> >> >> On Tue, Oct 20, 2015 at 7:34 PM, Mark Shannon wrote: >>> >>> >>> >>> On 20/10/15 08:46, Nicholas H.Tollervey wrote: >>>> >>>> >>>> Hi Folks, >>>> >>>> We're very please that the BBC have finally allowed us to open source >>>> our repos. As a result we're going to have to change the permissions on >>>> it now that it's vaguely public. >>>> >>>> The new repository is here: >>>> >>>> https://github.com/bbcmicrobit/micropython >>>> >>>> Its hosted under the auspices of the BBC because that gives us >>>> legitimacy and acknowledges we're actually part of the "official" >>>> micro:bit effort (which we've always been, but because of NDA have been >>>> unable to talk about). >>>> >>>> Damien has announced MicroPython's involvement in the project here: >>>> >>>> http://forum.micropython.org/viewtopic.php?f=8&t=1042 >>>> >>>> I have blogged the historical context here: >>>> >>>> http://ntoll.org/article/story-micropython-on-microbit >>>> >>>> I'll be submitting something to tech news places later. Here's hoping >>>> people get interested. As a starter, here's the link to my submission on >>>> Hacker News: >>>> >>>> https://news.ycombinator.com/item?id=10417919 >>>> >>>> Please up-vote..! >>>> >>>> Because we're now "open" we're going to use the standard GitHub >>>> fork->branch->PR methodology that people are used to. >>> >>> >>> >>> Aren't we already doing that? >>> >>> Ergo, we're going >>>> >>>> >>>> to revoke push access for everyone except for Damien (and probably me as >>>> backup) - who will act as official gatekeeper. >>> >>> >>> >>> Given that this is a nominally a BBC and/or PSF project (please correct >>> me >>> if I'm wrong) wouldn't be better if we had a flatter hierarchy. >>> What I would suggest is that most people should have push access, but >>> that >>> everyone (including Damien and yourself) should submit PRs which are then >>> merged by the reviewer. >>> That way all code gets at least two pairs of eyes on it before it is >>> merged. >>> >>> I'm happy to review any PRs. >>> >>>> >>>> Please fork the repos! >>>> >>>> If this is a real pain in the neck for you we'll re-add you if you let >>>> us know. >>>> >>>> Best wishes, >>>> >>>> Nicholas. >>>> >>> >>> Cheers, >>> Mark. >>> _______________________________________________ >>> 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 From ntoll at ntoll.org Wed Oct 21 00:55:36 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 20 Oct 2015 23:55:36 +0100 Subject: [Microbit-Python] Open sourcing the code In-Reply-To: References: <5625F168.8050707@ntoll.org> <5626891C.1050008@hotpy.org> <5626C066.3060708@hotpy.org> Message-ID: <5626C668.7020008@ntoll.org> Hi Folks, I'm still mid-answering emails after today's announcement. My 2c - I think the biggest blocker will be the BBC. Basically, they have lawyers and infosec people who want to audit / know who is responsible for the code. They are (quite rightly) concerned with who has access to the code given that it's such a high profile project for the BBC. A high profile project that includes children. There are all sorts of onerous ramifications if things go wrong. Having some trusted gatekeepers helps our cause in this respect: and I agree that trust goes a long way - but these are lawyers we're dealing with here... ;-) Ergo how about the following middle ground..? Those people who had push rights on this list can have them re-installed if they want them. We appease the BBC because you've already been "let in", as it were, to the circle of trust. This would certainly help mitigate against a low bus factor. Henceforth, if new people want push rights they'll need to prove they are legitimate, capable and ethical contributors. Does that make sense? (It may not, because I've been up since 5am and I still have 10 emails to reply to and I'm feeling a bit frazzled at the moment). As always, I'm more than happy to discuss any/all of the above and move forward in a way so that we achieve a consensus that everyone is happy with. Comments, constructive critique and good ideas are most welcome! Best wishes, N. On 20/10/15 23:43, Damien George wrote: > Hi Mark, > > I think everyone has their own way of using github in a collaborative > way. For example, in MicroPython (upstream) we have 3 people with > push rights and we trust each other to just push changes they consider > minor, and put larger changes up as a PR for comment/review. Usually > then it is the author that merges their own PR after taking feedback. > We find this works very well (we have CI to keep us honest) and means > we can move very fast with updates and features. > > I'm happy to use a different work-flow for the microbit, and certainly > happy to have you (and others) with push rights. But we need > Nicholas' input here regarding the administration side of things. > > Cheers, > Damien. > > > > On Tue, Oct 20, 2015 at 11:29 PM, Mark Shannon wrote: >> Hi Damien, >> >> The way GitHub works is that in order to review and then merge code, the >> reviewer needs push rights. >> >> As I said, I don't think anyone should merge their own code. >> Ideally all code gets reviewed and merged by someone other than the author, >> after all we can all make mistakes. >> But to do that, you need to give more people push access. >> >> A bit of trust goes a long way. >> >> Cheers, >> Mark. >> >> >> >> On 20/10/15 23:21, Damien George wrote: >>> >>> Hi Mark, >>> >>> We can't have too flat a hierarchy because then we'd lose control. >>> Who/what do you mean by "most" in "most people should have push >>> access"? >>> >>> The great thing about git(hub) is that anyone can clone the repo and >>> hack on it themselves, without concent from the original >>> author(s)/owner(s). And then they can use such firmware on their >>> microbit. >>> >>> Also, the real issue here is that the firmware generated from >>> bbcmicrobit/micropython will be the firmware that kids use, and so it >>> needs strict control as to what is commited. That's going to be the >>> controlling factor when it comes to push rights. >>> >>> Cheers, >>> Damien. >>> >>> >>> >>> >>> On Tue, Oct 20, 2015 at 7:34 PM, Mark Shannon wrote: >>>> >>>> >>>> >>>> On 20/10/15 08:46, Nicholas H.Tollervey wrote: >>>>> >>>>> >>>>> Hi Folks, >>>>> >>>>> We're very please that the BBC have finally allowed us to open source >>>>> our repos. As a result we're going to have to change the permissions on >>>>> it now that it's vaguely public. >>>>> >>>>> The new repository is here: >>>>> >>>>> https://github.com/bbcmicrobit/micropython >>>>> >>>>> Its hosted under the auspices of the BBC because that gives us >>>>> legitimacy and acknowledges we're actually part of the "official" >>>>> micro:bit effort (which we've always been, but because of NDA have been >>>>> unable to talk about). >>>>> >>>>> Damien has announced MicroPython's involvement in the project here: >>>>> >>>>> http://forum.micropython.org/viewtopic.php?f=8&t=1042 >>>>> >>>>> I have blogged the historical context here: >>>>> >>>>> http://ntoll.org/article/story-micropython-on-microbit >>>>> >>>>> I'll be submitting something to tech news places later. Here's hoping >>>>> people get interested. As a starter, here's the link to my submission on >>>>> Hacker News: >>>>> >>>>> https://news.ycombinator.com/item?id=10417919 >>>>> >>>>> Please up-vote..! >>>>> >>>>> Because we're now "open" we're going to use the standard GitHub >>>>> fork->branch->PR methodology that people are used to. >>>> >>>> >>>> >>>> Aren't we already doing that? >>>> >>>> Ergo, we're going >>>>> >>>>> >>>>> to revoke push access for everyone except for Damien (and probably me as >>>>> backup) - who will act as official gatekeeper. >>>> >>>> >>>> >>>> Given that this is a nominally a BBC and/or PSF project (please correct >>>> me >>>> if I'm wrong) wouldn't be better if we had a flatter hierarchy. >>>> What I would suggest is that most people should have push access, but >>>> that >>>> everyone (including Damien and yourself) should submit PRs which are then >>>> merged by the reviewer. >>>> That way all code gets at least two pairs of eyes on it before it is >>>> merged. >>>> >>>> I'm happy to review any PRs. >>>> >>>>> >>>>> Please fork the repos! >>>>> >>>>> If this is a real pain in the neck for you we'll re-add you if you let >>>>> us know. >>>>> >>>>> Best wishes, >>>>> >>>>> Nicholas. >>>>> >>>> >>>> Cheers, >>>> Mark. >>>> _______________________________________________ >>>> 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 > _______________________________________________ > 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: From david at thinkingbinaries.com Wed Oct 21 00:56:24 2015 From: david at thinkingbinaries.com (David Whale) Date: Tue, 20 Oct 2015 23:56:24 +0100 Subject: [Microbit-Python] Open sourcing the code In-Reply-To: References: <5625F168.8050707@ntoll.org> <5626891C.1050008@hotpy.org> Message-ID: Two questions: 1. Is there any sort of auto test harness? i.e. how do we know if a PR has broken something else that was once working? 2. is there a cache of 'recent known good' micro python hex files, for those of us who don't really want to install all the tools but still want to follow along at a slower pace? D ___________________________________________________________ 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 20 October 2015 at 23:21, Damien George wrote: > Hi Mark, > > We can't have too flat a hierarchy because then we'd lose control. > Who/what do you mean by "most" in "most people should have push > access"? > > The great thing about git(hub) is that anyone can clone the repo and > hack on it themselves, without concent from the original > author(s)/owner(s). And then they can use such firmware on their > microbit. > > Also, the real issue here is that the firmware generated from > bbcmicrobit/micropython will be the firmware that kids use, and so it > needs strict control as to what is commited. That's going to be the > controlling factor when it comes to push rights. > > Cheers, > Damien. > > > > > On Tue, Oct 20, 2015 at 7:34 PM, Mark Shannon wrote: > > > > > > On 20/10/15 08:46, Nicholas H.Tollervey wrote: > >> > >> Hi Folks, > >> > >> We're very please that the BBC have finally allowed us to open source > >> our repos. As a result we're going to have to change the permissions on > >> it now that it's vaguely public. > >> > >> The new repository is here: > >> > >> https://github.com/bbcmicrobit/micropython > >> > >> Its hosted under the auspices of the BBC because that gives us > >> legitimacy and acknowledges we're actually part of the "official" > >> micro:bit effort (which we've always been, but because of NDA have been > >> unable to talk about). > >> > >> Damien has announced MicroPython's involvement in the project here: > >> > >> http://forum.micropython.org/viewtopic.php?f=8&t=1042 > >> > >> I have blogged the historical context here: > >> > >> http://ntoll.org/article/story-micropython-on-microbit > >> > >> I'll be submitting something to tech news places later. Here's hoping > >> people get interested. As a starter, here's the link to my submission on > >> Hacker News: > >> > >> https://news.ycombinator.com/item?id=10417919 > >> > >> Please up-vote..! > >> > >> Because we're now "open" we're going to use the standard GitHub > >> fork->branch->PR methodology that people are used to. > > > > > > Aren't we already doing that? > > > > Ergo, we're going > >> > >> to revoke push access for everyone except for Damien (and probably me as > >> backup) - who will act as official gatekeeper. > > > > > > Given that this is a nominally a BBC and/or PSF project (please correct > me > > if I'm wrong) wouldn't be better if we had a flatter hierarchy. > > What I would suggest is that most people should have push access, but > that > > everyone (including Damien and yourself) should submit PRs which are then > > merged by the reviewer. > > That way all code gets at least two pairs of eyes on it before it is > merged. > > > > I'm happy to review any PRs. > > > >> > >> Please fork the repos! > >> > >> If this is a real pain in the neck for you we'll re-add you if you let > >> us know. > >> > >> Best wishes, > >> > >> Nicholas. > >> > > > > Cheers, > > Mark. > > _______________________________________________ > > 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: From damien.p.george at gmail.com Wed Oct 21 01:12:51 2015 From: damien.p.george at gmail.com (Damien George) Date: Wed, 21 Oct 2015 00:12:51 +0100 Subject: [Microbit-Python] Open sourcing the code In-Reply-To: References: <5625F168.8050707@ntoll.org> <5626891C.1050008@hotpy.org> Message-ID: Hi David, 1. There is no test harness, nor any tests! The problem with CI is that it'd need to use yotta, and would need access (somehow) to the private lancaster-dal repos. Also, it's hard to test the code automatically unless we have a microbit simulator, some dummy/mock C++ harness, or a physical microbit connected to some server which undergoes tests. All the MicroPython core is tested (with test coverage) upstream. So what remains is the microbit API. 2. Yes it would be great to have firmware available. Being conservative, I don't know exactly what we are allowed to make public (eg can we have firmware.hex sitting somewhere public?) so don't know the best place to put such firmware. I'd be happy to have it available from micropython.org/microbit/firmware.hex (or similar) if that was allowed under the NDA. Cheers, Damien. On Tue, Oct 20, 2015 at 11:56 PM, David Whale wrote: > Two questions: > > 1. Is there any sort of auto test harness? i.e. how do we know if a PR has > broken something else that was once working? > > 2. is there a cache of 'recent known good' micro python hex files, for those > of us who don't really want to install all the tools but still want to > follow along at a slower pace? > > D > > > > ___________________________________________________________ > 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 20 October 2015 at 23:21, Damien George > wrote: >> >> Hi Mark, >> >> We can't have too flat a hierarchy because then we'd lose control. >> Who/what do you mean by "most" in "most people should have push >> access"? >> >> The great thing about git(hub) is that anyone can clone the repo and >> hack on it themselves, without concent from the original >> author(s)/owner(s). And then they can use such firmware on their >> microbit. >> >> Also, the real issue here is that the firmware generated from >> bbcmicrobit/micropython will be the firmware that kids use, and so it >> needs strict control as to what is commited. That's going to be the >> controlling factor when it comes to push rights. >> >> Cheers, >> Damien. >> >> >> >> >> On Tue, Oct 20, 2015 at 7:34 PM, Mark Shannon wrote: >> > >> > >> > On 20/10/15 08:46, Nicholas H.Tollervey wrote: >> >> >> >> Hi Folks, >> >> >> >> We're very please that the BBC have finally allowed us to open source >> >> our repos. As a result we're going to have to change the permissions on >> >> it now that it's vaguely public. >> >> >> >> The new repository is here: >> >> >> >> https://github.com/bbcmicrobit/micropython >> >> >> >> Its hosted under the auspices of the BBC because that gives us >> >> legitimacy and acknowledges we're actually part of the "official" >> >> micro:bit effort (which we've always been, but because of NDA have been >> >> unable to talk about). >> >> >> >> Damien has announced MicroPython's involvement in the project here: >> >> >> >> http://forum.micropython.org/viewtopic.php?f=8&t=1042 >> >> >> >> I have blogged the historical context here: >> >> >> >> http://ntoll.org/article/story-micropython-on-microbit >> >> >> >> I'll be submitting something to tech news places later. Here's hoping >> >> people get interested. As a starter, here's the link to my submission >> >> on >> >> Hacker News: >> >> >> >> https://news.ycombinator.com/item?id=10417919 >> >> >> >> Please up-vote..! >> >> >> >> Because we're now "open" we're going to use the standard GitHub >> >> fork->branch->PR methodology that people are used to. >> > >> > >> > Aren't we already doing that? >> > >> > Ergo, we're going >> >> >> >> to revoke push access for everyone except for Damien (and probably me >> >> as >> >> backup) - who will act as official gatekeeper. >> > >> > >> > Given that this is a nominally a BBC and/or PSF project (please correct >> > me >> > if I'm wrong) wouldn't be better if we had a flatter hierarchy. >> > What I would suggest is that most people should have push access, but >> > that >> > everyone (including Damien and yourself) should submit PRs which are >> > then >> > merged by the reviewer. >> > That way all code gets at least two pairs of eyes on it before it is >> > merged. >> > >> > I'm happy to review any PRs. >> > >> >> >> >> Please fork the repos! >> >> >> >> If this is a real pain in the neck for you we'll re-add you if you let >> >> us know. >> >> >> >> Best wishes, >> >> >> >> Nicholas. >> >> >> > >> > Cheers, >> > Mark. >> > _______________________________________________ >> > 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 > From ntoll at ntoll.org Wed Oct 21 01:14:11 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Wed, 21 Oct 2015 00:14:11 +0100 Subject: [Microbit-Python] Open sourcing the code In-Reply-To: References: <5625F168.8050707@ntoll.org> <5626891C.1050008@hotpy.org> Message-ID: <5626CAC3.7070100@ntoll.org> On 21/10/15 00:12, Damien George wrote: > 2. Yes it would be great to have firmware available. Being > conservative, I don't know exactly what we are allowed to make public > (eg can we have firmware.hex sitting somewhere public?) so don't know > the best place to put such firmware. I'd be happy to have it > available from micropython.org/microbit/firmware.hex (or similar) if > that was allowed under the NDA. I'll check and report back. N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From sparks.m at gmail.com Wed Oct 21 01:39:17 2015 From: sparks.m at gmail.com (Michael) Date: Wed, 21 Oct 2015 00:39:17 +0100 Subject: [Microbit-Python] Open sourcing the code In-Reply-To: <5626CAC3.7070100@ntoll.org> References: <5625F168.8050707@ntoll.org> <5626891C.1050008@hotpy.org> <5626CAC3.7070100@ntoll.org> Message-ID: For reference, I have a server we could use for this purpose, and would be happy to maintain an access list. Dunno if that makes a difference, but you could mention that. In fact, I have two I could use - one BBC owned/managed - the one we used for the schools' trial, and one I pay for. It's not difficult to manage after all, just an .htaccess, a directory and an htpasswd file. Personally, I think it makes more sense though on micropython.org :-) Michael On 21 October 2015 at 00:14, Nicholas H.Tollervey wrote: > On 21/10/15 00:12, Damien George wrote: > > 2. Yes it would be great to have firmware available. Being > > conservative, I don't know exactly what we are allowed to make public > > (eg can we have firmware.hex sitting somewhere public?) so don't know > > the best place to put such firmware. I'd be happy to have it > > available from micropython.org/microbit/firmware.hex (or similar) if > > that was allowed under the NDA. > > I'll check and report back. > > N. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Wed Oct 21 13:45:34 2015 From: sparks.m at gmail.com (Michael) Date: Wed, 21 Oct 2015 12:45:34 +0100 Subject: [Microbit-Python] A sound related long shot... In-Reply-To: References: <5620EC2F.50501@ntoll.org> <5620EF78.1050105@hastings.org> Message-ID: Hi Damien, Really cool to see this :-) Question - is it possible to get the source for this hex file? I'm very tempted to see what would be necessary to get that phoneme playing code working on microbit, and having your code for this to see where to start would be useful. :) Michael. On 16 October 2015 at 14:48, Damien George wrote: > I have managed to get proper synthesised audio out of the microbit, > using a hand-written PWM loop. As a proof of principle, it can play a > short recorded sample. > > Attached is the firmware. I won't tell you what the sample is, so see > if you can find out! Here are instructions: > > 1. download firmware.hex to the microbit > 2. attach a speaker to pin0 and pin1 (don't use ground) > 3. load up the serial terminal > 4. execute: synth_run(10, 31, 3) > 5. listen in awe! > > You can adjust the numbers passed to synth_run to muck about with the > sample. > > With this we can basically play any audio, from a mod tracker to a > speech synth. The only caveat is that it can't run in the background. > The loop needs full control of the CPU to get the audio to play > properly. > > To answer Nicholas' questions: > > 1. Could this be done? Yes. > 2. Would we want to do it? It would be cool if it (speech synth, or a > mod tracker, or ...) was implemented. > 3. What would need to happen? We need to find someone with the time to > implement it! It's a fair bit of work (but there are no barriers > except time). > > The SAM software would be ideal, if only it were properly licensed. > Otherwise there's a fair bit of work to record all the 49 phonemes, > etc. > > Maybe we can just provide some prerecorded samples (eg "exterminate") > and provide functions to adjust the pitch, echo, etc, and combine > sounds, and then play them? > > D. > > > > > On Fri, Oct 16, 2015 at 1:37 PM, Larry Hastings > wrote: > > > > > > On 10/16/2015 05:23 AM, Nicholas H.Tollervey wrote: > > > > Hi Folks, > > > > So I was thinking about the amazing example Larry posted yesterday of > > the 20yo calculator turned into a multi-part sequencer with effects > etc... > > > > Could we do something just as amazing... would we even want to try..? > > > > Then I remembered - as a child of the 1980s I had an original BBC B at > > home and one of the most amazing feats Superior Software pulled off was > > a 7.5k program called, simply, "Speech!". To give you an idea of what it > > was like I found this on YouTube: > > > > https://www.youtube.com/watch?v=t8wyUsaDAyI > > > > > > The equivalent for computers manufactured outside Britain was "Software > > Automatic Mouth", or "SAM", available for the Apple ][, Atari 400/800, > and > > Commodore 64. > > > > Some enterprising hacker has taken the C=64 version, compiled the > assembler > > into messy C, cleaned it up (some), and put it up on Github: > > > > https://github.com/s-macke/SAM > > > > > > He then used Emscript to translate that into Javascript, and behold: web > > page demo. > > > > http://simulationcorner.net/index.php?page=sam > > > > > > (Aside: cripes, modern computers are fast. Just imagine how awful this > code > > is, and what a Rube Goldberg machine its runtime must be like. Yet it > runs > > in the tiniest fraction of a second.) > > > > So, thoughts..? Is this even possible..? I imagine a very simple API > > such as this: > > > > import microbit > > microbit.say("Hello, World") > > microbit.say("Hello, World", pin=microbit.pin1) # Lke music API > > > > > > Possible, yes. But I don't know anything about voice synthesis, so I > could > > hardly write one myself. And even if SAM is "abandonware", legally > somebody > > still owns the copyright, so I wouldn't ship that specific > implementation. > > > > > > /arry > > > > _______________________________________________ > > 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: From damien.p.george at gmail.com Wed Oct 21 13:53:08 2015 From: damien.p.george at gmail.com (Damien George) Date: Wed, 21 Oct 2015 12:53:08 +0100 Subject: [Microbit-Python] A sound related long shot... In-Reply-To: References: <5620EC2F.50501@ntoll.org> <5620EF78.1050105@hastings.org> Message-ID: Hi Michael, Attached is the synth code and the recorded sample. It's pretty simple, just a PWM loop. The relevant function is synth_run, and this is the one that's exposed to Python. Cheers, Damien. On Wed, Oct 21, 2015 at 12:45 PM, Michael wrote: > Hi Damien, > > > Really cool to see this :-) > > Question - is it possible to get the source for this hex file? I'm very > tempted to see what would be necessary to get that phoneme playing code > working on microbit, and having your code for this to see where to start > would be useful. > > :) > > > Michael. > > On 16 October 2015 at 14:48, Damien George > wrote: >> >> I have managed to get proper synthesised audio out of the microbit, >> using a hand-written PWM loop. As a proof of principle, it can play a >> short recorded sample. >> >> Attached is the firmware. I won't tell you what the sample is, so see >> if you can find out! Here are instructions: >> >> 1. download firmware.hex to the microbit >> 2. attach a speaker to pin0 and pin1 (don't use ground) >> 3. load up the serial terminal >> 4. execute: synth_run(10, 31, 3) >> 5. listen in awe! >> >> You can adjust the numbers passed to synth_run to muck about with the >> sample. >> >> With this we can basically play any audio, from a mod tracker to a >> speech synth. The only caveat is that it can't run in the background. >> The loop needs full control of the CPU to get the audio to play >> properly. >> >> To answer Nicholas' questions: >> >> 1. Could this be done? Yes. >> 2. Would we want to do it? It would be cool if it (speech synth, or a >> mod tracker, or ...) was implemented. >> 3. What would need to happen? We need to find someone with the time to >> implement it! It's a fair bit of work (but there are no barriers >> except time). >> >> The SAM software would be ideal, if only it were properly licensed. >> Otherwise there's a fair bit of work to record all the 49 phonemes, >> etc. >> >> Maybe we can just provide some prerecorded samples (eg "exterminate") >> and provide functions to adjust the pitch, echo, etc, and combine >> sounds, and then play them? >> >> D. >> >> >> >> >> On Fri, Oct 16, 2015 at 1:37 PM, Larry Hastings >> wrote: >> > >> > >> > On 10/16/2015 05:23 AM, Nicholas H.Tollervey wrote: >> > >> > Hi Folks, >> > >> > So I was thinking about the amazing example Larry posted yesterday of >> > the 20yo calculator turned into a multi-part sequencer with effects >> > etc... >> > >> > Could we do something just as amazing... would we even want to try..? >> > >> > Then I remembered - as a child of the 1980s I had an original BBC B at >> > home and one of the most amazing feats Superior Software pulled off was >> > a 7.5k program called, simply, "Speech!". To give you an idea of what it >> > was like I found this on YouTube: >> > >> > https://www.youtube.com/watch?v=t8wyUsaDAyI >> > >> > >> > The equivalent for computers manufactured outside Britain was "Software >> > Automatic Mouth", or "SAM", available for the Apple ][, Atari 400/800, >> > and >> > Commodore 64. >> > >> > Some enterprising hacker has taken the C=64 version, compiled the >> > assembler >> > into messy C, cleaned it up (some), and put it up on Github: >> > >> > https://github.com/s-macke/SAM >> > >> > >> > He then used Emscript to translate that into Javascript, and behold: web >> > page demo. >> > >> > http://simulationcorner.net/index.php?page=sam >> > >> > >> > (Aside: cripes, modern computers are fast. Just imagine how awful this >> > code >> > is, and what a Rube Goldberg machine its runtime must be like. Yet it >> > runs >> > in the tiniest fraction of a second.) >> > >> > So, thoughts..? Is this even possible..? I imagine a very simple API >> > such as this: >> > >> > import microbit >> > microbit.say("Hello, World") >> > microbit.say("Hello, World", pin=microbit.pin1) # Lke music API >> > >> > >> > Possible, yes. But I don't know anything about voice synthesis, so I >> > could >> > hardly write one myself. And even if SAM is "abandonware", legally >> > somebody >> > still owns the copyright, so I wouldn't ship that specific >> > implementation. >> > >> > >> > /arry >> > >> > _______________________________________________ >> > 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 -------------- A non-text attachment was scrubbed... Name: synth.c Type: text/x-csrc Size: 20724 bytes Desc: not available URL: From sparks.m at gmail.com Wed Oct 21 13:58:05 2015 From: sparks.m at gmail.com (Michael) Date: Wed, 21 Oct 2015 12:58:05 +0100 Subject: [Microbit-Python] A sound related long shot... In-Reply-To: References: <5620EC2F.50501@ntoll.org> <5620EF78.1050105@hastings.org> Message-ID: Cool. I'll see what I can do :-) Michael. On 21 October 2015 at 12:53, Damien George wrote: > Hi Michael, > > Attached is the synth code and the recorded sample. > > It's pretty simple, just a PWM loop. The relevant function is > synth_run, and this is the one that's exposed to Python. > > Cheers, > Damien. > > > > On Wed, Oct 21, 2015 at 12:45 PM, Michael wrote: > > Hi Damien, > > > > > > Really cool to see this :-) > > > > Question - is it possible to get the source for this hex file? I'm very > > tempted to see what would be necessary to get that phoneme playing code > > working on microbit, and having your code for this to see where to start > > would be useful. > > > > :) > > > > > > Michael. > > > > On 16 October 2015 at 14:48, Damien George > > wrote: > >> > >> I have managed to get proper synthesised audio out of the microbit, > >> using a hand-written PWM loop. As a proof of principle, it can play a > >> short recorded sample. > >> > >> Attached is the firmware. I won't tell you what the sample is, so see > >> if you can find out! Here are instructions: > >> > >> 1. download firmware.hex to the microbit > >> 2. attach a speaker to pin0 and pin1 (don't use ground) > >> 3. load up the serial terminal > >> 4. execute: synth_run(10, 31, 3) > >> 5. listen in awe! > >> > >> You can adjust the numbers passed to synth_run to muck about with the > >> sample. > >> > >> With this we can basically play any audio, from a mod tracker to a > >> speech synth. The only caveat is that it can't run in the background. > >> The loop needs full control of the CPU to get the audio to play > >> properly. > >> > >> To answer Nicholas' questions: > >> > >> 1. Could this be done? Yes. > >> 2. Would we want to do it? It would be cool if it (speech synth, or a > >> mod tracker, or ...) was implemented. > >> 3. What would need to happen? We need to find someone with the time to > >> implement it! It's a fair bit of work (but there are no barriers > >> except time). > >> > >> The SAM software would be ideal, if only it were properly licensed. > >> Otherwise there's a fair bit of work to record all the 49 phonemes, > >> etc. > >> > >> Maybe we can just provide some prerecorded samples (eg "exterminate") > >> and provide functions to adjust the pitch, echo, etc, and combine > >> sounds, and then play them? > >> > >> D. > >> > >> > >> > >> > >> On Fri, Oct 16, 2015 at 1:37 PM, Larry Hastings > >> wrote: > >> > > >> > > >> > On 10/16/2015 05:23 AM, Nicholas H.Tollervey wrote: > >> > > >> > Hi Folks, > >> > > >> > So I was thinking about the amazing example Larry posted yesterday of > >> > the 20yo calculator turned into a multi-part sequencer with effects > >> > etc... > >> > > >> > Could we do something just as amazing... would we even want to try..? > >> > > >> > Then I remembered - as a child of the 1980s I had an original BBC B at > >> > home and one of the most amazing feats Superior Software pulled off > was > >> > a 7.5k program called, simply, "Speech!". To give you an idea of what > it > >> > was like I found this on YouTube: > >> > > >> > https://www.youtube.com/watch?v=t8wyUsaDAyI > >> > > >> > > >> > The equivalent for computers manufactured outside Britain was > "Software > >> > Automatic Mouth", or "SAM", available for the Apple ][, Atari 400/800, > >> > and > >> > Commodore 64. > >> > > >> > Some enterprising hacker has taken the C=64 version, compiled the > >> > assembler > >> > into messy C, cleaned it up (some), and put it up on Github: > >> > > >> > https://github.com/s-macke/SAM > >> > > >> > > >> > He then used Emscript to translate that into Javascript, and behold: > web > >> > page demo. > >> > > >> > http://simulationcorner.net/index.php?page=sam > >> > > >> > > >> > (Aside: cripes, modern computers are fast. Just imagine how awful > this > >> > code > >> > is, and what a Rube Goldberg machine its runtime must be like. Yet it > >> > runs > >> > in the tiniest fraction of a second.) > >> > > >> > So, thoughts..? Is this even possible..? I imagine a very simple API > >> > such as this: > >> > > >> > import microbit > >> > microbit.say("Hello, World") > >> > microbit.say("Hello, World", pin=microbit.pin1) # Lke music API > >> > > >> > > >> > Possible, yes. But I don't know anything about voice synthesis, so I > >> > could > >> > hardly write one myself. And even if SAM is "abandonware", legally > >> > somebody > >> > still owns the copyright, so I wouldn't ship that specific > >> > implementation. > >> > > >> > > >> > /arry > >> > > >> > _______________________________________________ > >> > 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 > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Thu Oct 22 08:54:54 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 22 Oct 2015 07:54:54 +0100 Subject: [Microbit-Python] Making this list public Message-ID: <5628883E.8070208@ntoll.org> Hi Folks, Given the amount of interest in this work now that we've announced it as "open" I think we should welcome the wider world to this mailing list. Before we do I'd like to discuss it a little. I'd like your opinion on two things: 1) Do you agree that we should open the mailing list. 2) If not open this mailing list, perhaps we could create another one (micropython at python.org..?????) Thoughts. N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mail at timgolden.me.uk Thu Oct 22 11:07:56 2015 From: mail at timgolden.me.uk (Tim Golden) Date: Thu, 22 Oct 2015 10:07:56 +0100 Subject: [Microbit-Python] Making this list public In-Reply-To: <5628883E.8070208@ntoll.org> References: <5628883E.8070208@ntoll.org> Message-ID: <5628A76C.7030102@timgolden.me.uk> On 22/10/2015 07:54, Nicholas H.Tollervey wrote: > Hi Folks, > > Given the amount of interest in this work now that we've announced it as > "open" I think we should welcome the wider world to this mailing list. > > Before we do I'd like to discuss it a little. I'd like your opinion on > two things: > > 1) Do you agree that we should open the mailing list. > 2) If not open this mailing list, perhaps we could create another one > (micropython at python.org..?????) Without feeling strongly, I'd rather regard this list as prehistory and start a new one. TJG From mark at hotpy.org Thu Oct 22 11:27:46 2015 From: mark at hotpy.org (Mark Shannon) Date: Thu, 22 Oct 2015 10:27:46 +0100 Subject: [Microbit-Python] Making this list public In-Reply-To: <5628A76C.7030102@timgolden.me.uk> References: <5628883E.8070208@ntoll.org> <5628A76C.7030102@timgolden.me.uk> Message-ID: <5628AC12.6080309@hotpy.org> 1. Yes 2. Don't care On 22/10/15 10:07, Tim Golden wrote: > On 22/10/2015 07:54, Nicholas H.Tollervey wrote: >> Hi Folks, >> >> Given the amount of interest in this work now that we've announced it as >> "open" I think we should welcome the wider world to this mailing list. >> >> Before we do I'd like to discuss it a little. I'd like your opinion on >> two things: >> >> 1) Do you agree that we should open the mailing list. >> 2) If not open this mailing list, perhaps we could create another one >> (micropython at python.org..?????) > > Without feeling strongly, I'd rather regard this list as prehistory and > start a new one. > > TJG > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From sparks.m at gmail.com Thu Oct 22 11:56:13 2015 From: sparks.m at gmail.com (Michael) Date: Thu, 22 Oct 2015 10:56:13 +0100 Subject: [Microbit-Python] Making this list public In-Reply-To: <5628883E.8070208@ntoll.org> References: <5628883E.8070208@ntoll.org> Message-ID: On 22 October 2015 at 07:54, Nicholas H.Tollervey wrote: > Hi Folks, > > Given the amount of interest in this work now that we've announced it as > "open" I think we should welcome the wider world to this mailing list. > > Before we do I'd like to discuss it a little. I'd like your opinion on > two things: > > 1) Do you agree that we should open the mailing list. > Strong +1 > 2) If not open this mailing list, perhaps we could create another one > (micropython at python.org..?????) > -0 on micropython at python.org Two main reasons: * Archives are useful - we established early on that opening this list up might well happen, and this list documents a lot of decisions taken. That's valuable IME for anyone joining. * The other is on the name - micropython is a more important project that just micropython for micro:bit. It predates micro:bit, and eventually all hardware platforms die, but languages tend to survive. It's a small, clean efficient implementation of python, and I can see there being genuine utility *at some point* for micropython at python.org - and that being dedicated to micropython in general For example, it's entirely plausible to imagine a scenario where ARM or an ARM vendor decide to put a couple of hundred Cortex M0 style processors on a single chip. Programming all of those using python would be quite nice, and micropython could sit there, one per chip, all working together. I've no idea if that's something they'd do, but it's a plausible scenario at some point. Since that's hypothetical, that's why I'm -0 on this. The archives thing I do think matters and is a good thing and I feel a bit stronger about. As an example - in the past couple of years I've tried repeatedly to identify the person who designed the BBC Owl logo from the BBC Micro campaign. (For various reasons). It's been surprisingly difficult. I think I've narrowed it down to a handful of possible people, but it's not as simple as you'd expect. Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Thu Oct 22 12:41:55 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 22 Oct 2015 11:41:55 +0100 Subject: [Microbit-Python] Making this list public In-Reply-To: References: <5628883E.8070208@ntoll.org> Message-ID: <5628BD73.4050309@ntoll.org> OK... I'll leave things until the weekend when I'll make the list public (which is what people appear to want given the replies so far) unless there are strong objections. Just managing expectations of timeline and outcome. BTW, I'd love to know who designed the owl logo. Can this be put into the public domain or something "re-usable"..? N. On 22/10/15 10:56, Michael wrote: > On 22 October 2015 at 07:54, Nicholas H.Tollervey > wrote: > > Hi Folks, > > Given the amount of interest in this work now that we've announced it as > "open" I think we should welcome the wider world to this mailing list. > > Before we do I'd like to discuss it a little. I'd like your opinion on > two things: > > 1) Do you agree that we should open the mailing list. > > > Strong +1 > > > 2) If not open this mailing list, perhaps we could create another one > (micropython at python.org..?????) > > > -0 on micropython at python.org > > Two main reasons: > > * Archives are useful - we established early on that opening this list up > might well happen, and this list documents a lot of decisions taken. > That's valuable IME for anyone joining. > > * The other is on the name - micropython is a more important project that > just micropython for micro:bit. It predates micro:bit, and eventually > all > hardware platforms die, but languages tend to survive. It's a small, clean > efficient implementation of python, and I can see there being genuine > utility *at some point* for micropython at python.org > - and that being > dedicated to micropython in general > > For example, it's entirely plausible to imagine a scenario where ARM or an > ARM vendor decide to put a couple of hundred Cortex M0 style processors on a > single chip. Programming all of those using python would be quite nice, and > micropython could sit there, one per chip, all working together. I've no > idea > if that's something they'd do, but it's a plausible scenario at some point. > > Since that's hypothetical, that's why I'm -0 on this. > > The archives thing I do think matters and is a good thing and I feel a > bit stronger about. As an example - in the past couple of years I've tried > repeatedly to identify the person who designed the BBC Owl logo from > the BBC Micro campaign. (For various reasons). It's been surprisingly > difficult. I think I've narrowed it down to a handful of possible people, > but it's not as simple as you'd expect. > > > > > Michael. > > > _______________________________________________ > 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: From sparks.m at gmail.com Thu Oct 22 13:22:47 2015 From: sparks.m at gmail.com (Michael) Date: Thu, 22 Oct 2015 12:22:47 +0100 Subject: [Microbit-Python] Making this list public In-Reply-To: <5628BD73.4050309@ntoll.org> References: <5628883E.8070208@ntoll.org> <5628BD73.4050309@ntoll.org> Message-ID: On 22 October 2015 at 11:41, Nicholas H.Tollervey wrote: > OK... I'll leave things until the weekend when I'll make the list public > (which is what people appear to want given the replies so far) unless > there are strong objections. > > Just managing expectations of timeline and outcome. > > BTW, I'd love to know who designed the owl logo. Can this be put into > the public domain or something "re-usable"..? > That was the reason I was trying to hunt down the creator FWIW. The tl;dr version of below is "arrrrrrgggghhhh. dunno? and because of that 'not as far as we know'" :-/ The impression that I've got from various people is that the Owl was design by a full time member of staff who was a designer. (Having chatted to several members of the original team, but confirmation is tricky) If that was the case, it would be relatively simple (in BBC terms...) to get that resolved. That said, it's unknown and not that simple. In a similar way to the fact that any code I write at work is owned by the BBC and I have no rights over (such as the reference/prototype micro:bit implementation), that would mean that the original designer wouldn't own the rights - since the BBC would own the full rights. As a result that would explain why it's tricky to identify the originator. A bit tangentially, but worth explaining: Managing rights at the BBC is an astonishingly complicated thing incidentally. I was once working on a project which required time sync'd metadata as a source, and I ended up using one of the rights databases. The rights for something like the doctor who proms meant that someone would sit with a stop watch, pause button, etc, and watch the final cut. And pretty much much every 2-3 seconds have to note what thing which may have a rights implication (prop, clip from the show, bit of music, star coming on screen, going off screen, etc) would come up. Similarly things like soaps can be problematic due to full screen copies of posters on walls and so on. Printed out, such a document of single line entries, the Doctor Who prom would result in a 80-100 page document. By contrast, something like a 3-4 hour programme on the winter olympics would have a handful of pages - because the people with "rights" in the show would be very few. If you think combining licenses for works based on GPL, Apache and MPL can be tricky, they're MUCH simpler by comparison :-) This focus on recording things correctly, and getting things resolved early has improved an awful lot since the 70's & 80's, but sometimes there can be odd examples that catch out. For example the CD release (in the late 90's I think?) of the original Hitch Hiker's radio serial was *allegedly* delayed because they couldn't find the sound mixer who did the original incidental audio mix. Since they couldn't find them, and that the person was a contractor (who would've been paid for all rights to the radio, tape and vinyl mixes...) they couldn't rely on just being able to use the same mix - so the audio needed to be remixed. Now, how true this is, I don't know - sometimes BBC stories you hear are true or based on truth - I suspect this one is either true or close to what actually happened - either with hitch-hikers or similar. The problem here with the Owl arises,and becomes unclear though, because a lot of designers were also not full time staff members, and whether things like designs were actually owned outright by the BBC can be unclear. Hence the estate of Terry Nation owning the rights to the Daleks, Bob Baker owning K9. (K9 is uncomfortably close in timeline of invention to the owl - which is why I mention it) Anyway, the impression I think everyone has is that based on everyone I've spoken to, people *think* that the Owl logo is owned by the BBC, but no-one is really sure, and that uncertainty is one of the reasons (I think) that it's not used any more, except buried halfway down the page on the BBC internet blog. (http://www.bbc.co.uk/blogs/internet) Given all that, I think it might be clear why some people are more willing to give it a go than others, but you can't give out a license on something you don't own. If you do give out a license on something you don't own, it's an offence (and a much more serious one than just making copies yourself because you think you own the rights). If you're not sure, what do you do? Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Thu Oct 22 13:30:56 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 22 Oct 2015 12:30:56 +0100 Subject: [Microbit-Python] Making this list public In-Reply-To: References: <5628883E.8070208@ntoll.org> <5628BD73.4050309@ntoll.org> Message-ID: <5628C8F0.3060204@ntoll.org> When I was a jobbing freelance musician doing work for the BBC I basically signed away all my rights to anything I did, for ever. I guess this thread just confirms that IP is bonkers. Don't the BBC keep records of this sort of thing..? N. On 22/10/15 12:22, Michael wrote: > On 22 October 2015 at 11:41, Nicholas H.Tollervey > wrote: > > OK... I'll leave things until the weekend when I'll make the list public > (which is what people appear to want given the replies so far) unless > there are strong objections. > > Just managing expectations of timeline and outcome. > > BTW, I'd love to know who designed the owl logo. Can this be put into > the public domain or something "re-usable"..? > > > That was the reason I was trying to hunt down the creator FWIW. > > The tl;dr version of below is "arrrrrrgggghhhh. dunno? and because of > that 'not as far as we know'" :-/ > > The impression that I've got from various people is that the Owl was > design by a full time member of staff who was a designer. (Having > chatted to several members of the original team, but confirmation is > tricky) If that was the case, it would be relatively simple (in BBC > terms...) to get that resolved. That said, it's unknown and not that simple. > > In a similar way to the fact that any code I write at work is owned by > the BBC and I have no rights over (such as the reference/prototype > micro:bit implementation), that would mean that the original designer > wouldn't own the rights - since the BBC would own the full rights. As a > result that would explain why it's tricky to identify the originator. > > A bit tangentially, but worth explaining: > > Managing rights at the BBC is an astonishingly complicated thing > incidentally. I was once working on a project which required time sync'd > metadata as a source, and I ended up using one of the rights databases. > The rights for something like the doctor who proms meant that someone > would sit with a stop watch, pause button, etc, and watch the final cut. > And pretty much much every 2-3 seconds have to note what thing which may > have a rights implication (prop, clip from the show, bit of music, star > coming on screen, going off screen, etc) would come up. Similarly things > like soaps can be problematic due to full screen copies of posters on > walls and so on. > > Printed out, such a document of single line entries, the Doctor Who prom > would result in a 80-100 page document. By contrast, something like a > 3-4 hour programme on the winter olympics would have a handful of pages > - because the people with "rights" in the show would be very few. If you > think combining licenses for works based on GPL, Apache and MPL can be > tricky, they're MUCH simpler by comparison :-) > > This focus on recording things correctly, and getting things resolved > early has improved an awful lot since the 70's & 80's, but sometimes > there can be odd examples that catch out. For example the CD release (in > the late 90's I think?) of the original Hitch Hiker's radio serial was > *allegedly* delayed because they couldn't find the sound mixer who did > the original incidental audio mix. > > Since they couldn't find them, and that the person was a contractor (who > would've been paid for all rights to the radio, tape and vinyl mixes...) > they couldn't rely on just being able to use the same mix - so the audio > needed to be remixed. Now, how true this is, I don't know - sometimes > BBC stories you hear are true or based on truth - I suspect this one is > either true or close to what actually happened - either with > hitch-hikers or similar. > > The problem here with the Owl arises,and becomes unclear though, because > a lot of designers were also not full time staff members, and whether > things like designs were actually owned outright by the BBC can be > unclear. Hence the estate of Terry Nation owning the rights to the > Daleks, Bob Baker owning K9. (K9 is uncomfortably close in timeline of > invention to the owl - which is why I mention it) > > Anyway, the impression I think everyone has is that based on everyone > I've spoken to, people *think* that the Owl logo is owned by the BBC, > but no-one is really sure, and that uncertainty is one of the reasons (I > think) that it's not used any more, except buried halfway down the page > on the BBC internet blog. (http://www.bbc.co.uk/blogs/internet) > > Given all that, I think it might be clear why some people are more > willing to give it a go than others, but you can't give out a license on > something you don't own. If you do give out a license on something you > don't own, it's an offence (and a much more serious one than just making > copies yourself because you think you own the rights). If you're not > sure, what do you do? > > > Michael. > > > _______________________________________________ > 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: From sparks.m at gmail.com Thu Oct 22 13:31:24 2015 From: sparks.m at gmail.com (Michael) Date: Thu, 22 Oct 2015 12:31:24 +0100 Subject: [Microbit-Python] Making this list public In-Reply-To: References: <5628883E.8070208@ntoll.org> <5628BD73.4050309@ntoll.org> Message-ID: To put that into context, I don't like quoting private email, but some relevant fragments from one of the original team members: I managed to locate all the documents on the book, as well as the drafts of the hardware and software specs of the computer. Also drafts of the programmes themselves. However I do have, somewhere, a file with some of the minutes of the meetings, not just the correspondence. The stuff I looked at so far does not even mention the owl. ... PS I do seem to remember that the owl was the logo of BBC Education originally....not sure if that was before or after the Computer programme though. Interesting huh? My impression is that what probably happened is someone said "we need a logo", and someone designed one and they just went "thanks" and moved on. Of course for those of us who grew up in the 80s it's one of *those* logos :-) As a result, it's things like this that make me think that archives are a good thing :-) Michael. [:] On 22 October 2015 at 12:22, Michael wrote: > On 22 October 2015 at 11:41, Nicholas H.Tollervey wrote: > >> OK... I'll leave things until the weekend when I'll make the list public >> (which is what people appear to want given the replies so far) unless >> there are strong objections. >> >> Just managing expectations of timeline and outcome. >> >> BTW, I'd love to know who designed the owl logo. Can this be put into >> the public domain or something "re-usable"..? >> > > That was the reason I was trying to hunt down the creator FWIW. > > The tl;dr version of below is "arrrrrrgggghhhh. dunno? and because of that > 'not as far as we know'" :-/ > > The impression that I've got from various people is that the Owl was > design by a full time member of staff who was a designer. (Having chatted > to several members of the original team, but confirmation is tricky) If > that was the case, it would be relatively simple (in BBC terms...) to get > that resolved. That said, it's unknown and not that simple. > > In a similar way to the fact that any code I write at work is owned by the > BBC and I have no rights over (such as the reference/prototype micro:bit > implementation), that would mean that the original designer wouldn't own > the rights - since the BBC would own the full rights. As a result that > would explain why it's tricky to identify the originator. > > A bit tangentially, but worth explaining: > > Managing rights at the BBC is an astonishingly complicated thing > incidentally. I was once working on a project which required time sync'd > metadata as a source, and I ended up using one of the rights databases. The > rights for something like the doctor who proms meant that someone would sit > with a stop watch, pause button, etc, and watch the final cut. And pretty > much much every 2-3 seconds have to note what thing which may have a rights > implication (prop, clip from the show, bit of music, star coming on screen, > going off screen, etc) would come up. Similarly things like soaps can be > problematic due to full screen copies of posters on walls and so on. > > Printed out, such a document of single line entries, the Doctor Who prom > would result in a 80-100 page document. By contrast, something like a 3-4 > hour programme on the winter olympics would have a handful of pages - > because the people with "rights" in the show would be very few. If you > think combining licenses for works based on GPL, Apache and MPL can be > tricky, they're MUCH simpler by comparison :-) > > This focus on recording things correctly, and getting things resolved > early has improved an awful lot since the 70's & 80's, but sometimes there > can be odd examples that catch out. For example the CD release (in the late > 90's I think?) of the original Hitch Hiker's radio serial was *allegedly* > delayed because they couldn't find the sound mixer who did the original > incidental audio mix. > > Since they couldn't find them, and that the person was a contractor (who > would've been paid for all rights to the radio, tape and vinyl mixes...) > they couldn't rely on just being able to use the same mix - so the audio > needed to be remixed. Now, how true this is, I don't know - sometimes BBC > stories you hear are true or based on truth - I suspect this one is either > true or close to what actually happened - either with hitch-hikers or > similar. > > The problem here with the Owl arises,and becomes unclear though, because a > lot of designers were also not full time staff members, and whether things > like designs were actually owned outright by the BBC can be unclear. Hence > the estate of Terry Nation owning the rights to the Daleks, Bob Baker > owning K9. (K9 is uncomfortably close in timeline of invention to the owl - > which is why I mention it) > > Anyway, the impression I think everyone has is that based on everyone I've > spoken to, people *think* that the Owl logo is owned by the BBC, but no-one > is really sure, and that uncertainty is one of the reasons (I think) that > it's not used any more, except buried halfway down the page on the BBC > internet blog. (http://www.bbc.co.uk/blogs/internet) > > Given all that, I think it might be clear why some people are more willing > to give it a go than others, but you can't give out a license on something > you don't own. If you do give out a license on something you don't own, > it's an offence (and a much more serious one than just making copies > yourself because you think you own the rights). If you're not sure, what do > you do? > > > Michael. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Thu Oct 22 13:44:28 2015 From: damien.p.george at gmail.com (Damien George) Date: Thu, 22 Oct 2015 12:44:28 +0100 Subject: [Microbit-Python] Making this list public In-Reply-To: References: <5628883E.8070208@ntoll.org> <5628BD73.4050309@ntoll.org> Message-ID: I agree with Michael's reasoning, and vote: 1) +1, 2) -1. There's also the option to use forum.micropython.org, and create a sub-topic for microbit. There is already a perfect spot for this, alongside the other boards that run uPy (the pyboard and wipy). But I understand that mailing lists are more convenient for some than forums. On Thu, Oct 22, 2015 at 12:31 PM, Michael wrote: > To put that into context, I don't like quoting private email, but some > relevant fragments from one of the original team members: > > I managed to locate all the documents on the book, as well as > the drafts of the hardware and software specs of the computer. > Also drafts of the programmes themselves. However I do have, > somewhere, a file with some of the minutes of the meetings, not > just the correspondence. The stuff I looked at so far does not even > mention the owl. > ... > PS I do seem to remember that the owl was the logo of BBC Education > originally....not sure if that was before or after the Computer > programme > though. > > Interesting huh? My impression is that what probably happened is someone > said "we need a logo", and someone designed one and they just went "thanks" > and moved on. Of course for those of us who grew up in the 80s it's one of > *those* logos :-) > > As a result, it's things like this that make me think that archives are a > good thing :-) > > > Michael. > [:] > > > > > > On 22 October 2015 at 12:22, Michael wrote: >> >> On 22 October 2015 at 11:41, Nicholas H.Tollervey wrote: >>> >>> OK... I'll leave things until the weekend when I'll make the list public >>> (which is what people appear to want given the replies so far) unless >>> there are strong objections. >>> >>> Just managing expectations of timeline and outcome. >>> >>> BTW, I'd love to know who designed the owl logo. Can this be put into >>> the public domain or something "re-usable"..? >> >> >> That was the reason I was trying to hunt down the creator FWIW. >> >> The tl;dr version of below is "arrrrrrgggghhhh. dunno? and because of that >> 'not as far as we know'" :-/ >> >> The impression that I've got from various people is that the Owl was >> design by a full time member of staff who was a designer. (Having chatted to >> several members of the original team, but confirmation is tricky) If that >> was the case, it would be relatively simple (in BBC terms...) to get that >> resolved. That said, it's unknown and not that simple. >> >> In a similar way to the fact that any code I write at work is owned by the >> BBC and I have no rights over (such as the reference/prototype micro:bit >> implementation), that would mean that the original designer wouldn't own the >> rights - since the BBC would own the full rights. As a result that would >> explain why it's tricky to identify the originator. >> >> A bit tangentially, but worth explaining: >> >> Managing rights at the BBC is an astonishingly complicated thing >> incidentally. I was once working on a project which required time sync'd >> metadata as a source, and I ended up using one of the rights databases. The >> rights for something like the doctor who proms meant that someone would sit >> with a stop watch, pause button, etc, and watch the final cut. And pretty >> much much every 2-3 seconds have to note what thing which may have a rights >> implication (prop, clip from the show, bit of music, star coming on screen, >> going off screen, etc) would come up. Similarly things like soaps can be >> problematic due to full screen copies of posters on walls and so on. >> >> Printed out, such a document of single line entries, the Doctor Who prom >> would result in a 80-100 page document. By contrast, something like a 3-4 >> hour programme on the winter olympics would have a handful of pages - >> because the people with "rights" in the show would be very few. If you think >> combining licenses for works based on GPL, Apache and MPL can be tricky, >> they're MUCH simpler by comparison :-) >> >> This focus on recording things correctly, and getting things resolved >> early has improved an awful lot since the 70's & 80's, but sometimes there >> can be odd examples that catch out. For example the CD release (in the late >> 90's I think?) of the original Hitch Hiker's radio serial was *allegedly* >> delayed because they couldn't find the sound mixer who did the original >> incidental audio mix. >> >> Since they couldn't find them, and that the person was a contractor (who >> would've been paid for all rights to the radio, tape and vinyl mixes...) >> they couldn't rely on just being able to use the same mix - so the audio >> needed to be remixed. Now, how true this is, I don't know - sometimes BBC >> stories you hear are true or based on truth - I suspect this one is either >> true or close to what actually happened - either with hitch-hikers or >> similar. >> >> The problem here with the Owl arises,and becomes unclear though, because a >> lot of designers were also not full time staff members, and whether things >> like designs were actually owned outright by the BBC can be unclear. Hence >> the estate of Terry Nation owning the rights to the Daleks, Bob Baker owning >> K9. (K9 is uncomfortably close in timeline of invention to the owl - which >> is why I mention it) >> >> Anyway, the impression I think everyone has is that based on everyone I've >> spoken to, people *think* that the Owl logo is owned by the BBC, but no-one >> is really sure, and that uncertainty is one of the reasons (I think) that >> it's not used any more, except buried halfway down the page on the BBC >> internet blog. (http://www.bbc.co.uk/blogs/internet) >> >> Given all that, I think it might be clear why some people are more willing >> to give it a go than others, but you can't give out a license on something >> you don't own. If you do give out a license on something you don't own, it's >> an offence (and a much more serious one than just making copies yourself >> because you think you own the rights). If you're not sure, what do you do? >> >> >> Michael. > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From sparks.m at gmail.com Thu Oct 22 13:44:57 2015 From: sparks.m at gmail.com (Michael) Date: Thu, 22 Oct 2015 12:44:57 +0100 Subject: [Microbit-Python] Making this list public In-Reply-To: <5628C8F0.3060204@ntoll.org> References: <5628883E.8070208@ntoll.org> <5628BD73.4050309@ntoll.org> <5628C8F0.3060204@ntoll.org> Message-ID: On 22 October 2015 at 12:30, Nicholas H.Tollervey wrote: > When I was a jobbing freelance musician doing work for the BBC I > basically signed away all my rights to anything I did, for ever. > Yep - they've learnt an awful lot from the transition from analogue media of the pre-90's into digital media from the 90's onwards (well, CD's onwards). My contract is even more rights grabby (which you'd expect) - but means that sometimes I make sure people are aware of personal home projects before they get released, or release them before they're even vaguely useful or usable. (such as pyxie) > I guess this thread just confirms that IP is bonkers. > More bonkers than most people think. It's why I try to stay abreast of any open sourcing discussions at the BBC... > Don't the BBC keep records of this sort of thing..? > Yes - *amazingly* detailed - especially for anything "recent" in BBC terms. (think past 10-20 years at least) The project I referred as a rights database is actually called P4A, and I can't remember what the 4 P's stand for, nor the A, but I do know that a single programme can have *incredibly* detailed rights info. (Down to "in order to use segment from 20 mins 30s to 20 mins 32 seconds, phone this number and ask for...") Retrieval of information from the 70's and 80's (remember the computer literacy project started in the 70's - the BBC micro was a relatively late addition) can be incredibly difficult. Especially if people at the time didn't think a piece of information important, and it's not been important for a long time after (due to the logo not representing an active "thing"). You have to remember after all, in the 70's they were still at the stage where they would record over tapes of TV programmes of the era. It was a different era in many regards. (Back then the idea that the programmes would ever be watched more than once or twice was inconceivable) (The requirement for the BBC to maintain archives for example was added to charters *after* the sort of time period we're talking about, before that they were best practice, and maintained what people though would be important.) Anyway, enough silliness. :-) Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Thu Oct 22 14:42:38 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 22 Oct 2015 13:42:38 +0100 Subject: [Microbit-Python] More news snippets Message-ID: <5628D9BE.9030708@ntoll.org> For your entertainment: A robot forum from Poland: http://forbot.pl/blog/wiadomosci/micropython-na-bbc-microbit-id10006 More significantly, Hackaday features MicroPython: http://hackaday.com/2015/10/20/bbcs-microbit-gets-python/ Enjoy! N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From Jonathan.Austin at arm.com Thu Oct 22 14:48:50 2015 From: Jonathan.Austin at arm.com (Jonathan Austin) Date: Thu, 22 Oct 2015 12:48:50 +0000 Subject: [Microbit-Python] More news snippets In-Reply-To: <5628D9BE.9030708@ntoll.org> References: <5628D9BE.9030708@ntoll.org> Message-ID: Hi all, > On 22 Oct 2015, at 13:42, Nicholas H.Tollervey wrote: > > More significantly, Hackaday features MicroPython: > > http://hackaday.com/2015/10/20/bbcs-microbit-gets-python/ This is totally awesome! I have only one comment - Hackaday has has pushed me over the edge on ?mbed? versus ?mBed?! I?ve been trying not to be ?that guy?, but turns out I am ;) ?mbed? or 'ARM mbed? is the correct way to write mbed. I?m not sure how/where the capital B came from, but it seems once it happens once, everyone follows. /me takes off brand hat /me feels slightly dirty Happy Hacking! Jonny > > Enjoy! > > N. > > _______________________________________________ > 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. From sparks.m at gmail.com Thu Oct 22 14:55:53 2015 From: sparks.m at gmail.com (Michael) Date: Thu, 22 Oct 2015 13:55:53 +0100 Subject: [Microbit-Python] More news snippets In-Reply-To: References: <5628D9BE.9030708@ntoll.org> Message-ID: On 22 October 2015 at 13:48, Jonathan Austin wrote: > Hi all, > > > On 22 Oct 2015, at 13:42, Nicholas H.Tollervey wrote: > > > > More significantly, Hackaday features MicroPython: > > > > http://hackaday.com/2015/10/20/bbcs-microbit-gets-python/ > > This is totally awesome! > Indeed. I have only one comment - Hackaday has has pushed me over the edge on > ?mbed? versus ?mBed?! I?ve been trying not to be ?that guy?, but turns out > I am ;) > > ?mbed? or 'ARM mbed? is the correct way to write mbed. I?m not sure > how/where the capital B came from, but it seems once it happens once, > everyone follows. > I never knew that. I'd always seem mBed everywhere and copied. I now know better :-) Regards, Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Sun Oct 25 17:20:30 2015 From: larry at hastings.org (Larry Hastings) Date: Sun, 25 Oct 2015 21:20:30 +0000 Subject: [Microbit-Python] Which interrupts wake up WFI? Message-ID: <562D479E.6030104@hastings.org> Damien: Mark Shannon and I have been poking around in the DAL the last day or two here at PyCon IE. One question that came up: which interrupts wake up the WFI() function call? Is it just the 6ms system timer interrupt? Or do the display refresh and UART interrupts wake up WFI too? Thanks, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Sun Oct 25 19:54:56 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Sun, 25 Oct 2015 23:54:56 +0000 Subject: [Microbit-Python] Testing 1,2, 3... In-Reply-To: <562D6595.5030309@ntoll.org> References: <562D6595.5030309@ntoll.org> Message-ID: <562D6BD0.5070504@ntoll.org> On 25/10/15 23:28, Nicholas H.Tollervey wrote: > I trust everyone has had a good weekend. Have had reports of bounced > emails. Just checking. Please ignore and apologies for the noise on the > line. > > N. > TEST! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ntoll at ntoll.org Sun Oct 25 19:28:21 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Sun, 25 Oct 2015 23:28:21 +0000 Subject: [Microbit-Python] Testing 1,2, 3... Message-ID: <562D6595.5030309@ntoll.org> I trust everyone has had a good weekend. Have had reports of bounced emails. Just checking. Please ignore and apologies for the noise on the line. N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From guido at python.org Fri Oct 23 11:05:20 2015 From: guido at python.org (Guido van Rossum) Date: Fri, 23 Oct 2015 08:05:20 -0700 Subject: [Microbit-Python] Oxford workshop. In-Reply-To: <5629DCEB.4080808@ntoll.org> References: <5629DCEB.4080808@ntoll.org> Message-ID: Sounds like the structure and organization of micro:bit community events could learn a bit from the checklist DjangoGirls uses for their events. :-) On Fri, Oct 23, 2015 at 12:08 AM, Nicholas H.Tollervey wrote: > Hi Folks, > > Some observations and comments that fall out from the Oxford PUG > workshop I ran yesterday. > > * About 20 people turned up. > > * People love Python (obviously) and are "gunning" for us. This may be a > reflection of the attendees at a Python User Group but I got the > impression that a significant minority were not Pythonistas but had come > along to find out more. > > * Have clear and accurate help docs is important. > > * We have to make it as simple as possible to access MicroPython on the > device. Things I saw: > > - No one read the README's for the editor, repl or MicroPython repos. > - One guy complained he couldn't connect to the REPL without realising > he had to first flash the device. > - Inexperienced users don't understand the difference between a REPL > and code editor. > - USB cables are a big pain point. Several people couldn't connect > their device, spent 1/2 hour faffing about with their computer only to > discover that they had a knackered lead. (This happened twice.) :-( > - Once connected people had a lot of fun. Ergo, getting people > "connected" is a "bump" we should address. > - People really REALLY enjoyed the examples (Mark, your compass was a > big hit). Having a library of existing simple example code to adapt to > your own purposes is A GOOD THING. People feel positive about cutting > and pasting code and then massaging it to something else. > > * A university professor from Australia attended > (sydney.edu.au/engineering/it/about/people/staff/curran.shtml). AFAICT > he's on some sort of secondment to Oxford University and is responsible > for this rather amazing site: https://groklearning.com/ He wants to get > involved. He especially would like to be introduced to Damien and > perhaps say "hello" when he's next in Cambridge visiting the RPi > Foundation. He appears to be the driving force behind Australia's > equivalent to "Make it Digital". He'd like to integrate the MicroPython > / micro:bit offering into GrokLearning. > > * Once people "settled" into the device they were having lots of fun and > enjoyed using MicroPython. > > When I get time over the weekend I'll try to turn the above into user > stories we can work at. > > All the best, > > Nicholas. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Fri Oct 23 17:58:26 2015 From: damien.p.george at gmail.com (Damien George) Date: Fri, 23 Oct 2015 22:58:26 +0100 Subject: [Microbit-Python] Oxford workshop. In-Reply-To: <5629DCEB.4080808@ntoll.org> References: <5629DCEB.4080808@ntoll.org> Message-ID: Hi Nicholas, Great news! (Good news is starting to be a theme around here!) Comments inline below. > * Have clear and accurate help docs is important. Yes, definitely. We need to solidify our API (it's almost there, need gestures) and write some nice docs. > * We have to make it as simple as possible to access MicroPython on the > device. Things I saw: For sure. We've known this from day one. > - No one read the README's for the editor, repl or MicroPython repos. In most cases they shouldn't need to. If you get a REPL, then help() and tab completion will get you most of the way. > - One guy complained he couldn't connect to the REPL without realising > he had to first flash the device. You know what we could do: ask the BBC if they can preinstall MicroPython on all the microbits. Why not? We could include a demo script so they do something fun when you turn them on. And the big benefit is that users can get a REPL straight away. They don't ever need to see the internet in order to do cool stuff. > - Inexperienced users don't understand the difference between a REPL > and code editor. Fair enough. That just needs education. > - USB cables are a big pain point. Several people couldn't connect > their device, spent 1/2 hour faffing about with their computer only to > discover that they had a knackered lead. (This happened twice.) :-( Yeah, I've seen this as well. A lot of micro USB cables are for charging only and don't have data connected. Other cables have dodgy data connections. > - Once connected people had a lot of fun. Ergo, getting people > "connected" is a "bump" we should address. Set-up is always going to be a bump, no matter what the technology. But we can do our best here by providing lots of good docs for all platforms, and easy access to drivers/install programs/etc. > - People really REALLY enjoyed the examples (Mark, your compass was a > big hit). Having a library of existing simple example code to adapt to > your own purposes is A GOOD THING. People feel positive about cutting > and pasting code and then massaging it to something else. Good to hear. We should write more! > * A university professor from Australia attended > (sydney.edu.au/engineering/it/about/people/staff/curran.shtml). AFAICT > he's on some sort of secondment to Oxford University and is responsible > for this rather amazing site: https://groklearning.com/ He wants to get > involved. He especially would like to be introduced to Damien and > perhaps say "hello" when he's next in Cambridge visiting the RPi > Foundation. He appears to be the driving force behind Australia's > equivalent to "Make it Digital". He'd like to integrate the MicroPython > / micro:bit offering into GrokLearning. Wow, that's exciting! Yes I'd definitely be up to meet him and discuss this further. > * Once people "settled" into the device they were having lots of fun and > enjoyed using MicroPython. Ok, great. That means we have done a good job :) You have a few more of these events, so we can collect even more data! Cheers, Damien. From david.john.ames at gmail.com Sat Oct 24 04:56:13 2015 From: david.john.ames at gmail.com (Dave Ames) Date: Sat, 24 Oct 2015 08:56:13 +0000 Subject: [Microbit-Python] Oxford workshop. In-Reply-To: <5629DCEB.4080808@ntoll.org> References: <5629DCEB.4080808@ntoll.org> Message-ID: Hi My thoughts after briefly getting to try out MicroPython on the micro:bit at our training the other day. 1) I couldn't get the REPL to work with screen (which I'd used with the MicroPython board previously), had to install picocom as mentioned in the Readme. Any idea whether there is a specific reason? 2) Running the local file on a micro:bit required me to install pyserial (I was on a relatively recent install), but there is no mention of this requirement. 3) Is there a way of putting a copy of your python file onto the board (drag it across into the USB drive) with a specific name so that MicroPython can interpret and run it (in the same way we can with the MicroPython boards)? If so is it documented as I couldn't see it in the Readme? I'm sure it's all written up somewhere but a nice overview of what's available in the API would be nice too, if it's already there then signposts pointing to it might need to be more explicit. Making the whole experience as slick and easy as possible, needs to be a goal. Cheers Dave On Fri, 23 Oct 2015 08:08 Nicholas H.Tollervey wrote: > Hi Folks, > > Some observations and comments that fall out from the Oxford PUG > workshop I ran yesterday. > > * About 20 people turned up. > > * People love Python (obviously) and are "gunning" for us. This may be a > reflection of the attendees at a Python User Group but I got the > impression that a significant minority were not Pythonistas but had come > along to find out more. > > * Have clear and accurate help docs is important. > > * We have to make it as simple as possible to access MicroPython on the > device. Things I saw: > > - No one read the README's for the editor, repl or MicroPython repos. > - One guy complained he couldn't connect to the REPL without realising > he had to first flash the device. > - Inexperienced users don't understand the difference between a REPL > and code editor. > - USB cables are a big pain point. Several people couldn't connect > their device, spent 1/2 hour faffing about with their computer only to > discover that they had a knackered lead. (This happened twice.) :-( > - Once connected people had a lot of fun. Ergo, getting people > "connected" is a "bump" we should address. > - People really REALLY enjoyed the examples (Mark, your compass was a > big hit). Having a library of existing simple example code to adapt to > your own purposes is A GOOD THING. People feel positive about cutting > and pasting code and then massaging it to something else. > > * A university professor from Australia attended > (sydney.edu.au/engineering/it/about/people/staff/curran.shtml). AFAICT > he's on some sort of secondment to Oxford University and is responsible > for this rather amazing site: https://groklearning.com/ He wants to get > involved. He especially would like to be introduced to Damien and > perhaps say "hello" when he's next in Cambridge visiting the RPi > Foundation. He appears to be the driving force behind Australia's > equivalent to "Make it Digital". He'd like to integrate the MicroPython > / micro:bit offering into GrokLearning. > > * Once people "settled" into the device they were having lots of fun and > enjoyed using MicroPython. > > When I get time over the weekend I'll try to turn the above into user > stories we can work at. > > All the best, > > Nicholas. > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Mon Oct 26 07:48:27 2015 From: damien.p.george at gmail.com (Damien George) Date: Mon, 26 Oct 2015 11:48:27 +0000 Subject: [Microbit-Python] Testing 1,2, 3... In-Reply-To: <562D6BD0.5070504@ntoll.org> References: <562D6595.5030309@ntoll.org> <562D6BD0.5070504@ntoll.org> Message-ID: Yes, I received this one! On Sun, Oct 25, 2015 at 11:54 PM, Nicholas H.Tollervey wrote: > On 25/10/15 23:28, Nicholas H.Tollervey wrote: >> I trust everyone has had a good weekend. Have had reports of bounced >> emails. Just checking. Please ignore and apologies for the noise on the >> line. >> >> N. >> > > TEST! > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From guido at python.org Mon Oct 26 23:09:41 2015 From: guido at python.org (Guido van Rossum) Date: Mon, 26 Oct 2015 20:09:41 -0700 Subject: [Microbit-Python] Testing 1,2, 3... In-Reply-To: References: <562D6595.5030309@ntoll.org> <562D6BD0.5070504@ntoll.org> Message-ID: Apparently the disk of python.org's mail (ominously named "albatross" :-) server died. Benjamin mentioned this to me at work. On Mon, Oct 26, 2015 at 4:48 AM, Damien George wrote: > Yes, I received this one! > > On Sun, Oct 25, 2015 at 11:54 PM, Nicholas H.Tollervey > wrote: > > On 25/10/15 23:28, Nicholas H.Tollervey wrote: > >> I trust everyone has had a good weekend. Have had reports of bounced > >> emails. Just checking. Please ignore and apologies for the noise on the > >> line. > >> > >> N. > >> > > > > TEST! > > > > > > _______________________________________________ > > 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 > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.john.ames at gmail.com Tue Oct 27 02:35:05 2015 From: david.john.ames at gmail.com (Dave Ames) Date: Tue, 27 Oct 2015 06:35:05 +0000 Subject: [Microbit-Python] Testing 1,2, 3... In-Reply-To: <562D6BD0.5070504@ntoll.org> References: <562D6595.5030309@ntoll.org> <562D6BD0.5070504@ntoll.org> Message-ID: Hi Nicholas I replied to your Oxford one and got a message, but don't know if it finally went through? Cheers Dave On Tue, 27 Oct 2015 06:08 Nicholas H.Tollervey wrote: > On 25/10/15 23:28, Nicholas H.Tollervey wrote: > > I trust everyone has had a good weekend. Have had reports of bounced > > emails. Just checking. Please ignore and apologies for the noise on the > > line. > > > > N. > > > > TEST! > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Tue Oct 27 05:25:38 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 27 Oct 2015 09:25:38 +0000 Subject: [Microbit-Python] Testing 1,2, 3... In-Reply-To: <562D6BD0.5070504@ntoll.org> References: <562D6595.5030309@ntoll.org> <562D6BD0.5070504@ntoll.org> Message-ID: Green :-) Michael On 25 October 2015 at 23:54, Nicholas H.Tollervey wrote: > On 25/10/15 23:28, Nicholas H.Tollervey wrote: > > I trust everyone has had a good weekend. Have had reports of bounced > > emails. Just checking. Please ignore and apologies for the noise on the > > line. > > > > N. > > > > TEST! > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.p.george at gmail.com Tue Oct 27 06:37:35 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 27 Oct 2015 10:37:35 +0000 Subject: [Microbit-Python] Which interrupts wake up WFI? In-Reply-To: <562D479E.6030104@hastings.org> References: <562D479E.6030104@hastings.org> Message-ID: All interrupts should wake the WFI() call. On Sun, Oct 25, 2015 at 9:20 PM, Larry Hastings wrote: > > > Damien: > > Mark Shannon and I have been poking around in the DAL the last day or two > here at PyCon IE. One question that came up: which interrupts wake up the > WFI() function call? Is it just the 6ms system timer interrupt? Or do the > display refresh and UART interrupts wake up WFI too? > > Thanks, > > > /arry > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From ntoll at ntoll.org Tue Oct 27 06:47:30 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 27 Oct 2015 10:47:30 +0000 Subject: [Microbit-Python] Python editor designs from Steve Message-ID: <562F5642.1@ntoll.org> Hi Folks, Here is a link to a screenie of Steve's current design for the Python editor (I've added Steve to this list): http://ntoll.org/static/images/py-editor-dark.png Apart from a couple of textual changes I've already fed back to Steve, I think we're definitely on the right track. If you remember, Steve was asked to create something that looked "Pythonic", would appeal to 11yo kids and be simple to use. It should also look "cool" (for some definition of "cool") in a way that complements the BBC micro:bit's design. The next steps are to send this to the BBC branding and UX compliance teams to ensure we're meeting the partnership requirements. Once this is done we can apply the styling to the existing editor and get the thing into TouchDevelop. Yay! Many thanks and congratulations to Steve for such amazing work. Feedback welcome..! Best wishes, Nicholas. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From damien.p.george at gmail.com Tue Oct 27 07:12:17 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 27 Oct 2015 11:12:17 +0000 Subject: [Microbit-Python] Python editor designs from Steve In-Reply-To: <562F5642.1@ntoll.org> References: <562F5642.1@ntoll.org> Message-ID: Hi Nicholas & Steve, It looks great, but is missing any mention of MicroPython... is there a plan to add this? Cheers, Damien. On Tue, Oct 27, 2015 at 10:47 AM, Nicholas H.Tollervey wrote: > Hi Folks, > > Here is a link to a screenie of Steve's current design for the Python > editor (I've added Steve to this list): > > http://ntoll.org/static/images/py-editor-dark.png > > Apart from a couple of textual changes I've already fed back to Steve, I > think we're definitely on the right track. If you remember, Steve was > asked to create something that looked "Pythonic", would appeal to 11yo > kids and be simple to use. It should also look "cool" (for some > definition of "cool") in a way that complements the BBC micro:bit's design. > > The next steps are to send this to the BBC branding and UX compliance > teams to ensure we're meeting the partnership requirements. Once this is > done we can apply the styling to the existing editor and get the thing > into TouchDevelop. > > Yay! Many thanks and congratulations to Steve for such amazing work. > > Feedback welcome..! > > Best wishes, > > Nicholas. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From ntoll at ntoll.org Tue Oct 27 07:15:18 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 27 Oct 2015 11:15:18 +0000 Subject: [Microbit-Python] Python editor designs from Steve In-Reply-To: References: <562F5642.1@ntoll.org> Message-ID: <562F5CC6.9090502@ntoll.org> Dammit... I knew there was something missing. Steve, as we discussed can we add the MicroPython logo on the bottom RHS next to the Python one..? Damien, apologies on my part... should've spotted that..! N. On 27/10/15 11:12, Damien George wrote: > Hi Nicholas & Steve, > > It looks great, but is missing any mention of MicroPython... is there > a plan to add this? > > Cheers, > Damien. > > > On Tue, Oct 27, 2015 at 10:47 AM, Nicholas H.Tollervey wrote: >> Hi Folks, >> >> Here is a link to a screenie of Steve's current design for the Python >> editor (I've added Steve to this list): >> >> http://ntoll.org/static/images/py-editor-dark.png >> >> Apart from a couple of textual changes I've already fed back to Steve, I >> think we're definitely on the right track. If you remember, Steve was >> asked to create something that looked "Pythonic", would appeal to 11yo >> kids and be simple to use. It should also look "cool" (for some >> definition of "cool") in a way that complements the BBC micro:bit's design. >> >> The next steps are to send this to the BBC branding and UX compliance >> teams to ensure we're meeting the partnership requirements. Once this is >> done we can apply the styling to the existing editor and get the thing >> into TouchDevelop. >> >> Yay! Many thanks and congratulations to Steve for such amazing work. >> >> Feedback welcome..! >> >> Best wishes, >> >> Nicholas. >> >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ntoll at ntoll.org Tue Oct 27 07:15:55 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 27 Oct 2015 11:15:55 +0000 Subject: [Microbit-Python] Python editor designs from Steve In-Reply-To: References: <562F5642.1@ntoll.org> Message-ID: <562F5CEB.7030706@ntoll.org> FYI, the logos will link to python.org and micropython.org respectively. N. On 27/10/15 11:12, Damien George wrote: > Hi Nicholas & Steve, > > It looks great, but is missing any mention of MicroPython... is there > a plan to add this? > > Cheers, > Damien. > > > On Tue, Oct 27, 2015 at 10:47 AM, Nicholas H.Tollervey wrote: >> Hi Folks, >> >> Here is a link to a screenie of Steve's current design for the Python >> editor (I've added Steve to this list): >> >> http://ntoll.org/static/images/py-editor-dark.png >> >> Apart from a couple of textual changes I've already fed back to Steve, I >> think we're definitely on the right track. If you remember, Steve was >> asked to create something that looked "Pythonic", would appeal to 11yo >> kids and be simple to use. It should also look "cool" (for some >> definition of "cool") in a way that complements the BBC micro:bit's design. >> >> The next steps are to send this to the BBC branding and UX compliance >> teams to ensure we're meeting the partnership requirements. Once this is >> done we can apply the styling to the existing editor and get the thing >> into TouchDevelop. >> >> Yay! Many thanks and congratulations to Steve for such amazing work. >> >> Feedback welcome..! >> >> Best wishes, >> >> Nicholas. >> >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From damien.p.george at gmail.com Tue Oct 27 07:19:10 2015 From: damien.p.george at gmail.com (Damien George) Date: Tue, 27 Oct 2015 11:19:10 +0000 Subject: [Microbit-Python] Python editor designs from Steve In-Reply-To: <562F5CEB.7030706@ntoll.org> References: <562F5642.1@ntoll.org> <562F5CEB.7030706@ntoll.org> Message-ID: Awesome! Along with the logo, will it also say "MicroPython"? If the choice was between logo or "MicroPython" I'd actually rather it say "MicroPython", since you have to already know the logo to know what it refers to. Of course, the best scenario would be to have both the logo and the name :) On Tue, Oct 27, 2015 at 11:15 AM, Nicholas H.Tollervey wrote: > FYI, the logos will link to python.org and micropython.org respectively. > > N. > > On 27/10/15 11:12, Damien George wrote: >> Hi Nicholas & Steve, >> >> It looks great, but is missing any mention of MicroPython... is there >> a plan to add this? >> >> Cheers, >> Damien. >> >> >> On Tue, Oct 27, 2015 at 10:47 AM, Nicholas H.Tollervey wrote: >>> Hi Folks, >>> >>> Here is a link to a screenie of Steve's current design for the Python >>> editor (I've added Steve to this list): >>> >>> http://ntoll.org/static/images/py-editor-dark.png >>> >>> Apart from a couple of textual changes I've already fed back to Steve, I >>> think we're definitely on the right track. If you remember, Steve was >>> asked to create something that looked "Pythonic", would appeal to 11yo >>> kids and be simple to use. It should also look "cool" (for some >>> definition of "cool") in a way that complements the BBC micro:bit's design. >>> >>> The next steps are to send this to the BBC branding and UX compliance >>> teams to ensure we're meeting the partnership requirements. Once this is >>> done we can apply the styling to the existing editor and get the thing >>> into TouchDevelop. >>> >>> Yay! Many thanks and congratulations to Steve for such amazing work. >>> >>> Feedback welcome..! >>> >>> Best wishes, >>> >>> Nicholas. >>> >>> >>> _______________________________________________ >>> 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 > From ntoll at ntoll.org Tue Oct 27 07:43:34 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 27 Oct 2015 11:43:34 +0000 Subject: [Microbit-Python] Oxford workshop. In-Reply-To: References: <5629DCEB.4080808@ntoll.org> Message-ID: <562F6366.10206@ntoll.org> On 23/10/15 16:05, Guido van Rossum wrote: > Sounds like the structure and organization of micro:bit community events > could learn a bit from the checklist DjangoGirls uses for their events. :-) > I know the DjangoGirls and they're on my "radar" for people to ping for *exactly* that sort of advice (among other things). ;-) N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ntoll at ntoll.org Tue Oct 27 07:54:25 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 27 Oct 2015 11:54:25 +0000 Subject: [Microbit-Python] Oxford workshop. In-Reply-To: References: <5629DCEB.4080808@ntoll.org> Message-ID: <562F65F1.1010208@ntoll.org> See comments in-line below... N. On 23/10/15 22:58, Damien George wrote: > Hi Nicholas, > > Great news! (Good news is starting to be a theme around here!) > Comments inline below. > >> * Have clear and accurate help docs is important. > > Yes, definitely. We need to solidify our API (it's almost there, > need gestures) and write some nice docs. > And Larry's game related contributions that I need to find the time to write up into a straw-man API just like we did for the music API. >> * We have to make it as simple as possible to access MicroPython on >> the device. Things I saw: > > For sure. We've known this from day one. > >> - No one read the README's for the editor, repl or MicroPython >> repos. > > In most cases they shouldn't need to. If you get a REPL, then > help() and tab completion will get you most of the way. > I meant the README for the connecting to th REPL..! :-) >> - One guy complained he couldn't connect to the REPL without >> realising he had to first flash the device. > > You know what we could do: ask the BBC if they can preinstall > MicroPython on all the microbits. Why not? We could include a demo > script so they do something fun when you turn them on. And the big > benefit is that users can get a REPL straight away. They don't ever > need to see the internet in order to do cool stuff. > I think Jonny has more control over that. Perhaps it'd be good to sound him out... Jonny? IIRC the default is a C++ version of the classic Snake game. >> - Inexperienced users don't understand the difference between a >> REPL and code editor. > > Fair enough. That just needs education. > That's the name of the game. ;-) >> - USB cables are a big pain point. Several people couldn't connect >> their device, spent 1/2 hour faffing about with their computer only >> to discover that they had a knackered lead. (This happened twice.) >> :-( > > Yeah, I've seen this as well. A lot of micro USB cables are for > charging only and don't have data connected. Other cables have > dodgy data connections. > The important thing is that now we know about this we can include this into the messaging we provide to users so they can self-diagnose and (hopefully) get themselves out of the bad situation. >> - Once connected people had a lot of fun. Ergo, getting people >> "connected" is a "bump" we should address. > > Set-up is always going to be a bump, no matter what the technology. > But we can do our best here by providing lots of good docs for all > platforms, and easy access to drivers/install programs/etc. > Yes. I'm looking into how we can do this for both teachers and kids. Docs are not the only medium we can use. Kids especially love YouTube how-to type affairs a la the bazillions you find online by kids, aimed at kids all about Minecraft. I want to explore this as a low-effort template (these videos only last 2 mins or so and are relatively simple to make). Plus, I happen to have an 11yo and buddies to hand to try this out on. >> - People really REALLY enjoyed the examples (Mark, your compass was >> a big hit). Having a library of existing simple example code to >> adapt to your own purposes is A GOOD THING. People feel positive >> about cutting and pasting code and then massaging it to something >> else. > > Good to hear. We should write more! > Again... another thing I'm looking into. >> * A university professor from Australia attended >> (sydney.edu.au/engineering/it/about/people/staff/curran.shtml). >> AFAICT he's on some sort of secondment to Oxford University and is >> responsible for this rather amazing site: https://groklearning.com/ >> He wants to get involved. He especially would like to be introduced >> to Damien and perhaps say "hello" when he's next in Cambridge >> visiting the RPi Foundation. He appears to be the driving force >> behind Australia's equivalent to "Make it Digital". He'd like to >> integrate the MicroPython / micro:bit offering into GrokLearning. > > Wow, that's exciting! Yes I'd definitely be up to meet him and > discuss this further. > He visits Cambridge quite a lot. He wants to buy you lunch! :-) Bonzer! (As I believe you guys say.) >> * Once people "settled" into the device they were having lots of >> fun and enjoyed using MicroPython. > > Ok, great. That means we have done a good job :) > Yes. Lots of positive vibes. Right now I think it'd be useful to spend time making sure the set-up and "on boarding" are smooth and simple. > You have a few more of these events, so we can collect even more > data! > Cambridge next week, London the week after, Sheffield after that. I'm also going to wangle meeting up with teachers and then hijack some kids and a teacher who's offered to help with testing. I want to do this with developers first because they're confident at self-diagnosing and are good at writing bug reports. Busy times. :-) N. > Cheers, Damien. _______________________________________________ > 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: From david at thinkingbinaries.com Tue Oct 27 08:02:57 2015 From: david at thinkingbinaries.com (David Whale) Date: Tue, 27 Oct 2015 12:02:57 +0000 Subject: [Microbit-Python] Python editor designs from Steve In-Reply-To: <562F5642.1@ntoll.org> References: <562F5642.1@ntoll.org> Message-ID: Looks cool, but... Can we have a user settable option to make the background white and the text the same colours as used by IDLE? Also for UX accessibility guideline compliance, you may have to provide either an alternative colour scheme, or a way for users to configure the colour scheme to their linking, specifically supporting at least one 'high contrast' scheme for visually impaired users. It's really hard for visually impaired people to read that black background design, to be honest. Thanks! 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 27 October 2015 at 10:47, Nicholas H.Tollervey wrote: > Hi Folks, > > Here is a link to a screenie of Steve's current design for the Python > editor (I've added Steve to this list): > > http://ntoll.org/static/images/py-editor-dark.png > > Apart from a couple of textual changes I've already fed back to Steve, I > think we're definitely on the right track. If you remember, Steve was > asked to create something that looked "Pythonic", would appeal to 11yo > kids and be simple to use. It should also look "cool" (for some > definition of "cool") in a way that complements the BBC micro:bit's design. > > The next steps are to send this to the BBC branding and UX compliance > teams to ensure we're meeting the partnership requirements. Once this is > done we can apply the styling to the existing editor and get the thing > into TouchDevelop. > > Yay! Many thanks and congratulations to Steve for such amazing work. > > Feedback welcome..! > > Best wishes, > > Nicholas. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Tue Oct 27 08:58:54 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 27 Oct 2015 12:58:54 +0000 Subject: [Microbit-Python] Python editor designs from Steve In-Reply-To: References: <562F5642.1@ntoll.org> Message-ID: <562F750E.5060600@ntoll.org> Fear not David, we have a white background version too. Another thought is some means of resizing the text to make it bigger/smaller depending on who's looking at it (useful if you want to present your work). N. On 27/10/15 12:02, David Whale wrote: > Looks cool, but... > > Can we have a user settable option to make the background white and the > text the same colours as used by IDLE? Also for UX accessibility > guideline compliance, you may have to provide either an alternative > colour scheme, or a way for users to configure the colour scheme to > their linking, specifically supporting at least one 'high contrast' > scheme for visually impaired users. > > It's really hard for visually impaired people to read that black > background design, to be honest. > > Thanks! > > 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 27 October 2015 at 10:47, Nicholas H.Tollervey > wrote: > > Hi Folks, > > Here is a link to a screenie of Steve's current design for the Python > editor (I've added Steve to this list): > > http://ntoll.org/static/images/py-editor-dark.png > > Apart from a couple of textual changes I've already fed back to Steve, I > think we're definitely on the right track. If you remember, Steve was > asked to create something that looked "Pythonic", would appeal to 11yo > kids and be simple to use. It should also look "cool" (for some > definition of "cool") in a way that complements the BBC micro:bit's > design. > > The next steps are to send this to the BBC branding and UX compliance > teams to ensure we're meeting the partnership requirements. Once this is > done we can apply the styling to the existing editor and get the thing > into TouchDevelop. > > Yay! Many thanks and congratulations to Steve for such amazing work. > > Feedback welcome..! > > Best wishes, > > Nicholas. > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From sparks.m at gmail.com Tue Oct 27 09:10:26 2015 From: sparks.m at gmail.com (Michael) Date: Tue, 27 Oct 2015 13:10:26 +0000 Subject: [Microbit-Python] Python editor designs from Steve In-Reply-To: <562F750E.5060600@ntoll.org> References: <562F5642.1@ntoll.org> <562F750E.5060600@ntoll.org> Message-ID: Talking about presenting work, digital whiteboard mode? Big fonts, etc? Our team uses pivotal tracker at work, and one of the useful things about that is a digital whiteboard mode - makes every thing just easier to see at a distance. It's "just" a CSS change/toggle, but it does make life a lot nicer. Michael. On 27 October 2015 at 12:58, Nicholas H.Tollervey wrote: > Fear not David, we have a white background version too. > > Another thought is some means of resizing the text to make it > bigger/smaller depending on who's looking at it (useful if you want to > present your work). > > N. > > On 27/10/15 12:02, David Whale wrote: > > Looks cool, but... > > > > Can we have a user settable option to make the background white and the > > text the same colours as used by IDLE? Also for UX accessibility > > guideline compliance, you may have to provide either an alternative > > colour scheme, or a way for users to configure the colour scheme to > > their linking, specifically supporting at least one 'high contrast' > > scheme for visually impaired users. > > > > It's really hard for visually impaired people to read that black > > background design, to be honest. > > > > Thanks! > > > > 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 27 October 2015 at 10:47, Nicholas H.Tollervey > > wrote: > > > > Hi Folks, > > > > Here is a link to a screenie of Steve's current design for the Python > > editor (I've added Steve to this list): > > > > http://ntoll.org/static/images/py-editor-dark.png > > > > Apart from a couple of textual changes I've already fed back to > Steve, I > > think we're definitely on the right track. If you remember, Steve was > > asked to create something that looked "Pythonic", would appeal to > 11yo > > kids and be simple to use. It should also look "cool" (for some > > definition of "cool") in a way that complements the BBC micro:bit's > > design. > > > > The next steps are to send this to the BBC branding and UX compliance > > teams to ensure we're meeting the partnership requirements. Once > this is > > done we can apply the styling to the existing editor and get the > thing > > into TouchDevelop. > > > > Yay! Many thanks and congratulations to Steve for such amazing work. > > > > Feedback welcome..! > > > > Best wishes, > > > > Nicholas. > > > > > > _______________________________________________ > > 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: From ntoll at ntoll.org Tue Oct 27 09:31:35 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Tue, 27 Oct 2015 13:31:35 +0000 Subject: [Microbit-Python] Python editor designs from Steve In-Reply-To: References: <562F5642.1@ntoll.org> <562F750E.5060600@ntoll.org> Message-ID: <562F7CB7.1060603@ntoll.org> On 27/10/15 13:10, Michael wrote: > Talking about presenting work, digital whiteboard mode? > > Big fonts, etc? > > Our team uses pivotal tracker at work, and one of the useful things > about that is a digital whiteboard mode - makes every thing just easier > to see at a distance. It's "just" a CSS change/toggle, but it does make > life a lot nicer. > Can you send a screenie / photo of what you mean..? N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mark at hotpy.org Tue Oct 27 15:36:21 2015 From: mark at hotpy.org (Mark Shannon) Date: Tue, 27 Oct 2015 19:36:21 +0000 Subject: [Microbit-Python] Accelerometer API Message-ID: <562FD235.3050504@hotpy.org> Hi, Did we decide that accelerometer API should be get_x(), get_y(), get_z() (as it is now) or just x(), y(), z() ? I don't recall. Cheers, Mark From ntoll at ntoll.org Thu Oct 29 06:55:27 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 29 Oct 2015 10:55:27 +0000 Subject: [Microbit-Python] Fwd: Jodrell bank and the microbit In-Reply-To: <9657B439C88D984EA4A13731A35E81EC43CB57C9@bgb01xud1002> References: <9657B439C88D984EA4A13731A35E81EC43CB57C9@bgb01xud1002> Message-ID: <5631FB1F.2000007@ntoll.org> See below. I'm guessing several people on this list would be very interested in contributing. I'm about to send an "affirmative, tell us more" reply. For those who don't know: https://en.wikipedia.org/wiki/Jodrell_Bank_Observatory http://www.jb.man.ac.uk/ It'd be super duper cool if MicroPython was driving such a famous dish. Any takers I can cc on the resulting conversation..? N. -------- Forwarded Message -------- Subject: Jodrell bank and the microbit Date: Thu, 29 Oct 2015 10:43:39 +0000 From: Shirley Hunt-Benson To: 'larchard at upbeatpd.co.uk' , 'larchard at develangel.co.uk' , 'larchard at gmail.com' , 'Jonathan.Austin at arm.com' , Nicholas H.Tollervey CC: Howard Baker-IF&L , Matt Gallop , 'Tim O'Brien' Hi Lawrence, Jonathan & Nick I wonder if you can help me with a current film I am trying to set up for The One Show as part of the microbit launch campaign? We would like to get the telescope being moved / controlled by the microbit and also potentially be able to visualise the rhythm of pulsars on the LED screen. Having set that up and got buy -in from the team at Jodrell bank we now need to work out how to do it ? which is where we need your help and expertise. How do we get the interface between the telescope and the microbit. This is the note from Tim (copied in above) (07768394491) at Jodrell Bank: Current theory might be: 1. Select object from a list on some text interface running on microchip. 2. Code (in python?) runs on chip to convert celestial coordinates to actual pointing coordinates for telescope (azimuth and elevation). 3. This is sent as an xml string **somehow** so our telescope control software can read it and point telescope. 4. Data from telescope processed by one of our computers which fires data to an IP address (on MicroChip, how does it read this) as a sequence of numbers. 5. Program on microchip flashes LEDs when above a threshold. 6. If this were a pulsar then it would flash in time. 7. Maybe it could also make a sound. Is this the sort of thing one of you might be able to help us out with? We are hoping to set the filming up for this in December so with approx. 4 weeks to go there is a sense of urgency. Depending on availability the most effective way might be to set up a meet at Jodrell Bank itself (potentially for next week?) Apologise for the group email but I?d be very grateful if you could get back in touch and or give me a call on the number below with your thoughts. Kind regards shirley */Shirley Benson/* */Campaign Producer BBC micro:bit/* */07974660220/* MBSIG_V2*//* */ /* */ /* *From:*Howard Baker-IF&L *Sent:* 29 October 2015 10:24 *To:* Shirley Hunt-Benson *Subject:* Lawrence and jonny Lawrence Archard > (larchard at upbeatpd.co.uk ) Lawrence Archard (larchard at develangel.co.uk ) larchard at gmail.com Jonathan Austin (Jonathan.Austin at arm.com ) Lawrence 07906387776 Howard *Howard Baker * *Editor, Innovations and Development * Tel: 07713 315 808 | Email: howard.baker at bbc.co.uk Bridge House (3rd Floor) | MediaCityUK | Salford | M50 2BH -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ntoll at ntoll.org Thu Oct 29 07:37:41 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 29 Oct 2015 11:37:41 +0000 Subject: [Microbit-Python] Fwd: Jodrell bank and the microbit In-Reply-To: <5631FB1F.2000007@ntoll.org> References: <9657B439C88D984EA4A13731A35E81EC43CB57C9@bgb01xud1002> <5631FB1F.2000007@ntoll.org> Message-ID: <56320505.7030304@ntoll.org> They'd like a conference call on Monday. Any takers? N. On 29/10/15 10:55, Nicholas H.Tollervey wrote: > See below. I'm guessing several people on this list would be very > interested in contributing. I'm about to send an "affirmative, tell us > more" reply. > > For those who don't know: > > https://en.wikipedia.org/wiki/Jodrell_Bank_Observatory > http://www.jb.man.ac.uk/ > > It'd be super duper cool if MicroPython was driving such a famous dish. > > Any takers I can cc on the resulting conversation..? > > N. > > -------- Forwarded Message -------- > Subject: Jodrell bank and the microbit > Date: Thu, 29 Oct 2015 10:43:39 +0000 > From: Shirley Hunt-Benson > To: 'larchard at upbeatpd.co.uk' , > 'larchard at develangel.co.uk' , > 'larchard at gmail.com' , 'Jonathan.Austin at arm.com' > , Nicholas H.Tollervey > CC: Howard Baker-IF&L , Matt Gallop > , 'Tim O'Brien' > > > > Hi Lawrence, Jonathan & Nick > > > > I wonder if you can help me with a current film I am trying to set up > for The One Show as part of the microbit launch campaign? > > > > We would like to get the telescope being moved / controlled by the > microbit and also potentially be able to visualise the rhythm of pulsars > on the LED screen. > > > > Having set that up and got buy -in from the team at Jodrell bank we now > need to work out how to do it ? which is where we need your help and > expertise. How do we get the interface between the telescope and the > microbit. > > > > This is the note from Tim (copied in above) (07768394491) at Jodrell Bank: > > > > Current theory might be: > > > > 1. Select object from a list on some text interface running on > microchip. > > 2. Code (in python?) runs on chip to convert celestial coordinates > to actual pointing coordinates for telescope (azimuth and elevation). > > 3. This is sent as an xml string **somehow** so our telescope > control software can read it and point telescope. > > 4. Data from telescope processed by one of our computers which > fires data to an IP address (on MicroChip, how does it read this) as a > sequence of numbers. > > 5. Program on microchip flashes LEDs when above a threshold. > > 6. If this were a pulsar then it would flash in time. > > 7. Maybe it could also make a sound. > > > > Is this the sort of thing one of you might be able to help us out with? > > We are hoping to set the filming up for this in December so with approx. > 4 weeks to go there is a sense of urgency. > > Depending on availability the most effective way might be to set up a > meet at Jodrell Bank itself (potentially for next week?) > > Apologise for the group email but I?d be very grateful if you could get > back in touch and or give me a call on the number below with your thoughts. > > Kind regards shirley > > > > */Shirley Benson/* > > */Campaign Producer BBC micro:bit/* > > */07974660220/* > > MBSIG_V2*//* > > */ /* > > */ /* > > > > > > > > > > *From:*Howard Baker-IF&L > *Sent:* 29 October 2015 10:24 > *To:* Shirley Hunt-Benson > *Subject:* Lawrence and jonny > > > > Lawrence Archard > (larchard at upbeatpd.co.uk > ) > > Lawrence Archard (larchard at develangel.co.uk > ) > > larchard at gmail.com > > Jonathan Austin (Jonathan.Austin at arm.com ) > > > > Lawrence 07906387776 > > > > Howard > > > > > > > > *Howard Baker * > > *Editor, Innovations and Development * > > Tel: 07713 315 808 | Email: howard.baker at bbc.co.uk > > > Bridge House (3rd Floor) | MediaCityUK | Salford | M50 2BH > > > > > > > > > > > _______________________________________________ > 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: From matthewelse1997 at gmail.com Thu Oct 29 07:39:03 2015 From: matthewelse1997 at gmail.com (Matthew Else) Date: Thu, 29 Oct 2015 11:39:03 +0000 Subject: [Microbit-Python] Fwd: Jodrell bank and the microbit In-Reply-To: <56320505.7030304@ntoll.org> References: <9657B439C88D984EA4A13731A35E81EC43CB57C9@bgb01xud1002> <5631FB1F.2000007@ntoll.org> <56320505.7030304@ntoll.org> Message-ID: I?d be quite interested to see what?s going on, but I?m not sure to what extent I?d be able to contribute. I?ll also have at least some time to work on it in the next few weeks too. Matthew On 29/10/2015, 11:37, "Microbit on behalf of Nicholas H.Tollervey" wrote: >They'd like a conference call on Monday. Any takers? > >N. > >On 29/10/15 10:55, Nicholas H.Tollervey wrote: >> See below. I'm guessing several people on this list would be very >> interested in contributing. I'm about to send an "affirmative, tell us >> more" reply. >> >> For those who don't know: >> >> https://en.wikipedia.org/wiki/Jodrell_Bank_Observatory >> http://www.jb.man.ac.uk/ >> >> It'd be super duper cool if MicroPython was driving such a famous dish. >> >> Any takers I can cc on the resulting conversation..? >> >> N. >> >> -------- Forwarded Message -------- >> Subject: Jodrell bank and the microbit >> Date: Thu, 29 Oct 2015 10:43:39 +0000 >> From: Shirley Hunt-Benson >> To: 'larchard at upbeatpd.co.uk' , >> 'larchard at develangel.co.uk' , >> 'larchard at gmail.com' , 'Jonathan.Austin at arm.com' >> , Nicholas H.Tollervey >> CC: Howard Baker-IF&L , Matt Gallop >> , 'Tim O'Brien' >> >> >> >> Hi Lawrence, Jonathan & Nick >> >> >> >> I wonder if you can help me with a current film I am trying to set up >> for The One Show as part of the microbit launch campaign? >> >> >> >> We would like to get the telescope being moved / controlled by the >> microbit and also potentially be able to visualise the rhythm of pulsars >> on the LED screen. >> >> >> >> Having set that up and got buy -in from the team at Jodrell bank we now >> need to work out how to do it ? which is where we need your help and >> expertise. How do we get the interface between the telescope and the >> microbit. >> >> >> >> This is the note from Tim (copied in above) (07768394491) at Jodrell Bank: >> >> >> >> Current theory might be: >> >> >> >> 1. Select object from a list on some text interface running on >> microchip. >> >> 2. Code (in python?) runs on chip to convert celestial coordinates >> to actual pointing coordinates for telescope (azimuth and elevation). >> >> 3. This is sent as an xml string **somehow** so our telescope >> control software can read it and point telescope. >> >> 4. Data from telescope processed by one of our computers which >> fires data to an IP address (on MicroChip, how does it read this) as a >> sequence of numbers. >> >> 5. Program on microchip flashes LEDs when above a threshold. >> >> 6. If this were a pulsar then it would flash in time. >> >> 7. Maybe it could also make a sound. >> >> >> >> Is this the sort of thing one of you might be able to help us out with? >> >> We are hoping to set the filming up for this in December so with approx. >> 4 weeks to go there is a sense of urgency. >> >> Depending on availability the most effective way might be to set up a >> meet at Jodrell Bank itself (potentially for next week?) >> >> Apologise for the group email but I?d be very grateful if you could get >> back in touch and or give me a call on the number below with your thoughts. >> >> Kind regards shirley >> >> >> >> */Shirley Benson/* >> >> */Campaign Producer BBC micro:bit/* >> >> */07974660220/* >> >> MBSIG_V2*//* >> >> */ /* >> >> */ /* >> >> >> >> >> >> >> >> >> >> *From:*Howard Baker-IF&L >> *Sent:* 29 October 2015 10:24 >> *To:* Shirley Hunt-Benson >> *Subject:* Lawrence and jonny >> >> >> >> Lawrence Archard > > (larchard at upbeatpd.co.uk >> ) >> >> Lawrence Archard (larchard at develangel.co.uk >> ) >> >> larchard at gmail.com >> >> Jonathan Austin (Jonathan.Austin at arm.com ) >> >> >> >> Lawrence 07906387776 >> >> >> >> Howard >> >> >> >> >> >> >> >> *Howard Baker * >> >> *Editor, Innovations and Development * >> >> Tel: 07713 315 808 | Email: howard.baker at bbc.co.uk >> >> >> Bridge House (3rd Floor) | MediaCityUK | Salford | M50 2BH >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 From harry at pythonanywhere.com Thu Oct 29 07:31:08 2015 From: harry at pythonanywhere.com (Harry Percival) Date: Thu, 29 Oct 2015 11:31:08 +0000 Subject: [Microbit-Python] Fwd: Jodrell bank and the microbit In-Reply-To: <5631FB1F.2000007@ntoll.org> References: <9657B439C88D984EA4A13731A35E81EC43CB57C9@bgb01xud1002> <5631FB1F.2000007@ntoll.org> Message-ID: <5632037C.3010908@pythonanywhere.com> I worried I'm a little disconnected from micro:bit things, and a bit too about-to-have-a-child-ey, but I'd love to be kept informed. Said infant will be Sir Bernard Lovell's great-grandchild (via my wife)... On 29/10/15 10:55, Nicholas H.Tollervey wrote: > See below. I'm guessing several people on this list would be very > interested in contributing. I'm about to send an "affirmative, tell us > more" reply. > > For those who don't know: > > https://en.wikipedia.org/wiki/Jodrell_Bank_Observatory > http://www.jb.man.ac.uk/ > > It'd be super duper cool if MicroPython was driving such a famous dish. > > Any takers I can cc on the resulting conversation..? > > N. > > -------- Forwarded Message -------- > Subject: Jodrell bank and the microbit > Date: Thu, 29 Oct 2015 10:43:39 +0000 > From: Shirley Hunt-Benson > To: 'larchard at upbeatpd.co.uk' , > 'larchard at develangel.co.uk' , > 'larchard at gmail.com' , 'Jonathan.Austin at arm.com' > , Nicholas H.Tollervey > CC: Howard Baker-IF&L , Matt Gallop > , 'Tim O'Brien' > > > > Hi Lawrence, Jonathan & Nick > > > > I wonder if you can help me with a current film I am trying to set up > for The One Show as part of the microbit launch campaign? > > > > We would like to get the telescope being moved / controlled by the > microbit and also potentially be able to visualise the rhythm of pulsars > on the LED screen. > > > > Having set that up and got buy -in from the team at Jodrell bank we now > need to work out how to do it ? which is where we need your help and > expertise. How do we get the interface between the telescope and the > microbit. > > > > This is the note from Tim (copied in above) (07768394491) at Jodrell Bank: > > > > Current theory might be: > > > > 1. Select object from a list on some text interface running on > microchip. > > 2. Code (in python?) runs on chip to convert celestial coordinates > to actual pointing coordinates for telescope (azimuth and elevation). > > 3. This is sent as an xml string **somehow** so our telescope > control software can read it and point telescope. > > 4. Data from telescope processed by one of our computers which > fires data to an IP address (on MicroChip, how does it read this) as a > sequence of numbers. > > 5. Program on microchip flashes LEDs when above a threshold. > > 6. If this were a pulsar then it would flash in time. > > 7. Maybe it could also make a sound. > > > > Is this the sort of thing one of you might be able to help us out with? > > We are hoping to set the filming up for this in December so with approx. > 4 weeks to go there is a sense of urgency. > > Depending on availability the most effective way might be to set up a > meet at Jodrell Bank itself (potentially for next week?) > > Apologise for the group email but I?d be very grateful if you could get > back in touch and or give me a call on the number below with your thoughts. > > Kind regards shirley > > > > */Shirley Benson/* > > */Campaign Producer BBC micro:bit/* > > */07974660220/* > > MBSIG_V2*//* > > */ /* > > */ /* > > > > > > > > > > *From:*Howard Baker-IF&L > *Sent:* 29 October 2015 10:24 > *To:* Shirley Hunt-Benson > *Subject:* Lawrence and jonny > > > > Lawrence Archard > (larchard at upbeatpd.co.uk > ) > > Lawrence Archard (larchard at develangel.co.uk > ) > > larchard at gmail.com > > Jonathan Austin (Jonathan.Austin at arm.com ) > > > > Lawrence 07906387776 > > > > Howard > > > > > > > > *Howard Baker * > > *Editor, Innovations and Development * > > Tel: 07713 315 808 | Email: howard.baker at bbc.co.uk > > > Bridge House (3rd Floor) | MediaCityUK | Salford | M50 2BH > > > > > > > > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit -- Harry Percival Developer harry at pythonanywhere.com PythonAnywhere - a fully browser-based Python development and hosting environment PythonAnywhere LLP 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number OC378414. Registered address: 28 Ely Place, 3rd Floor, London EC1N 6TD, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Thu Oct 29 07:57:11 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 29 Oct 2015 11:57:11 +0000 Subject: [Microbit-Python] Fwd: Jodrell bank and the microbit In-Reply-To: <5632037C.3010908@pythonanywhere.com> References: <9657B439C88D984EA4A13731A35E81EC43CB57C9@bgb01xud1002> <5631FB1F.2000007@ntoll.org> <5632037C.3010908@pythonanywhere.com> Message-ID: <56320997.7060107@ntoll.org> On 29/10/15 11:31, Harry Percival wrote: > I worried I'm a little disconnected from micro:bit things, and a bit too > about-to-have-a-child-ey, but I'd love to be kept informed. Said infant > will be Sir Bernard Lovell's great-grandchild (via my wife)... > That's a great connection with which the BBC may connect dots. (Who knows??) Fancy contributing some code? ;-) N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From harry at pythonanywhere.com Thu Oct 29 08:01:29 2015 From: harry at pythonanywhere.com (Harry Percival) Date: Thu, 29 Oct 2015 12:01:29 +0000 Subject: [Microbit-Python] Fwd: Jodrell bank and the microbit In-Reply-To: <56320997.7060107@ntoll.org> References: <9657B439C88D984EA4A13731A35E81EC43CB57C9@bgb01xud1002> <5631FB1F.2000007@ntoll.org> <5632037C.3010908@pythonanywhere.com> <56320997.7060107@ntoll.org> Message-ID: <56320A99.9040107@pythonanywhere.com> How could I not! Definitely count me in... On 29/10/15 11:57, Nicholas H.Tollervey wrote: > On 29/10/15 11:31, Harry Percival wrote: >> I worried I'm a little disconnected from micro:bit things, and a bit too >> about-to-have-a-child-ey, but I'd love to be kept informed. Said infant >> will be Sir Bernard Lovell's great-grandchild (via my wife)... >> > That's a great connection with which the BBC may connect dots. (Who > knows??) Fancy contributing some code? ;-) > > N. > > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit -- Harry Percival Developer harry at pythonanywhere.com PythonAnywhere - a fully browser-based Python development and hosting environment PythonAnywhere LLP 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number OC378414. Registered address: 28 Ely Place, 3rd Floor, London EC1N 6TD, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Fri Oct 30 12:11:43 2015 From: larry at hastings.org (Larry Hastings) Date: Fri, 30 Oct 2015 09:11:43 -0700 Subject: [Microbit-Python] Accessor API design on the micro:bit Message-ID: <563396BF.5030703@hastings.org> I want to revisit something that was decided during the sprints at PyCon UK. On a Github PR today ( https://github.com/bbcmicrobit/micropython/pull/58 ) there was a short discussion about how to spell "give me the x coordinate reading from the accelerometer object". I suggested "accelerometer.x". In response, Damien George said: > We discussed this at length at PyCon UK: we use functions for > everything. It's more consistent (and setters like obj.attr = 1 can't > be used in a lambda, while obj.set_attr(1) can). Nick Tollervey said, nigh-simultaneously: > I seem to remember having a conversation about get_foo() v foo or > foo() at PyCon UK. IIRC we agreed to keep such things as method calls > since that's a consistent pattern in the way the API is written. I > also remember a discussion about using explicit verbs in the method > name so kids immediately understood what it was they were calling. > I.e. get_foo() is more obvious than simply just foo(). I'm all for consistency, but in this case I think the group has chosen to be consistent in the wrong way. Things like "accelerometer.x" are /exactly/ what the descriptor protocol is for. The spelling couldn't be clearer, not to mention it's easy to read and pleasingly short to type. I would absolutely 100% design my API that way for adults and I think it's better for kids too. It's true that you can't use an assignment statement in a lambda function. But: 1. one shouldn't warp one's API design to accommodate lambda functions, 2. accelerometer.x is read-only, 3. I doubt the curriculum for 11-year-olds will include lambda, and 4. I propose we strenuously avoid callback-based APIs. ("I don't like callback interfaces, I always get them wrong" --GvR (quote is approximate)) Iteration > callbacks. For example, Python's sched.Scheduler class has a callback-based API, but the Scheduler class I've written for the micro:bit (coming soon!) does not. I'd greatly rather see us make properties of objects behave like simple attributes, using descriptors where necessary. I suggest that's far more Pythonic--accessor functions always feel like Java or C++ to me. (Indeed, ISTM the descriptor protocol was added to Python precisely so we don't ever need accessor functions!) It's our API, we can spell it any way we like. I propose we use simple attributes nearly everywhere, using descriptors where necessary. I'd reserve the .set_x() accessor method spelling for the rare attribute that actively changes something (e.g. microbit.display.set_display_mode). And I still might use a read-only descriptor instead of a .get_x() method for those. (Though I'd have to think about that one, and/or play with some examples.) Cheers, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Fri Oct 30 13:19:04 2015 From: sparks.m at gmail.com (Michael) Date: Fri, 30 Oct 2015 17:19:04 +0000 Subject: [Microbit-Python] Accessor API design on the micro:bit In-Reply-To: <563396BF.5030703@hastings.org> References: <563396BF.5030703@hastings.org> Message-ID: This discussion came up on this mailing list after the Pycon UK sprints as well: > Subject: [Microbit-Python] Flat API > Date: 22 September 2015 at 00:52 ... and in it I raised the issue of properties. (I was in favour of properties) Summarising the thread point was raised that you have a choice: 1 Exposing some things as properties and some as set_{thing} and get_{thing} 2 Exposing everything as properties 3 Exposing everything as set_{thing} and get_{thing} The consensus of that discussion was that (1) would be confusing since rather than one concept for setting/getting things you need to understand 2. In the case of a complete full range ability set in schools, this is problematic. Every Y7 age child in the UK means *every* Y7 child, including those who are the most challenged. (I'm not arguing fighting to build something for lowest common denominator, just not abandoning the lowest quartile - since that way chaos in classroom's ensues... ) That leave 2) and 3). IMO, it's simply not practical to have *everything* as properties. The particular discussion point used that I'm referring to related to pins, and the comment that I'm referring to here is this: Tom Viner wrote: > I don't actually think microbit.dpin0 = True is pythonic if that does anything > other than set (and completely override) a variable value. And I think we > agreed yesterday that standard properties were an extra concept to > explain, and furthermore not introspectable. So that rules out > mb.dpin0 = True too. The argument made the point that you're saying this: somevalue_value = some.name.somewhere some.name.somewhere = 5 means something different to: pin_value = some.name.somewhere some.name.somepin_as_a_property = 5 In terms of the overall effect. In an API designed for standard usage, I wouldn't have a problem with this. Indeed I argued (weakly) for it. However, if instead you have this: pin_value = some.name.somepin.get_value() some.name.somepin.set_value(5) Then you have something you can attach help to. Given that discussion, that suggests that using properties everywhere isn't appropriate, resulting in the choice to use option 3 - to use get_{thing} set_{thing} everywhere. I personally think that that argument is much stronger than the one around lambda's. Indeed, even though the argument for lambdas also applies to list comprehensions etc, I still think that's a weak argument. That said, all 4 points you list in points 1 - 4 I completely agree with. I just don't think this about callbacks. This is more about having just one painfully literally obvious and introspectable way to do it. I do think however, having worked with kids, that when you create an API for children, it really does have to be simpler than most people realise, and get/set is a really good sign post - even though in "real" APIs you wouldn't do that. For example, this is going to 11/12 year olds - in the UK computing syllabus they won't get to object orientation until 16/17 (A-Levels) - which means some schools DO actively avoid anything that looks vaguely object based *because* they're dealing with such a wide range of abilities. (Again, I'm not saying we should pander to that, but knowing about it is useful) ie IMO it's not really a pythonic/non-pythonic decision that was taken back in september, but one focussed on the pedagogical practicalities. (This is a bit like the prototype's DAL was more focussed on pedagogical practicality than the production version's DAL is - I'd always expected to enable older children to hack on the DAL - which won't be practical now AFAICT- but I digress.) For reference, I'm not arguing one way or the other, but just recounting the process that got us here, and as I say, I think the lambda argument is a complete red herring - pretty much for the reasons you say. Regards, Michael On 30 October 2015 at 16:11, Larry Hastings wrote: > > > I want to revisit something that was decided during the sprints at PyCon > UK. On a Github PR today ( > https://github.com/bbcmicrobit/micropython/pull/58 ) there was a short > discussion about how to spell "give me the x coordinate reading from the > accelerometer object". I suggested "accelerometer.x". In response, Damien > George said: > > We discussed this at length at PyCon UK: we use functions for everything. > It's more consistent (and setters like obj.attr = 1 can't be used in a > lambda, while obj.set_attr(1) can). > > > Nick Tollervey said, nigh-simultaneously: > > I seem to remember having a conversation about get_foo() v foo or foo() at > PyCon UK. IIRC we agreed to keep such things as method calls since that's a > consistent pattern in the way the API is written. I also remember a > discussion about using explicit verbs in the method name so kids > immediately understood what it was they were calling. I.e. get_foo() is > more obvious than simply just foo(). > > > I'm all for consistency, but in this case I think the group has chosen to > be consistent in the wrong way. Things like "accelerometer.x" are > *exactly* what the descriptor protocol is for. The spelling couldn't be > clearer, not to mention it's easy to read and pleasingly short to type. I > would absolutely 100% design my API that way for adults and I think it's > better for kids too. > > It's true that you can't use an assignment statement in a lambda function. > But: > > 1. one shouldn't warp one's API design to accommodate lambda functions, > 2. accelerometer.x is read-only, > 3. I doubt the curriculum for 11-year-olds will include lambda, and > 4. I propose we strenuously avoid callback-based APIs. ("I don't like > callback interfaces, I always get them wrong" --GvR (quote is approximate)) > Iteration > callbacks. For example, Python's sched.Scheduler class has a > callback-based API, but the Scheduler class I've written for the micro:bit > (coming soon!) does not. > > > I'd greatly rather see us make properties of objects behave like simple > attributes, using descriptors where necessary. I suggest that's far more > Pythonic--accessor functions always feel like Java or C++ to me. (Indeed, > ISTM the descriptor protocol was added to Python precisely so we don't ever > need accessor functions!) > > It's our API, we can spell it any way we like. I propose we use simple > attributes nearly everywhere, using descriptors where necessary. I'd > reserve the .set_x() accessor method spelling for the rare attribute that > actively changes something (e.g. microbit.display.set_display_mode). And I > still might use a read-only descriptor instead of a .get_x() method for > those. (Though I'd have to think about that one, and/or play with some > examples.) > > > Cheers, > > > */arry* > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Fri Oct 30 16:22:40 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 30 Oct 2015 20:22:40 +0000 Subject: [Microbit-Python] I'm opening up the list right now. Message-ID: <5633D190.6010409@ntoll.org> Hi, So it's Friday, and, as promised, since I've not had any objections I'll make this list public in the following ways: * Archives will be public. * It'll be listed as an available mailing list. * New members won't need my approval to join. Have a great weekend! N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From ntoll at ntoll.org Fri Oct 30 17:15:27 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 30 Oct 2015 21:15:27 +0000 Subject: [Microbit-Python] Accessor API design on the micro:bit In-Reply-To: <563396BF.5030703@hastings.org> References: <563396BF.5030703@hastings.org> Message-ID: <5633DDEF.2040100@ntoll.org> Hi Larry (and Michael), Larry, thank you for playing devil's advocate here and please remember that I too am playing this role. Please also remember that I'm open minded and not precious about my opinions ~ I'm exploring this API problem and, for me at least, I tend to try different things out and sometimes flip flop while I weigh the pros and cons for the different sorts of users of the API. Put simply, here's what's on my mind: * The obviousness argument for the full ability range of 11yo kids that Michael uses in his compelling. Accessors are the coding equivalent of calling a spade a spade - it's hard to get confused by what they're doing despite their verbosity and klunkiness. * Alternatively, I also find it compelling that part of our job as "teachers" is to promote good idiomatic programming so I like Larry's KISS accelerometer.x. It's Pythonic and descriptors are part of the language. It makes me rather uncomfortable that we're making our API look Java-esque rather than Pythonic. Upon reflection, as a music teacher I was used to exactly this situation in a musical context - the general rule of thumb is to do the correct / idiomatic thing (whatever that may be) and teach around it. For example, rhythmic notation is all about fractions / ratios and ('cos we're in Europe) weird historical names like "quaver" and "minim". I couldn't ignore that, but I got quite good at teaching such things to classes of 11yo containing a wide range of abilities - to the extent that they could sight-clap rhythms and write down rhythmic dictation after a few of weeks. Part of me thinks we should just trust the teachers / learners. There's also the argument that a bad teacher will bodge up accessor methods too. I guess I'm saying that no matter what we do, we need to provide plenty of idiomatic examples of different features of the language for teachers and learners to study. I started this email thinking I was for accessors but while re-reading it I find myself more drawn to descriptors. Perhaps that's just a symptom of it being Friday evening and I've had a hellish week at "real work". I'm going to sleep on it before commenting further. Please feel free to shoot me down - as always comments, constructive critique and idea are most welcome! I hope we all agree that no-matter which way we go, we ensure it's consistently applied throughout the API. :-) Best wishes, Nicholas. On 30/10/15 16:11, Larry Hastings wrote: > > > I want to revisit something that was decided during the sprints at PyCon > UK. On a Github PR today ( > https://github.com/bbcmicrobit/micropython/pull/58 ) there was a short > discussion about how to spell "give me the x coordinate reading from the > accelerometer object". I suggested "accelerometer.x". In response, > Damien George said: >> We discussed this at length at PyCon UK: we use functions for >> everything. It's more consistent (and setters like obj.attr = 1 can't >> be used in a lambda, while obj.set_attr(1) can). > > Nick Tollervey said, nigh-simultaneously: >> I seem to remember having a conversation about get_foo() v foo or >> foo() at PyCon UK. IIRC we agreed to keep such things as method calls >> since that's a consistent pattern in the way the API is written. I >> also remember a discussion about using explicit verbs in the method >> name so kids immediately understood what it was they were calling. >> I.e. get_foo() is more obvious than simply just foo(). > > I'm all for consistency, but in this case I think the group has chosen > to be consistent in the wrong way. Things like "accelerometer.x" are > /exactly/ what the descriptor protocol is for. The spelling couldn't be > clearer, not to mention it's easy to read and pleasingly short to type. > I would absolutely 100% design my API that way for adults and I think > it's better for kids too. > > It's true that you can't use an assignment statement in a lambda > function. But: > > 1. one shouldn't warp one's API design to accommodate lambda functions, > 2. accelerometer.x is read-only, > 3. I doubt the curriculum for 11-year-olds will include lambda, and > 4. I propose we strenuously avoid callback-based APIs. ("I don't like > callback interfaces, I always get them wrong" --GvR (quote is > approximate)) Iteration > callbacks. For example, Python's > sched.Scheduler class has a callback-based API, but the Scheduler > class I've written for the micro:bit (coming soon!) does not. > > > I'd greatly rather see us make properties of objects behave like simple > attributes, using descriptors where necessary. I suggest that's far more > Pythonic--accessor functions always feel like Java or C++ to me. > (Indeed, ISTM the descriptor protocol was added to Python precisely so > we don't ever need accessor functions!) > > It's our API, we can spell it any way we like. I propose we use simple > attributes nearly everywhere, using descriptors where necessary. I'd > reserve the .set_x() accessor method spelling for the rare attribute > that actively changes something (e.g. > microbit.display.set_display_mode). And I still might use a read-only > descriptor instead of a .get_x() method for those. (Though I'd have to > think about that one, and/or play with some examples.) > > > Cheers, > > > //arry/ > > > _______________________________________________ > 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: From willingc at willingconsulting.com Fri Oct 30 17:20:55 2015 From: willingc at willingconsulting.com (Carol Willing) Date: Fri, 30 Oct 2015 14:20:55 -0700 Subject: [Microbit-Python] Hello and Hackaday conference Message-ID: <5633DF37.4050408@willingconsulting.com> Hi all, Thanks to all for the great work on the Microbit and Micropython. I have a couple of the early PyBoards and they are great fun to tinker on. I'm attending the Hackaday SuperConference (https://hackaday.io/superconference/) in a couple of weeks. I've been asked to give a lightning talk. Please let me know if you would like me to give one on the Microbit and Micropython. Alternatively, I'll be sharing the Raspberry Pi, Jupyter, and game controller stuff. Carol -- *Carol Willing* Developer | Willing Consulting https://willingconsulting.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Fri Oct 30 17:27:22 2015 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 30 Oct 2015 21:27:22 +0000 Subject: [Microbit-Python] Hello and Hackaday conference In-Reply-To: <5633DF37.4050408@willingconsulting.com> References: <5633DF37.4050408@willingconsulting.com> Message-ID: <5633E0BA.9060608@ntoll.org> On 30/10/15 21:20, Carol Willing wrote: > I'm attending the Hackaday SuperConference > (https://hackaday.io/superconference/) in a couple of weeks. I've been > asked to give a lightning talk. Please let me know if you would like me > to give one on the Microbit and Micropython. Alternatively, I'll be > sharing the Raspberry Pi, Jupyter, and game controller stuff. > Yes yes yes yes yes yes..! :-) I'll post another email soon about an idea for how to make the limited stock of devices available to as many of the community as possible for exactly such circumstances. N. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From sparks.m at gmail.com Fri Oct 30 18:25:33 2015 From: sparks.m at gmail.com (Michael) Date: Fri, 30 Oct 2015 22:25:33 +0000 Subject: [Microbit-Python] Accessor API design on the micro:bit In-Reply-To: <5633DDEF.2040100@ntoll.org> References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org> Message-ID: On 30 October 2015 at 21:15, Nicholas H.Tollervey wrote: > Hi Larry (and Michael), > > Larry, thank you for playing devil's advocate here and please remember > that I too am playing this role. Please also remember that I'm open > minded and not precious about my opinions ~ I'm exploring this API > problem and, for me at least, I tend to try different things out and > sometimes flip flop while I weigh the pros and cons for the different > sorts of users of the API. > > Put simply, here's what's on my mind: > > * The obviousness argument for the full ability range of 11yo kids that > Michael uses in his compelling. Accessors are the coding equivalent of > calling a spade a spade - it's hard to get confused by what they're > doing despite their verbosity and klunkiness. > The argument that convinced me was Tom Viner's one summarising the discussion from the sprints - the fact that it gives you additional help as to what will happen when you do something, and that something is available. You don't really get that with the descriptor protocol - because the variables become magic variables/magic attributes in the eyes of the user. (On that basis, consider that time.time() is a function...) That's perhaps why properties would need explaining - the value accelerometer.x would return would change without you doing anything, but other named values don't. If we weren't targetting *every* ability group, and targetting just the subset of 14-16 year olds studying this for an exam, I'd stand up for doing it "right" and using a property here (since it does make sense for idiomatic python). But we're targetting those that don't even know if they can do things or would want to do things. The idea of dealing with things idiomatically in music I get, and if you take an analogy used on twitter the other day in a discussion, there were comments about grade 1, grade 2, grade 3, etc. Before you reach grade 1 though, you need to decide that actually doing something with it is itself worthwhile. Yes, you can bash a drum as much as you like, whack a piano, blow a trumpet, make a horrible noise with a violin, but there has to be a concious decision to go from *that* to choosing to do it properly. With an instrument, that's easy, you do what's obvious and see what you can do. You'll it badly, but then decide if it's worthwhile. In my eyes, that's the real aim of the micro:bit - to have a digital programming instrument that you can play with and decide later if it's something you want to take further, and *then* also to be the thing you can use to take further. Remember, while the devices are being shipped through schools, they'll be owned by the children themselves. Furthermore, the target isn't the geek who wants to learn to code -- though they will probably benefit the most (with luck). It isn't the Alan O'Donohoe's[1] of the world, because teachers like him are awesome, and will use anything and everything they can to inspire their kids (and again, this will help them too with luck). The target is the children of the teachers who say "let's not do computer science, and only teach usage of applications" - as I *have* heard *some* local teachers say. It's the children of children in a girls only school (oddly single sex schools still exist), who think "programming isn't for girls" (again, scarily DOES still happen). It's for the child who likes playing with using applications and it's never crossed their mind that they can make them themselves. It's for the artist, the musician, and so on - the ones who self-select *away* from coding. And for me that also includes the kids who are from the most deprived areas of the UK. ie don't think "good teacher", think "unsupported child who doesn't know if they want to do this stuff". (Hm, went off on one there, sorry! :) ) [1] I'm using Alan as an example since I'm pretty sure he'll approve :-) Anyway, for them, "making some noise" (or more specifically with the default starting point "tell stories, flash patterns, make games"), is more important than "doing it right" - the reason being that that aspect of "making some noise" will encourage them to want to learn to "do it right". On the specific example of the accelerometer, I see little merit either way of saying "it should be a get thing or property". (The halfway house that touch develop uses incidentally for this example is accelerometer("x") which seems reasonable - but also completely different from what we have in other areas) It was Tom's point that if you have get/set *and* properties, then that's an additional thing to deal with, and that get/set automatically give you something natural to hang documentation off that I quite liked. On the flip side - there is also the other element - micro:bit should also give people a good reason to want to learn how/why something works, and is part of why there's some concious decisions in there for things NOT to match some expectations that people bring with them. (The most obvious example to a non-programmer being the fact that the display origin is top-left - like all major graphics systems, but "wrong" relative to bottom left being the origin in maths) So, while I'm in favour of picking one approach - descriptors all the way or get/set all the way - I can see good reason for actively choosing to break that rule. If we do, we can then signpost that it works differently and why. The niggle at the back of my mind is that if you do "accel.x/y/z" this way, why not temp, "compass", time, pins, buttons and LEDs - as raised back in the thread "Flat API". Last point, I think the reason why accel.x() or accel.get_x() seems slightly more appropriate is due to the fact it's the result of a function call makes it very obvious that you can't change the value. > I hope we all agree that no-matter which way we go, we ensure it's > consistently applied throughout the API. > Likewise. I personally wouldn't use accessors normally - but in this case I would - largely because the API as a whole at present has a more "accessor--y" feel to it which seems pretty nice to use. Going back to the music analogy though, if we did python as "grades" I'd expect being able to use a function to do things to be grade 1, using python properties as grade 2 or 3, understanding them grade 3, and implementing them as grade 4 or 5 :-) (I never did grades 1,2,3, etc for any instrument, but I know kids who do, and IME grade 1 means you can bang the rocks together, grade 3 you start get an understanding as to why you're banging rocks, and somewhere closer to grade 6 why you're banging those rocks and why they do a specific thing when you bang them) Anyway, I've probably said too much now, so leave my comments there :) Regards, Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sparks.m at gmail.com Fri Oct 30 17:16:16 2015 From: sparks.m at gmail.com (Michael) Date: Fri, 30 Oct 2015 21:16:16 +0000 Subject: [Microbit-Python] I'm opening up the list right now. In-Reply-To: <5633D190.6010409@ntoll.org> References: <5633D190.6010409@ntoll.org> Message-ID: Fantastic milestone -- best news all day :-) Regards, Michael. On 30 October 2015 at 20:22, Nicholas H.Tollervey wrote: > Hi, > > So it's Friday, and, as promised, since I've not had any objections I'll > make this list public in the following ways: > > * Archives will be public. > * It'll be listed as an available mailing list. > * New members won't need my approval to join. > > Have a great weekend! > > N. > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Sat Oct 31 12:29:21 2015 From: larry at hastings.org (Larry Hastings) Date: Sat, 31 Oct 2015 09:29:21 -0700 Subject: [Microbit-Python] Accessor API design on the micro:bit In-Reply-To: References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org> Message-ID: <5634EC61.4020003@hastings.org> On 10/30/2015 03:25 PM, Michael wrote: > The argument that convinced me was Tom Viner's one summarising the > discussion from the sprints - the fact that it gives you additional > help as to what will happen when you do something, and that something > is available. I don't appear to have Tom's summary. And I don't know what help you're talking about--do you mean docstrings? Right now I didn't think hardly anything in the micro:bit API had docstrings, and I didn't think that was likely to change. And while you and I are comfortable in the REPL, I'm not convinced that the kids will spend a lot of time there. > That's perhaps why properties would need explaining - the value > accelerometer.x would return would change without you doing anything, > but other named values don't. Is that actually a problem? Surely children are familiar with objects that change their own state--clocks and televisions for example. Someone who's new to programming wouldn't have the preconceived notion that "accelerometer.x won't change until I tell it to". I'm not sure it needs explaining past "accelerometer.x is the current value of the accelerometer, it refreshes itself". Incidentally, the way it works right now, there's an idle thread that among other things updates the accelerometer and compass readings. accelerometer.get_x() currently doesn't compute anything, it's literally one line of code, returning a private member of the object. So it /already/ changes without you doing anything. The fact that it's hidden behind a function call is a bit misleading, if anything. > So, while I'm in favour of picking one approach - descriptors all the > way or get/set all the way - I can see good reason for actively > choosing to break that rule. If we do, we can then signpost that it > works differently and why. > > The niggle at the back of my mind is that if you do "accel.x/y/z" this > way, why not temp, "compass", time, pins, buttons and LEDs - as raised > back in the thread "Flat API". The rule I use, which I admit is a bit subjective, is that descriptors are good if: * you don't need to specify parameters (because, after all, you can't specify any) * you feel like you're passively getting a value, not executing live code (e.g. Subprocess.return_value shouldn't execute the program, just return the result once it's been executed) A little magic behind a descriptor is okay, like constructing a database query object then accessing fields might actually lazy-run the query from inside a descriptor. Unsurprisingly, I think computing the current value of an accelerometer axis is a fine candidate for a descriptor ;-) If descriptors were bad, Guido would hop in his time machine and take them away from us, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From larry at hastings.org Sat Oct 31 12:30:51 2015 From: larry at hastings.org (Larry Hastings) Date: Sat, 31 Oct 2015 09:30:51 -0700 Subject: [Microbit-Python] Accessor API design on the micro:bit In-Reply-To: <5633DDEF.2040100@ntoll.org> References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org> Message-ID: <5634ECBB.4070308@hastings.org> Private, off-list: On 10/30/2015 02:15 PM, Nicholas H.Tollervey wrote: > * Alternatively, I also find it compelling that part of our job as > "teachers" is to promote good idiomatic programming so I like Larry's > KISS accelerometer.x. It's Pythonic and descriptors are part of the > language. It makes me rather uncomfortable that we're making our API > look Java-esque rather than Pythonic. I just wanted to say, that was a whole lot less jeez-Larry-give-it-a-rest-already than I thought it was going to be ;-) I may have a longer on-list reply sometime soon. I just wanted to touch base and say... phew! Not shot down yet, //arry/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at hotpy.org Sat Oct 31 12:50:55 2015 From: mark at hotpy.org (Mark Shannon) Date: Sat, 31 Oct 2015 16:50:55 +0000 Subject: [Microbit-Python] Accessor API design on the micro:bit In-Reply-To: <5634EC61.4020003@hastings.org> References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org> <5634EC61.4020003@hastings.org> Message-ID: <5634F16F.6000407@hotpy.org> Hi, W.r.t. to .get_x()/.x()/.x for the accelerometer API, I would like to point out that functions are descriptors objects. Therefore, suggesting that using properties is some how magically and methods are not, seems to me to be a bit of a red herring. For example, we can already do this: >>> p = display.print >>> c = Image.NO.crop >>> p(c(1,1,4,4)) type(display).print and Image.crop may be functions, but p and c are bound-methods. I think the issue worth discussing is consistency vs. Pythonic-ness. Is it better that all interactions with the hardware are via a function or method interface, or is better to have a more Pythonic interface even though it may make it a bit harder to understand? Cheers, Mark On 31/10/15 16:29, Larry Hastings wrote: > > > On 10/30/2015 03:25 PM, Michael wrote: >> The argument that convinced me was Tom Viner's one summarising the >> discussion from the sprints - the fact that it gives you additional >> help as to what will happen when you do something, and that something >> is available. > > I don't appear to have Tom's summary. And I don't know what help you're > talking about--do you mean docstrings? Right now I didn't think hardly > anything in the micro:bit API had docstrings, and I didn't think that > was likely to change. And while you and I are comfortable in the REPL, > I'm not convinced that the kids will spend a lot of time there. > > >> That's perhaps why properties would need explaining - the value >> accelerometer.x would return would change without you doing anything, >> but other named values don't. > > Is that actually a problem? Surely children are familiar with objects > that change their own state--clocks and televisions for example. > Someone who's new to programming wouldn't have the preconceived notion > that "accelerometer.x won't change until I tell it to". I'm not sure it > needs explaining past "accelerometer.x is the current value of the > accelerometer, it refreshes itself". > > Incidentally, the way it works right now, there's an idle thread that > among other things updates the accelerometer and compass readings. > accelerometer.get_x() currently doesn't compute anything, it's literally > one line of code, returning a private member of the object. So it > /already/ changes without you doing anything. The fact that it's hidden > behind a function call is a bit misleading, if anything. > > >> So, while I'm in favour of picking one approach - descriptors all the >> way or get/set all the way - I can see good reason for actively >> choosing to break that rule. If we do, we can then signpost that it >> works differently and why. >> >> The niggle at the back of my mind is that if you do "accel.x/y/z" this >> way, why not temp, "compass", time, pins, buttons and LEDs - as raised >> back in the thread "Flat API". > > The rule I use, which I admit is a bit subjective, is that descriptors > are good if: > > * you don't need to specify parameters (because, after all, you can't > specify any) > * you feel like you're passively getting a value, not executing live > code (e.g. Subprocess.return_value shouldn't execute the program, > just return the result once it's been executed) > > A little magic behind a descriptor is okay, like constructing a database > query object then accessing fields might actually lazy-run the query > from inside a descriptor. Unsurprisingly, I think computing the current > value of an accelerometer axis is a fine candidate for a descriptor ;-) > > > If descriptors were bad, Guido would hop in his time machine and take > them away from us, > > > //arry/ > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From sparks.m at gmail.com Sat Oct 31 14:27:12 2015 From: sparks.m at gmail.com (Michael) Date: Sat, 31 Oct 2015 18:27:12 +0000 Subject: [Microbit-Python] Accessor API design on the micro:bit In-Reply-To: <5634EC61.4020003@hastings.org> References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org> <5634EC61.4020003@hastings.org> Message-ID: On 31 October 2015 at 16:29, Larry Hastings wrote: > > > On 10/30/2015 03:25 PM, Michael wrote: > > The argument that convinced me was Tom Viner's one summarising the > discussion from the sprints - the fact that it gives you additional help as > to what will happen when you do something, and that something is available. > > > I don't appear to have Tom's summary. > I replied in list, Tom replied to me with his summary. You also replied to me. Thread is archived here: https://mail.python.org/pipermail/microbit/2015-September/000233.html > And I don't know what help you're talking about--do you mean docstrings? > Right now I didn't think hardly anything in the micro:bit API had > docstrings, and I didn't think that was likely to change. > I was assuming that once things stablised that this would change. > And while you and I are comfortable in the REPL, I'm not convinced that > the kids will spend a lot of time there. > Reading the CAS forums, one of the things schools like about python is the REPL. That's perhaps why properties would need explaining - the value > accelerometer.x would return would change without you doing anything, but > other named values don't. > > > Is that actually a problem? > Yes, I DO think it is. I've seen a lot of non-technical people and kids (and when I was at Uni back in the 90's other CS students...), and others learning repeatedly store things "just to make sure". Yes, I know it's "silly", but child coders *are* silly and unsure. This is REALLY good IMO since they have fewer pre-concieved notions, but a risk in terms of being much easier to confuse. ("variables don't change unless you change them", "but this thing that looks like one to you does") As I said before, I think a descriptor based approach of just doing "accelerometer.x" is perfectly fine - and appropriate - for the general case. When building things for kids, I don't expect them to be able to handle everything, I'd throw a bone that this something changes underneath and do accelerometer.x() (or accelerometer.get_x() etc). IMO, it's simply the difference between a bike with stablisers vs a bike without. Incidentally, the way it works right now, there's an idle thread that among > other things updates the accelerometer and compass readings. > accelerometer.get_x() currently doesn't compute anything, it's literally > one line of code, returning a private member of the object. So it > *already* changes without you doing anything. > Yes, I expected that. The fact that it's hidden behind a function call is a bit misleading, if > anything. > Not really - it depends on how many concepts you want to teach when starting out. I personally favour the absolute minimal set, used as expressively as possible. In this case, putting it behind a function hides the complexity of the fact that it's being updated by an idle thread. (An irrelevant detail that can easily lead to derail a class - which when you have 1 teacher and 30 kids can cause issues) The cheat sheets teachers use for teaching python at the moment are *really* simple (astonishly so in fact), and it's very *very* easy to under-estimate that first step on the rung for a general ability class. > If descriptors were bad, Guido would hop in his time machine and take them away from us, I'm not sure that's helpful -- I find argument from authority with hyperbole the sort of argument that just makes me want to walk away. That's not your intent, so instead I'd just say this: I'm not saying descriptors are *in general* bad (by which I assume you mean properties). I am saying that it's an extra concept that's being used to make things "nice", at the expense of making the initial speed bumps harder. My comments are based on working with kids and knowing that what can take an adult 5 minutes generally at this age can take an hour or two, and that's for each extra thing. (When planning something for a cubs session, if it takes longer than 5-10 minutes for an adult, it's generally a sign that it'll be too difficult for children to achieve in an hour or so) Once again, as I said before, I'm not adverse to the idea of saying "Yes, we actively choose to do this", but if we do, it needs to be clearly sign-posted as to why it's different and how. After all, having examples of why you choose to create an API in a certain way is a good/useful thing. Best Regards, Michael. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willingc at willingconsulting.com Sat Oct 31 16:08:09 2015 From: willingc at willingconsulting.com (Carol Willing) Date: Sat, 31 Oct 2015 13:08:09 -0700 Subject: [Microbit-Python] Accessor API design on the micro:bit In-Reply-To: References: <563396BF.5030703@hastings.org> <5633DDEF.2040100@ntoll.org> <5634EC61.4020003@hastings.org> Message-ID: <56351FA9.3080809@willingconsulting.com> While I am joining this discussion after a couple of months of history, I am going to step back for a moment and ask a simple question: Does this have to be a decision between x, x(), get_x()? For the accelerometer (not necessarily all other functionality, but since the accelerometer is built into the chip and accessible without soldering anything, it will be used by many), could we support all three? If I was an 11 year old with access to Google, I could find resources appropriate for an 11 year old that use all three of these approaches: Young Coders workshop, Adafruit/Sparkfun, MicroPython tutorials, Python for Kids book, and others. If I didn't have access to Google, I, as a student, would use `help` or example programs to model what I would choose. It's critical for the educational setting for the approach to be consistent within an example program. While in a perfect world that might imply consistent across all example programs. Yet, we know that there are several approaches to programming that lend the same result but with differing implementations. It seems to me if there is space to support all three for the accelerometer that would make reasonable sense. We can tailor the help message to guide to the desired approach; yet, all three will work for the student whether they are using a recommended approach or something that they googled. Based on my experience teaching a wide spectrum of children, I do think with gentle instruction all levels will be able to use the accelerometer. Warmly, Carol -- *Carol Willing* Developer | Willing Consulting https://willingconsulting.com -------------- next part -------------- An HTML attachment was scrubbed... URL: