I have some python test scripts which run tests on DUT. As part of this test script we need to monitor some GPIO pins, UART bus and I2C bus. Basically we want “real time” monitoring of these buses such that when data comes in the UART bus we can send commands to the DUT. Also as we do testing we send commands to DUT and verify the buses and GPIOs are correct.
Is there a way we can get real time access through the API?
Basically we need saleae to be running continuously where we poll for data, verses starting and stopping for capture.
The Glasgow Interface Explorer might be a good fit for that use case.
Hi @trampas,
Unfortunately we do not offer a real-time API to grab the inputs. The main thing we see users do with our API is start a free run (looping) capture, then once started, they will exercise their device under test for whatever function they are testing, then they will stop the capture and process the recorded data. Unfortunately we don’t have a way of just grabbing the current inputs. Unfortunately doing this with a short capture has a pretty high overhead of several hundred milliseconds, depending on which unit you have.
Are you just asking for a way to call a function and get the current state of each input pin from the unit? If so, how fast would that need to be? (e.g. 10ms, 1ms, less than 1ms, etc)
Also, regarding the protocol data, how much latency would you still accept, between the packet appearing on the bus and when your application is able to read it?
I think it really depends on what amount of latency is allowed for your “real time” request? The Logic Automation API is more suited for non-interactive ‘batch’ processing, where you 1) setup a test, and 2) capture/process the result. There isn’t a way to interact with the data/analyzers while the test is in process.
With the HLA python scripts, you could do some level of interactivity, but it will not be super low latency, and will depend on your PC/host performance, as well as the USB bandwidth consumed by the data being streamed by the test (i.e., if you’re collecting high sample rate analog data, you might lag out, or get increasingly behind the “real time” execution of the DUT – as the streams will become backlogged due to overhead of processing too much data to keep up).
However, if you are using mostly/only digital (no or minimal low sample rate analog), then the HLA python script might allow you to do what you want. It may still be quite limited, as the HLA python environment is built into the Logic GUI, and doesn’t easily have a way to extend it with other packages (i.e., no off-the-shelf ‘pip’ supported).
Otherwise, you could look into using CircuitPython or the Blinka libraries for a PC hosted environment.
There are various USB target boards supported by Blinja, including:
| Board / Chip | I/O Features |
|---|---|
| MCP2221/A | I2C, GPIO, ADC, DAC |
| FT232H | SPI, I2C, GPIO, UART |
| FT2232H | Dual SPI/I2C/UART |
| RP2040/2350 (with U2IF) | SPI, I2C, GPIO, ADC, PWM |
| GreatFET One | SPI, I2C, GPIO, ADC, DAC, PWM |
However, if you need multiple serial interfaces and GPIO to all work simultaneously or more specialized control, then you might need to use the underlying libraries directly (PyFtdi, etc.) vs. using Blinka/CircuitPython. I’m sure other USB serial/GPIO hardware exists with interactive hardware interface control from a PC hosted python script.
Finally, you could combine using the boards above with the Logic Automation API to take snapshots while/after sending serial commands in the same python script. Ultimately, it depends on exactly what you’re trying to do, and how tight the timing has to be. Anything controlled by a PC and using USB (at least on Windows) will typically have some O(milliseconds) or higher latency, due to USB and Windows OS overhead. For O(microseconds) or better performance, you’ll likely need to use custom or dedicated hardware or something with lower latency (dedicated PCIe card?)