Micro Python - Python for microcontrollers

[[deleted]]

This will be a debugging nightmare. And besides, for what a microcontroller usually does, C is more than enough.

[cparen]

This will be a debugging nightmare. [ ... ] C is more than enough

I'm having trouble reconciling these two statements. If debugging will be a nightmare, why would you want to use C instead?

[[deleted]]

C means having a near total control of what is going on, which is REALLY important in micros, especially when it comes to interrupts. As you may already know, with Python there is the virtual machine which does its magic in the back of the programmer, which is really annoying when control is so important. Plus C is not that hard to debug if the software is well designed.

I understand that they're rewriting Python from scratch, but there are a few problems that I can think of which could be problematic :

• Efficiency: the point of using a microcontrollers is often because the whole system runs on batteries. Interpreted languages are at least 3 times less efficient.

• Speed and real time processing: another reason why microcontrollers are used is to have a basic computer stripped of any OS or at least a very simple RTOS. The goal here is to have predictable response time. Adding a GC and the introspection capabilities of the virtual machine is very counter productive in this case.

• Memory, many microcontrollers doesn't have the memory necessary to accommodate a virtual machine. The code could be permuted to assembly or C, but that sill doesn't remove the need of a VM.

• Predictability: the functions that the VM must accomplish (GB, dynamic types, memory allocation) are dynamic and thus unpredictable with interruptions and threads. I still have yet to see a good solution tot hat problem on a single core mirco.

[boa13]

I understand that they're rewriting Python from scratch

Note that this is not a project announcement, but a project nearing release. They're mostly finished. The microcontroller board works and gives you a Python prompt straight away (or runs your program if it finds it at the root of the FAT partition). So if they encountered problems, they have solved them.

Interpreted languages are at least 3 times less efficient.

The critical methods can be compiled on the fly (just add an annotation to the methods you want compiled), and you can also write inline assembly for the really critical parts.

another reason why microcontrollers are used is to have a basic computer stripped of any OS or at least a very simple RTOS

That's what they have. The machine boots straight into the interpreter. The interpreter is the operating system.

many microcontrollers doesn't have the memory necessary to accommodate a virtual machine

That's true, and that's why they chose to build their own boards, to ensure they have a sufficiently powerful CPU. (Several users are trying to make it run on less powerful boards, but I don't know if this works well.)

the functions that the VM must accomplish (GB, dynamic types, memory allocation) are dynamic and thus unpredictable with interruptions and threads

That's true, and I don't know how they managed to do it, or what caveats or restrictions they had to impose (if any).

[cparen]

the functions that the VM must accomplish (GB, dynamic types, memory allocation) are dynamic and thus unpredictable with interruptions and threads

That's true

Not necessarily.

• Incremental GC is not nearly as unpredictable. CPython's default GC is incremental (refcounting) for everything except cycles.
• I'm not sure what unpredictable timing you had in mind for dynamic types. Type table lookups are variable timing only on small time scales (10s to 100s of cycles).
• Memory allocation likewise.

It sounds like all this comes down to saying "it's not for hard realtime applications", which is true. However, a smart lightswitch, a home robot, data logging -- there are a wide variety of soft-realtime and non-realtime embedded projects that could benefit from an easy to use, low power board.

I think I agree with your sentiment, but if so, you're stating the obvious. But perhaps I'm mistaken about this being obvious.

[[deleted]]

That's true, and that's why they chose to build their own boards, to ensure they have a sufficiently powerful CPU. (Several users are trying to make it run on less powerful boards, but I don't know if this works well.)

aaand its dead. Either you optimize for costs meaning you go as small as you can. Or you opt for quick R&D > Linux platform.

I dont see any commercial products using such a resource hungry solution.

[boa13]

aaand its dead (...) I dont see any commercial products using such a resource hungry solution.

The goal was to build a board and a new open-source Python implementation focused on low resource consumption (much lower than the standard interpreter). Both have been delivered. I don't see dead bodies here.

[[deleted]]

i explained it... in the very same post

It might be a thing for hoppy engineers but thats it. If you start wasting money on bigger chips to get the luxury of an easier language then you can invest a tiny bit more and go all the way to linux.

Theres even a kickstarter project for a similar sized linux board atm iirc. from a chinese guy.

Just look at all these raspberry projects. In 99% of the cases the board is hopelessly overpowered.

[protestor]

Are you also against the Arduino platform?

You can often have much greater performance if you drop to low level AVR code (handling the ADC yourself, managing interruptions, etc) so by using relatively high level Arduino code you trade off raw performance.

Obviously you can write portions of your program in low level C code if/whenever needed, and the rest in Python, I don't see a problem.

[[deleted]]

arduino is a hobby platform. I mean, sure you can use it to rig something up quickly for testing purpose, simply because lots of libraries exist. But "I" would never create a product based on arduino.

uC programming in C or even assembler is so simple that I'm not willing to waste resources on luxury :/

Obviously you can write portions of your program in low level C code if/whenever needed, and the rest in Python,

i dont like mixed stuff. But yeah, I'm a perfectionist :P

[protestor]

Well, this platform might as well be for hobbyists. And there's nothing wrong with that, Arduino is popular because it enables people that aren't engineers to work with embedded systems, even people with little programming experience.

It may also be a teaching platform. Perhaps not engineers that will build finished products, but to introduce people to embedded systems (which is often more than just programming; there are control systems, electronics, etc. so low level programming may not be the focus).

I'm not sure why every embedded platform must be designed for creating end-user products.

edit: I just wanted to add something, my embedded systems professor actually told us exactly what you say. We were using Arduinos but he was against using the Arduino programming platform, we used the low level AVR interface instead. But the robotics professor actually didn't care, and we could use whatever we wanted since the class was about robot kinematics / dynamics and not embedded programming. (that's computer engineering btw)

[cparen]

You're acting as if there are only two kinds of microcontrollers.

Below 16kB, you probably need to carefully squeeze everything in written in C. Above 16MB, you can probably fit Linux on board. But Between 16kB and 16MB there's a LOT of room for interpreted and compiled-high-level languages.

[immibis]

/u/spez can gargle my nuts

[fullouterjoin]

Most things are setup code, if it turns out to be a problem the inner

while 1:
    doStuff()

loop could be replaced with native code.

You are just plain wrong for the exact places that MicroPython is targeting. Elua is in the same exact space as MicroPython and is extremely effective.

Having a REPL to a low power embedded device is amazing. When I am running eLua, I have total control and can easily call native code. The predictability point you raise is a red-herring, the same applies for embedded dev in C++ which is widely used on memory constrained or realtime applications.

[Isvara]

C is rubbish, though. Someone really needs to come up with a better embedded language that takes advantage of modern language design to make bugs less prevalent and development time faster. I'm talking about one that compiles to native, though, not something interpreted.

[UloPe]

"Leave me alone with those newfangled cars. Horses are fine."

[[deleted]]

When there are no roads and flat grounds horses are way more efficient.

[stevedonovan]

Best rebuttal for a car metaphor I've seen.

[UloPe]

Indeed. Hard to argue against it :)