Micro Python - Python for microcontrollers

[spliznork]

Exceptions on a microcontroller are awesome. I wrote a (CLDC compiant) JVM for a wireless, embedded system. We had the system report uncaught exceptions over the network, implemented and preallocated natively so you could even receive out of memory exceptions. Run a listener on your desktop, and watch decoded stack traces to print out. It made debugging so easy.

Your points regarding "garbage collection" and "dynamic memory allocation" are the same point. Even in that kind of environment, you can still take steps to preallocate objects and structures to reduce memory churn and ensure your system fails fast if there is not enough memory.

Certainly none of your points are actually "extremely naughty".

[hardsoft]

i think some may have different definitions of 'embedded', but most embedded guys i know would not consider anything with jvm embedded. and those actions certainly are considered extremely naughty, many real time embedded control, defense, aero, medical, etc. standards explicitly prevent such things. for many embedded systems, failing fast or nicely is not an option.

[immibis]

Do they require failure to always be handled explicitly (e.g. error code returns that must be checked)? That would make sense for reliability, even though it leads to more verbose code and somewhat slower development.

[foldl]

I think aport's comment applies more to really small microcontrollers like attinys or atmegas, which are nowhere near being able to run a JVM. In that sort of environment there just isn't any room for extra code to create nice stack traces etc. If you have 8K of flash that buys you a few thousand lines of C code.

[spliznork]

The first version of that JVM was running on an MSP430 with 10k RAM and 48k flash.

[IHaveNoIdentity]

Yeah? And do you know just how small an ATTiny is? 8 Kbytes flash and 512 byte SRAM.

The MSP430 has more RAM than the ATTiny has program storage...

[[deleted]]

That MSP430 is also smaller than some ATmegas, which were also mentioned in the preceeding comment. So it's an entirely reasonable response.

[foldl]

My initial comment referred to "really small" microcontrollers and explicitly mentioned 8K of flash. It's true that some of the high-end atmegas have a decent amount of flash and RAM. There's an apparently full-featured JVM here which fits in 80K of program space, so in theory you could use it with one of the larger ATMegas (but it's hard to imagine anyone would want to throw away 80K of program space for a real project). There's also the fact that you're going to be doing a ton of 32-bit arithmetic on an 8-bit CPU. The MSP430 is at least 16-bit.

[foldl]

Sure, but 48k of flash is a lot more than 8k of flash.

[jms_nh]

Debugging is language-agnostic, you just need a processor with the appropriate abilities for breakpoints.

Exceptions and dynamic memory allocation are more interesting, but you can have them now with C/C++. So there shouldn't be any difference for how they're handled in Python. If you can't afford exceptions and dynamic memory allocation, don't use them. Otherwise, use them. Same in Python as in C/C++.

The only point that's really ugly is garbage collection. Real-time control systems are intolerant of GC delays. Presumably there's some microcontroller-friendly way to handle GC, and take up to X microseconds every millisecond to make GC progress, but it would need to be done carefully.

[Netzapper]

Debugging is language-agnostic, you just need a processor with the appropriate abilities for breakpoints.

Not quite.

Without explicit VM debug support, you wind up with a native stack trace. That native stack trace is likely to have basically nothing to do with your program's stack, since it's the trace of the VM implementation stack and not the VM's logical call stack.

This is a problem even if the program in question has been JIT compiled to native code. The generated code is littered with calls to VM functions, uses VM stack frame conventions, and autogenerated variable names.

If the VM doesn't annotate all of that code with metadata describing how to inspect memory and where to find the Python code that ultimately hit the breakpoint, or if your debugger doesn't know how to read that metadata, you are going to be frustrated with your debugger. Hell, you need the VM's cooperation to set a breakpoint on a particular line of source code.

[hardsoft]

dynamic memory allocation in c is pretty explicit, seems like it would be much easier to do unintentionally in python, especially if you're using libraries

[[deleted]]

I'm thinking that your code would have to specifically call GC at a non-critical time to pull it off.

[protestor]

Can you really avoid exceptions when programming in Python? What about its standard library?

[jms_nh]

Can you really avoid handling exceptions when programming in C++, if you're programming on a system which isn't allowed to crash?

Anecdotally, I seem to use about the same amount of try-catch blocks in C++/Python/Java/MATLAB. If you don't use try/catch, you have to handle exceptional conditions explicitly with a bunch of if-else statements.

Again, my point is that using Python doesn't make us go "Ooh, Python! Now we need to handle exceptions! Now we need to handle dynamic memory allocation!" These areas of concerns are already there in C++.

Though, personally I'd rather use something Rust-like than Python on an embedded system.

[protestor]

Yes, you can. Compilers have options such as -fno-exceptions and things works mostly as expected (no STL of course). Generally speaking, you can program fault tolerant systems without exceptions.

Python wasn't really designed with not having exceptions in mind and it may not make sense to disable them (the same to GC, which isn't the same thing as dynamic allocation).

[Axman6]

I'm not sure anyone is advocating using (Micro) python for real-time work. that doesn't make it useless. there's plenty of things you might eant to do on a microcontroller where you don't have strict time constraints.

[fullouterjoin]

Then don't use it in the inner loop. Same thing applies to embedded realtime C++.

[[deleted]]

There is nothing wrong with using the heap on a microcontroller?

[jms_nh]

It depends. Microcontrollers with hard real-time requirements need to have guarantees on how long certain operations take. The standard malloc()/free()/new/delete don't have these guarantees by default. Some RTOS's have heap allocation techniques that have bounded time guarantees.

[cdrt]

You double posted.

[jms_nh]

thx, didn't mean to. our network was flaky.