Promoting Micropython with workshops and courses

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
User avatar
Posts: 59
Joined: Tue Nov 14, 2017 3:11 am
Location: Perth, Australia

Promoting Micropython with workshops and courses

Post by philwilkinson40 » Wed Jun 20, 2018 12:26 pm

answering @cefn question related to teaching Micropython feels like a new topic! Feel free to post comments against my approach, ask questions or just post what you have done.

Apologies for the delay in responding @cefn,
I have just started a series of workshops to introduce Micropython. This comes after general frustration that no community exists where I live. I simply don't have the skills to develop the language, but at least I can help promote its use!

The strategy is to initially teach it to people with Python skills, so they can then become teacher of the course. The overall aim is to get more people using Micropython, more often.
  • Firstly I promoted the concept at a Python-focussed MeetUp in my city. The feedback was really positive so I developed the course.
  • Initially we started with a Soldering session, in which we soldered up the boards and shields as a group. We also flashed micropython onto the ESP8266 and did some basic tests.
  • next is the main workshop(s) where we will work through the basics
I am writing up the main workshop material right now. But you can bet that the notes will shamelessly steal from 'getting started with the ESP8266' and @depishu excellent tutorial using the same boards.

One comment is that, in my opinion, Micropython sorely needs a IDE to help absolute beginners get started, particularly kids. MU is great but doesn't support ESP32/ESP8266 'generic' boards yet.

I will update this post when I have completed the materials. Happy to help in any way I can.

Posts: 230
Joined: Tue Aug 09, 2016 10:58 am

Re: Promoting Micropython with workshops and courses

Post by cefn » Wed Jun 20, 2018 6:31 pm

Thanks for the diligent and comprehensive reply, @philwilkinson40

My comments below are not intended to suggest you should have done anything differently, but are just to share perspectives where I have chosen to make different decisions, so people can see some alternatives.


The focus of VGkits work is first and foremost enabling new learners to issue their first python commands, write their first code blocks and see a result. This is with a laser focus on eliminating aspects which would make your first python experiments less motivating/accessible (e.g. financial cost, special tools, perceived irrelevance). Choices are made with an awareness of future development (low floors, wide walls, high ceilings ... ide-walls/ ), but if a choice has to be made, it will favour accelerating your first 8 hours.

VGkits' emphasis is justified by the idea that once you have established what this physical computing and python world is all about, and you start to imagine things you can do with it, then you will be ready to consider investing time and money to achieve specific outcomes. We assume the most likely failure mode is that you simply never come to learn anything about this world at all, and be prevented from doing so by technical and logistic hurdles. This is why we are crafting a curated experience which anyone could recreate at home or in a classroom, to get learners going.


I was extremely tempted to go with the D1 ecosystem when developing resources at In particular the availability of of motor shields and screen shields. It unfortunately uses a different pin labelling system than the ESP8266 internal GPIO numbers, which makes coding hard. However, the D1 has the symmetrical allocation and spacing of pins which means breadboard projects are feasible and nicely balanced, and avoids breaking out pins which will confuse learners (NodeMCUv2 is particularly bad for this). The D1 Mini Lite (with ESP8285 module) is competitive with the devices we are using. However, the clincher which made me choose NodeMCU-M was this email thread I initiated with Lolin (Wemos)

Cefn: "Can you supply D1 mini modules with pre-soldered headers?"
Ou Chen "sorry, you need DIY."

That means that by contrast with the 1 minute python shell access we can offer the moment you open the envelope from china, there remained a huge obstacle for anyone choosing Lolin products. This implicitly excludes 99% of the population who might otherwise succeed at issuing their first python command. This is illustrated by the way you had to invest the first chunk of time in soldering. This will work for some people, who already have the skills or might accept the 'delayed gratification' because they believe it's worth it. However, those are (by hypothesis) exactly the people VGkits _don't_ need to help.

The board we have settled on (see ) comes pre-soldered with male header pins. This means that we can ship female 'dupont' jumpers to wire directly to a whole host of inputs and outputs with no engineering steps. The UART drivers for this board are built-in on Linux and Windows 10. Essentially this means you can order it from china with a handful of components, plug it in and start learning python, and an hour later, start plugging arbitrary devices to it with jumpers.


I tend to shy away from single-component shields for the following reasons...
* Yet more soldering needed
* hard-wired pin allocations which may clash with each other
* Extra cost compared to the raw components (can be a 10-fold increase)
* limited suppliers (typically just the shield designer)

Often the same component can just be wired to directly with wires. When imagining early projects, you can also choose components which CAN be wired to directly (e.g. servo, piezo, DS18B20). For elements which need a handful of components you can often find a substantial competitive marketplace for breakout boards which come with male headers pre-soldered instead, which can be wired with jumpers just the same. I'm doing this with the Vanguard board dead-bug-style since it eliminates the cost of the breadboard for most projects, and when the board is sourced for $2.50, eliminating a $1 breadboard counts!


I've been buying USB cables in batches of 100 which brings the cost down to £0.82 'BSP' ( ). All our wholesalers are linked from the project page...
The USB supplier we used last was... ... 3e5fxAEGn0
...I'm not sure what the Minimum Order Quantity (MOQ) is for these.


If you encounter issues with any breadboards, (hard pin insertion, corrosion, number printing), and need to buy in bulk, I have used NBEverest for years, see


I am intrigued by the potential of Thonny, and its plugins thonny-esp ( ) but it's minimally documented right now.


As an alternative to a graphical tool, the scheme we're emphasising for now is the use of a console tool which has the bare minimum operations easily accessible - get a shell, upload modules and, upload new firmware, reboot the board, load a text editor. That's the vgkits-vanguard toolset at

It's partly because it introduces a way of working we would like to encourage for learners to have 'high ceilings' - use of the terminal.

It would be good to get your steer on the workflow you will be guiding people to use. There's some discussion in this thread around the mpy-miniterm project (yet another different console tool) viewtopic.php?f=15&t=4888#p28230

I would find it very valuable if you could attempt to use vgkits-vanguard for your work and let me know what fundamental operations are missing, that we could add as named commands so that everything a typical learner needs is a few keypresses away. Ideas for how to approach each of these new features can only come from people embedded in using and teaching. The vanguard toolset is designed to be able to work with ESP8266 and potentially ESP32, (it has board detection routines built in, and just needs extra entries in the table for any new board).


As for VGkits' resources, the next steps are to find nice compelling, self-contained projects we can document in detail which are fun enough for people to want to replicate them, which really allow for some expressiveness in python which uses what the board can do (e.g. using the internet for something practical, wiring up I2C sensors in some application context, moving a servo as part of a craft project). People buying into the projects will then pick up some Micropython and physical computing awareness while following the build and specialising it for themselves.

Initially, we've put together the Vanguard Rainbow project, but it's really an 'also-ran' project since it's all about flashing neopixels, which always raises the question WHY!?


Would love to hear your decisions about what projects you want to build as you proceed, or if we can work together on preparing resources for some fun ones. I can potentially guide you through the use of Adafruit_Blinka_Micropython if driver support is something you need to address, or perhaps Medea if you want to process information from mainstream Internet APIs. I'm expecting to involve these projects in some way in the VGkits examples so they need some hand-holding docs anyway.

Post Reply