The nice thing is that micropython comes with a full blown networking stack , encryption and the whole hoopla. All the annoying crap nobody wants to deal with is already handled. you don't need to muck with libraries.
But surely at some point - SOMEONE has to get drivers for the processor up and runnning? someone has to get libraries included, compiling, and more importantly thoroughly debugged.
the executive for python has to be able to run on the chip, talk to any on chip peripheral you need, manage memory allocation, map any sleep commands that the "OS" supports to the specific sleep functionality of the processor...
So in this case, if I have a processor that someone's gone and spent a bunch of time adding all this stuff in and getting it working, then yeah. I guess it'd be cool (but god help me if there's any bugs under that huge rug that literally all the hardware has been swept under!)
Compare to freeRTOS which also gives you this stuff, with its own API for the features that will be about the same as the micropython hardware API. except freeRTOS is years older, and so years more developed, with support all over the place for numerous chips (actively supported and encouraged for use by most cortex M manufacturers!) And if you have a problem with FreeRTOS, it's all there in your project to dig into and look at if needed
Here is a nice task to do : pick a cpu, slap on wifi and bluetooth. hook up a temperature/humidity/voc sensor. send data to a logging server. scatter 20 of these things around a building.
let's look at a few things:
- development time
- development tools
- cost of the hardware
i can do it with an epsressif ESP32 ( 180 MHz SOC with wif and bluetooth embedded ) and a bosh BM280 environmental sensor. hardware cost : 4 to 5$
you can use these parts with a C compiler, too.
Development time : open i2c port , read bytes , send them through json packager and blast them into a socket instance. It's all there. the whole program is barely 30 lines of code. including network protection and encryption.
working with FreeRTOS will be similar.
Development tools needed : a computer with a terminal program. i don't need no stinking compiler , no stinking debugger, no stinking ide , no stinking jtag dongle. no stinking wires no stinking serial port.
mbed might be OK for a simple toy application like this... and that's a similar deal.
hell, it already has example apps from microsoft and IBM for sending this kind of data vial MQTT or HTTP REST(or AMQP with azure) all the way to azure or watson.
OK, it wont support ESP32 specifically, as that's some weird non-ARM architecture. But maybe the Realtek part will get mbed support some time? otherwise, use nearly ANY arm cortex part with a $2 ESP8266 module.
i can write, edit, trace directly over the bluetooth or wifi serial port emulator. firmware is updated over the air.
Try doing that with your devtools.
OK, now using serial port debugging from inside your python application, you try tracing what happens when the I2C driver compiled into the executive messes up underneath your python code for some reason, and you can only read zeros from your sensor...
or the memory allocation code screws up in some funny way on your particular target?
Or the way the generic OS sleep functionality is mapped to the specific features of your particular target is not right for some specific setting that the executive picks without telling you when you call a generic sleep/wait function?
And having all the relevant code for even looking at what might actually be happening under your application locked away in a separate project that you have no direct access to, no easy way to trace into it from your application code, and no experience with the language it's written in?
It may not work for all cases but for small systems that do processing at the node and send data to an aggregator :perfect.
Don't get me wrong - I really love fast prototyping capabilities in modern software dev offerings... and I may even get a micropython dev board to play with some time.... My main issue is this is so far removed from normal embedded tools, that you're really going out on a limb just to learn it and really limiting your options when something goes wrong. For similar effort, you could just learn an embedded development language and basic techniques that have been proven over literally 5 decades of use.
To me, as neat a solution as it may be, it just looks like "IoT toy for web developer who wants to think they're a hardware person" same deal as that Tessel javascript board. It may be neat, beautiful, and elegant, but at the end of the day, it's a neat beautiful elegant cage.