To Thread or not to Thread....?

[John Nagle]

On 12/1/2010 1:24 AM, Antoine Pitrou wrote:
> On Wed, 1 Dec 2010 02:45:50 +0000
> Jack Keegan<whatsjacksemail at gmail.com>  wrote:
>
>> Hi there,
>>
>> I'm currently writing an application to control and take measurements during
>> an experiments. This is to be done on an embedded computer running XPe so I
>> am happy to have python available, although I am pretty new to it.
>> The application basically runs as a state machine, which transitions through
>> it's states based on inputs read in from a set of general purpose
>> input/output (GPIO) lines. So when a certain line is pulled low/high, do
>> something and move to another state. All good so far and since I get through
>> main loop pretty quickly, I can just do a read of the GPIO lines on each
>> pass through the loop and respond accordingly.
>
>> However, in one of the states I have to start reading in, and storing frames
>> from a camera. In another, I have to start reading accelerometer data from
>> an I2C bus (which operates at 400kHz). I haven't implemented either yet but
>> I would imagine that, in the case of the camera data, reading a frame would
>> take a large amount of time as compared to other operations. Therefore, if I
>> just tried to read one (or one set of) frames on each pass through the loop
>> then I would hold up the rest of the application. Conversely, as the I2C bus
>> will need to be read at such a high rate, I may not be able to get the
>> required data rate I need even without the camera data. This naturally leads
>> me to think I need to use threads.
>> As I am no expert in either I2C, cameras, python or threading I thought I
>> would chance asking for some advice on the subject. Do you think I need
>> threads here or would I be better off using some other method. I was
>> previously toying with the idea of using generators to create weightless
>> threads (as detailed in
>> http://www.ibm.com/developerworks/library/l-pythrd.html) for reading the
>> GPIOs. Do you think this would work in this situation?
>
> The main question IMO: the I2C bus operates at 400kHz, but how much
> received data can it buffer? That will give you a hint as to how much
> latency you can tolerate.

    Right.  Neither Windows XPe nor Python is designed for hard real time
work.  Unless your peripheral devices have considerable buffering, don't
expect this to work without missing a measurement once in a while.
If you have to talk to the I2C interface for each bus transaction before
you get another reading, so that you have to respond to the device
within 2ms every time, this probably won't work.

    If you were writing this in C++ on QNX, which is intended for
hard real-time work, you could easily meet those time requirements.
I've done that, and just reading the devices took maybe 3% of a
Pentium 4.  Python on Windows XPe, maybe not.  You'll need to test.
XPe is just XP with some stuff taken out; it's not a real-time OS.

    A good test is to hook up a square wave generator to some I2C device
you can read, and try to read it in real time, measuring the time in
microseconds between each pulse.  Turn up the frequency until you start
missing events.  That will give you a handle on how good your real time
capabilities are.

    Note that the machine you're using matters.  Some computers have
stuff going on in system management mode that results in long
interrupt lockout latencies.

    One option may be to put something like an Arduno on a USB port,
and let it talk to the I2C device.  See

    http://www.arduino.cc/playground/Learning/I2C

Let it queue up and timestamp the accelerometer data, which can then
be read in blocks from the USB port.  If both the accelerometer data
and video frames are buffered, then you can do your processing in
Python without trying to meet hard real-time constraints.  This is
the usual approach in Windows land.
		
				John Nagle