MicroPython Forum (Archive)

This post is somewhat overdue, it should have gone somewhere in March, the anniversary of the Kickstarter project, but due do reasons explained below, I'm getting to it just now.

So, more than a year ago, when we with Damien considered what would be a reasonable target for the campaign, we considered one year of development for the port, with the idea that afterwards it will be supported and maintained largely by the community. Well, as you know, the campaign went a great success, so - the project continues! Our specific work breakdown is as follows:

Myself - given that we haven't finished all the stretch goals yet, I'm concentrating on ESP8266 port, avoiding the temptation to work, or even play, with other hardware, this includes ESP32. (As a full disclosure, I also work on Zephyr RTOS port as part of my dayjob). Unfortunately, I had some health issues last few months, which affect my productivity and probably will continue for the foreseeable future.

Damien - you might have heard that ESP32 port was started, it currently lives in the separate tree: https://github.com/micropython/micropython-esp32 , so Damien works both on ESP8266 and ESP32 (and bunch of other things, as he's full time on MicroPython).

I guess such responsibility breakdown is the best we can have - a lot of people were interested in ESP32 and even asked it to be a stretch goal for ESP8266 campaign (which we couldn't reasonable do, and indeed, ESP32 general availability was largely delayed), so now there's ESP32 port! At the same time, it's important to continue working on ESP8266 tasks - the whole idea of the project was to improve MicroPython as a whole while working on ESP8266 port.

By now, we tackled almost all of the stretch goals. Many of course can use or need further work, but that's of course how it is expected to be - if the feature is needed and interesting, there's always something to improve or optimize. One feature still waiting in the queue is the consistent, standardized sensor driver API and driver library. That task was blocked on finalizing Hardware API, so hopefully soon we'll get to it.

Oh, there's yet another still-in-the-queue stretch goal: tutorial videos. Well... We got carried away... It's even some of our backers had concerns, arguing to other backers: "Guys, don't push on that, let these guys do what they can do the best - write code". Last time we discussed this issue with Damien, he was positive it's still a fun task he'd be interested to do soon. Well, months pass, we're working on the code daily on average, and the fun time when we can just relax and shoot some fun video doesn't come .

So, I have a proposal to our backers. As you know, for ESP8266 campaign, we partnered with Adafruit for sharing a word about MicroPython on ESP8266. They went much further than that and recorded bunch of the great videos for MicroPython on the ESP. They actually went even further than that - they forked MicroPython to use on their future boards. Unfortunately, cooperation on the development side didn't go that well - they never contributed a single patch back to the mainline, not even typo fixes they made throughout the codebase. So, I would like to ask the EPS8266 Kickstarter campaign backers if they would consider fair to treat Adafruit's MicroPython tutorial video contributions to the wide MicroPython community, following the principle that everyone does what they can do the best: the mainline developers work on the code, which also benefits Adafruit, and Adafruit gives back to ESP8266 users with the excellent tutorials.

If the backers don't agree to such "exchange", well, the videos then still remain on us, it's a matter of time when they will be done...

Thanks!

I wasn't a backer (got into ESP's late) but my two cents is that the Adafruit videos are more than sufficient to meet this goal. Until CircuitPython becomes so different that the videos are of no use (its close or there already) or the existing micropython videos become too dated to be useful there is no need to replace what works. Maybe the video effort would be better suited to something like micropython 2.0 where the fresh start would likely be required...

Hello Paul, it's not good that xou have health issues. I hope you will fully recover. Best whishes for that from my side. Robert

Also the best wishes from my side!

And the minor thing... with the videos stretch goal... you have my backer voice to steal back the fruits (bad reference to adafruit ).

Also best wishes on your recovery. In my mind, Tony DiCola's esp8266 and other micropython videos more than fulfill the need for tutorial videos. From my point of view, I would have Damien and you spend as much time on micropython code as possible. The excellent work that you have done has opened up opportunities to create IoT projects that I would otherwise not have been able to pursue. Thank you.

Thanks for the update. Amazing effort to date. Well done team!

IMHO scrap video tutorials in favour of regular text/screenshot based tutorials, and add more real-world examples. eg.
https://github.com/pfalcon/picoweb
https://github.com/pfalcon/notes-pico
More bang for your buck without the additional costs of video production. Bonus: we can contribute.

Best wishes for a speedy recovery Paul.

I hope you heal up fast !

As a backer, I'm in complete agreement to ditch the video tutorial commitment. I'm convinced that your time is most valuable to develop the core features of micropython.

The work you and Damien have done is remarkable. I really think it's a game changer for getting people started to program microcontrollers.
I use micropython as the core technology in a makerspace class I lead. It has been quite popular. Some participants came with little programming experience, but were able to master sensor reading and pushing data to the cloud via wifi. here's the class description and outline:
https://drive.google.com/open?id=1nFeZD ... ETqIz_g9eA
https://drive.google.com/open?id=1KgooK ... 38UsspRKI0

thanks so much for your work !

Paul, please accept my very best wishes regarding your health problems. I have 13 years experience of how tough long term health problems are

Regarding the videos, if Adafruit have good ones use them! You and Damien should stick to what you do so well: developing MicroPython.

I'm sorry to hear about your health problems, I hope this is transient and you will get better soon.

I think it's a great shame that you are only now starting to work on the sensor drivers. I was hoping that actually using the machine module in a real world application could bring some practicality and sanity to the design. But as it is, it's still a largely hand-wavy top-down waterfall. Oh well, I still hope that when you actually start using it, more changes will come, this time for the better. Shame that every time this happens all the other libraries and example code break -- so personally I will give myself a year or two before contributing anything, so that I don't have to change everything again.

I think that you are wrong about Adafruit not contributing any code to MicroPython. In fact, all the changes they made and all the code they wrote is open and freely available for you to pick from. Feel free to choose any patches you want. What they refused to do is waste time arguing with you over pull requests, and having done that myself in past, I honestly really can't blame them for that decision. So please don't push the blame for the lack of third-party improvements on them.

Finally, if you plan to claim the Adafruit tutorial videos as the official MicroPython tutorials for the Kickstarter, I think it would be good and fair to actually make them official by including them in the official documentation, and not just pointing the users in the general direction of Adafruit.

Hello Paul, just my opinion about the videos: I prefer the written word, because in most cases it is more concise and precise, and the existing documentation supports that impression. And, not to forget, you can serach in it for a topic. So if appropriate videos of Adafruit exist, just let people use them. You may point at them in your documentation, but should not include a direct link besides one to the top level page, because then you would have to maintain these for changes & updates.