Possible I2C speed up for digital sensors

[GoogleCodeExporter]

Hey guys,

I've just been reading through the sensor.py code (current trunk). I might've 
spotted a way to reduce the number of direct commands necessary to retrieve a 
sample from a digital sensor. In Bluetooth connections (which are fairly slow 
as you probably know), this can sometimes/often save one out of 3 direct 
commands and reduce the time to query a digital sensor by roughly 30ms.

I'm not sure if I understood the whole nxt-python package correctly, but I 
assume that all sample retrieval communication with digital sensors is 
happening through the method "i2c_query()" from the class DigitalSensor (here: 
http://code.google.com/p/nxt-python/source/browse/trunk/nxt/sensor.py#128 ). If 
that's correct, then in line 135, _ls_get_status() get's called, which seems to 
do busy waiting until the I2C bus / the sensor has finished its current 
operation. Only when enough bytes are ready (or in case of a timeout), the 
polling (direct command LSGetStatus) will stop.

Now the point: If LSGetStatus tells you "everything ok, data ready to be 
retrieved", you have to issue the direct command LSRead. This is where you can 
save time. You can totally ignore the LSGetStatus commands, and allways try 
LSRead straight away. As long as there isn't enough data, you can detect this 
situation from the status byte of the reply package. But if you're lucky, i.e. 
once the sensor is ready, you already got the valid data as payload. In summary 
this saves 1 command.

We've been using this method for a long time successfully, and it did greatly 
improve the performance with all digital sensors (the US being most widely 
used).

An implementation example with further explanations and some statusbyte-codes 
can be found here:
http://www.mindstorms.rwth-aachen.de/trac/browser/tags/version-4.03/RWTHMindstor
msNXT/COM_ReadI2C.m#L139


I'd love to see you guys use that principle and see if you can improve your 
Bluetooth performance. If not that's fine, but you could keep this in mind and 
maybe on the to-do-list.
Thanks for reading.

Regards, Linus

Original issue reported on code.google.com by linus.at...@gmx.de on 19 Aug 2010 at 12:36