Hacker News Reader

Comment by fumplethumb | Hacker News Reader

I think an important point in the context of Python (and other languages) vs. C/C++ is the proliferation of cheap hardware capable of running Linux. The relatively new phenomenon of a $10 Linux device makes it an attractive option in many situations. The cost gap between a traditional microcontroller (no Linux) and a linux device is closing.

The Linux device is compelling when speed (and ease) of development is important, scale is low, or the market is insensitive to pricing. Not to mention the added bonus of more processing power. On the other hand a traditional microcontroller is still compelling where volumes are high or there are strict real-time concerns.

As an embedded software engineer, I'm watching closely. Personally I'm reaching up to higher languages like Python to make myself more attractive in an industry that I see moving toward more Linux devices.

View on HN

Another problem is power consumption.

Wit the current, appallingly bad battery technology the only way off-the-grid IoT can hope to proliferate is by keeping the power consumption as small as possible. This is of course a problem for a rather specific use case of IoT/WSNs, but one that gets completely destroyed if not taking this into account.

Err. I wouldn't learn python to make yourself more attractive in the embedded software engineering field. I do embedded software in mostly Python and C these days and when I get messages on Linked in from recruiters they're normally looking for C++ experience which I've become weak on.

I've been brushing up on Python (and Elixir!) to make myself more well-rounded as a software engineer, not just an embedded engineer. However I stand by my point that many "embedded" domains are served just fine by a Linux device, which can be programmed using Python.

Also not sure how much stock I put in what the recruiters on LinkedIn are touting...

I appreciate the opinion though!

What do you think about MicroPython?

I am a total MicroPython fan boy. I've done a lot of embedded C-on-bare-metal development and related electronics. For most non-embedded work, I use Python and am a huge fan of the language, so having Python on an ARM Cortex gets me very excited. MicroPython is absolutely great for getting a complex embedded project up and running quickly. Execution performance, of course, is nowhere near C. But, since a lot of performance critical I/O handling is already done as a C extension (import machine), and it is just as easy to write a MicroPython C extension as it is to write a CPython C extension, you can always move the performance critical parts to C as needed. Overall it is a huge win in development time. MicroPython does require a fairly biggish ARM Cortex M3, though.

> MicroPython does require a fairly biggish ARM Cortex M3, though.

What do you mean? I run it on an ESP8266 just fine, the tooling isn't great (it launches a REPL and takes up your serial port with no way to stop that), but other than that it's fantastic.

Yes, but the ESP8266 is a bit of a squeeze. It's a more comfortable fit on larger processors.

As to the serial port/repl issue, can't you build your own image to do something else that you like better? Micropython is pretty easy to build, in general.

I imagine I could, but I'm very bad with C :(

The REPL is fantastic when you want to prototype stuff, but it's not great when you want to actually deploy things. I'm sure there's going to be some way to avoid launching it in the future, though, such as having a main.py file that has a `repl.run()` you can take out when deploying your own code.

The code for Micropython is very well structured. The toolchain is pretty easy to set up, just apt-get and go. The configuration things like I/O pin assignments and such are all on pretty simple definition files. I'd be very surprised if the repl loop takes more than flipping a #define to turn off. No C wizardry needed.

Hmm, I'll have a look, but currently you need the repl to be able to write files (otherwise I'd have to include my files in the firmware and copy the entire thing every time).

That's not really so bad, as it's what you do for the C++ version, but it would be nice if there were a way to update the code somehow. Maybe I'll write some code to fetch a file from an HTTP server and unpack it, though.

I haven't tried MicroPython, but I'd love to check it out. I've been recently seduced by Elixir, so I'm looking into Nerves[1] at the moment.

[1] http://nerves-project.org/

Reply on news.ycombinator.com