MicroPython News

Anything not related to STM32
gbulmer
Posts: 67
Joined: Wed Sep 23, 2015 12:04 am
Location: UK

MicroPython News

Post by gbulmer » Sun Apr 17, 2016 8:45 pm

I didn't see an entry for it, so I thought I should mention MicroPython, which runs on several MCUs including STM32F.

To quote its web site 'MicroPython is a lean and fast implementation of the Python 3 programming language that is optimised to run on a microcontroller'. It has a very open MIT license.

Damien George, who started the MicroPython project, recently had a KickStarter to port MicroPython to ESP8266

The kickstarter campaign was successful enough to fund ESP8266-code early release to the Micropython github repo.
The campaign is also funding some quite interesting libraries including a port of MQTT, a light-weight messaging system, popular for IoT.

One of the interesting aspects of MicroPython is the system has an interactive REPL (read-evaluate-print loop) which runs directly on the MCU. So you can interrogate the MCU using only a serial terminal, which may be handy for debugging and development.

So, folks might want to investigate MicroPython as a viable alternative to C/C++ development on STM32F.

User avatar
mrburnette
Posts: 2060
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: MicroPython News

Post by mrburnette » Sun Apr 17, 2016 9:10 pm

gbulmer wrote:I didn't see an entry for it, so I thought I should mention MicroPython, which runs on several MCUs including STM32F.
<...>
So, folks might want to investigate MicroPython as a viable alternative to C/C++ development on STM32F.
I think this should have been posted in Off-topic... because STM32duino implies the main section is "Arduino'ish" (IMO.)

Your mention of micropython did register with some neuron displaced no-doubt by previous indulgences with Single Malt Scotch... but, that one neuron did cascade that spark to a few others that remembered an article in EDN last year. Here.

The takeaway is mixed, but it seems that MicroPython is geared more to the STM32F4 series of uC. There are some serious overheads since Python is generally considered a scripting language, but when used as a program language, the instantiation and destruction of objects does force the need for "garbage collection" and other house-cleaning functions. (same can be said of C++)

I want to scream, "No!" but I will not. Read the link and make up your own minds.

***** Roger, could you move this thread to Off-Topic, please?


Ray

User avatar
RogerClark
Posts: 7552
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: MicroPython News

Post by RogerClark » Sun Apr 17, 2016 9:42 pm

Ray

Ok. I will try to move it. But I will need to fire up a grown up computer and administrating on a tablet is a nightmare ;-)

Edit.

As you can see.. I figured out how to move it.

gbulmer
Posts: 67
Joined: Wed Sep 23, 2015 12:04 am
Location: UK

Re: MicroPython News

Post by gbulmer » Mon Apr 18, 2016 8:54 pm

mrburnette wrote:
gbulmer wrote:I didn't see an entry for it, so I thought I should mention MicroPython, which runs on several MCUs including STM32F.
<...>
I think this should have been posted in Off-topic... because STM32duino implies the main section is "Arduino'ish" (IMO.)
Okay.
mrburnette wrote: ... remembered an article in EDN last year. Here.
Yes, an okay review. The author claims to have written some simple realtime system, and had no problems, from the article:
EDN Article wrote:The use of proper design techniques through the use of interrupts and timers allow most real-time deadlines to be met with ease. I even designed a scheduler and loaded it up with tasks to read analog sensors, drive a motor, and read SPI and I2C sensors, all while calculating a complex algorithm
The article is a bit inaccurate, and out of date, including the follow-up comments.
For example, MicroPython runs on vanilla Linux, including R-Pi, as well as several different MCUs, including the BBC Micro:bit and more recently the ESP8266. One interesting point is MicroPython appears to be relatively portable across its supported platforms. Another is it has a C API, so if aspects of a system do need improvements there may be a way to satisfy them without abandoning MicroPython.

Writing code to handle comms looks easier in MicroPython than C. For example, they are building a socket-based library for WiFi support on the ESP8266, rather than using the 'native' ESP8266 WiFi call-backs.

I started programming in the 70's. Back then, CPU was expensive.
We had a baby-VAX (750, about 2/3rds a VAX 780, which is 1 DMIPS), which ran UNIX, and supported the department.
It was very easy to obsess about things like performance. I loved C then, and still do. However, I have mellowed in the intervening years. Nowadays, on OS-based platforms, I might use Go lang, or maybe Erlang, for the sort of problems I would have used C/C++, or Java for.

I remember when we first started using Java, in early 1995. We were amazed that we could do 3D animation within the browser, using a byte-code-based, interpreted language (this was an early release of the Java VM on Intel, and not the later JIT-compiler based system).

As folks are showing in the benchmark thread, an STM32F103 is about 50VAX MIPS. That is actually a lot of CPU.

As the author of that EDN article noted, it was relatively easy and quick to build a working, simple, realtime system on an STM32F405. We can have that level of performance on a sub 10 GBP nucleo.

Nowadays, I think it's important to fully get to grips with a project early, aiming to properly understand the whole problem. My experience is often that quickly developing a representative solution is more important than the relative run-time performance of the programming language. For example, a lot of the run-time might be spent in libraries, and not my code. Or the insight gained from an initial development might yield evidence that my assumptions about performance bottle-necks were wrong, even irrelevant.

I've taught CS on-and-off since the 80's. We always warn people about premature optimisation; obsessing about some aspect of performance before having a reasonable, correct solution is usually counter-productive. IMHO, assuming a technology isn't up to the job because historically it was slow, maybe an unnecessary optimisation. I'm willing to 'spend' a bit of time early in a project to adequately understand the problem. I am in favour of tools which help me understand the problem more quickly, and maybe produce an adequate solution more quickly.

User avatar
martinayotte
Posts: 1239
Joined: Mon Apr 27, 2015 1:45 pm

Re: MicroPython News

Post by martinayotte » Mon Apr 18, 2016 9:37 pm

More than a year ago, when I've un-dusted my Netduino2Plus, even before starting to port STM32F4xx to my Netduino2Plus, I've tried to run MicroPython on it, it was the old version, but I've succeeded within few minutes. Now that the current MicroPython is much more mature, I should maybe try again.

gbulmer
Posts: 67
Joined: Wed Sep 23, 2015 12:04 am
Location: UK

Re: MicroPython News

Post by gbulmer » Mon Apr 18, 2016 11:51 pm

martinayotte wrote:More than a year ago, when I've un-dusted my Netduino2Plus, even before starting to port STM32F4xx to my Netduino2Plus, I've tried to run MicroPython on it, it was the old version, but I've succeeded within few minutes. Now that the current MicroPython is much more mature, I should maybe try again.
That's an interesting re-purposing of a Netduino. Very cool!

An obvious use of MicroPython might be on the ESP32.

Making an HTTP client or server using Python should be easier than using C/C++. Better, it would have REPL, so I could debug the thing more easily too. With modules carrying 4MB flash, there should be enough space for web pages :)

Of course, part of the MicroPythin attraction might be portability; the same code should run on multiple platforms, assuming the 'HAL' for each is kept aligned.

User avatar
RogerClark
Posts: 7552
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: MicroPython News

Post by RogerClark » Tue Apr 19, 2016 12:07 am

I totally agree with @gbulmer's assertion of getting a feel for a project.

However, I guess it depends on whether you are used to programming in Python.

I use it from time to time, but find it a strange language to get to grips with.
Its not just that the formatting of the page affects the syntax - as I actually prefer all of my code to be well formatted as it makes it much easier to read of everything is nicely indented etc.

But I've never found it that easy to switch between C, C++, Java,C# and various other languages, into Python.

For some code, I prototype it on the PC, in either C or perhaps JavaScript etc (depending on what I'm trying to achieve), as its quicker to get algorithms working on the PC (in C) and then copy the code over to the embedded platform, as on the PC you don't have the upload / flashing step and you can debug into the code easily, which you can't do so easily on an embedded platform without running GDB etc

User avatar
martinayotte
Posts: 1239
Joined: Mon Apr 27, 2015 1:45 pm

Re: MicroPython News

Post by martinayotte » Tue Apr 19, 2016 1:42 am

The MicroPython campaign is obviously targeting the ESPs ... :D

About my Python experience, it is main scripting language since almost 15 years on almost any platforms.
What could be something I would want to see/dream on the STM32F4 is kind of merge between both worlds : Duino sketches that can run some python scripts ...
On F4xx, there is no reason why it could not be achieved !
BTW, Wayne would then have another reason to build his STM32F4 piggyback for UNO, all those UNOs would becomes Python capable ! :lol:

But "time is the missing ingredient" ... :?

@gbulmer, you should team up with @fireduino (Wayne) !

stevech
Posts: 441
Joined: Thu Aug 27, 2015 6:32 am

Re: MicroPython News

Post by stevech » Tue Apr 19, 2016 5:08 am

I had that desire... micropython on a fat STM32F4. And so Viper now called http://community.zerynth.com/ - it works; multi-targets. But there are too many libraries that can't run to give me the portability of code.

So now I use the RPi Zero ($5, I have 2) or the RPi 2. Linux, full python 2 or 3 and all libraries. Same python code using I/O libraries of all sorts runs on RPi/Linux and on Windows. Or x86 Linux. A very few needs are such that the RPi won't do.

It is (was) fun to do bare metal MCU programming in C/C++. But I have a new path now for most projects. And free PyQt works on Linux/Windows.

I've done two really big projects in Python - like 2-3K lines of code in many modules. At first I hated it.. too weird. But now I love it.

User avatar
mrburnette
Posts: 2060
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: MicroPython News

Post by mrburnette » Tue Apr 19, 2016 1:45 pm

stevech wrote: <...>
It is (was) fun to do bare metal MCU programming in C/C++. But I have a new path now for most projects. And free PyQt works on Linux/Windows.
<...>.
Obviously, you are talking apples & oranges as uC programming in C/C++ and programming on a RPi with a Linux OS is nowhere similar, IMO. I personally do not understand the use of "fun" but if that translates to your quality time spent on your hobby, then I think I understand... we all have limited time and must make choices. That being said...

It is not a technology issue, but a personal decision. Others who program as a profession on the micro-Linux platforms may find the STM32 or ESP8266 a fun diversion from the norm. We live in a time where it is so great to have large numbers of people playing in the different microelectronic computing platforms - the diversity allows one to be selective in what sandbox they want to play in!

But, even with the RPi and other similar platforms, good system design for a major project would suggest off-loading some of the processing to distributed uC to manage the data gathering, pre-processing, transmittal, protocol conversions, etc. Such low-level activities are ill-suited IMO to being directly interconnected to the RPi: I believe that just because it can be done does not mean that one should do it. uC's are so capable these days that using them as single (multiple) sensor interfaces is smart. In a well designed system, the RPi could be taken off-line, updated, and put back online and the data stream would start up and all buffered data would bring the RPi current with no data lost. Systems Engineering makes the best use of the best platforms.

If (micro)Python floats your boat, go sailing.


Ray

Post Reply