Use time.sleep() to 'sneak up' on the desired time, then busy-wait during the last 1-10 ms. One reason I'm staying with Python 2.x today is PyPy: Things always go faster with LLVM!ĭon't be afraid to busy-wait when critical timing is needed. My first RT Python project greatly benefited from Psyco (yeah, I've been doing this a while). Use Python accelerators to speed up your code. Optimizing C module performance is a PITA, especially when translating across the Python-C interface becomes the most expensive part of the code. Things (usually) go faster with C! But mainly if you don't have to write your own: Stay in Python unless there really is no alternative. Which basically means not only avoiding threading, but also avoiding system calls to the greatest extent possible, especially during time-critical operations, unless they are non-blocking.
Use threading/multiprocessing only to offload non-RT work from the primary thread, where queues between threads are acceptable and cooperative threading is possible (no preemptive threads!).Īvoid the GIL. There are some basic strategies and tactics I've learned along the way: I've built several all-Python soft real-time (RT) systems, with primary cycle times from 1 ms to 1 second. I have never tested a RT-Linux system, don't know how comparable it to QNX in terms of stability and efficiency, but I know that all the members of Python habitat and non-Python tools (like Google Earth) that the new system could be developed on works most of the time out-of-the-box. Looking further on QNX might be advantageous to us since 6.4 has a free academic licensing option, comes with Python 2.5, and a recent GCC version. This is a proprietary system and we can't access the internals of it. NOTE1: The reason of emphasizing on QNX is due to we already have a QNX 4.25 based data acquisition system ( M300) for our atmospheric measurement experiments. Which way would you advise me to work on? I would be glad if you point some similar design cases and further readings as well. Or at least wrapping the C code using Python to provide an easier access to the system. If not, mixing with timing-critical parts of the design with "C", or writing everything in C and not even putting a line of Python code. However I am curious to know and want to learn some experienced people's opinions before I blindly jump into the coding action whether it would be feasible and wiser to write everything in Python (from low-level instrument interfacing through a shiny graphical user interface). (Either on a QNX or an RT-Linux system.)Īs far as I know, these jobs are performed using C / C++ to get the most out of the system. I am planning to implement a small-scale data acquisition system on an RTOS platform.
0 kommentar(er)
