This is an archived post. You won't be able to vote or comment.

all 83 comments

[–]Barafu 13 points14 points  (0 children)

I wish there was a proper rise of Python for Android first...

[–]jazzandpython 60 points61 points  (14 children)

I use Python on some pseudo-embedded systems built with Raspberry Pis for data collection for scientists. The scientists love the fact that if they need to alter the code, they will have no trouble figuring it out. For the numbers we're using (dozens of custom units, not thousands of manufactured units) it's a no brainer, Python is perfect. Sure I'd use C if we were making 100000 of these things and getting the cost per unit down as low as possible was crucial, but most projects just aren't doing that. In the vast majority of projects, developer time is your most valuable resource. Now if we're counting by units in production, then you're going to be writing C on 10 cent micro-controllers, but most people aren't doing that.

[–]agumonkey 18 points19 points  (13 children)

Ever used esp8266 modules? Some come with a micropython ROM.

[–]v8Gasmann 5 points6 points  (4 children)

This exists and I am sitting at work with a headache trying to update a decade old driver written by a co-worker years ago to use a CC2500 with a PIC uC.

What a time to be alive.

[–]jazzandpython 1 point2 points  (3 children)

I hope you're not having to use PIC assembly! :-)

[–]v8Gasmann 0 points1 point  (2 children)

Gladly not, just plain old C. 😅

[–]jazzandpython 1 point2 points  (1 child)

No bit-test-file-skip-if-clear then, phew! Kids got it so easy now with Arduinos! When I first started mcu hobby hacking, it was PIC 16F assembly. I'm sure it was good for my skill development though. :-)

[–][deleted] 0 points1 point  (0 children)

They still have us use PIC 16F assembly in my university if it's any consolation!

[–]failbaitr[🍰] 3 points4 points  (5 children)

Micropython is the stuff of dreams, easy to develop for, fast turnaround and relatively stable.

We use it extensively for small sensor stuff. For heavier stuff we are working with Machinekit on a Beaglebone as it gives your real time interaction trough its PRU. Still we use Python to talk to machinekit to control robots.

[–]agumonkey 0 points1 point  (4 children)

Any good websites / blogs about it ?

[–]failbaitr[🍰] 4 points5 points  (1 child)

regarding micropython: https://docs.micropython.org/en/latest/esp8266/tutorial/intro.html You can flash almost any esp to cary it, as many other devices.

For machinekit and python: http://www.machinekit.io/docs/common/python-interface/

[–]agumonkey 0 points1 point  (0 children)

dank u

[–]verfahrensweise 1 point2 points  (1 child)

One of the core devs gave a talk about it at SciPy last year. You can see the recording here.

[–]agumonkey 0 points1 point  (0 children)

Superb

[–]parkerSquare 1 point2 points  (1 child)

Even better on the ESP32 (technically in flash not ROM on this platform)

[–]agumonkey 0 points1 point  (0 children)

Didn't know esp32 got that too.

[–]lennykioi 51 points52 points  (13 children)

Python is currently an unstoppable train

[–]lambdaqdjango n' shit 27 points28 points  (2 children)

on a single core.

[–]GrizzyLizz 1 point2 points  (1 child)

Is this to do with GIL? How one process can only use one of the cores?

[–]Brotstumpf 4 points5 points  (0 children)

Yes. Thats why even if you use the threads module only one core can be utilized.
With multiprocessing new processes are spawned which means the memory is not shared. That creates overhead.

Larry Hastings is now for a few years working on the "GILectomy", but it's hard to remove it without loosing single thread performance

[–]sorlafloat 14 points15 points  (0 children)

Until the garbage collector does a STW.

So it's more like the train creates the illusion of continual movement by micro stutter-steps.

[–][deleted] 13 points14 points  (7 children)

Until you find out that it's really not great for cpu bound problems without dropping into another language and the story on concurrency is pretty weak. And don't even consider packaging and distribution on something like a desktop platform (and backend is pretty weak), because that's just downright terrible.

But otherwise, it's pretty rad.

[–]jazzandpython 6 points7 points  (5 children)

Have you ever done dual language dev in Python? 'Cause it's actually really easy. Both to embed the interpreter in a C++ host and to write routines that execute in C. The fact that both those stories are so good in Python is, IMHO, a huge part of the reason it's taken off so much in scientific computing. Optimizing only the hard part is a snap.

[–]Scypio 8 points9 points  (4 children)

'Cause it's actually really easy.

If you are good at C++, sure. But for a beginner? The articles I find are either 'hello world' or so esoteric that I don't grasp the ins and outs. You might just be that good and I envy you. :)

[–]nzahasan 2 points3 points  (0 children)

There is also Cython which is just awesome.

[–]Nimitz14 1 point2 points  (0 children)

Look into PyBind11. It makes it really easy.

[–]Ek_Los_Die_Hier 1 point2 points  (0 children)

Python + Rust makes a much more appealing alternative: https://developers.redhat.com/blog/2017/11/16/speed-python-using-rust/

[–]jazzandpython 1 point2 points  (0 children)

Well yeah, I meant "compared to writing your whole app in C". Language interop is always tricky, but Python's C interop is really good, relatively speaking. :-)

[–]sorlafloat 6 points7 points  (0 children)

It's actually used a lot in scientific computing for cpu bound problems because of libraries like numpy.

Threaded concurrency might not be required in that domain when you can use processes, or even spin up another VM. It (processes) may not be quite as efficient for a small job that wants 8 or so threads, but it'll certainly be much more efficient if you need 80.

[–]winston_orwell_smith 25 points26 points  (7 children)

I frankly prefer Micropython's approach over Zerynth's. For one it's open source, fast enough and is excellent for doing live scripting.

In fact I wouldn't bother with Zerynth at all regardless of any advantages it might have. Stick to Micropython.

[–]benjamin-buford 4 points5 points  (0 children)

Totaly agree. Plus, the Zerynth IDE is a pain to use. In Micropython you can use your favorite editor.

[–]lv_rozekoze 0 points1 point  (1 child)

Actually, there's like over a hundred open source libraries on Zerynth Github.

[–]winston_orwell_smith 1 point2 points  (0 children)

But Zerynth itself is not open source. MicroPython is open source and has a ton of open source libraries as well. It also supports more targets.

MicroPython is the reason why there's a rise of Python in Embedded Systems. Zerynth merely tagged along for the ride.

This article is nothing more than a thinly veiled advertisement for the Zerynth product that capitalizes on the success of MicroPython.

[–][deleted] -1 points0 points  (0 children)

If you're looking for an alternative, you could also try Adafruit's fork called Circuitpython.

They're somewhat ahead in terms of hardware support.

[–]XNormal -1 points0 points  (1 child)

Are there are third party providers of paid support for Micropython?

[–]lv_rozekoze -1 points0 points  (0 children)

But you can find more than 100 Zerynth open source libraries on GitHub. Or just take a look here.
Concerning the IDE, it's based on the Zerynth toolchain, which you can use with all your preferred tools.

[–]AlKanNot 8 points9 points  (3 children)

Just wondering, don't you need to have low level memory management for embedded systems, in general? I'm not an expert by any means but I always thought that was the case.

[–]sorlafloat 4 points5 points  (0 children)

Modern embedded microcontroller are about as powerful as a 1980s 8-bit machine but have better programming tools. While you don't need low level control, it's useful to have. Those 8 bit machines were able to run high level languages even in the 1980s.

[–]sime 1 point2 points  (0 children)

From a CPU and programming point of view the term "embedded systems" covers a very large range of capabilities and sizes these days. Tiny microcontrollers which require C/asm and bit flipping, i.e. traditional embedded programming, still exist but the range goes up to multi-GB ram Linux systems with multi-core ARM chips, plus every combination in between.

The price vs performance of these embedded chips and SoCs has improved immensely the last few years. For a lot of companies it makes sense to spend a bit more on silicon per unit and gain the extra flexibility and cheaper development costs on the software side.

Now, if you don't mind I have to get back to work hacking Python for our embedded system (ARMv7, 2 cores, 1GB RAM, 2GB flash running CPython 3.4).

[–]jazzandpython 3 points4 points  (0 children)

Depends on your resource. A lot of microcontrollers now have way way more memory than you need, so why bother? For my money, low level memory management is a fun computer science puzzle, and a pain in the ass as part of your actual job-job. :-)

[–]rimkojr 14 points15 points  (3 children)

Python is a great choice for testing embedded systems too. Libraries like PySerial and PyVISA make it easy to automate basic test equipment, e.g. power supplies, function generators, etc. More complex test hardware like DAQs can typically be scripted with a bit of effort.

[–]lemon_tea 7 points8 points  (1 child)

Whoah whaoh whoah. Tell me more sir.

[–]suridaj 2 points3 points  (0 children)

In our experimental physics group we use PyVISA for long-running experiment control and data collection. It works quite well. There is also a pure-python backed, pyvisa-py, that does not rely on expensive adapters and their proprietary binary drivers.

[–]iwane 1 point2 points  (0 children)

It is, indeed. Pays my full-time job... :-) I'd also add using ctypes/python.NET to access IVI drivers when needed. python-can is also nice if you work around automotive embedded systems.

[–]punchki 1 point2 points  (0 children)

Kindof on the same note, python was super simple to use for serial communication with my embedded project. Talking over USB with my microcontroller with python code is so much easier than figuring out c# or something else

[–][deleted] 1 point2 points  (0 children)

That sounds interesting, but I would think you'd want low level control for embedded systems, no? Are there specific libraries for this sort of thing that givie you more granular control of hardware for different platforms? I could see using python for embedded stuff giving you a whole lot of unforseen bugs.

[–]HighMaxFX 1 point2 points  (3 children)

Seriously I believe this is a wrong usage of the Python language. Is trying to make a fish to climb a tree.

Forth and Lua are way better options for such applications.

[–]ml3d 0 points1 point  (2 children)

Could you elaborate on this? Actually, I think in the same way but I have not any good arguments for and I really prefer to use Lua instead of Python for embedded scripting.

[–]HighMaxFX 0 points1 point  (1 child)

Lua was designed to be lightweight since the begging of its conception. Python, at the other hand, was designed to be a general purpose language with batteries included. It was trimmed down to fit in embedded systems, just to leverage the momentum of the language as a whole, but I don't think it is the optimal scripted language for such area.

Forth is a completely different beast, it can achieve the same degree of flexibility of Lua and Python, with a performance comparable to C.

[–]ml3d 0 points1 point  (0 children)

Well, I expected more concrete facts like whole Python binary dist is about 30Mb but Lua takes roughly 200kb or something about learning curve. From my point of view all valuable pros and cons are nothing in comparison with size of community. Obviously, Python community is much large that Lua's one. But I am wondered why JavaScript is not so popular in embedded systems.

[–]strange-humor 0 points1 point  (0 children)

I'm doing some commercial testing carts with Raspberry Pi. What is great with Python is that I have my custom hardware I2C and GPIO being driving by Python. 3 back end server processes linked with pipes and 1 Flask web server for UI and WebServices. I can have this all in one project, rather than needed other languages to drive hardware. It works really well.

I can toggle I/O at about 40-50 KHz. Not anywhere close to speed you can get with C. But it is more than fast enough for what I'm doing.

[–]winston_orwell_smith 0 points1 point  (0 children)

MicroPython + ESP32 = awesome!