From mail at kushaldas.in Tue Nov 1 04:42:45 2016 From: mail at kushaldas.in (Kushal Das) Date: Tue, 1 Nov 2016 14:12:45 +0530 Subject: [Microbit-Python] Sprint with MicroPython on ESP8266 and BBC microbits In-Reply-To: References: <5814F51C.1020401@egenix.com> <581757F8.6000701@egenix.com> <54515882-4d65-28cd-b2a2-f8cbacf1970b@ntoll.org> Message-ID: <20161101084245.GA11697@kdas-laptop> On 31/10/16, Nevil Hunt wrote: > Hi Nicholas, > > > Were you running the ESP8266 stand alone using micro python or did you have it hooked up to a micro:bit? > For direct usage on MicroPython one can follow [1]. [1] micropython-on-esp8266-workshop.readthedocs.io Kushal -- Fedora Cloud Engineer CPython Core Developer https://kushaldas.in https://dgplug.org From nevil.hunt at hotmail.co.uk Tue Nov 1 11:46:30 2016 From: nevil.hunt at hotmail.co.uk (Nevil Hunt) Date: Tue, 1 Nov 2016 15:46:30 +0000 Subject: [Microbit-Python] Creating Hex File from Mu? Message-ID: Does anyone know if there is a way to generate a Hex file from Mu, rather than just downloading it directly? The reason why I'm asking is that once I've finished a program I like to keep the Hex file so I can quickly reload it without access to Mu. I've been doing this by developing in Mu but once complete copying-and-pasting into the Web Python Editor to generate the final Hex. I've now just started using the Radio module and the Web tool doesn't yet support Radio! Alternatively is there a way to read the Hex file off a micro:bit? Then I could program using Mu and save the final Hex file by reading it back from the micro:bit. Cheers, Nevil -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlosperate at gmail.com Tue Nov 1 12:09:55 2016 From: carlosperate at gmail.com (Carlos Pereira Atencio) Date: Tue, 1 Nov 2016 16:09:55 +0000 Subject: [Microbit-Python] Creating Hex File from Mu? In-Reply-To: References: Message-ID: Hi Nevil, You can unplug the microbit from the computer, in which case Mu won?t be able to automatically detect it and so it will ask you to manually locate it with a directory dialogue. You can then just select any folder on your computer to save the hex file. It is worth pointing out that the Python editor from the http://python.microbit.org website (note the .org instead of .co.uk) should be updated with the latest MicroPython. At the moment as far as I know there is no way to read the contents of flash. On 1 November 2016 at 15:46, Nevil Hunt wrote: > Does anyone know if there is a way to generate a Hex file from Mu, rather > than just downloading it directly? > > > The reason why I'm asking is that once I've finished a program I like to > keep the Hex file so I can quickly reload it without access to Mu. > > I've been doing this by developing in Mu but once complete > copying-and-pasting into the Web Python Editor to generate the final Hex. > > I've now just started using the Radio module and the Web tool doesn't yet > support Radio! > > > Alternatively is there a way to read the Hex file off a micro:bit? Then I > could program using Mu and save the final Hex file by reading it back from > the micro:bit. > > > > Cheers, > > > Nevil > > _______________________________________________ > 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 Nov 1 12:17:50 2016 From: david at thinkingbinaries.com (David Whale) Date: Tue, 1 Nov 2016 16:17:50 +0000 Subject: [Microbit-Python] Creating Hex File from Mu? In-Reply-To: References: Message-ID: Yes just leave micro bit unplugged and when it says 'find microbit' just navigate to the folder to save it. It will create a local micropython.hex that is the file that would have been flashed. David On 1 Nov 2016 3:46 pm, "Nevil Hunt" wrote: > Does anyone know if there is a way to generate a Hex file from Mu, rather > than just downloading it directly? > > > The reason why I'm asking is that once I've finished a program I like to > keep the Hex file so I can quickly reload it without access to Mu. > > I've been doing this by developing in Mu but once complete > copying-and-pasting into the Web Python Editor to generate the final Hex. > > I've now just started using the Radio module and the Web tool doesn't yet > support Radio! > > > Alternatively is there a way to read the Hex file off a micro:bit? Then I > could program using Mu and save the final Hex file by reading it back from > the micro:bit. > > > > Cheers, > > > Nevil > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nevil.hunt at hotmail.co.uk Tue Nov 1 12:49:48 2016 From: nevil.hunt at hotmail.co.uk (Nevil Hunt) Date: Tue, 1 Nov 2016 16:49:48 +0000 Subject: [Microbit-Python] Creating Hex File from Mu? In-Reply-To: References: , Message-ID: Thanks David/Carlos Yes, that works! It gives the Hex file the default file name micropython.hex so I just needed to rename it. As far as the Web Editor is concerned the "start with this editor" button takes you back to the BBC version. I should have used the "try beta editor with radio" button which takes you to microbit.org (the clue was in the button name but I didn't spot it first time!) Nevil ________________________________ From: Microbit on behalf of David Whale Sent: 01 November 2016 16:17 To: For Pythonic MicroBit related disucssions Subject: Re: [Microbit-Python] Creating Hex File from Mu? Yes just leave micro bit unplugged and when it says 'find microbit' just navigate to the folder to save it. It will create a local micropython.hex that is the file that would have been flashed. David On 1 Nov 2016 3:46 pm, "Nevil Hunt" > wrote: Does anyone know if there is a way to generate a Hex file from Mu, rather than just downloading it directly? The reason why I'm asking is that once I've finished a program I like to keep the Hex file so I can quickly reload it without access to Mu. I've been doing this by developing in Mu but once complete copying-and-pasting into the Web Python Editor to generate the final Hex. I've now just started using the Radio module and the Web tool doesn't yet support Radio! Alternatively is there a way to read the Hex file off a micro:bit? Then I could program using Mu and save the final Hex file by reading it back from the micro:bit. Cheers, Nevil _______________________________________________ Microbit mailing list Microbit at python.org https://mail.python.org/mailman/listinfo/microbit -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jonathan.Austin at arm.com Tue Nov 1 14:29:12 2016 From: Jonathan.Austin at arm.com (Jonathan Austin) Date: Tue, 1 Nov 2016 18:29:12 +0000 Subject: [Microbit-Python] Creating Hex File from Mu? In-Reply-To: References: Message-ID: <74AD98B6-2460-492E-BD02-613E24F975DE@arm.com> On 1 Nov 2016, at 16:17, David Whale > wrote: Yes just leave micro bit unplugged and when it says 'find microbit' just navigate to the folder to save it. It will create a local micropython.hex that is the file that would have been flashed. Admittedly this is a valid workaround, but I wonder if it might be more useful to have a ?save as? style dialogue where you can choose ?hex? or ?python? ? The nice thing about saving hex is that you know that file will work - I recently had to go and fetch an older version of Mu in order to build a python file that had previously built but was now running out of memory. Jonny David On 1 Nov 2016 3:46 pm, "Nevil Hunt" > wrote: Does anyone know if there is a way to generate a Hex file from Mu, rather than just downloading it directly? The reason why I'm asking is that once I've finished a program I like to keep the Hex file so I can quickly reload it without access to Mu. I've been doing this by developing in Mu but once complete copying-and-pasting into the Web Python Editor to generate the final Hex. I've now just started using the Radio module and the Web tool doesn't yet support Radio! Alternatively is there a way to read the Hex file off a micro:bit? Then I could program using Mu and save the final Hex file by reading it back from the micro:bit. Cheers, Nevil _______________________________________________ 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at thinkingbinaries.com Fri Nov 4 17:24:35 2016 From: david at thinkingbinaries.com (David Whale) Date: Fri, 4 Nov 2016 21:24:35 +0000 Subject: [Microbit-Python] 4800bps on UART on pins on edge connector Message-ID: Has anyone used 4800bps on the UART object bound to edge connector pins? I have reports from someone in the community of it sending corrupted characters, although I haven't managed to find my FTDI-232-3V device yet in my box of tricks to replicate this issue. If nobody has used 4800bps yet, is it possible there is a baud rate divisor issue? I'll try and find some hardware I can use to replicate this, but I just thought I would put a call out in case anyone else has tried this and seen it already work. Thanks! David -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at groklearning.com Sat Nov 5 06:48:45 2016 From: jim at groklearning.com (Jim Mussared) Date: Sat, 5 Nov 2016 21:48:45 +1100 Subject: [Microbit-Python] 4800bps on UART on pins on edge connector In-Reply-To: References: Message-ID: hi David, No issues here - using firmware from Mu updated from github today, 4800 baud, 75kB message, verified bit timing on the scope, and no trouble receiving on a bus pirate or standalone FTDI. If you can give me more info about the code that's running I can try and repro. Jim On 5 November 2016 at 08:24, David Whale wrote: > Has anyone used 4800bps on the UART object bound to edge connector pins? I > have reports from someone in the community of it sending corrupted > characters, although I haven't managed to find my FTDI-232-3V device yet in > my box of tricks to replicate this issue. > > If nobody has used 4800bps yet, is it possible there is a baud rate divisor > issue? > > I'll try and find some hardware I can use to replicate this, but I just > thought I would put a call out in case anyone else has tried this and seen > it already work. > > Thanks! > > David > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From david at thinkingbinaries.com Sat Nov 5 07:12:02 2016 From: david at thinkingbinaries.com (David Whale) Date: Sat, 5 Nov 2016 11:12:02 +0000 Subject: [Microbit-Python] 4800bps on UART on pins on edge connector In-Reply-To: References: Message-ID: Thanks Jim, that's good to know. It might be the users code then, rather than any specific problem with serial, at least that narrows it down a bit. David ___________________________________________________________ David Whale, B.Sc (Hons), MIET *Software Engineer and IET Schools Liaison Officer, Essex* On 5 November 2016 at 10:48, Jim Mussared via Microbit wrote: > hi David, > > No issues here - using firmware from Mu updated from github today, > 4800 baud, 75kB message, verified bit timing on the scope, and no > trouble receiving on a bus pirate or standalone FTDI. > > If you can give me more info about the code that's running I can try and > repro. > > Jim > > On 5 November 2016 at 08:24, David Whale > wrote: > > Has anyone used 4800bps on the UART object bound to edge connector pins? > I > > have reports from someone in the community of it sending corrupted > > characters, although I haven't managed to find my FTDI-232-3V device yet > in > > my box of tricks to replicate this issue. > > > > If nobody has used 4800bps yet, is it possible there is a baud rate > divisor > > issue? > > > > I'll try and find some hardware I can use to replicate this, but I just > > thought I would put a call out in case anyone else has tried this and > seen > > it already work. > > > > Thanks! > > > > David > > > > > > _______________________________________________ > > 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 Nov 5 07:17:06 2016 From: david at thinkingbinaries.com (David Whale) Date: Sat, 5 Nov 2016 11:17:06 +0000 Subject: [Microbit-Python] 4800bps on UART on pins on edge connector In-Reply-To: References: Message-ID: I've pointed the user at the mailing list, so hopefully they will post a question and code there, that we can pick up on. Thanks for your help Jim, David ___________________________________________________________ David Whale, B.Sc (Hons), MIET *Software Engineer and IET Schools Liaison Officer, Essex* On 5 November 2016 at 11:12, David Whale wrote: > Thanks Jim, that's good to know. > > It might be the users code then, rather than any specific problem with > serial, at least that narrows it down a bit. > > David > > > ___________________________________________________________ > David Whale, B.Sc (Hons), MIET > *Software Engineer and IET Schools Liaison Officer, Essex* > > > On 5 November 2016 at 10:48, Jim Mussared via Microbit < > microbit at python.org> wrote: > >> hi David, >> >> No issues here - using firmware from Mu updated from github today, >> 4800 baud, 75kB message, verified bit timing on the scope, and no >> trouble receiving on a bus pirate or standalone FTDI. >> >> If you can give me more info about the code that's running I can try and >> repro. >> >> Jim >> >> On 5 November 2016 at 08:24, David Whale >> wrote: >> > Has anyone used 4800bps on the UART object bound to edge connector >> pins? I >> > have reports from someone in the community of it sending corrupted >> > characters, although I haven't managed to find my FTDI-232-3V device >> yet in >> > my box of tricks to replicate this issue. >> > >> > If nobody has used 4800bps yet, is it possible there is a baud rate >> divisor >> > issue? >> > >> > I'll try and find some hardware I can use to replicate this, but I just >> > thought I would put a call out in case anyone else has tried this and >> seen >> > it already work. >> > >> > Thanks! >> > >> > David >> > >> > >> > _______________________________________________ >> > 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 barrachri at gmail.com Tue Nov 15 06:23:36 2016 From: barrachri at gmail.com (Christian Barra) Date: Tue, 15 Nov 2016 12:23:36 +0100 Subject: [Microbit-Python] Poland:Microbit In-Reply-To: References: <553bb6f6-1f1f-302e-6820-cd5eb0d93a3c@ntoll.org> <597d3998-5185-3e02-422f-ba8cbf81e0fa@ntoll.org> <20161030224201.71024602@ghostwheel> Message-ID: We are online ! www.microbitpolska.org I changed the name of the repo: https://github.com/MicrobitPolska -------------- next part -------------- An HTML attachment was scrubbed... URL: From nevil.hunt at hotmail.co.uk Wed Nov 16 04:04:57 2016 From: nevil.hunt at hotmail.co.uk (Nevil Hunt) Date: Wed, 16 Nov 2016 09:04:57 +0000 Subject: [Microbit-Python] Can the micro:bit display text on the Adafruit OLED display? Message-ID: Hi, Thanks to help from Phillip at Adafruit I have the Adafruit 128x32 I2C OLED display (www.adafruit.com/product/931) working with the micro:bit using their Micro Python driver (https://github.com/adafruit?query=micropython) see attached photo. However I am limited to just generating patterns but I would like to generate text! Adafruit's view on this is that generating text could be difficult a) because there is limited available RAM on the micro:bit, and b) because they don't have access to the micro:bit's internal font. Does anyone have any thoughts on this? e.g. Can Python get access to the internal font? If so, how could this font be used to generate characters on the OLED display without running out of RAM? Cheers, Nevil -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: microbit-adafruit-128x32-I2C-OLED-Display.jpg Type: image/jpeg Size: 287024 bytes Desc: microbit-adafruit-128x32-I2C-OLED-Display.jpg URL: From mark at hotpy.org Thu Nov 17 04:57:16 2016 From: mark at hotpy.org (Mark Shannon) Date: Thu, 17 Nov 2016 09:57:16 +0000 Subject: [Microbit-Python] Can the micro:bit display text on the Adafruit OLED display? In-Reply-To: References: Message-ID: <033b0dc7-1e75-8d70-a59e-fac8dda9223c@hotpy.org> Hi Nevil, The simplest thing to do is to write code that mirrors the micro:bit display onto the external display: def update_external_display(): for x in range(5): for y in range(5) external_display.set_pixel(x, y, display.get_pixel(x, y)) Then use the normal display code. Or, you can get the font data by creating an Image from a character: >>> Image("%") Image('99009:90090:00900:09009:90099:') Cheers, Mark. On 16/11/16 09:04, Nevil Hunt wrote: > Hi, > > > Thanks to help from Phillip at Adafruit I have the Adafruit 128x32 I2C > OLED display (www.adafruit.com/product/931 > ) working with the micro:bit using > their Micro Python > driver (https://github.com/adafruit?query=micropython) see attached > photo. However I am limited to just generating patterns but I would like > to generate text! > > > Adafruit's view on this is that generating text could be difficult > > a) because there is limited available RAM on the micro:bit, and > > b) because they don't have access to the micro:bit's internal font. > > > Does anyone have any thoughts on this? > > e.g. Can Python get access to the internal font? > > If so, how could this font be used to generate characters on the OLED > display without running out of RAM? > > > > Cheers, > > > Nevil > > > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From mal at egenix.com Thu Nov 17 05:43:46 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Thu, 17 Nov 2016 11:43:46 +0100 Subject: [Microbit-Python] Can the micro:bit display text on the Adafruit OLED display? In-Reply-To: <033b0dc7-1e75-8d70-a59e-fac8dda9223c@hotpy.org> References: <033b0dc7-1e75-8d70-a59e-fac8dda9223c@hotpy.org> Message-ID: <582D89E2.1010107@egenix.com> On 17.11.2016 10:57, Mark Shannon wrote: > Or, you can get the font data by creating an Image from a character: > >>>> Image("%") > Image('99009:90090:00900:09009:90099:') Thanks for that little trick :-) I was always wondering how I could get at the font definitions of the chars. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 17 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ From nevil.hunt at hotmail.co.uk Thu Nov 17 05:46:25 2016 From: nevil.hunt at hotmail.co.uk (Nevil Hunt) Date: Thu, 17 Nov 2016 10:46:25 +0000 Subject: [Microbit-Python] Can the micro:bit display text on the Adafruit OLED display? In-Reply-To: <033b0dc7-1e75-8d70-a59e-fac8dda9223c@hotpy.org> References: , <033b0dc7-1e75-8d70-a59e-fac8dda9223c@hotpy.org> Message-ID: Thanks Mark! I'll give that a go! Nevil ________________________________ From: Microbit on behalf of Mark Shannon Sent: 17 November 2016 09:57 To: microbit at python.org Subject: Re: [Microbit-Python] Can the micro:bit display text on the Adafruit OLED display? Hi Nevil, The simplest thing to do is to write code that mirrors the micro:bit display onto the external display: def update_external_display(): for x in range(5): for y in range(5) external_display.set_pixel(x, y, display.get_pixel(x, y)) Then use the normal display code. Or, you can get the font data by creating an Image from a character: >>> Image("%") Image('99009:90090:00900:09009:90099:') Cheers, Mark. On 16/11/16 09:04, Nevil Hunt wrote: > Hi, > > > Thanks to help from Phillip at Adafruit I have the Adafruit 128x32 I2C > OLED display (www.adafruit.com/product/931 > ) working with the micro:bit using > their Micro Python > driver (https://github.com/adafruit?query=micropython) see attached > photo. However I am limited to just generating patterns but I would like > to generate text! > > > Adafruit's view on this is that generating text could be difficult > > a) because there is limited available RAM on the micro:bit, and > > b) because they don't have access to the micro:bit's internal font. > > > Does anyone have any thoughts on this? > > e.g. Can Python get access to the internal font? > > If so, how could this font be used to generate characters on the OLED > display without running out of RAM? > > > > Cheers, > > > Nevil > > > > > > _______________________________________________ > 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 Nov 17 06:31:48 2016 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Thu, 17 Nov 2016 11:31:48 +0000 Subject: [Microbit-Python] Can the micro:bit display text on the Adafruit OLED display? In-Reply-To: <582D89E2.1010107@egenix.com> References: <033b0dc7-1e75-8d70-a59e-fac8dda9223c@hotpy.org> <582D89E2.1010107@egenix.com> Message-ID: <4ec8371f-93d9-cc11-9f52-108ba9260dab@ntoll.org> On 17/11/16 10:43, M.-A. Lemburg wrote: > Thanks for that little trick :-) I was always wondering how > I could get at the font definitions of the chars. Me too. :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From tony at tonydicola.com Thu Nov 17 15:40:35 2016 From: tony at tonydicola.com (Tony DiCola) Date: Thu, 17 Nov 2016 12:40:35 -0800 Subject: [Microbit-Python] Can the micro:bit display text on the Adafruit OLED display? In-Reply-To: <4ec8371f-93d9-cc11-9f52-108ba9260dab@ntoll.org> References: <033b0dc7-1e75-8d70-a59e-fac8dda9223c@hotpy.org> <582D89E2.1010107@egenix.com> <4ec8371f-93d9-cc11-9f52-108ba9260dab@ntoll.org> Message-ID: Check out this tutorial I recently did too: https://learn.adafruit.com/micropython-displays-drawing-text It uses a little bitmap font library I made here: https://github.com/adafruit/micropython-adafruit-bitmap-font In theory it should be able to work with any pixel-based display like the microbit's LED matrix, an OLED, etc. It works by having you plug in the pixel drawing function to the module so it can call out to set all the pixels when you draw text. The font it includes is a simple 5 pixel wide by 8 pixel tall font we used in Adafruit's Arduino libraries, so it works well for small low density displays like LED grids, etc. Should work reasonably well on a little OLED too. The code is all pure python so no need to build a new firmware, and if microbit supports .mpy files you can copy those over and import and use it without a big memory hit. The font data is read from a file as needed to reduce memory usage (otherwise it's a solid 1k+ of RAM you'd need to load all the font data.. a bit too much). On Thu, Nov 17, 2016 at 3:31 AM, Nicholas H.Tollervey wrote: > On 17/11/16 10:43, M.-A. Lemburg wrote: >> Thanks for that little trick :-) I was always wondering how >> I could get at the font definitions of the chars. > > Me too. :-) > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > From nevil.hunt at hotmail.co.uk Fri Nov 18 06:23:03 2016 From: nevil.hunt at hotmail.co.uk (Nevil Hunt) Date: Fri, 18 Nov 2016 11:23:03 +0000 Subject: [Microbit-Python] Can the micro:bit display text on the Adafruit OLED display? In-Reply-To: References: <033b0dc7-1e75-8d70-a59e-fac8dda9223c@hotpy.org> <582D89E2.1010107@egenix.com> <4ec8371f-93d9-cc11-9f52-108ba9260dab@ntoll.org>, Message-ID: Hi Tony, Thanks for the links to you tutorial - I hadn't spotted this one although I have seen some of your other Tutorials and Videos including the one on Micro Python where you demo'ed the micro:bit! Yesterday, thanks to Mark's suggestion I got the OLED display working displaying text. At this stage only a single character but with a bit more time I'm sure I can make it display more! The info about the FeatherWing display is just what I needed! I received one of these on Wednesday along with various other Adafruit Displays and Sensors and I have the CharlieWing Display almost ready to test (see attached photo). By the sound of it your new libraries may help me get the FeatherWing going as well as helping enhance my OLED display s/w, although it seems you have found I'm often running out of memory and it can take a while to work out how to make the code fit within both Flash & RAM . I'll give it a go over the next few days and let you know if I am successful! Cheers, Nevil ________________________________ From: Microbit on behalf of Tony DiCola Sent: 17 November 2016 20:40 To: For Pythonic MicroBit related discussions Subject: Re: [Microbit-Python] Can the micro:bit display text on the Adafruit OLED display? Check out this tutorial I recently did too: https://learn.adafruit.com/micropython-displays-drawing-text It uses a little bitmap font library I made here: https://github.com/adafruit/micropython-adafruit-bitmap-font In [https://avatars3.githubusercontent.com/u/181069?v=3&s=400] adafruit/micropython-adafruit-bitmap-font github.com micropython-adafruit-bitmap-font - Text rendering module to write messages with simple bitmap fonts on any pixel-based display. theory it should be able to work with any pixel-based display like the microbit's LED matrix, an OLED, etc. It works by having you plug in the pixel drawing function to the module so it can call out to set all the pixels when you draw text. The font it includes is a simple 5 pixel wide by 8 pixel tall font we used in Adafruit's Arduino libraries, so it works well for small low density displays like LED grids, etc. Should work reasonably well on a little OLED too. The code is all pure python so no need to build a new firmware, and if microbit supports .mpy files you can copy those over and import and use it without a big memory hit. The font data is read from a file as needed to reduce memory usage (otherwise it's a solid 1k+ of RAM you'd need to load all the font data.. a bit too much). On Thu, Nov 17, 2016 at 3:31 AM, Nicholas H.Tollervey wrote: > On 17/11/16 10:43, M.-A. Lemburg wrote: >> Thanks for that little trick :-) I was always wondering how >> I could get at the font definitions of the chars. > > Me too. :-) > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit Microbit Info Page - Python mail.python.org The MicroBit is a small programmable device for children created by the BBC (in partnership with various other organisations, such as the PSF). > _______________________________________________ Microbit mailing list Microbit at python.org https://mail.python.org/mailman/listinfo/microbit Microbit Info Page - Python mail.python.org The MicroBit is a small programmable device for children created by the BBC (in partnership with various other organisations, such as the PSF). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: microbit-adafruit-15x7-CharlieWing-Display.jpg Type: image/jpeg Size: 313543 bytes Desc: microbit-adafruit-15x7-CharlieWing-Display.jpg URL: From Peter.Dodson at uk.bosch.com Fri Nov 18 09:52:29 2016 From: Peter.Dodson at uk.bosch.com (Dodson Peter (TT-WB/ECT1-Wo)) Date: Fri, 18 Nov 2016 14:52:29 +0000 Subject: [Microbit-Python] Using REPL in Mu Message-ID: Hi guys, I have recently bought a BBC Micro Bit, to assess it's capabilities. I would like to introduce my teenage boys to this world ( they are learning Python at school, but have no exposure to the Microbit ). I have successfully run programs on it, using the BBC web site. I have also obtained Mu , which allows me to program offline. Question : Mu provides an option to Flash the Microbit - which is fine Mu also provides an option to talk to the Microbit via REPL - not fine ! How do I get this to work correctly ? Experience : Whenever I click on the REPL option in Mu, it issues an error message. I have attempted to research this topic, but with no success. Suspicion : I have a sneaking feeling that the Microbit is only ready to operate in REPL mode when it is first powered up. Once any programs have been created and run on it - then the REPL mode is no longer available. I get the impression that the Firmware on the Microbit has to be re-flashed with it's original code But how ? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Incidentally : I obtained Mu, primarily because the Cut and Paste facility does not work when writing programs on the BBC web site ! I can copy from it, to other applications - but I cannot paste into it - which is intensely frustrating. Best regards Peter Dodson TT-WB/ECT1-Wo Tel. +44(1905)75-2909 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 1.jpg Type: image/jpeg Size: 14091 bytes Desc: Picture (Device Independent Bitmap) 1.jpg URL: From ntoll at ntoll.org Fri Nov 18 10:48:36 2016 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Fri, 18 Nov 2016 15:48:36 +0000 Subject: [Microbit-Python] Using REPL in Mu In-Reply-To: References: Message-ID: Hi Peter, Have you installed the USB-serial driver? (As per instructions on the http://codewith.mu/ website.) Have you flashed the micro:bit with MicroPython? The REPL won't work unless MicroPython is on the device. If you have a MicroPython script already running on the device the REPL should interrupt it so you'll be able to interrogate the current state of your program. Sometimes it takes a while for the host operating system to register the device as available for USB-serial connections. Does this help? N. On 18/11/16 14:52, Dodson Peter (TT-WB/ECT1-Wo) wrote: > Hi guys, > > I have recently bought a BBC Micro Bit, to assess it?s capabilities. > I would like to introduce my teenage boys to this world ( they are > learning Python at school, but have no exposure to the Microbit ). > > I have successfully run programs on it, using the BBC web site. > I have also obtained Mu , which allows me to program offline. > > Question : > Mu provides an option to Flash the Microbit ? which is fine > Mu also provides an option to talk to the Microbit via REPL ? > not fine ! > How do I get this to work correctly ? > > Experience : > Whenever I click on the REPL option in Mu, it issues an error > message. > > > > > I have attempted to research this topic, but with no success. > > Suspicion : > I have a sneaking feeling that the Microbit is only ready to > operate in REPL mode when it is first powered up. > Once any programs have been created and run on it ? then the > REPL mode is no longer available. > > I get the impression that the Firmware on the Microbit has to be > re-flashed with it?s original code > But how ? > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Incidentally : > I obtained Mu, primarily because the Cut and Paste facility does > not work when writing programs on the BBC web site ! > I can copy from it, to other applications ? but I cannot paste > into it ? which is intensely frustrating. > > > Best regards > > *Peter Dodson * > *TT-WB/ECT1-Wo* > > Tel. +44(1905)75-2909 > > > > > _______________________________________________ > 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: 455 bytes Desc: OpenPGP digital signature URL: From carlosperate at gmail.com Fri Nov 18 10:49:38 2016 From: carlosperate at gmail.com (Carlos Pereira Atencio) Date: Fri, 18 Nov 2016 15:49:38 +0000 Subject: [Microbit-Python] Using REPL in Mu In-Reply-To: References: Message-ID: Hi Peter, Mu also provides an option to talk to the Microbit via REPL ? not fine ! > How do I get this to work correctly ? > You can download the drivers for the REPL access from the link in http://codewith.mu , it should be next to the windows download button. I have a sneaking feeling that the Microbit is only ready to > operate in REPL mode when it is first powered up. > Once any programs have been created and run on it ? then the REPL > mode is no longer available. > It would be the opposite actually, on a new micro:bit there would be flash demo application without micropython, and therefore without the REPL. So in order to use it, you must first flash a micropython script (could be an empty script, just to get micropython into the micro:bit). I obtained Mu, primarily because the Cut and Paste facility does > not work when writing programs on the BBC web site ! > I can copy from it, to other applications ? but I cannot paste > into it ? which is intensely frustrating. > Could you elaborate a bit more, that shouldn't happen. What browser and version are you using? Regards, Carlos On 18 November 2016 at 14:52, Dodson Peter (TT-WB/ECT1-Wo) < Peter.Dodson at uk.bosch.com> wrote: > Hi guys, > > I have recently bought a BBC Micro Bit, to assess it?s capabilities. > I would like to introduce my teenage boys to this world ( they are > learning Python at school, but have no exposure to the Microbit ). > > I have successfully run programs on it, using the BBC web site. > I have also obtained Mu , which allows me to program offline. > > Question : > Mu provides an option to Flash the Microbit ? which is fine > Mu also provides an option to talk to the Microbit via REPL ? not > fine ! > How do I get this to work correctly ? > > Experience : > Whenever I click on the REPL option in Mu, it issues an error > message. > > > > > I have attempted to research this topic, but with no success. > > Suspicion : > I have a sneaking feeling that the Microbit is only ready to > operate in REPL mode when it is first powered up. > Once any programs have been created and run on it ? then the REPL > mode is no longer available. > > I get the impression that the Firmware on the Microbit has to be > re-flashed with it?s original code > But how ? > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Incidentally : > I obtained Mu, primarily because the Cut and Paste facility does > not work when writing programs on the BBC web site ! > I can copy from it, to other applications ? but I cannot paste > into it ? which is intensely frustrating. > > > Best regards > > *Peter Dodson * > *TT-WB/ECT1-Wo* > > Tel. +44(1905)75-2909 > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 1.jpg Type: image/jpeg Size: 14091 bytes Desc: not available URL: From microbit at sheep.art.pl Fri Nov 18 10:48:23 2016 From: microbit at sheep.art.pl (Radomir Dopieralski) Date: Fri, 18 Nov 2016 16:48:23 +0100 Subject: [Microbit-Python] Using REPL in Mu In-Reply-To: References: Message-ID: <20161118164823.04c507f8@ghostwheel> Did you get a chance to actually read that error message? Could you quote it here? That could shed some light about what is happening. The REPL doesn't require any special program to be flashed -- it should work whenever the flashed program finished its work, in particular, when you flash an empty program, or whenever you break the program flow by pressing ctrl+c (useful for programs that never stop by themselves). My suspicion is that Mu has trouble locating the hardware serial port that the micro:bit is visible as. It may be because you didn't install the drivers for it (sadly, even though Microsoft is one of the partners, they didn't make the drivers auto-installable), or because your system is non-standard in some way, and Mu got confused. It would also help if you told us which operating system you are using. On Fri, 18 Nov 2016 14:52:29 +0000 "Dodson Peter (TT-WB/ECT1-Wo)" wrote: > Hi guys, > > I have recently bought a BBC Micro Bit, to assess it's capabilities. > I would like to introduce my teenage boys to this world ( they are > learning Python at school, but have no exposure to the Microbit ). > > I have successfully run programs on it, using the BBC web site. > I have also obtained Mu , which allows me to program offline. > > Question : > Mu provides an option to Flash the Microbit - which is fine > Mu also provides an option to talk to the Microbit via REPL - > not fine ! How do I get this to work correctly ? > > Experience : > Whenever I click on the REPL option in Mu, it issues an error > message. > > > > > I have attempted to research this topic, but with no success. > > Suspicion : > I have a sneaking feeling that the Microbit is only ready to > operate in REPL mode when it is first powered up. Once any programs > have been created and run on it - then the REPL mode is no longer > available. > > I get the impression that the Firmware on the Microbit has to > be re-flashed with it's original code But how ? > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > Incidentally : > I obtained Mu, primarily because the Cut and Paste facility > does not work when writing programs on the BBC web site ! I can copy > from it, to other applications - but I cannot paste into it - which > is intensely frustrating. > > > Best regards > > Peter Dodson > TT-WB/ECT1-Wo > > Tel. +44(1905)75-2909 > > -- Radomir Dopieralski -- Radomir Dopieralski From mal at egenix.com Sun Nov 20 10:04:52 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Sun, 20 Nov 2016 16:04:52 +0100 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 Message-ID: <5831BB94.5020205@egenix.com> Hello, over the weekend, we tried to get a connection from a BBC Microbit to an ESP8266, both running the latest MicroPython for the resp. platform, established via SPI. We found several problems with this: * the SPI APIs on the ESP8266 are all non-blocking and return whatever is currently in the buffer (using 0x00 for missing data and 0xff in case no connection is available) * the SPI APIs on the Microbit are all blocking, only returning if all data is sent / received * the connection is rather unreliable: we had lots of data loss or data corruption, with bytes not being transmitted or with lost bits - we tried several different baud rates without success On the plus side, we did get SPI to work fine between two Microbits, but that's not really what we were after, since we wanted to get one of the Microbits in our mesh network connected to a WLAN and work as gateway. The blocking nature of the MB APIs make it difficult to write interfaces which aim at being fault tolerant and work as gateways. Having non-blocking versions would be better for this sort of application. Are there better ways to connect MBs and ESP8266 ? We also tried I2C, but gave up, since the pins on the MB for accessing I2C were too tiny to connect to without a breakout board. BTW: We were impressed by the new radio module. Getting MBs to connect using these low level radios is really easy. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ From mark at hotpy.org Sun Nov 20 11:05:39 2016 From: mark at hotpy.org (Mark Shannon) Date: Sun, 20 Nov 2016 16:05:39 +0000 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: <5831BB94.5020205@egenix.com> References: <5831BB94.5020205@egenix.com> Message-ID: <5688ca12-5070-8906-1254-cef61273ac93@hotpy.org> Hi, If you use the latest firmware, you can use any of the pins for I2C. Hope that helps. Cheers, Mark. On 20/11/16 15:04, M.-A. Lemburg wrote: > Hello, > > over the weekend, we tried to get a connection from a BBC Microbit > to an ESP8266, both running the latest MicroPython for the resp. > platform, established via SPI. > > We found several problems with this: > > * the SPI APIs on the ESP8266 are all non-blocking and return > whatever is currently in the buffer (using 0x00 for missing data > and 0xff in case no connection is available) > > * the SPI APIs on the Microbit are all blocking, only returning > if all data is sent / received > > * the connection is rather unreliable: we had lots of data loss or > data corruption, with bytes not being transmitted or with lost bits > - we tried several different baud rates without success > > On the plus side, we did get SPI to work fine between two Microbits, > but that's not really what we were after, since we wanted to get > one of the Microbits in our mesh network connected to a WLAN and > work as gateway. > > The blocking nature of the MB APIs make it difficult to write > interfaces which aim at being fault tolerant and work as > gateways. Having non-blocking versions would be better for this > sort of application. > > Are there better ways to connect MBs and ESP8266 ? > > We also tried I2C, but gave up, since the pins on the MB for > accessing I2C were too tiny to connect to without a breakout > board. > > BTW: We were impressed by the new radio module. Getting MBs > to connect using these low level radios is really easy. > > Cheers, > From carlosperate at gmail.com Sun Nov 20 11:06:24 2016 From: carlosperate at gmail.com (Carlos Pereira Atencio) Date: Sun, 20 Nov 2016 16:06:24 +0000 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: <5831BB94.5020205@egenix.com> References: <5831BB94.5020205@egenix.com> Message-ID: Hi, We also tried I2C, but gave up, since the pins on the MB for > accessing I2C were too tiny to connect to without a breakout > board. > With the latest version you should be able to select different pins, so the I2C could be routed to the bigger pads: https://github.com/bbcmicrobit/micropython/pull/377 Just keep in mind that you wouldn't be able to talk to the sensors connected to the original I2C pins. On 20 November 2016 at 15:04, M.-A. Lemburg wrote: > Hello, > > over the weekend, we tried to get a connection from a BBC Microbit > to an ESP8266, both running the latest MicroPython for the resp. > platform, established via SPI. > > We found several problems with this: > > * the SPI APIs on the ESP8266 are all non-blocking and return > whatever is currently in the buffer (using 0x00 for missing data > and 0xff in case no connection is available) > > * the SPI APIs on the Microbit are all blocking, only returning > if all data is sent / received > > * the connection is rather unreliable: we had lots of data loss or > data corruption, with bytes not being transmitted or with lost bits > - we tried several different baud rates without success > > On the plus side, we did get SPI to work fine between two Microbits, > but that's not really what we were after, since we wanted to get > one of the Microbits in our mesh network connected to a WLAN and > work as gateway. > > The blocking nature of the MB APIs make it difficult to write > interfaces which aim at being fault tolerant and work as > gateways. Having non-blocking versions would be better for this > sort of application. > > Are there better ways to connect MBs and ESP8266 ? > > We also tried I2C, but gave up, since the pins on the MB for > accessing I2C were too tiny to connect to without a breakout > board. > > BTW: We were impressed by the new radio module. Getting MBs > to connect using these low level radios is really easy. > > Cheers, > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts > >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ > >>> Python Database Interfaces ... http://products.egenix.com/ > >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ > ________________________________________________________________________ > > ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From microbit at sheep.art.pl Sun Nov 20 11:30:29 2016 From: microbit at sheep.art.pl (Radomir Dopieralski) Date: Sun, 20 Nov 2016 17:30:29 +0100 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: <5688ca12-5070-8906-1254-cef61273ac93@hotpy.org> References: <5831BB94.5020205@egenix.com> <5688ca12-5070-8906-1254-cef61273ac93@hotpy.org> Message-ID: <20161120173029.31d31a79@ghostwheel> It may be still a little problematic, because MicroPython on the ESP8266 doesn't have an implementation of I2C slave (and neither does Micro:bit). On Sun, 20 Nov 2016 16:05:39 +0000 Mark Shannon wrote: > Hi, > > If you use the latest firmware, you can use any of the pins for I2C. > Hope that helps. > > Cheers, > Mark. > > On 20/11/16 15:04, M.-A. Lemburg wrote: > > Hello, > > > > over the weekend, we tried to get a connection from a BBC Microbit > > to an ESP8266, both running the latest MicroPython for the resp. > > platform, established via SPI. > > > > We found several problems with this: > > > > * the SPI APIs on the ESP8266 are all non-blocking and return > > whatever is currently in the buffer (using 0x00 for missing data > > and 0xff in case no connection is available) > > > > * the SPI APIs on the Microbit are all blocking, only returning > > if all data is sent / received > > > > * the connection is rather unreliable: we had lots of data loss or > > data corruption, with bytes not being transmitted or with lost > > bits > > - we tried several different baud rates without success > > > > On the plus side, we did get SPI to work fine between two Microbits, > > but that's not really what we were after, since we wanted to get > > one of the Microbits in our mesh network connected to a WLAN and > > work as gateway. > > > > The blocking nature of the MB APIs make it difficult to write > > interfaces which aim at being fault tolerant and work as > > gateways. Having non-blocking versions would be better for this > > sort of application. > > > > Are there better ways to connect MBs and ESP8266 ? > > > > We also tried I2C, but gave up, since the pins on the MB for > > accessing I2C were too tiny to connect to without a breakout > > board. > > > > BTW: We were impressed by the new radio module. Getting MBs > > to connect using these low level radios is really easy. > > > > Cheers, > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit -- Radomir Dopieralski From nevil.hunt at hotmail.co.uk Sun Nov 20 12:06:52 2016 From: nevil.hunt at hotmail.co.uk (Nevil Hunt) Date: Sun, 20 Nov 2016 17:06:52 +0000 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: <5831BB94.5020205@egenix.com> References: <5831BB94.5020205@egenix.com> Message-ID: Marc-Andre, As regards... * the connection is rather unreliable: we had lots of data loss or data corruption, with bytes not being transmitted or with lost bits - we tried several different baud rates without success I'd certainly be interested if you can find out why. I hooked a micro:bit up to a SPI RAM about a month ago and was able to write then read back from it, however it was a bit unreliable as sometimes the 'Reads' returned corrupted data. >From my recollection it looked like it was the 'Write' that was getting corrupted as repeated 'Reads' always returned the same corrupted data. I used the 'Bus Pirate' to try and debug it but I wasn't able to determine whether it was a h/w or s/w problem...then I ran out of time and haven't returned to it! I have however been in touch with Paul from Microsoft who has a micro:bit talking to an SD Card with s/w written in 'C' so it looks like the micro:bit SPI interface can be made to work! Cheers, Nevil ________________________________ From: Microbit on behalf of M.-A. Lemburg Sent: 20 November 2016 15:04 To: For Pythonic MicroBit related discussions Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 Hello, over the weekend, we tried to get a connection from a BBC Microbit to an ESP8266, both running the latest MicroPython for the resp. platform, established via SPI. We found several problems with this: * the SPI APIs on the ESP8266 are all non-blocking and return whatever is currently in the buffer (using 0x00 for missing data and 0xff in case no connection is available) * the SPI APIs on the Microbit are all blocking, only returning if all data is sent / received * the connection is rather unreliable: we had lots of data loss or data corruption, with bytes not being transmitted or with lost bits - we tried several different baud rates without success On the plus side, we did get SPI to work fine between two Microbits, but that's not really what we were after, since we wanted to get one of the Microbits in our mesh network connected to a WLAN and work as gateway. The blocking nature of the MB APIs make it difficult to write interfaces which aim at being fault tolerant and work as gateways. Having non-blocking versions would be better for this sort of application. Are there better ways to connect MBs and ESP8266 ? We also tried I2C, but gave up, since the pins on the MB for accessing I2C were too tiny to connect to without a breakout board. BTW: We were impressed by the new radio module. Getting MBs to connect using these low level radios is really easy. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ eGenix.com - Professional Python Software, Skills and Services www.egenix.com eGenix? is your leading partner for Python and database focused custom projects, services, coaching, consulting and products. We implement business ideas ... >>> Python Database Interfaces ... http://products.egenix.com/ eGenix.com Products products.egenix.com eGenix.com offers a large portfolio of products for Python and Python-based applications, many of them focusing on database connectivity. >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ eGenix.com: eGenix.com Plone & Zope Products zope.egenix.com Plone/Zope Database Connectivity. eGenix.com has been actively working in the field of Python database connectivity for more than 15 years. Using our Zope and Plone ... ________________________________________________________________________ ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ eGenix.com: Company: Contact www.egenix.com We provide various ways of contacting eGenix.com depending on what area of interest you have. EMail. General Questions: info at egenix.com Support: support at egenix.com _______________________________________________ Microbit mailing list Microbit at python.org https://mail.python.org/mailman/listinfo/microbit Microbit Info Page - Python mail.python.org The MicroBit is a small programmable device for children created by the BBC (in partnership with various other organisations, such as the PSF). -------------- next part -------------- An HTML attachment was scrubbed... URL: From radomir at dopieralski.pl Sun Nov 20 12:19:49 2016 From: radomir at dopieralski.pl (Radomir Dopieralski) Date: Sun, 20 Nov 2016 18:19:49 +0100 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: References: <5831BB94.5020205@egenix.com> Message-ID: <20161120181949.48d9df64@ghostwheel> You sometimes get unreliable transmission if your use a different spi mode than the device expects (it then reads the value from the bus at the wrong moment, and can read it when it is changing). On Sun, 20 Nov 2016 17:06:52 +0000 Nevil Hunt wrote: > Marc-Andre, > > > As regards... > > > * the connection is rather unreliable: we had lots of data loss or > data corruption, with bytes not being transmitted or with lost bits > - we tried several different baud rates without success > > > I'd certainly be interested if you can find out why. > > I hooked a micro:bit up to a SPI RAM about a month ago and was able > to write then read back from it, however it was a bit unreliable as > sometimes the 'Reads' returned corrupted data. > > From my recollection it looked like it was the 'Write' that was > getting corrupted as repeated 'Reads' always returned the same > corrupted data. > > I used the 'Bus Pirate' to try and debug it but I wasn't able to > determine whether it was a h/w or s/w problem...then I ran out of > time and haven't returned to it! > > I have however been in touch with Paul from Microsoft who has a > micro:bit talking to an SD Card with s/w written in 'C' so it looks > like the micro:bit SPI interface can be made to work! > > > Cheers, > > > Nevil > > > ________________________________ > From: Microbit > on behalf of M.-A. Lemburg Sent: 20 November 2016 > 15:04 To: For Pythonic MicroBit related discussions > Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 > > Hello, > > over the weekend, we tried to get a connection from a BBC Microbit > to an ESP8266, both running the latest MicroPython for the resp. > platform, established via SPI. > > We found several problems with this: > > * the SPI APIs on the ESP8266 are all non-blocking and return > whatever is currently in the buffer (using 0x00 for missing data > and 0xff in case no connection is available) > > * the SPI APIs on the Microbit are all blocking, only returning > if all data is sent / received > > * the connection is rather unreliable: we had lots of data loss or > data corruption, with bytes not being transmitted or with lost bits > - we tried several different baud rates without success > > On the plus side, we did get SPI to work fine between two Microbits, > but that's not really what we were after, since we wanted to get > one of the Microbits in our mesh network connected to a WLAN and > work as gateway. > > The blocking nature of the MB APIs make it difficult to write > interfaces which aim at being fault tolerant and work as > gateways. Having non-blocking versions would be better for this > sort of application. > > Are there better ways to connect MBs and ESP8266 ? > > We also tried I2C, but gave up, since the pins on the MB for > accessing I2C were too tiny to connect to without a breakout > board. > > BTW: We were impressed by the new radio module. Getting MBs > to connect using these low level radios is really easy. > > Cheers, > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts > >>> Python Projects, Coaching and Consulting ... > >>> http://www.egenix.com/ > > eGenix.com - Professional Python Software, Skills and > Services www.egenix.com > eGenix? is your leading partner for Python and database focused > custom projects, services, coaching, consulting and products. We > implement business ideas ... > > > > >>> Python Database Interfaces ... > >>> http://products.egenix.com/ > > eGenix.com Products > products.egenix.com > eGenix.com offers a large portfolio of products for Python and > Python-based applications, many of them focusing on database > connectivity. > > > > >>> Plone/Zope Database Interfaces ... > >>> http://zope.egenix.com/ > > eGenix.com: eGenix.com Plone & Zope Products > zope.egenix.com > Plone/Zope Database Connectivity. eGenix.com has been actively > working in the field of Python database connectivity for more than 15 > years. Using our Zope and Plone ... > > > > ________________________________________________________________________ > > ::::: Try our mxODBC.Connect Python Database Interface for > free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > > eGenix.com: Company: Contact > www.egenix.com > We provide various ways of contacting eGenix.com depending on what > area of interest you have. EMail. General Questions: info at egenix.com > Support: support at egenix.com > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > Microbit Info Page - > Python > mail.python.org The MicroBit is a small programmable device for > children created by the BBC (in partnership with various other > organisations, such as the PSF). > > > -- Radomir Dopieralski From microbit at sheep.art.pl Sun Nov 20 12:21:29 2016 From: microbit at sheep.art.pl (Radomir Dopieralski) Date: Sun, 20 Nov 2016 18:21:29 +0100 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: References: <5831BB94.5020205@egenix.com> Message-ID: <20161120182129.139706fc@ghostwheel> You sometimes get unreliable transmission if your use a different spi mode than the device expects (it then reads the value from the bus at the wrong moment, and can read it when it is changing). On Sun, 20 Nov 2016 17:06:52 +0000 Nevil Hunt wrote: > Marc-Andre, > > > As regards... > > > * the connection is rather unreliable: we had lots of data loss or > data corruption, with bytes not being transmitted or with lost bits > - we tried several different baud rates without success > > > I'd certainly be interested if you can find out why. > > I hooked a micro:bit up to a SPI RAM about a month ago and was able > to write then read back from it, however it was a bit unreliable as > sometimes the 'Reads' returned corrupted data. > > From my recollection it looked like it was the 'Write' that was > getting corrupted as repeated 'Reads' always returned the same > corrupted data. > > I used the 'Bus Pirate' to try and debug it but I wasn't able to > determine whether it was a h/w or s/w problem...then I ran out of > time and haven't returned to it! > > I have however been in touch with Paul from Microsoft who has a > micro:bit talking to an SD Card with s/w written in 'C' so it looks > like the micro:bit SPI interface can be made to work! > > > Cheers, > > > Nevil > > > ________________________________ > From: Microbit > on behalf of M.-A. Lemburg Sent: 20 November 2016 > 15:04 To: For Pythonic MicroBit related discussions > Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 > > Hello, > > over the weekend, we tried to get a connection from a BBC Microbit > to an ESP8266, both running the latest MicroPython for the resp. > platform, established via SPI. > > We found several problems with this: > > * the SPI APIs on the ESP8266 are all non-blocking and return > whatever is currently in the buffer (using 0x00 for missing data > and 0xff in case no connection is available) > > * the SPI APIs on the Microbit are all blocking, only returning > if all data is sent / received > > * the connection is rather unreliable: we had lots of data loss or > data corruption, with bytes not being transmitted or with lost bits > - we tried several different baud rates without success > > On the plus side, we did get SPI to work fine between two Microbits, > but that's not really what we were after, since we wanted to get > one of the Microbits in our mesh network connected to a WLAN and > work as gateway. > > The blocking nature of the MB APIs make it difficult to write > interfaces which aim at being fault tolerant and work as > gateways. Having non-blocking versions would be better for this > sort of application. > > Are there better ways to connect MBs and ESP8266 ? > > We also tried I2C, but gave up, since the pins on the MB for > accessing I2C were too tiny to connect to without a breakout > board. > > BTW: We were impressed by the new radio module. Getting MBs > to connect using these low level radios is really easy. > > Cheers, -- Radomir Dopieralski From david at thinkingbinaries.com Sun Nov 20 13:20:58 2016 From: david at thinkingbinaries.com (David Whale) Date: Sun, 20 Nov 2016 18:20:58 +0000 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: References: <5831BB94.5020205@egenix.com> Message-ID: Ian Stephenson (aka @sniffCode on twitter) had the SPI working with an SDCard really reliably, back in May: http://www.sniff.org.uk/2016/05/spi-explained-connecting-sd-cards-to.html Might be worth comparing notes with him. Sniff uses the standard mbed SPI driver, same as the micro:bit does. Also double check your SPOL and SPHA settings to make sure they are compatible with the receiving end. https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Clock_polarity_and_phase David ___________________________________________________________ David Whale, B.Sc (Hons), MIET *Software Engineer and IET Schools Liaison Officer, Essex* On 20 November 2016 at 17:06, Nevil Hunt wrote: > Marc-Andre, > > > As regards... > > > * the connection is rather unreliable: we had lots of data loss or > data corruption, with bytes not being transmitted or with lost bits > - we tried several different baud rates without success > > I'd certainly be interested if you can find out why. > > I hooked a micro:bit up to a SPI RAM about a month ago and was able to > write then read back from it, however it was a bit unreliable as sometimes > the 'Reads' returned corrupted data. > > From my recollection it looked like it was the 'Write' that was getting > corrupted as repeated 'Reads' always returned the same corrupted data. > > I used the 'Bus Pirate' to try and debug it but I wasn't able to determine > whether it was a h/w or s/w problem...then I ran out of time and haven't > returned to it! > > I have however been in touch with Paul from Microsoft who has a micro:bit > talking to an SD Card with s/w written in 'C' so it looks like the > micro:bit SPI interface can be made to work! > > > Cheers, > > > Nevil > > ------------------------------ > *From:* Microbit > on behalf of M.-A. Lemburg > *Sent:* 20 November 2016 15:04 > *To:* For Pythonic MicroBit related discussions > *Subject:* [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 > > Hello, > > over the weekend, we tried to get a connection from a BBC Microbit > to an ESP8266, both running the latest MicroPython for the resp. > platform, established via SPI. > > We found several problems with this: > > * the SPI APIs on the ESP8266 are all non-blocking and return > whatever is currently in the buffer (using 0x00 for missing data > and 0xff in case no connection is available) > > * the SPI APIs on the Microbit are all blocking, only returning > if all data is sent / received > > * the connection is rather unreliable: we had lots of data loss or > data corruption, with bytes not being transmitted or with lost bits > - we tried several different baud rates without success > > On the plus side, we did get SPI to work fine between two Microbits, > but that's not really what we were after, since we wanted to get > one of the Microbits in our mesh network connected to a WLAN and > work as gateway. > > The blocking nature of the MB APIs make it difficult to write > interfaces which aim at being fault tolerant and work as > gateways. Having non-blocking versions would be better for this > sort of application. > > Are there better ways to connect MBs and ESP8266 ? > > We also tried I2C, but gave up, since the pins on the MB for > accessing I2C were too tiny to connect to without a breakout > board. > > BTW: We were impressed by the new radio module. Getting MBs > to connect using these low level radios is really easy. > > Cheers, > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts > >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ > > eGenix.com - Professional Python Software, Skills and Services > > www.egenix.com > eGenix? is your leading partner for Python and database focused custom > projects, services, coaching, consulting and products. We implement > business ideas ... > > > > >>> Python Database Interfaces ... http://products.egenix.com/ > > eGenix.com Products > products.egenix.com > eGenix.com offers a large portfolio of products for Python and > Python-based applications, many of them focusing on database connectivity. > > > > >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ > > eGenix.com: eGenix.com Plone & Zope Products > zope.egenix.com > Plone/Zope Database Connectivity. eGenix.com has been actively working in > the field of Python database connectivity for more than 15 years. Using our > Zope and Plone ... > > > > ________________________________________________________________________ > > ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > > eGenix.com: Company: Contact > www.egenix.com > We provide various ways of contacting eGenix.com depending on what area of > interest you have. EMail. General Questions: info at egenix.com Support: > support at egenix.com > > > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > > Microbit Info Page - Python > > mail.python.org > The MicroBit is a small programmable device for children created by the > BBC (in partnership with various other organisations, such as the PSF). > > > > > _______________________________________________ > 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 Nov 21 00:24:17 2016 From: damien.p.george at gmail.com (Damien George) Date: Mon, 21 Nov 2016 16:24:17 +1100 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: References: <5831BB94.5020205@egenix.com> Message-ID: Hi Marc-Andre, I'm rather confused (and intrigued!) how you got SPI to work even a little bit because neither uPy on the microbit nor uPy on the ESP8266 support *slave* SPI mode. So both boards would be in master... or am I missing something? Similarly, neither support slave I2C. I think UART would be the best bet, but then you don't have a REPL. Cheers, Damien. On 21 November 2016 at 05:20, David Whale wrote: > Ian Stephenson (aka @sniffCode on twitter) had the SPI working with an > SDCard really reliably, back in May: > > http://www.sniff.org.uk/2016/05/spi-explained-connecting-sd-cards-to.html > > Might be worth comparing notes with him. Sniff uses the standard mbed SPI > driver, same as the micro:bit does. > > Also double check your SPOL and SPHA settings to make sure they are > compatible with the receiving end. > > https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_ > Bus#Clock_polarity_and_phase > > David > > > > ___________________________________________________________ > David Whale, B.Sc (Hons), MIET > *Software Engineer and IET Schools Liaison Officer, Essex* > > > On 20 November 2016 at 17:06, Nevil Hunt wrote: > >> Marc-Andre, >> >> >> As regards... >> >> >> * the connection is rather unreliable: we had lots of data loss or >> data corruption, with bytes not being transmitted or with lost bits >> - we tried several different baud rates without success >> >> I'd certainly be interested if you can find out why. >> >> I hooked a micro:bit up to a SPI RAM about a month ago and was able to >> write then read back from it, however it was a bit unreliable as sometimes >> the 'Reads' returned corrupted data. >> >> From my recollection it looked like it was the 'Write' that was getting >> corrupted as repeated 'Reads' always returned the same corrupted data. >> >> I used the 'Bus Pirate' to try and debug it but I wasn't able to >> determine whether it was a h/w or s/w problem...then I ran out of time and >> haven't returned to it! >> >> I have however been in touch with Paul from Microsoft who has a micro:bit >> talking to an SD Card with s/w written in 'C' so it looks like the >> micro:bit SPI interface can be made to work! >> >> >> Cheers, >> >> >> Nevil >> >> ------------------------------ >> *From:* Microbit >> on behalf of M.-A. Lemburg >> *Sent:* 20 November 2016 15:04 >> *To:* For Pythonic MicroBit related discussions >> *Subject:* [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 >> >> Hello, >> >> over the weekend, we tried to get a connection from a BBC Microbit >> to an ESP8266, both running the latest MicroPython for the resp. >> platform, established via SPI. >> >> We found several problems with this: >> >> * the SPI APIs on the ESP8266 are all non-blocking and return >> whatever is currently in the buffer (using 0x00 for missing data >> and 0xff in case no connection is available) >> >> * the SPI APIs on the Microbit are all blocking, only returning >> if all data is sent / received >> >> * the connection is rather unreliable: we had lots of data loss or >> data corruption, with bytes not being transmitted or with lost bits >> - we tried several different baud rates without success >> >> On the plus side, we did get SPI to work fine between two Microbits, >> but that's not really what we were after, since we wanted to get >> one of the Microbits in our mesh network connected to a WLAN and >> work as gateway. >> >> The blocking nature of the MB APIs make it difficult to write >> interfaces which aim at being fault tolerant and work as >> gateways. Having non-blocking versions would be better for this >> sort of application. >> >> Are there better ways to connect MBs and ESP8266 ? >> >> We also tried I2C, but gave up, since the pins on the MB for >> accessing I2C were too tiny to connect to without a breakout >> board. >> >> BTW: We were impressed by the new radio module. Getting MBs >> to connect using these low level radios is really easy. >> >> Cheers, >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Experts >> >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >> >> eGenix.com - Professional Python Software, Skills and Services >> >> www.egenix.com >> eGenix? is your leading partner for Python and database focused custom >> projects, services, coaching, consulting and products. We implement >> business ideas ... >> >> >> >> >>> Python Database Interfaces ... http://products.egenix.com/ >> >> eGenix.com Products >> products.egenix.com >> eGenix.com offers a large portfolio of products for Python and >> Python-based applications, many of them focusing on database connectivity. >> >> >> >> >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ >> >> eGenix.com: eGenix.com Plone & Zope Products >> zope.egenix.com >> Plone/Zope Database Connectivity. eGenix.com has been actively working in >> the field of Python database connectivity for more than 15 years. Using our >> Zope and Plone ... >> >> >> >> ________________________________________________________________________ >> >> ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ >> >> eGenix.com: Company: Contact >> www.egenix.com >> We provide various ways of contacting eGenix.com depending on what area >> of interest you have. EMail. General Questions: info at egenix.com Support: >> support at egenix.com >> >> >> >> _______________________________________________ >> Microbit mailing list >> Microbit at python.org >> https://mail.python.org/mailman/listinfo/microbit >> >> Microbit Info Page - Python >> >> mail.python.org >> The MicroBit is a small programmable device for children created by the >> BBC (in partnership with various other organisations, such as the PSF). >> >> >> >> >> _______________________________________________ >> 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 mal at egenix.com Mon Nov 21 04:18:00 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 21 Nov 2016 10:18:00 +0100 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: <20161120173029.31d31a79@ghostwheel> References: <5831BB94.5020205@egenix.com> <5688ca12-5070-8906-1254-cef61273ac93@hotpy.org> <20161120173029.31d31a79@ghostwheel> Message-ID: <5832BBC8.3080107@egenix.com> On 20.11.2016 17:30, Radomir Dopieralski wrote: > It may be still a little problematic, because MicroPython on the ESP8266 > doesn't have an implementation of I2C slave (and neither does > Micro:bit). This was the main reason I didn't continue trying to solder on two cables to the pins (I was surprised that soldering did work well on those pins). Tom, who was working with me at the sprint, found the documentation saying that I2C is only implemented in master mode, so I didn't want to mess with the MB only to find out that things aren't working. We then turned to SPI where the cabling looked more promising... > On Sun, 20 Nov 2016 16:05:39 +0000 > Mark Shannon wrote: > >> Hi, >> >> If you use the latest firmware, you can use any of the pins for I2C. >> Hope that helps. Thanks, Mark. We did use the latest firmware, but I guess the documentation hasn't been updated yet, since we couldn't find any API to adjust the pin selection: http://microbit-micropython.readthedocs.io/en/latest/i2c.html The PR Carlos mentioned points to a new init() function for this: https://github.com/bbcmicrobit/micropython/pull/377 https://github.com/bbcmicrobit/micropython/commit/e88e3b2f6c579eab0eafda02242092bff51f6934 >> Cheers, >> Mark. >> >> On 20/11/16 15:04, M.-A. Lemburg wrote: >>> Hello, >>> >>> over the weekend, we tried to get a connection from a BBC Microbit >>> to an ESP8266, both running the latest MicroPython for the resp. >>> platform, established via SPI. >>> >>> We found several problems with this: >>> >>> * the SPI APIs on the ESP8266 are all non-blocking and return >>> whatever is currently in the buffer (using 0x00 for missing data >>> and 0xff in case no connection is available) >>> >>> * the SPI APIs on the Microbit are all blocking, only returning >>> if all data is sent / received >>> >>> * the connection is rather unreliable: we had lots of data loss or >>> data corruption, with bytes not being transmitted or with lost >>> bits >>> - we tried several different baud rates without success >>> >>> On the plus side, we did get SPI to work fine between two Microbits, >>> but that's not really what we were after, since we wanted to get >>> one of the Microbits in our mesh network connected to a WLAN and >>> work as gateway. >>> >>> The blocking nature of the MB APIs make it difficult to write >>> interfaces which aim at being fault tolerant and work as >>> gateways. Having non-blocking versions would be better for this >>> sort of application. >>> >>> Are there better ways to connect MBs and ESP8266 ? >>> >>> We also tried I2C, but gave up, since the pins on the MB for >>> accessing I2C were too tiny to connect to without a breakout >>> board. >>> >>> BTW: We were impressed by the new radio module. Getting MBs >>> to connect using these low level radios is really easy. >>> >>> Cheers, >>> >> _______________________________________________ >> Microbit mailing list >> Microbit at python.org >> https://mail.python.org/mailman/listinfo/microbit > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 21 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ From mal at egenix.com Mon Nov 21 04:30:16 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 21 Nov 2016 10:30:16 +0100 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: References: <5831BB94.5020205@egenix.com> Message-ID: <5832BEA8.7000706@egenix.com> Hi Nevil, On 20.11.2016 18:06, Nevil Hunt wrote: > Marc-Andre, > > > As regards... > > > * the connection is rather unreliable: we had lots of data loss or > data corruption, with bytes not being transmitted or with lost bits > - we tried several different baud rates without success > > > I'd certainly be interested if you can find out why. > > I hooked a micro:bit up to a SPI RAM about a month ago and was able to write then read back from it, however it was a bit unreliable as sometimes the 'Reads' returned corrupted data. > >>From my recollection it looked like it was the 'Write' that was getting corrupted as repeated 'Reads' always returned the same corrupted data. > > I used the 'Bus Pirate' to try and debug it but I wasn't able to determine whether it was a h/w or s/w problem...then I ran out of time and haven't returned to it! Our guess was that the clock sync wasn't working properly. However, changing the baud rate didn't really help much either. We tried higher values than the default 1Mbit and lower ones (down to 10kbit). > I have however been in touch with Paul from Microsoft who has a micro:bit talking to an SD Card with s/w written in 'C' so it looks like the micro:bit SPI interface can be made to work! I'm sure there is some way to make it work, since we did get data across the wires. It may have something to do with signal levels or the SPI mode as Radomir suggested - even though we made sure that both the ESP and the MB were using the same default mode 0 and both the ESP and the MB were connected to the same notebook (which should, in theory, make signal level problems less likely). We had wanted to work around the blocking APIs on the MB using keep alive messages on the ESP side, but the data loss prevented this: every now and then the MB wanted to send data, but some bytes did not make it through and it then blocked. It would be great to have non-blocking SPI APIs on the MB as well or at least a timeout that you can set to prevent the MBs from hanging in case of such data loss. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 21 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ From mal at egenix.com Mon Nov 21 04:33:37 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 21 Nov 2016 10:33:37 +0100 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: <20161120182129.139706fc@ghostwheel> References: <5831BB94.5020205@egenix.com> <20161120182129.139706fc@ghostwheel> Message-ID: <5832BF71.90903@egenix.com> On 20.11.2016 18:21, Radomir Dopieralski wrote: > You sometimes get unreliable transmission if your use a different > spi mode than the device expects (it then reads the value from the > bus at the wrong moment, and can read it when it is changing). We made sure that both ESP and MB were using SPI mode 0 in software. Of course, it's possible that the hardware was still using different modes and this could explain the unreliable transmissions. This would then hint at a software bug somewhere. We did not look into this at depth using an analyzer. The fact that connecting two MBs using SPI did not result in such unreliable transmission would also hint at an incompatibility at the SPI mode level. > On Sun, 20 Nov 2016 17:06:52 +0000 > Nevil Hunt wrote: > >> Marc-Andre, >> >> >> As regards... >> >> >> * the connection is rather unreliable: we had lots of data loss or >> data corruption, with bytes not being transmitted or with lost bits >> - we tried several different baud rates without success >> >> >> I'd certainly be interested if you can find out why. >> >> I hooked a micro:bit up to a SPI RAM about a month ago and was able >> to write then read back from it, however it was a bit unreliable as >> sometimes the 'Reads' returned corrupted data. >> >> From my recollection it looked like it was the 'Write' that was >> getting corrupted as repeated 'Reads' always returned the same >> corrupted data. >> >> I used the 'Bus Pirate' to try and debug it but I wasn't able to >> determine whether it was a h/w or s/w problem...then I ran out of >> time and haven't returned to it! >> >> I have however been in touch with Paul from Microsoft who has a >> micro:bit talking to an SD Card with s/w written in 'C' so it looks >> like the micro:bit SPI interface can be made to work! >> >> >> Cheers, >> >> >> Nevil >> >> >> ________________________________ >> From: Microbit >> on behalf of M.-A. Lemburg Sent: 20 November 2016 >> 15:04 To: For Pythonic MicroBit related discussions >> Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 >> >> Hello, >> >> over the weekend, we tried to get a connection from a BBC Microbit >> to an ESP8266, both running the latest MicroPython for the resp. >> platform, established via SPI. >> >> We found several problems with this: >> >> * the SPI APIs on the ESP8266 are all non-blocking and return >> whatever is currently in the buffer (using 0x00 for missing data >> and 0xff in case no connection is available) >> >> * the SPI APIs on the Microbit are all blocking, only returning >> if all data is sent / received >> >> * the connection is rather unreliable: we had lots of data loss or >> data corruption, with bytes not being transmitted or with lost bits >> - we tried several different baud rates without success >> >> On the plus side, we did get SPI to work fine between two Microbits, >> but that's not really what we were after, since we wanted to get >> one of the Microbits in our mesh network connected to a WLAN and >> work as gateway. >> >> The blocking nature of the MB APIs make it difficult to write >> interfaces which aim at being fault tolerant and work as >> gateways. Having non-blocking versions would be better for this >> sort of application. >> >> Are there better ways to connect MBs and ESP8266 ? >> >> We also tried I2C, but gave up, since the pins on the MB for >> accessing I2C were too tiny to connect to without a breakout >> board. >> >> BTW: We were impressed by the new radio module. Getting MBs >> to connect using these low level radios is really easy. >> >> Cheers, > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 21 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ From mal at egenix.com Mon Nov 21 04:53:36 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 21 Nov 2016 10:53:36 +0100 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: References: <5831BB94.5020205@egenix.com> Message-ID: <5832C420.1060000@egenix.com> On 20.11.2016 19:20, David Whale wrote: > Ian Stephenson (aka @sniffCode on twitter) had the SPI working with an > SDCard really reliably, back in May: > > http://www.sniff.org.uk/2016/05/spi-explained-connecting-sd-cards-to.html > > Might be worth comparing notes with him. Sniff uses the standard mbed SPI > driver, same as the micro:bit does. > > Also double check your SPOL and SPHA settings to make sure they are > compatible with the receiving end. > > https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Clock_polarity_and_phase Thanks for these notes, David. We did have some problems with SPI at first. We used the wrong set of pins on the ESP, since this comes with two sets: one which is meant to connect SD cards (named SPI on the ESP) and another set which is available for other things (named HSPI): http://www.kloppenborg.net/images/blog/esp8266/esp8266-node-mcu-pinout.png (SPI are the green pins on the left, HSPI the green pins on the right). More infos on this (only found this now): http://d.av.id.au/blog/esp8266-hardware-spi-hspi-general-info-and-pinout/ We first used the SPI pins (since we didn't know about the second SPI set) and this resulted both the MB and the ESP to go crazy. Only when using the HSPI set things started working. Since both devices were running in SPI master mode, we simply crossed the MISO and MOSI cables, connecting MISO on the ESP to MOSI on the MB and vice-versa. We also pulled down the chip select pin on the ESP to GND using a 4.7k resistor. The MB doesn't expose this pin. This is also how you can connect two MBs using the SPI pins (we moved these to the large pins 0, 1 and 2 and used croco cables to connect). In any case, I'll keep on trying to get this to work. Thanks for all the input so far. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 21 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ From microbit at sheep.art.pl Mon Nov 21 05:01:17 2016 From: microbit at sheep.art.pl (Radomir Dopieralski) Date: Mon, 21 Nov 2016 11:01:17 +0100 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: <5832C420.1060000@egenix.com> References: <5831BB94.5020205@egenix.com> <5832C420.1060000@egenix.com> Message-ID: <20161121110117.38b16cc0@ghostwheel> On Mon, 21 Nov 2016 10:53:36 +0100 "M.-A. Lemburg" wrote: > Since both devices were running in SPI master mode, we simply > crossed the MISO and MOSI cables, connecting MISO on the > ESP to MOSI on the MB and vice-versa. We also pulled down > the chip select pin on the ESP to GND using a 4.7k resistor. > The MB doesn't expose this pin. This won't work. If you do that, each of the boards will completely ignore the other board's clock, and just spew data at its own pace. It may (unreliably) work when using two identical boards, as they are likely to have similar clocks, however, even that will go out of sync eventually. With completely different boards, such as the Micro:bit and the ESP8266, and with the clock speeds set with limited precision (the prescaler for the clock has only so much resolution), you are very unlikely to get any synchronisation at all. You could try using NodeMCU on the ESP8266, it has an I2C slave implemented. -- Radomir Dopieralski From david at thinkingbinaries.com Mon Nov 21 05:02:44 2016 From: david at thinkingbinaries.com (David Whale) Date: Mon, 21 Nov 2016 10:02:44 +0000 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: <5832BF71.90903@egenix.com> References: <5831BB94.5020205@egenix.com> <20161120182129.139706fc@ghostwheel> <5832BF71.90903@egenix.com> Message-ID: How did you connect the two micro:bits and transfer data between them? Could you send a wiring diagram we can look at? As Damien says, the SPI on the micro:bit is master only, so it will be generating the clock. If you have two micro:bits, then you have two devices generating a clock. I can't really see how you managed to get this to work at all? Thanks David On 21 November 2016 at 09:33, M.-A. Lemburg wrote: > On 20.11.2016 18:21, Radomir Dopieralski wrote: > > You sometimes get unreliable transmission if your use a different > > spi mode than the device expects (it then reads the value from the > > bus at the wrong moment, and can read it when it is changing). > > We made sure that both ESP and MB were using SPI mode 0 > in software. Of course, it's possible that the hardware > was still using different modes and this could explain > the unreliable transmissions. > > This would then hint at a software bug somewhere. > > We did not look into this at depth using an analyzer. > > The fact that connecting two MBs using SPI did not result > in such unreliable transmission would also hint at an > incompatibility at the SPI mode level. > > > > On Sun, 20 Nov 2016 17:06:52 +0000 > > Nevil Hunt wrote: > > > >> Marc-Andre, > >> > >> > >> As regards... > >> > >> > >> * the connection is rather unreliable: we had lots of data loss or > >> data corruption, with bytes not being transmitted or with lost bits > >> - we tried several different baud rates without success > >> > >> > >> I'd certainly be interested if you can find out why. > >> > >> I hooked a micro:bit up to a SPI RAM about a month ago and was able > >> to write then read back from it, however it was a bit unreliable as > >> sometimes the 'Reads' returned corrupted data. > >> > >> From my recollection it looked like it was the 'Write' that was > >> getting corrupted as repeated 'Reads' always returned the same > >> corrupted data. > >> > >> I used the 'Bus Pirate' to try and debug it but I wasn't able to > >> determine whether it was a h/w or s/w problem...then I ran out of > >> time and haven't returned to it! > >> > >> I have however been in touch with Paul from Microsoft who has a > >> micro:bit talking to an SD Card with s/w written in 'C' so it looks > >> like the micro:bit SPI interface can be made to work! > >> > >> > >> Cheers, > >> > >> > >> Nevil > >> > >> > >> ________________________________ > >> From: Microbit > >> on behalf of M.-A. Lemburg Sent: 20 November 2016 > >> 15:04 To: For Pythonic MicroBit related discussions > >> Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 > >> > >> Hello, > >> > >> over the weekend, we tried to get a connection from a BBC Microbit > >> to an ESP8266, both running the latest MicroPython for the resp. > >> platform, established via SPI. > >> > >> We found several problems with this: > >> > >> * the SPI APIs on the ESP8266 are all non-blocking and return > >> whatever is currently in the buffer (using 0x00 for missing data > >> and 0xff in case no connection is available) > >> > >> * the SPI APIs on the Microbit are all blocking, only returning > >> if all data is sent / received > >> > >> * the connection is rather unreliable: we had lots of data loss or > >> data corruption, with bytes not being transmitted or with lost bits > >> - we tried several different baud rates without success > >> > >> On the plus side, we did get SPI to work fine between two Microbits, > >> but that's not really what we were after, since we wanted to get > >> one of the Microbits in our mesh network connected to a WLAN and > >> work as gateway. > >> > >> The blocking nature of the MB APIs make it difficult to write > >> interfaces which aim at being fault tolerant and work as > >> gateways. Having non-blocking versions would be better for this > >> sort of application. > >> > >> Are there better ways to connect MBs and ESP8266 ? > >> > >> We also tried I2C, but gave up, since the pins on the MB for > >> accessing I2C were too tiny to connect to without a breakout > >> board. > >> > >> BTW: We were impressed by the new radio module. Getting MBs > >> to connect using these low level radios is really easy. > >> > >> Cheers, > > > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, Nov 21 2016) > >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ > >>> Python Database Interfaces ... http://products.egenix.com/ > >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ > ________________________________________________________________________ > > ::: We implement business ideas - efficiently in both time and costs ::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > http://www.malemburg.com/ > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mal at egenix.com Mon Nov 21 06:44:38 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 21 Nov 2016 12:44:38 +0100 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: <20161121110117.38b16cc0@ghostwheel> References: <5831BB94.5020205@egenix.com> <5832C420.1060000@egenix.com> <20161121110117.38b16cc0@ghostwheel> Message-ID: <5832DE26.9030300@egenix.com> On 21.11.2016 11:01, Radomir Dopieralski wrote: > On Mon, 21 Nov 2016 10:53:36 +0100 > "M.-A. Lemburg" wrote: > >> Since both devices were running in SPI master mode, we simply >> crossed the MISO and MOSI cables, connecting MISO on the >> ESP to MOSI on the MB and vice-versa. We also pulled down >> the chip select pin on the ESP to GND using a 4.7k resistor. >> The MB doesn't expose this pin. > > This won't work. If you do that, each of the boards will completely > ignore the other board's clock, and just spew data at its own pace. > It may (unreliably) work when using two identical boards, as they are > likely to have similar clocks, however, even that will go out of sync > eventually. With completely different boards, such as the Micro:bit and > the ESP8266, and with the clock speeds set with limited precision (the > prescaler for the clock has only so much resolution), you are very > unlikely to get any synchronisation at all. Ah, now that explains what we were seeing :-) Thanks for the explanation. > You could try using NodeMCU on the ESP8266, it has an I2C slave > implemented. Hmm, that would mean programming LUA... I'd rather stay with MicroPython, if possible :-) Looking at the mbed sources for SPI, the blocking appears to be a result of their API implementation: https://developer.mbed.org/users/mbed_official/code/mbed-src/file/a11c0372f0ba/hal/spi_api.h (even though it is only documented for the slave APIs) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 21 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ From david at thinkingbinaries.com Mon Nov 21 06:45:16 2016 From: david at thinkingbinaries.com (David Whale) Date: Mon, 21 Nov 2016 11:45:16 +0000 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: References: <5831BB94.5020205@egenix.com> <20161120182129.139706fc@ghostwheel> <5832BF71.90903@egenix.com> Message-ID: Hi there! As Radomir says - that won't work, unfortunately. SPI is a master/slave system, the master generates the clock, and the slave has to be synchronised to that clock. If both devices are generating a clock, you will get clock drift and therefore your data will become corrupted. In particular, if you look at the direction of the arrows on the first diagram on the wiki page, you'll see that SCLK is only driven from master to slave: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus One end must be configured as master, the other end must be configured as slave. We don't have an SPI slave implementation on the micro:bit. I'm also not quite sure I understand your questions about 'blocking API'. The SPI master will 'just blat out data blindly at it's configured clock rate', regardless of what the slave sends back. There is no inherent acknowledgement at the physical layer in SPI like there is in I2C (which uses a 9th ACK bit). If you tx a data payload of 0x12 0x34 0x56 0x78 on SPI into 'fresh air' you will always get back 0xFF 0xFF 0xFF 0xFF (assuming the bus is terminated and floats high). We'd need to check the underlying mbed SPI driver, and the SPI peripheral on the nRF51 application processor, to see what could be causing it to 'lock up', as that sounds quite odd. Although if the peripheral in the master sets the clock high, and your other micro:bit (slave) pulls it low, the peripheral might be entering an error state because it thinks that it cannot drive the SCLK line correctly, and that may be stopping the transfer by entering an error state. SPI is a really simple protocol to implement in software. It won't be quick, so you may have to slow down the master clock rate, but you could write a polled SPI slave at the receiving end that would work. However, I think Damien is right here - it's so much easier to just use the UART between the two devices, that should just work out of the box. David. On 21 November 2016 at 10:02, David Whale wrote: > How did you connect the two micro:bits and transfer data between them? > Could you send a wiring diagram we can look at? > > As Damien says, the SPI on the micro:bit is master only, so it will be > generating the clock. If you have two micro:bits, then you have two devices > generating a clock. I can't really see how you managed to get this to work > at all? > > Thanks > > David > > > On 21 November 2016 at 09:33, M.-A. Lemburg wrote: > >> On 20.11.2016 18:21, Radomir Dopieralski wrote: >> > You sometimes get unreliable transmission if your use a different >> > spi mode than the device expects (it then reads the value from the >> > bus at the wrong moment, and can read it when it is changing). >> >> We made sure that both ESP and MB were using SPI mode 0 >> in software. Of course, it's possible that the hardware >> was still using different modes and this could explain >> the unreliable transmissions. >> >> This would then hint at a software bug somewhere. >> >> We did not look into this at depth using an analyzer. >> >> The fact that connecting two MBs using SPI did not result >> in such unreliable transmission would also hint at an >> incompatibility at the SPI mode level. >> >> >> > On Sun, 20 Nov 2016 17:06:52 +0000 >> > Nevil Hunt wrote: >> > >> >> Marc-Andre, >> >> >> >> >> >> As regards... >> >> >> >> >> >> * the connection is rather unreliable: we had lots of data loss or >> >> data corruption, with bytes not being transmitted or with lost bits >> >> - we tried several different baud rates without success >> >> >> >> >> >> I'd certainly be interested if you can find out why. >> >> >> >> I hooked a micro:bit up to a SPI RAM about a month ago and was able >> >> to write then read back from it, however it was a bit unreliable as >> >> sometimes the 'Reads' returned corrupted data. >> >> >> >> From my recollection it looked like it was the 'Write' that was >> >> getting corrupted as repeated 'Reads' always returned the same >> >> corrupted data. >> >> >> >> I used the 'Bus Pirate' to try and debug it but I wasn't able to >> >> determine whether it was a h/w or s/w problem...then I ran out of >> >> time and haven't returned to it! >> >> >> >> I have however been in touch with Paul from Microsoft who has a >> >> micro:bit talking to an SD Card with s/w written in 'C' so it looks >> >> like the micro:bit SPI interface can be made to work! >> >> >> >> >> >> Cheers, >> >> >> >> >> >> Nevil >> >> >> >> >> >> ________________________________ >> >> From: Microbit >> >> on behalf of M.-A. Lemburg Sent: 20 November 2016 >> >> 15:04 To: For Pythonic MicroBit related discussions >> >> Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 >> >> >> >> Hello, >> >> >> >> over the weekend, we tried to get a connection from a BBC Microbit >> >> to an ESP8266, both running the latest MicroPython for the resp. >> >> platform, established via SPI. >> >> >> >> We found several problems with this: >> >> >> >> * the SPI APIs on the ESP8266 are all non-blocking and return >> >> whatever is currently in the buffer (using 0x00 for missing data >> >> and 0xff in case no connection is available) >> >> >> >> * the SPI APIs on the Microbit are all blocking, only returning >> >> if all data is sent / received >> >> >> >> * the connection is rather unreliable: we had lots of data loss or >> >> data corruption, with bytes not being transmitted or with lost bits >> >> - we tried several different baud rates without success >> >> >> >> On the plus side, we did get SPI to work fine between two Microbits, >> >> but that's not really what we were after, since we wanted to get >> >> one of the Microbits in our mesh network connected to a WLAN and >> >> work as gateway. >> >> >> >> The blocking nature of the MB APIs make it difficult to write >> >> interfaces which aim at being fault tolerant and work as >> >> gateways. Having non-blocking versions would be better for this >> >> sort of application. >> >> >> >> Are there better ways to connect MBs and ESP8266 ? >> >> >> >> We also tried I2C, but gave up, since the pins on the MB for >> >> accessing I2C were too tiny to connect to without a breakout >> >> board. >> >> >> >> BTW: We were impressed by the new radio module. Getting MBs >> >> to connect using these low level radios is really easy. >> >> >> >> Cheers, >> > >> >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Experts (#1, Nov 21 2016) >> >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >> >>> Python Database Interfaces ... http://products.egenix.com/ >> >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ >> ________________________________________________________________________ >> >> ::: We implement business ideas - efficiently in both time and costs ::: >> >> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >> Registered at Amtsgericht Duesseldorf: HRB 46611 >> http://www.egenix.com/company/contact/ >> http://www.malemburg.com/ >> >> _______________________________________________ >> Microbit mailing list >> Microbit at python.org >> https://mail.python.org/mailman/listinfo/microbit >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mal at egenix.com Mon Nov 21 07:29:48 2016 From: mal at egenix.com (M.-A. Lemburg) Date: Mon, 21 Nov 2016 13:29:48 +0100 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: References: <5831BB94.5020205@egenix.com> <20161120182129.139706fc@ghostwheel> <5832BF71.90903@egenix.com> Message-ID: <5832E8BC.8020405@egenix.com> On 21.11.2016 12:45, David Whale wrote: > Hi there! > > As Radomir says - that won't work, unfortunately. > > SPI is a master/slave system, the master generates the clock, and the slave > has to be synchronised to that clock. If both devices are generating a > clock, you will get clock drift and therefore your data will become > corrupted. Yep and that's what we were seeing with the combination ESP/MB. The combination MB/MB worked quite well with the limited testing we did. > In particular, if you look at the direction of the arrows on the first > diagram on the wiki page, you'll see that SCLK is only driven from master > to slave: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus > > One end must be configured as master, the other end must be configured as > slave. We don't have an SPI slave implementation on the micro:bit. > > I'm also not quite sure I understand your questions about 'blocking API'. The API calls for spi.read() and spi.write() do not return until data is available/sent. E.g. spi.read(3) will wait until it has received 3 bytes of data. spi.write(b'abc') won't return until the receiving end has done an spi.read(3). > The SPI master will 'just blat out data blindly at it's configured clock > rate', regardless of what the slave sends back. There is no inherent > acknowledgement at the physical layer in SPI like there is in I2C (which > uses a 9th ACK bit). If you tx a data payload of 0x12 0x34 0x56 0x78 on > SPI into 'fresh air' you will always get back 0xFF 0xFF 0xFF 0xFF (assuming > the bus is terminated and floats high). Right and that's what you see on the ESP when doing a .read() without the MB connected. Once connected, you get 0x00 bytes. I believe the blocking has to do with the somewhat weird SPI interface mbed has for the master. It provides a single spi_master_write() API (and not _read() API), which writes out data and then reads data: /** Write a byte out in master mode and receive a value * * @param[in] obj The SPI peripheral to use for sending * @param[in] value The value to send * @return Returns the value received during send */ int spi_master_write(spi_t *obj, int value); (Source: https://developer.mbed.org/users/mbed_official/code/mbed-src/file/a11c0372f0ba/hal/spi_api.h) In MicroPython, the code uses this in a loop: .write(): for (uint i = 0; i < bufinfo.len; ++i, ++buf) { spi_master_write(&self->spi, *buf); } .read(): for (uint i = 0; i < vstr.len; ++i) { vstr.buf[i] = spi_master_write(&self->spi, byte_out); } (Source: https://github.com/bbcmicrobit/micropython/blob/master/source/microbit/microbitspi.cpp) I suppose the "read data" part is what's causing this to block. > We'd need to check the underlying mbed SPI driver, and the SPI peripheral > on the nRF51 application processor, to see what could be causing it to > 'lock up', as that sounds quite odd. Although if the peripheral in the > master sets the clock high, and your other micro:bit (slave) pulls it low, > the peripheral might be entering an error state because it thinks that it > cannot drive the SCLK line correctly, and that may be stopping the transfer > by entering an error state. > > SPI is a really simple protocol to implement in software. It won't be > quick, so you may have to slow down the master clock rate, but you could > write a polled SPI slave at the receiving end that would work. > > However, I think Damien is right here - it's so much easier to just use the > UART between the two devices, that should just work out of the box. Probably, yes, but we didn't want to give up the UART on the MB, since we'd then no longer be able to monitor whether the script is working correctly (via print() output). We had also run out of time at the sprint to give this a try, after first going with I2C and then SPI. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 21 2016) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ From david at thinkingbinaries.com Mon Nov 21 09:21:50 2016 From: david at thinkingbinaries.com (David Whale) Date: Mon, 21 Nov 2016 14:21:50 +0000 Subject: [Microbit-Python] SPI APIs on BBC micro:bit and ESP8266 In-Reply-To: <5832E8BC.8020405@egenix.com> References: <5831BB94.5020205@egenix.com> <20161120182129.139706fc@ghostwheel> <5832BF71.90903@egenix.com> <5832E8BC.8020405@egenix.com> Message-ID: Hi! >>I believe the blocking has to do with the somewhat weird >>SPI interface mbed has for the master. It provides a single >>spi_master_write() API (and not _read() API), which writes out >>data and then reads data: Actually, this is normal SPI behaviour. SPI is like a big shift register, it shifts out one tx bit from the master, then it shifts in one rx bit from the slave. So every transaction is always a send and a receive together. Calling it 'write' is a bit of a mis-noma, it should really be called 'transfer' as data transfers bi-directionally, bit at a time. If you transmit 4 bytes, then you always receive 4 bytes back. If you look at this diagram, you can see that 8 clock pulses will cause a byte to be transmitted from the master, and a byte to be received from the slave. At the end of this byte transfer, the value that was in the data register in the master, and the data that was in the value register in the slave, have been swapped. Slave devices build their response protocol on top of this very basic physical layer. These higher level device protocols often look a little odd, this is because the master cannot know what the slave has sent back in the first byte, until the first tx byte has completed. https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#Operation There is no acknowledgement at the physical layer with SPI. The master is in full control of the bus and is the only device that drives the clock. As SPI transfers are normally very fast, it's usual to not worry about blocking behaviour of the 'transmit' (master end), as the master is in control and the bus speed is usually fast and this will always be predictable and a fixed time for a given number of bytes at a given clock rate. The receive end is more critical, if the receiver wishes to do other things while waiting for the master to start sending a packet, as it may want to get on with other things while transacting with the master. The mbed SPI driver has an async mode, I think that's what you are looking for in this case for it to be 'non blocking'? [image: Inline images 1] David. On 21 November 2016 at 12:29, M.-A. Lemburg wrote: > On 21.11.2016 12:45, David Whale wrote: > > Hi there! > > > > As Radomir says - that won't work, unfortunately. > > > > SPI is a master/slave system, the master generates the clock, and the > slave > > has to be synchronised to that clock. If both devices are generating a > > clock, you will get clock drift and therefore your data will become > > corrupted. > > Yep and that's what we were seeing with the combination ESP/MB. > The combination MB/MB worked quite well with the limited testing > we did. > > > In particular, if you look at the direction of the arrows on the first > > diagram on the wiki page, you'll see that SCLK is only driven from master > > to slave: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus > > > > One end must be configured as master, the other end must be configured as > > slave. We don't have an SPI slave implementation on the micro:bit. > > > > I'm also not quite sure I understand your questions about 'blocking API'. > > The API calls for spi.read() and spi.write() do not return > until data is available/sent. > > E.g. spi.read(3) will wait until it has received 3 bytes of > data. spi.write(b'abc') won't return until the receiving end > has done an spi.read(3). > > > The SPI master will 'just blat out data blindly at it's configured clock > > rate', regardless of what the slave sends back. There is no inherent > > acknowledgement at the physical layer in SPI like there is in I2C (which > > uses a 9th ACK bit). If you tx a data payload of 0x12 0x34 0x56 0x78 on > > SPI into 'fresh air' you will always get back 0xFF 0xFF 0xFF 0xFF > (assuming > > the bus is terminated and floats high). > > Right and that's what you see on the ESP when doing a .read() > without the MB connected. Once connected, you get 0x00 bytes. > > I believe the blocking has to do with the somewhat weird > SPI interface mbed has for the master. It provides a single > spi_master_write() API (and not _read() API), which writes out > data and then reads data: > > /** Write a byte out in master mode and receive a value > * > * @param[in] obj The SPI peripheral to use for sending > * @param[in] value The value to send > * @return Returns the value received during send > */ > int spi_master_write(spi_t *obj, int value); > > (Source: > https://developer.mbed.org/users/mbed_official/code/mbed- > src/file/a11c0372f0ba/hal/spi_api.h) > > In MicroPython, the code uses this in a loop: > > .write(): > for (uint i = 0; i < bufinfo.len; ++i, ++buf) { > spi_master_write(&self->spi, *buf); > } > > .read(): > for (uint i = 0; i < vstr.len; ++i) { > vstr.buf[i] = spi_master_write(&self->spi, byte_out); > } > > (Source: > https://github.com/bbcmicrobit/micropython/blob/master/source/microbit/ > microbitspi.cpp) > > I suppose the "read data" part is what's causing this > to block. > > > We'd need to check the underlying mbed SPI driver, and the SPI peripheral > > on the nRF51 application processor, to see what could be causing it to > > 'lock up', as that sounds quite odd. Although if the peripheral in the > > master sets the clock high, and your other micro:bit (slave) pulls it > low, > > the peripheral might be entering an error state because it thinks that it > > cannot drive the SCLK line correctly, and that may be stopping the > transfer > > by entering an error state. > > > > SPI is a really simple protocol to implement in software. It won't be > > quick, so you may have to slow down the master clock rate, but you could > > write a polled SPI slave at the receiving end that would work. > > > > However, I think Damien is right here - it's so much easier to just use > the > > UART between the two devices, that should just work out of the box. > > Probably, yes, but we didn't want to give up the UART on the MB, > since we'd then no longer be able to monitor whether the script is > working correctly (via print() output). We had also run out > of time at the sprint to give this a try, after first > going with I2C and then SPI. > > Cheers, > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, Nov 21 2016) > >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ > >>> Python Database Interfaces ... http://products.egenix.com/ > >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ > ________________________________________________________________________ > > ::: We implement business ideas - efficiently in both time and costs ::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > http://www.egenix.com/company/contact/ > http://www.malemburg.com/ > > _______________________________________________ > Microbit mailing list > Microbit at python.org > https://mail.python.org/mailman/listinfo/microbit > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-11-21 at 14.19.17.png Type: image/png Size: 37794 bytes Desc: not available URL: From nevil.hunt at hotmail.co.uk Tue Nov 22 03:12:30 2016 From: nevil.hunt at hotmail.co.uk (Nevil Hunt) Date: Tue, 22 Nov 2016 08:12:30 +0000 Subject: [Microbit-Python] Multiplexing UART between GPIO and REPL Message-ID: Hi, This is just thinking out loud after following Marc-Andre's attempts to get the WiFi module talking to the micro:bit. The conclusion seemed to be... "it's so much easier to just use the UART between the two devices, that should just work out of the box." but... "Probably, yes, but we didn't want to give up the UART on the MB, since we'd then no longer be able to monitor whether the script is working correctly (via print() output)." I have a few m:bit applications where I would like to use the UART to connect to external h/w but I was aware if programmed in Python I would loose the REPL, and debugging without the REPL to display 'print' commands and/or report syntax/memory errors would be difficult, so I wondered if this idea would be possible:- Could the UART be assigned to GPIO pins for communicating with the external h/w but, just before a 'print' command, could the UART Tx be reassigned to the USB? The text would then be sent to the REPL before the UART would need to be reassigned back to the GPIO pin. If so, could it be achieved without changing the current Micro Python / DAL. i.e. just within the user's Python code? The next stage would be to also send syntax error messages to the REPL. Does anyone have a view as to whether in theory this could be done within Micro Python or would it also require DAL changes? Cheers, Nevil -------------- next part -------------- An HTML attachment was scrubbed... URL: From danka.miklos at gmail.com Sun Nov 27 01:03:29 2016 From: danka.miklos at gmail.com (=?UTF-8?B?TWlrbMOzcyBBbmRyw6FzIERhbmth?=) Date: Sun, 27 Nov 2016 06:03:29 +0000 Subject: [Microbit-Python] Microbit Python Doc translation In-Reply-To: References: Message-ID: Hi, I haven't got any responses, so I wanted to ping again before I start hosting a fork. Read The Docs supports localisation in this way: http://read-the-docs.readthedocs.io/en/latest/localization.html Would you up for doing this? Thanks, Miklos On Mon, Oct 31, 2016 at 9:26 PM Mikl?s Andr?s Danka wrote: > Hello, > > I'm Miklos Danka, a software engineer and a teacher (here's an example > ). I'm > writing regarding the BBC Microbit Python edition - please let me know if > this is not the right place or contact for it. > > First of all: *it's really awesome.* Incredible job, especially around > the documentation, which even less experienced kids understood well. Very > very cool. > > Since I teach kids in Hungary, I wanted to translate the documentation > to Hungarian. My > question is: *do you have a recommended/preferred way of publishing the > translation?* I can always just fork the repository - but that would miss > out on the benefits of having the documentations tracked together at the > same website. > Would you recommend it as a Sphinx "version" (next to "latest" and > "stable")? Or does Sphinx provide and orthogonal translation feature? > > Any ideas/suggestions would be very welcome and appreciated. > > Thanks! > Miklos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ntoll at ntoll.org Sun Nov 27 07:13:26 2016 From: ntoll at ntoll.org (Nicholas H.Tollervey) Date: Sun, 27 Nov 2016 12:13:26 +0000 Subject: [Microbit-Python] Microbit Python Doc translation In-Reply-To: References: Message-ID: Hi Mikl?s, Hmmm... I can't find your original email to this mailing list. Also, to post you need to be a member (you can join here: https://mail.python.org/mailman/listinfo/microbit) although I get notified of all the non-member postings so let this one through! Also, since you're not a member I'm not sure you'll see any replies to the mailing list (hence me cc'ing you to my reply). Regarding translation and ReadTheDocs: it would be wonderful to have Hungarian translations of the documentation! RtD have started to put advertising on our documentation and there is also work on the pyedu.io website for Python in education related resources. I wonder if we shouldn't just put our tutorials on there instead (along with lots of other education related resources)..? Thoughts..? N. On 27/11/16 06:03, Mikl?s Andr?s Danka wrote: > Hi, > > I haven't got any responses, so I wanted to ping again before I start > hosting a fork. > > Read The Docs supports localisation in this way: > http://read-the-docs.readthedocs.io/en/latest/localization.html > > Would you up for doing this? > > Thanks, > Miklos > > > On Mon, Oct 31, 2016 at 9:26 PM Mikl?s Andr?s Danka > > wrote: > > Hello, > > I'm Miklos Danka, a software engineer and a teacher (here's an > example > ). I'm > writing regarding the BBC Microbit Python edition - please let me > know if this is not the right place or contact for it. > > First of all: *it's really awesome.* Incredible job, especially > around the documentation, which even less experienced kids > understood well. Very very cool. > > Since I teach kids in Hungary, I wanted to translate the > documentation > to > Hungarian. My question is: *do you have a recommended/preferred way > of publishing the translation?* I can always just fork the > repository - but that would miss out on the benefits of having the > documentations tracked together at the same website. > Would you recommend it as a Sphinx "version" (next to "latest" and > "stable")? Or does Sphinx provide and orthogonal translation feature? > > Any ideas/suggestions would be very welcome and appreciated. > > Thanks! > Miklos > > > > _______________________________________________ > 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: 455 bytes Desc: OpenPGP digital signature URL: From carlosperate at gmail.com Sun Nov 27 07:25:57 2016 From: carlosperate at gmail.com (Carlos Pereira Atencio) Date: Sun, 27 Nov 2016 12:25:57 +0000 Subject: [Microbit-Python] Microbit Python Doc translation In-Reply-To: References: Message-ID: Let's not forget we still need to formalise the way we create and process the translations: https://github.com/bbcmicrobit/micropython/pull/371 There's been some conversation there but not decisions done at all. On Sun, 27 Nov 2016, 12:13 Nicholas H.Tollervey, wrote: Hi Mikl?s, Hmmm... I can't find your original email to this mailing list. Also, to post you need to be a member (you can join here: https://mail.python.org/mailman/listinfo/microbit) although I get notified of all the non-member postings so let this one through! Also, since you're not a member I'm not sure you'll see any replies to the mailing list (hence me cc'ing you to my reply). Regarding translation and ReadTheDocs: it would be wonderful to have Hungarian translations of the documentation! RtD have started to put advertising on our documentation and there is also work on the pyedu.io website for Python in education related resources. I wonder if we shouldn't just put our tutorials on there instead (along with lots of other education related resources)..? Thoughts..? N. On 27/11/16 06:03, Mikl?s Andr?s Danka wrote: > Hi, > > I haven't got any responses, so I wanted to ping again before I start > hosting a fork. > > Read The Docs supports localisation in this way: > http://read-the-docs.readthedocs.io/en/latest/localization.html > > Would you up for doing this? > > Thanks, > Miklos > > > On Mon, Oct 31, 2016 at 9:26 PM Mikl?s Andr?s Danka > > wrote: > > Hello, > > I'm Miklos Danka, a software engineer and a teacher (here's an > example > ). I'm > writing regarding the BBC Microbit Python edition - please let me > know if this is not the right place or contact for it. > > First of all: *it's really awesome.* Incredible job, especially > around the documentation, which even less experienced kids > understood well. Very very cool. > > Since I teach kids in Hungary, I wanted to translate the > documentation > to > Hungarian. My question is: *do you have a recommended/preferred way > of publishing the translation?* I can always just fork the > repository - but that would miss out on the benefits of having the > documentations tracked together at the same website. > Would you recommend it as a Sphinx "version" (next to "latest" and > "stable")? Or does Sphinx provide and orthogonal translation feature? > > Any ideas/suggestions would be very welcome and appreciated. > > Thanks! > Miklos > > > > _______________________________________________ > 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 chris at chrisarndt.de Sun Nov 27 08:49:46 2016 From: chris at chrisarndt.de (Christopher Arndt) Date: Sun, 27 Nov 2016 14:49:46 +0100 Subject: [Microbit-Python] Microbit Python Doc translation In-Reply-To: References: Message-ID: Am 27.11.2016 um 13:13 schrieb Nicholas H.Tollervey: > Hmmm... I can't find your original email to this mailing list. https://mail.python.org/pipermail/microbit/2016-October/001450.html From danka.miklos at gmail.com Mon Nov 28 06:02:31 2016 From: danka.miklos at gmail.com (=?UTF-8?B?TWlrbMOzcyBBbmRyw6FzIERhbmth?=) Date: Mon, 28 Nov 2016 11:02:31 +0000 Subject: [Microbit-Python] Microbit Python Doc translation In-Reply-To: References: Message-ID: An alternative is Gitbook: https://www.gitbook.com/ - As far as I can see, it's free for public non-commercial uses - It supports translations: http://toolchain.gitbook.com/languages.html - It is non-technical to edit it - git backed, but no need to deal with git - For a live example, check out the documentation of Redux: http://redux.js.org/docs/basics/UsageWithReact.html Do you expect a reasonably quick decision on this? If these discussions take a longer time, then I think the best solution is if we fork the repo and start the translation - leaving time to decide the exact process. If you expect quick agreement, then we can wait until Gitbook or something else is set up. Thoughts? -Miklos PS. Nick, thanks for the response! I now requested membership. On Sun, Nov 27, 2016 at 11:26 PM Carlos Pereira Atencio < carlosperate at gmail.com> wrote: > Let's not forget we still need to formalise the way we create and process > the translations: https://github.com/bbcmicrobit/micropython/pull/371 > There's been some conversation there but not decisions done at all. > > > > On Sun, 27 Nov 2016, 12:13 Nicholas H.Tollervey, wrote: > > Hi Mikl?s, > > Hmmm... I can't find your original email to this mailing list. Also, to > post you need to be a member (you can join here: > https://mail.python.org/mailman/listinfo/microbit) although I get > notified of all the non-member postings so let this one through! Also, > since you're not a member I'm not sure you'll see any replies to the > mailing list (hence me cc'ing you to my reply). > > Regarding translation and ReadTheDocs: it would be wonderful to have > Hungarian translations of the documentation! RtD have started to put > advertising on our documentation and there is also work on the pyedu.io > website for Python in education related resources. > > I wonder if we shouldn't just put our tutorials on there instead (along > with lots of other education related resources)..? > > Thoughts..? > > N. > > > > On 27/11/16 06:03, Mikl?s Andr?s Danka wrote: > > Hi, > > > > I haven't got any responses, so I wanted to ping again before I start > > hosting a fork. > > > > Read The Docs supports localisation in this way: > > http://read-the-docs.readthedocs.io/en/latest/localization.html > > > > Would you up for doing this? > > > > Thanks, > > Miklos > > > > > > On Mon, Oct 31, 2016 at 9:26 PM Mikl?s Andr?s Danka > > > wrote: > > > > Hello, > > > > I'm Miklos Danka, a software engineer and a teacher (here's an > > example > > ). I'm > > writing regarding the BBC Microbit Python edition - please let me > > know if this is not the right place or contact for it. > > > > First of all: *it's really awesome.* Incredible job, especially > > around the documentation, which even less experienced kids > > understood well. Very very cool. > > > > Since I teach kids in Hungary, I wanted to translate the > > documentation > > to > > Hungarian. My question is: *do you have a recommended/preferred way > > of publishing the translation?* I can always just fork the > > repository - but that would miss out on the benefits of having the > > documentations tracked together at the same website. > > Would you recommend it as a Sphinx "version" (next to "latest" and > > "stable")? Or does Sphinx provide and orthogonal translation feature? > > > > Any ideas/suggestions would be very welcome and appreciated. > > > > Thanks! > > Miklos > > > > > > > > _______________________________________________ > > 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 carlosperate at gmail.com Mon Nov 28 06:15:24 2016 From: carlosperate at gmail.com (Carlos Pereira Atencio) Date: Mon, 28 Nov 2016 11:15:24 +0000 Subject: [Microbit-Python] Microbit Python Doc translation In-Reply-To: References: Message-ID: I am not really able to have a proper look until later, but from a very quick skim gitbook doesn't seem to offer any translation feature to give it an advantage over readthedocs. They both allow you to add translation to their document generation, but there isn't any features to be able to manage and synchronise such translations, no? Regards, Carlos On 28 November 2016 at 11:02, Mikl?s Andr?s Danka wrote: > An alternative is Gitbook: https://www.gitbook.com/ > > - As far as I can see, it's free for public non-commercial uses > - It supports translations: http://toolchain.gitbook.com/languages.html > - It is non-technical to edit it - git backed, but no need to deal > with git > - For a live example, check out the documentation of Redux: > http://redux.js.org/docs/basics/UsageWithReact.html > > > > Do you expect a reasonably quick decision on this? If these discussions > take a longer time, then I think the best solution is if we fork the repo > and start the translation - leaving time to decide the exact process. If > you expect quick agreement, then we can wait until Gitbook or something > else is set up. > > Thoughts? > > -Miklos > > > PS. Nick, thanks for the response! I now requested membership. > > > > > On Sun, Nov 27, 2016 at 11:26 PM Carlos Pereira Atencio < > carlosperate at gmail.com> wrote: > >> Let's not forget we still need to formalise the way we create and process >> the translations: https://github.com/bbcmicrobit/micropython/pull/371 >> There's been some conversation there but not decisions done at all. >> >> >> >> On Sun, 27 Nov 2016, 12:13 Nicholas H.Tollervey, wrote: >> >> Hi Mikl?s, >> >> Hmmm... I can't find your original email to this mailing list. Also, to >> post you need to be a member (you can join here: >> https://mail.python.org/mailman/listinfo/microbit) although I get >> notified of all the non-member postings so let this one through! Also, >> since you're not a member I'm not sure you'll see any replies to the >> mailing list (hence me cc'ing you to my reply). >> >> Regarding translation and ReadTheDocs: it would be wonderful to have >> Hungarian translations of the documentation! RtD have started to put >> advertising on our documentation and there is also work on the pyedu.io >> website for Python in education related resources. >> >> I wonder if we shouldn't just put our tutorials on there instead (along >> with lots of other education related resources)..? >> >> Thoughts..? >> >> N. >> >> >> >> On 27/11/16 06:03, Mikl?s Andr?s Danka wrote: >> > Hi, >> > >> > I haven't got any responses, so I wanted to ping again before I start >> > hosting a fork. >> > >> > Read The Docs supports localisation in this way: >> > http://read-the-docs.readthedocs.io/en/latest/localization.html >> > >> > Would you up for doing this? >> > >> > Thanks, >> > Miklos >> > >> > >> > On Mon, Oct 31, 2016 at 9:26 PM Mikl?s Andr?s Danka >> > > wrote: >> > >> > Hello, >> > >> > I'm Miklos Danka, a software engineer and a teacher (here's an >> > example >> > ). >> I'm >> > writing regarding the BBC Microbit Python edition - please let me >> > know if this is not the right place or contact for it. >> > >> > First of all: *it's really awesome.* Incredible job, especially >> > around the documentation, which even less experienced kids >> > understood well. Very very cool. >> > >> > Since I teach kids in Hungary, I wanted to translate the >> > documentation >> > to >> > Hungarian. My question is: *do you have a recommended/preferred way >> > of publishing the translation?* I can always just fork the >> > repository - but that would miss out on the benefits of having the >> > documentations tracked together at the same website. >> > Would you recommend it as a Sphinx "version" (next to "latest" and >> > "stable")? Or does Sphinx provide and orthogonal translation >> feature? >> > >> > Any ideas/suggestions would be very welcome and appreciated. >> > >> > Thanks! >> > Miklos >> > >> > >> > >> > _______________________________________________ >> > 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 danka.miklos at gmail.com Mon Nov 28 06:19:49 2016 From: danka.miklos at gmail.com (=?UTF-8?B?TWlrbMOzcyBBbmRyw6FzIERhbmth?=) Date: Mon, 28 Nov 2016 11:19:49 +0000 Subject: [Microbit-Python] Microbit Python Doc translation In-Reply-To: References: Message-ID: That's true - all I expected from translations support is that they allow listing translations together and possibly synchronising pages (so if I'm on page X and click the other language, I'm taken to the right page). What else are you looking for? More fine-grained support? Support for tracking/translating each English commit? I feel that ultimately, how live the documentation is in any language will depend on how active the community is. That's irrespective of the translation process. No? -Miklos On Mon, Nov 28, 2016 at 10:15 PM Carlos Pereira Atencio < carlosperate at gmail.com> wrote: > I am not really able to have a proper look until later, but from a very > quick skim gitbook doesn't seem to offer any translation feature to give it > an advantage over readthedocs. They both allow you to add translation to > their document generation, but there isn't any features to be able to > manage and synchronise such translations, no? > > Regards, > Carlos > > On 28 November 2016 at 11:02, Mikl?s Andr?s Danka > wrote: > > An alternative is Gitbook: https://www.gitbook.com/ > > - As far as I can see, it's free for public non-commercial uses > - It supports translations: http://toolchain.gitbook.com/languages.html > - It is non-technical to edit it - git backed, but no need to deal > with git > - For a live example, check out the documentation of Redux: > http://redux.js.org/docs/basics/UsageWithReact.html > > > Do you expect a reasonably quick decision on this? If these discussions > take a longer time, then I think the best solution is if we fork the repo > and start the translation - leaving time to decide the exact process. If > you expect quick agreement, then we can wait until Gitbook or something > else is set up. > > Thoughts? > > -Miklos > > > PS. Nick, thanks for the response! I now requested membership. > > > > > On Sun, Nov 27, 2016 at 11:26 PM Carlos Pereira Atencio < > carlosperate at gmail.com> wrote: > > Let's not forget we still need to formalise the way we create and process > the translations: https://github.com/bbcmicrobit/micropython/pull/371 > There's been some conversation there but not decisions done at all. > > > > On Sun, 27 Nov 2016, 12:13 Nicholas H.Tollervey, wrote: > > Hi Mikl?s, > > Hmmm... I can't find your original email to this mailing list. Also, to > post you need to be a member (you can join here: > https://mail.python.org/mailman/listinfo/microbit) although I get > notified of all the non-member postings so let this one through! Also, > since you're not a member I'm not sure you'll see any replies to the > mailing list (hence me cc'ing you to my reply). > > Regarding translation and ReadTheDocs: it would be wonderful to have > Hungarian translations of the documentation! RtD have started to put > advertising on our documentation and there is also work on the pyedu.io > website for Python in education related resources. > > I wonder if we shouldn't just put our tutorials on there instead (along > with lots of other education related resources)..? > > Thoughts..? > > N. > > > > On 27/11/16 06:03, Mikl?s Andr?s Danka wrote: > > Hi, > > > > I haven't got any responses, so I wanted to ping again before I start > > hosting a fork. > > > > Read The Docs supports localisation in this way: > > http://read-the-docs.readthedocs.io/en/latest/localization.html > > > > Would you up for doing this? > > > > Thanks, > > Miklos > > > > > > On Mon, Oct 31, 2016 at 9:26 PM Mikl?s Andr?s Danka > > > wrote: > > > > Hello, > > > > I'm Miklos Danka, a software engineer and a teacher (here's an > > example > > ). I'm > > writing regarding the BBC Microbit Python edition - please let me > > know if this is not the right place or contact for it. > > > > First of all: *it's really awesome.* Incredible job, especially > > around the documentation, which even less experienced kids > > understood well. Very very cool. > > > > Since I teach kids in Hungary, I wanted to translate the > > documentation > > to > > Hungarian. My question is: *do you have a recommended/preferred way > > of publishing the translation?* I can always just fork the > > repository - but that would miss out on the benefits of having the > > documentations tracked together at the same website. > > Would you recommend it as a Sphinx "version" (next to "latest" and > > "stable")? Or does Sphinx provide and orthogonal translation feature? > > > > Any ideas/suggestions would be very welcome and appreciated. > > > > Thanks! > > Miklos > > > > > > > > _______________________________________________ > > 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 radomir at dopieralski.pl Mon Nov 28 06:38:11 2016 From: radomir at dopieralski.pl (Radomir Dopieralski) Date: Mon, 28 Nov 2016 12:38:11 +0100 Subject: [Microbit-Python] Microbit Python Doc translation In-Reply-To: References: Message-ID: <20161128123811.2b48c22b@ghostwheel> I looked at gitbook, and I have a number of issues with it: 1. I uses a non-standard format completely different from the Sphinx documentation format that we are using, that is a well established standard among Python projects. 2. The "support" for translations is basically just linking to different language versions. There is no support whatsoever for actually translating the content or for keeping track and updating of translations. 3. It requires creation of yet another account, in addition to the github one, which is needed anyways. In the mean time, the contributors to the readthedocs translations can simply click the "edit on github" link, and edit the files right in the browser. They don't need a readthedocs account, unless they are starting a translation to a new language. On Mon, 28 Nov 2016 11:02:31 +0000 Mikl?s Andr?s Danka wrote: > An alternative is Gitbook: https://www.gitbook.com/ > > - As far as I can see, it's free for public non-commercial uses > - It supports translations: > http://toolchain.gitbook.com/languages.html > - It is non-technical to edit it - git backed, but no need to deal > with git > - For a live example, check out the documentation of Redux: > http://redux.js.org/docs/basics/UsageWithReact.html > > > Do you expect a reasonably quick decision on this? If these > discussions take a longer time, then I think the best solution is if > we fork the repo and start the translation - leaving time to decide > the exact process. If you expect quick agreement, then we can wait > until Gitbook or something else is set up. > > Thoughts? > > -Miklos > > > PS. Nick, thanks for the response! I now requested membership. > > > > > On Sun, Nov 27, 2016 at 11:26 PM Carlos Pereira Atencio < > carlosperate at gmail.com> wrote: > > > Let's not forget we still need to formalise the way we create and > > process the translations: > > https://github.com/bbcmicrobit/micropython/pull/371 There's been > > some conversation there but not decisions done at all. > > > > > > > > On Sun, 27 Nov 2016, 12:13 Nicholas H.Tollervey, > > wrote: > > > > Hi Mikl?s, > > > > Hmmm... I can't find your original email to this mailing list. > > Also, to post you need to be a member (you can join here: > > https://mail.python.org/mailman/listinfo/microbit) although I get > > notified of all the non-member postings so let this one through! > > Also, since you're not a member I'm not sure you'll see any replies > > to the mailing list (hence me cc'ing you to my reply). > > > > Regarding translation and ReadTheDocs: it would be wonderful to have > > Hungarian translations of the documentation! RtD have started to put > > advertising on our documentation and there is also work on the > > pyedu.io website for Python in education related resources. > > > > I wonder if we shouldn't just put our tutorials on there instead > > (along with lots of other education related resources)..? > > > > Thoughts..? > > > > N. > > > > > > > > On 27/11/16 06:03, Mikl?s Andr?s Danka wrote: > > > Hi, > > > > > > I haven't got any responses, so I wanted to ping again before I > > > start hosting a fork. > > > > > > Read The Docs supports localisation in this way: > > > http://read-the-docs.readthedocs.io/en/latest/localization.html > > > > > > Would you up for doing this? > > > > > > Thanks, > > > Miklos > > > > > > > > > On Mon, Oct 31, 2016 at 9:26 PM Mikl?s Andr?s Danka > > > > wrote: > > > > > > Hello, > > > > > > I'm Miklos Danka, a software engineer and a teacher (here's an > > > example > > > ). > > > I'm writing regarding the BBC Microbit Python edition - please > > > let me know if this is not the right place or contact for it. > > > > > > First of all: *it's really awesome.* Incredible job, > > > especially around the documentation, which even less experienced > > > kids understood well. Very very cool. > > > > > > Since I teach kids in Hungary, I wanted to translate the > > > documentation > > > to > > > Hungarian. My question is: *do you have a > > > recommended/preferred way of publishing the translation?* I can > > > always just fork the repository - but that would miss out on the > > > benefits of having the documentations tracked together at the > > > same website. Would you recommend it as a Sphinx "version" (next > > > to "latest" and "stable")? Or does Sphinx provide and orthogonal > > > translation feature? > > > > > > Any ideas/suggestions would be very welcome and appreciated. > > > > > > Thanks! > > > Miklos > > > > > > > > > > > > _______________________________________________ > > > 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 > > > > -- Radomir Dopieralski From carlosperate at gmail.com Mon Nov 28 06:50:58 2016 From: carlosperate at gmail.com (Carlos Pereira Atencio) Date: Mon, 28 Nov 2016 11:50:58 +0000 Subject: [Microbit-Python] Microbit Python Doc translation In-Reply-To: References: Message-ID: Readthedocs already offers linked translations, so we can continue using this platform. As far was what I would be looking for is better support for translation tracking and updating, so that people could easily do small contribution without a complex set up or trying to figure out what to update by manually reading the English and translated documents to spot unsynchronised bits. I mention some of my concerns with git here: https://github.com/bbcmicrobit/micropython/pull/371#discussion_r89747053 I feel that ultimately, how live the documentation is in any language will > depend on how active the community is. That's irrespective of the > translation process. No? > I wouldn't quite agree with that, we (as the open source community) always point to documentation, or in this case translations, as an easy first step. If we make this difficult we might inadvertently be turning away valuable contributions. I would expect some of this translations to come also from not-so-technical communities, teachers for instance are great candidates, and every time I even mention git/github to teachers I never hear anything even remotely positive (this specific point is just my personal experience and should be taken completely anecdotally). If we ignoring the use of git for this solutions, then it would be a very manual process to keep track of changes. Yes, "edit this on github" and PRs are easy, and I think it does work great for normal documentation, but translations are do not really follow the same model and I don't feel like git really is the best way to manage them. On 28 November 2016 at 11:19, Mikl?s Andr?s Danka wrote: > That's true - all I expected from translations support is that they allow > listing translations together and possibly synchronising pages (so if I'm > on page X and click the other language, I'm taken to the right page). > > What else are you looking for? More fine-grained support? Support for > tracking/translating each English commit? > > I feel that ultimately, how live the documentation is in any language will > depend on how active the community is. That's irrespective of the > translation process. No? > > -Miklos > > On Mon, Nov 28, 2016 at 10:15 PM Carlos Pereira Atencio < > carlosperate at gmail.com> wrote: > >> I am not really able to have a proper look until later, but from a very >> quick skim gitbook doesn't seem to offer any translation feature to give it >> an advantage over readthedocs. They both allow you to add translation to >> their document generation, but there isn't any features to be able to >> manage and synchronise such translations, no? >> >> Regards, >> Carlos >> >> On 28 November 2016 at 11:02, Mikl?s Andr?s Danka > > wrote: >> >> An alternative is Gitbook: https://www.gitbook.com/ >> >> - As far as I can see, it's free for public non-commercial uses >> - It supports translations: http://toolchain.gitbook.com/ >> languages.html >> - It is non-technical to edit it - git backed, but no need to deal >> with git >> - For a live example, check out the documentation of Redux: >> http://redux.js.org/docs/basics/UsageWithReact.html >> >> >> >> Do you expect a reasonably quick decision on this? If these discussions >> take a longer time, then I think the best solution is if we fork the repo >> and start the translation - leaving time to decide the exact process. If >> you expect quick agreement, then we can wait until Gitbook or something >> else is set up. >> >> Thoughts? >> >> -Miklos >> >> >> PS. Nick, thanks for the response! I now requested membership. >> >> >> >> >> On Sun, Nov 27, 2016 at 11:26 PM Carlos Pereira Atencio < >> carlosperate at gmail.com> wrote: >> >> Let's not forget we still need to formalise the way we create and process >> the translations: https://github.com/bbcmicrobit/micropython/pull/371 >> There's been some conversation there but not decisions done at all. >> >> >> >> On Sun, 27 Nov 2016, 12:13 Nicholas H.Tollervey, wrote: >> >> Hi Mikl?s, >> >> Hmmm... I can't find your original email to this mailing list. Also, to >> post you need to be a member (you can join here: >> https://mail.python.org/mailman/listinfo/microbit) although I get >> notified of all the non-member postings so let this one through! Also, >> since you're not a member I'm not sure you'll see any replies to the >> mailing list (hence me cc'ing you to my reply). >> >> Regarding translation and ReadTheDocs: it would be wonderful to have >> Hungarian translations of the documentation! RtD have started to put >> advertising on our documentation and there is also work on the pyedu.io >> website for Python in education related resources. >> >> I wonder if we shouldn't just put our tutorials on there instead (along >> with lots of other education related resources)..? >> >> Thoughts..? >> >> N. >> >> >> >> On 27/11/16 06:03, Mikl?s Andr?s Danka wrote: >> > Hi, >> > >> > I haven't got any responses, so I wanted to ping again before I start >> > hosting a fork. >> > >> > Read The Docs supports localisation in this way: >> > http://read-the-docs.readthedocs.io/en/latest/localization.html >> > >> > Would you up for doing this? >> > >> > Thanks, >> > Miklos >> > >> > >> > On Mon, Oct 31, 2016 at 9:26 PM Mikl?s Andr?s Danka >> > > wrote: >> > >> > Hello, >> > >> > I'm Miklos Danka, a software engineer and a teacher (here's an >> > example >> > ). >> I'm >> > writing regarding the BBC Microbit Python edition - please let me >> > know if this is not the right place or contact for it. >> > >> > First of all: *it's really awesome.* Incredible job, especially >> > around the documentation, which even less experienced kids >> > understood well. Very very cool. >> > >> > Since I teach kids in Hungary, I wanted to translate the >> > documentation >> > to >> > Hungarian. My question is: *do you have a recommended/preferred way >> > of publishing the translation?* I can always just fork the >> > repository - but that would miss out on the benefits of having the >> > documentations tracked together at the same website. >> > Would you recommend it as a Sphinx "version" (next to "latest" and >> > "stable")? Or does Sphinx provide and orthogonal translation >> feature? >> > >> > Any ideas/suggestions would be very welcome and appreciated. >> > >> > Thanks! >> > Miklos >> > >> > >> > >> > _______________________________________________ >> > 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 danka.miklos at gmail.com Mon Nov 28 06:59:15 2016 From: danka.miklos at gmail.com (=?UTF-8?B?TWlrbMOzcyBBbmRyw6FzIERhbmth?=) Date: Mon, 28 Nov 2016 11:59:15 +0000 Subject: [Microbit-Python] Microbit Python Doc translation In-Reply-To: References: Message-ID: Makes a lot more sense! Let me ruminate and explore a bit more. -Miklos On Mon, Nov 28, 2016 at 10:51 PM Carlos Pereira Atencio < carlosperate at gmail.com> wrote: > Readthedocs already offers linked translations, so we can continue using > this platform. As far was what I would be looking for is better support for > translation tracking and updating, so that people could easily do small > contribution without a complex set up or trying to figure out what to > update by manually reading the English and translated documents to spot > unsynchronised bits. I mention some of my concerns with git here: > https://github.com/bbcmicrobit/micropython/pull/371#discussion_r89747053 > > > I feel that ultimately, how live the documentation is in any language will > depend on how active the community is. That's irrespective of the > translation process. No? > > > I wouldn't quite agree with that, we (as the open source community) always > point to documentation, or in this case translations, as an easy first > step. If we make this difficult we might inadvertently be turning away > valuable contributions. I would expect some of this translations to come > also from not-so-technical communities, teachers for instance are great > candidates, and every time I even mention git/github to teachers I never > hear anything even remotely positive (this specific point is just my > personal experience and should be taken completely anecdotally). If we > ignoring the use of git for this solutions, then it would be a very manual > process to keep track of changes. Yes, "edit this on github" and PRs are > easy, and I think it does work great for normal documentation, but > translations are do not really follow the same model and I don't feel like > git really is the best way to manage them. > > > > On 28 November 2016 at 11:19, Mikl?s Andr?s Danka > wrote: > > That's true - all I expected from translations support is that they allow > listing translations together and possibly synchronising pages (so if I'm > on page X and click the other language, I'm taken to the right page). > > What else are you looking for? More fine-grained support? Support for > tracking/translating each English commit? > > I feel that ultimately, how live the documentation is in any language will > depend on how active the community is. That's irrespective of the > translation process. No? > > -Miklos > > On Mon, Nov 28, 2016 at 10:15 PM Carlos Pereira Atencio < > carlosperate at gmail.com> wrote: > > I am not really able to have a proper look until later, but from a very > quick skim gitbook doesn't seem to offer any translation feature to give it > an advantage over readthedocs. They both allow you to add translation to > their document generation, but there isn't any features to be able to > manage and synchronise such translations, no? > > Regards, > Carlos > > On 28 November 2016 at 11:02, Mikl?s Andr?s Danka > wrote: > > An alternative is Gitbook: https://www.gitbook.com/ > > - As far as I can see, it's free for public non-commercial uses > - It supports translations: http://toolchain.gitbook.com/languages.html > - It is non-technical to edit it - git backed, but no need to deal > with git > - For a live example, check out the documentation of Redux: > http://redux.js.org/docs/basics/UsageWithReact.html > > > Do you expect a reasonably quick decision on this? If these discussions > take a longer time, then I think the best solution is if we fork the repo > and start the translation - leaving time to decide the exact process. If > you expect quick agreement, then we can wait until Gitbook or something > else is set up. > > Thoughts? > > -Miklos > > > PS. Nick, thanks for the response! I now requested membership. > > > > > On Sun, Nov 27, 2016 at 11:26 PM Carlos Pereira Atencio < > carlosperate at gmail.com> wrote: > > Let's not forget we still need to formalise the way we create and process > the translations: https://github.com/bbcmicrobit/micropython/pull/371 > There's been some conversation there but not decisions done at all. > > > > On Sun, 27 Nov 2016, 12:13 Nicholas H.Tollervey, wrote: > > Hi Mikl?s, > > Hmmm... I can't find your original email to this mailing list. Also, to > post you need to be a member (you can join here: > https://mail.python.org/mailman/listinfo/microbit) although I get > notified of all the non-member postings so let this one through! Also, > since you're not a member I'm not sure you'll see any replies to the > mailing list (hence me cc'ing you to my reply). > > Regarding translation and ReadTheDocs: it would be wonderful to have > Hungarian translations of the documentation! RtD have started to put > advertising on our documentation and there is also work on the pyedu.io > website for Python in education related resources. > > I wonder if we shouldn't just put our tutorials on there instead (along > with lots of other education related resources)..? > > Thoughts..? > > N. > > > > On 27/11/16 06:03, Mikl?s Andr?s Danka wrote: > > Hi, > > > > I haven't got any responses, so I wanted to ping again before I start > > hosting a fork. > > > > Read The Docs supports localisation in this way: > > http://read-the-docs.readthedocs.io/en/latest/localization.html > > > > Would you up for doing this? > > > > Thanks, > > Miklos > > > > > > On Mon, Oct 31, 2016 at 9:26 PM Mikl?s Andr?s Danka > > > wrote: > > > > Hello, > > > > I'm Miklos Danka, a software engineer and a teacher (here's an > > example > > ). I'm > > writing regarding the BBC Microbit Python edition - please let me > > know if this is not the right place or contact for it. > > > > First of all: *it's really awesome.* Incredible job, especially > > around the documentation, which even less experienced kids > > understood well. Very very cool. > > > > Since I teach kids in Hungary, I wanted to translate the > > documentation > > to > > Hungarian. My question is: *do you have a recommended/preferred way > > of publishing the translation?* I can always just fork the > > repository - but that would miss out on the benefits of having the > > documentations tracked together at the same website. > > Would you recommend it as a Sphinx "version" (next to "latest" and > > "stable")? Or does Sphinx provide and orthogonal translation feature? > > > > Any ideas/suggestions would be very welcome and appreciated. > > > > Thanks! > > Miklos > > > > > > > > _______________________________________________ > > 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 barrachri at gmail.com Wed Nov 30 07:45:10 2016 From: barrachri at gmail.com (Christian Barra) Date: Wed, 30 Nov 2016 13:45:10 +0100 Subject: [Microbit-Python] Microbit Python Doc translation In-Reply-To: References: Message-ID: Hello, so we plan to keep Readthedocs for https://microbit- micropython.readthedocs.io/en/latest/. I'm developing a workshop about Microbit for kids and use that for microbitpolska.org. My idea was to have like the software-carpentry lesson (for example http://swcarpentry.github.io/python-novice-inflammation/) but the best option would be to have a solution that also handles translations (sw lessons are just in english). Any idea ? Readthedocs ? 2016-11-28 12:59 GMT+01:00 Mikl?s Andr?s Danka : > Makes a lot more sense! Let me ruminate and explore a bit more. > > -Miklos > > On Mon, Nov 28, 2016 at 10:51 PM Carlos Pereira Atencio < > carlosperate at gmail.com> wrote: > >> Readthedocs already offers linked translations, so we can continue using >> this platform. As far was what I would be looking for is better support for >> translation tracking and updating, so that people could easily do small >> contribution without a complex set up or trying to figure out what to >> update by manually reading the English and translated documents to spot >> unsynchronised bits. I mention some of my concerns with git here: >> https://github.com/bbcmicrobit/micropython/pull/371#discussion_r89747053 >> >> >> I feel that ultimately, how live the documentation is in any language >> will depend on how active the community is. That's irrespective of the >> translation process. No? >> >> >> I wouldn't quite agree with that, we (as the open source community) >> always point to documentation, or in this case translations, as an easy >> first step. If we make this difficult we might inadvertently be turning >> away valuable contributions. I would expect some of this translations to >> come also from not-so-technical communities, teachers for instance are >> great candidates, and every time I even mention git/github to teachers I >> never hear anything even remotely positive (this specific point is just my >> personal experience and should be taken completely anecdotally). If we >> ignoring the use of git for this solutions, then it would be a very manual >> process to keep track of changes. Yes, "edit this on github" and PRs are >> easy, and I think it does work great for normal documentation, but >> translations are do not really follow the same model and I don't feel like >> git really is the best way to manage them. >> >> >> >> On 28 November 2016 at 11:19, Mikl?s Andr?s Danka > > wrote: >> >> That's true - all I expected from translations support is that they allow >> listing translations together and possibly synchronising pages (so if I'm >> on page X and click the other language, I'm taken to the right page). >> >> What else are you looking for? More fine-grained support? Support for >> tracking/translating each English commit? >> >> I feel that ultimately, how live the documentation is in any language >> will depend on how active the community is. That's irrespective of the >> translation process. No? >> >> -Miklos >> >> On Mon, Nov 28, 2016 at 10:15 PM Carlos Pereira Atencio < >> carlosperate at gmail.com> wrote: >> >> I am not really able to have a proper look until later, but from a very >> quick skim gitbook doesn't seem to offer any translation feature to give it >> an advantage over readthedocs. They both allow you to add translation to >> their document generation, but there isn't any features to be able to >> manage and synchronise such translations, no? >> >> Regards, >> Carlos >> >> On 28 November 2016 at 11:02, Mikl?s Andr?s Danka > > wrote: >> >> An alternative is Gitbook: https://www.gitbook.com/ >> >> - As far as I can see, it's free for public non-commercial uses >> - It supports translations: http://toolchain.gitbook.com/ >> languages.html >> - It is non-technical to edit it - git backed, but no need to deal >> with git >> - For a live example, check out the documentation of Redux: >> http://redux.js.org/docs/basics/UsageWithReact.html >> >> >> >> Do you expect a reasonably quick decision on this? If these discussions >> take a longer time, then I think the best solution is if we fork the repo >> and start the translation - leaving time to decide the exact process. If >> you expect quick agreement, then we can wait until Gitbook or something >> else is set up. >> >> Thoughts? >> >> -Miklos >> >> >> PS. Nick, thanks for the response! I now requested membership. >> >> >> >> >> On Sun, Nov 27, 2016 at 11:26 PM Carlos Pereira Atencio < >> carlosperate at gmail.com> wrote: >> >> Let's not forget we still need to formalise the way we create and process >> the translations: https://github.com/bbcmicrobit/micropython/pull/371 >> There's been some conversation there but not decisions done at all. >> >> >> >> On Sun, 27 Nov 2016, 12:13 Nicholas H.Tollervey, wrote: >> >> Hi Mikl?s, >> >> Hmmm... I can't find your original email to this mailing list. Also, to >> post you need to be a member (you can join here: >> https://mail.python.org/mailman/listinfo/microbit) although I get >> notified of all the non-member postings so let this one through! Also, >> since you're not a member I'm not sure you'll see any replies to the >> mailing list (hence me cc'ing you to my reply). >> >> Regarding translation and ReadTheDocs: it would be wonderful to have >> Hungarian translations of the documentation! RtD have started to put >> advertising on our documentation and there is also work on the pyedu.io >> website for Python in education related resources. >> >> I wonder if we shouldn't just put our tutorials on there instead (along >> with lots of other education related resources)..? >> >> Thoughts..? >> >> N. >> >> >> >> On 27/11/16 06:03, Mikl?s Andr?s Danka wrote: >> > Hi, >> > >> > I haven't got any responses, so I wanted to ping again before I start >> > hosting a fork. >> > >> > Read The Docs supports localisation in this way: >> > http://read-the-docs.readthedocs.io/en/latest/localization.html >> > >> > Would you up for doing this? >> > >> > Thanks, >> > Miklos >> > >> > >> > On Mon, Oct 31, 2016 at 9:26 PM Mikl?s Andr?s Danka >> > > wrote: >> > >> > Hello, >> > >> > I'm Miklos Danka, a software engineer and a teacher (here's an >> > example >> > ). >> I'm >> > writing regarding the BBC Microbit Python edition - please let me >> > know if this is not the right place or contact for it. >> > >> > First of all: *it's really awesome.* Incredible job, especially >> > around the documentation, which even less experienced kids >> > understood well. Very very cool. >> > >> > Since I teach kids in Hungary, I wanted to translate the >> > documentation >> > to >> > Hungarian. My question is: *do you have a recommended/preferred way >> > of publishing the translation?* I can always just fork the >> > repository - but that would miss out on the benefits of having the >> > documentations tracked together at the same website. >> > Would you recommend it as a Sphinx "version" (next to "latest" and >> > "stable")? Or does Sphinx provide and orthogonal translation >> feature? >> > >> > Any ideas/suggestions would be very welcome and appreciated. >> > >> > Thanks! >> > Miklos >> > >> > >> > >> > _______________________________________________ >> > 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 > > -- With Gravitational Cheers, Christian EuroPython Society board member -------------- next part -------------- An HTML attachment was scrubbed... URL: