chip.py using very inefficient subcall to pyftdi

[judule1]

Pardon any unfamiliarity, as I've only been poking around for a day.

I'm currently using a Raspberry Pi 4B (up to date) with an Adafruit FT232H adapter (USB-C version) to an LIS3DH. While using the example Adafruit LIS3DH CircuitPython libraries, I discovered that I was getting a whopping 5 samples per second out of an expected 400 (default data rate). After a few hours of digging and tracing, I discovered that pyftdi is essentially crawling through and examining many USB devices every time I read bytes, leading to 120ms being spent every single accelerometer read on just init backend calls through libusb1.py.

This is happening due to line 72 in chip.py: count = len(UsbTools.find_all([(0x0403, 0x6014)])), which is there solely to determine whether the FT232H (or whatever board you might be using, if you're in another if-else branch) is connected. The corresponding function in the pyftdi library seems to do local caching which worked as I expected, so not sure why this kind of delay is happening in there - though there are a few TODO's in there about optimizing searches. Regardless, I didn't do much experimentation in there after I commented out the chip.py line as a hacky workaround (with the hope that I'll always be connected while running this & set the Blinka env variable in-application). My sampling rate went up to ~240 from 5 - still not where I'd like it to be, but much closer in magnitude.

Anyhow, I'd like to make a newbie recommendation that the count() call be changed to something more efficient. Also, thanks for writing all these libraries!

(Note: everything installed via pip3)
Raspbian Buster Desktop (fully up to date as of Sep 7, 2020)
pyftdi 0.52.2
Adafruit Blinka 5.3.3
adafruit-circuitpython-busdevice 5.0.1
Adafruit-PlatformDetect 2.15.0

[ladyada]

ok gotta ask - why are you using an FTDI to talk to the LIS3DH instead of directly connecting to the Pi??

[judule1]

Great question! Unfortunately I'm in a situation where my gateways are more easily deployed at some distance from my sensors (not just the LIS3DH). That length needs to be variable but will pretty much always be >1m (possibly quite a bit more), so SPI gets pretty dicey there.

[ladyada]

@judule1 where's that chip id function called from? it should only be called once at the beginning of the script

[judule1]

I'm away from my logs, but IIRC it's line 55 of board.py, also calling for id. It's called 14 times per acceleration read according to cProfile; not sure why that'd be.

[ladyada]

@makermelissa ok wanna look? we should only check the chip id once

[makermelissa]

Sure