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.
PROJECT ORIENTATION
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
https://design.blog/2016/08/25/mitchel- ... 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.
CHOICE OF BOARD
I was extremely tempted to go with the D1 ecosystem when developing resources at
http://vgkits.org 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)
2018-01-04
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
https://vgkits.org/blog/projects/vanguard/ ) 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.
SHIELDS
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!
USB CABLES
I've been buying USB cables in batches of 100 which brings the cost down to £0.82 'BSP' (
https://vgkits.org/blog/bsp/ ). All our wholesalers are linked from the project page...
https://vgkits.org/blog/projects/rainbow/
The USB supplier we used last was...
https://www.alibaba.com/product-detail/ ... 3e5fxAEGn0
...I'm not sure what the Minimum Order Quantity (MOQ) is for these.
BREADBOARDS
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
http://start.shrimping.it/kit/breadboard400.html
IDE
I am intrigued by the potential of Thonny, and its plugins thonny-esp (
https://pypi.org/project/thonny-esp/ ) but it's minimally documented right now.
CONSOLE WORK
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 main.py, upload new firmware, reboot the board, load a text editor. That's the vgkits-vanguard toolset at
https://github.com/vgkits/vgkits-vanguard
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).
NEXT STEPS FOR VANGUARD
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!?
FOLLOWUP
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.
