low-level uC function vs. high level language expectations

[torwag]

Hi,
I worked on some ideas which requires me to switch of the interrupt routines (among others, e.g. using the esp9266 with neopixels).
The esp8266 might be a good (or depending on the point of view bad) example, since it relies a lot on interrupt routines for e.g. the wifi functionality.
Therefore, I understand that switching of the interrupt routines can have all sorts of very funny (read nasty) side effects, which might be hard to debug. This made me wonder and interested, what is the correct way to deal with this in a project like MicroPython?
I could see the following two extremes here:

1. Users should take care about interrupt services by themselves and hence (hopefully know) about possible side-effects. However, being not use to it (e.g. coming from python on the PC) they might misuse or wrongly use this functionality.

2. Interrupt services are switched on and off (mostly in C) at points where needed. Devs will implement this, since they know best where to do that but users have no idea that it happens, which might again clash from time to time with users expectations (e.g. One can't do function X and have wifi functionality quasi-parallel to each other).

I find this particular interesting, because, solution 1 would be what you expect from a low level language, assembler, C, etc. Whereas, number 2 is what you expect for a high level language, not because of the language itself, but because usually all this IRQ-stuff is organized by the underlying operating system.

For MicroPython there is no underlying OS, however, people might expect the easiness in use of a high level language.
Thus, I would like to hear and learn what could be the solution in such a case, which as I believe, might just be an example for many cases where the need to use low-level uC functions and high-level language expectations might have to find a good balance.

[deshipu]

There may be one more reason to handle the IRQ flags inside C functions only, and never expose them to the Python layer -- Python may be simply too slow to toggle them.

[dhylands]

Whether python is too slow or not depends on the particular application you're doing.

Being able to disable interrupts is still useful to be able to do from python, as this example shows:
https://github.com/dhylands/upy-example ... /atomic.py

I consider anything and everything related to interrupts to be "advanced" and you need to understand what you're doing. Just because you're doing it in python doesn't make it safe. If we removed all of the interrupt callbacks and other "dangerous" things you might do, MicroPython would lose a large amount of its appeal (at least for me).

[marfis]

If we removed all of the interrupt callbacks and other "dangerous" things you might do, MicroPython would lose a large amount of its appeal (at least for me).

for me too.

regarding timing. I measured the delay until the python callback is executed to be around 15usec on a pyboard. That may be slow for very time critical applications, but for a lot of other things it should be sufficient.

[pythoncoder]

@dhylands Agreed 100%. MicroPython exposes a number of "advanced" features. You can write standard Python and ignore them; if you opt to use them, it's at your own risk. We can write tutorials to help, but it's inescapable that anyone doing real time embedded programming needs to learn the technology. This applies regardless of language.

If you crash a MicroPython platform by writing standard Python it's a bug; put it on Github and it will be fixed. If you go off-piste with interrupts, inline assembler and C modules, inevitably you need some know-how.

It's precisely this mix that makes it such a superb environment.