Multitasking?

[Jim Ford]

I see that there's an example of controlling servos, with 2 instances being created.

Would the servos operate sequentially - that is the first servo complete its travel before the next one starts - or does Micropython 'multitask' with a RTOS so they both operate simultaneously?

I look forward to getting one!

Jim

[torwag]

Hi,
not 100% sure. However, I would say the servos receive a PWM signal and those can be generated in parallel.
Thus, you could drive servos simultaneous.
There is no RTOS.

[Neon22]

Its intended that the servo actuator is done in an interrupt routine which services all servos.
So they appear to all be running concurrently and not impeding the flow of the python code.
Not fully implemented yet - but example on Teensy port.

[pfalcon]

Servo control is extreme case - as said before, it would require "hard realtime" interrupt-based control (coded in C) to implement (and that's certainly on TODO, knowing that folks want to control robots with micropython board).

But otherwise,oOne of the ideas of MicroPython is to let users implement their own multitasking - in high-level language. One of Kickstarter updates for dedicated to example of this: https://www.kickstarter.com/projects/21 ... sts/675393 (see Scheduler class). There's also ticket on github on this topic: https://github.com/micropython/micropython/issues/242 . It basicly points out that Python has native support for coroutines (via generators), and that can be good base for implementing cooperative multitasking in MicroPython. The ticket has more info and references.

[JohnHind]

IMHO an RTOS is the wrong model for this - event driven is a better approach for an interpreted language which is necessarily single-tasking.

So for the servo example you have a command 'moveto(45)' which does not block, so you can set two servos in motion at the same time without waiting for the first to complete its movement. If you need to take some action when the servo movement is complete, have a way of submitting another function to be run when the movement is complete (or a co-routine to be resumed). (Normal servos work this way in hardware - you just need to set a PWM to a pulse width proportional to the desired position and the servo electronics does the rest.)

The blocking problem is particularly acute for communications where you issue a command over some sort of serial link and then you need to wait for a reply. Again rather than blocking everything until the reply is received, you should hook a function to be run once the reply is ready to be acted upon (or better, a co-routine to be resumed).

Much simpler than an RTOS, just have an interrupt driven scheduler which maintains a queue of Python functions which are ready to run - each runs to completion before moving on to the next, with no preemption.

I will be very disappointed if it turns out that MicroPython is just a "big loop" system where you explicitly code a single top-level polling loop and nothing is event driven.

[dhylands]

I guess whether your program is event driven or not is largely up to the program which is running on top of micro python.

I know that I will certainly be using event driven approaches for controlling my robots, so I intend to make sure that those approaches will work.

MicroPython will allow interrupt handlers to be coded in python, so those will be able to act as event sources.

I know that the EXTI module has support for this now, I'm not sure that anything else does, but it will eventually.

[Max]

I will be very disappointed if it turns out that MicroPython is just a "big loop" system where you explicitly code a single top-level polling loop and nothing is event driven.

I know this is from ten days ago but the advantage of Python in this context is that Python allows for functional programming concepts to exist within our friendly and familiar imperative programming. Generators are a great way to implement a cooperative multitasker in very little code. For example, here's how you could have two "threads" or "tasks" or "microthreads" run side by side with independent stacks without an elaborate or frustrating state management scheme or a big fancy RTOS.

Code: Select all

def TaskOne():
    while True:
        # do work
        # relinquish control
        print "Task One!"
        yield None

def TaskTwo():
    while True:
        print "Task Two!"
        yield None

TaskQueue = [ TaskOne(), TaskTwo() ]

while True:
    # main loop here
    for task in TaskQueue:
        next(task)

This is a simple example. If you need to take it a step further you could write a mildly more elaborate scheduler, where Tasks can ask to only be woken back up when a certain condition is met (on some interrupt listener, or a software timer). You would have your python hardware interrupt handlers interact with the scheduler to re-organize what should get executed when the current task decides to yield.

This can be as elaborate or simple as you need it to be, but I wanted to show that MicroPython as it stands currently already offers a lot more than "just a big loop"

[nelfata]

Hello all,
I am thinking to integrate an RTOS (ChibiOS) underneath Micropython. By adding a nice Python API to the RTOS threads which could be dynamically created.
Is this of an interest to developers here?
Does it make sense to work on that or perhaps there are plans to have true Python Threading library?

NOTE: I have use ChibiOS extensively on multiple projects, it is tiny, efficient and provides a functional environment for most embedded applications.

Thanks.

[pfalcon]

I opened a thread for specific implementation of asyncio-like library for MicroPython: http://forum.micropython.org/viewtopic.php?f=3&t=85

[pfalcon]

Hello all,
I am thinking to integrate an RTOS (ChibiOS) underneath Micropython. By adding a nice Python API to the RTOS threads which could be dynamically created.
Is this of an interest to developers here?

The more MicroPython ports exist, the better . Of course, maintained ports are even better, so you should consider if you really need it.

Regarding preemptive multithreading support, please make sure you're aware of https://github.com/micropython/micropython/issues/595 . You're welcome to help with those issues, specifically stack usage analysis and optimization is something which certainly will benefit MicroPython.

Does it make sense to work on that or perhaps there are plans to have true Python Threading library?

I assume whoever will work on threading support, will implement it in the form of Python threading library (perhaps, a subset) - it just doesn't make sense to add support of threads to Python, but do it in non-Python way.