Carl Banks <[EMAIL PROTECTED]> wrote: > Python really isn't suitable for in-flight controls for various > reasons, and mission critical concerns is a minor one (systems with > less underlying complexity tend to have fewer failure modes). But > mostly it's raw throughput: Python is just too slow. Flight control > computers have to be powerful enough make a ton of mathematical > calculations in a matter of milliseconds, and under strict weight and > power constraints. The cost of running 100 times slower than optimal > is just too high.
I'm not convinced that's true for all avionics uses. Certainly, if you're doing the fly-by-wire stability control system for a dynamically unstable airframe, you need a lot of compute power and guaranteed real-time response (recovery from a VMC rollover is no time for garbage collection). But, not everything in an airplane is like that. Take something relatively complicated like a GPS. The basic receiver is pretty compute intensive, but that's likely to be a dedicated chip. Most of the functionality in the box, however, requires a lot less horsepower. You need to handle user input (i.e. keep up a scan on maybe 20 keys), and update a low-res display (320 x 240 x 8 bit color is typical) with text or cartoon graphics. There are certain real-time calculations which need to be done, such as time, distance, and bearing to the next waypoint, but these are typically updated a few times a second. Like most things that use Python (or TCL, or Ruby, or ...), I would expect that most of the low-level stuff would be done in something like C and Python would be used for the glue code and things where there's no time pressure. -- http://mail.python.org/mailman/listinfo/python-list
