Edit (24-Nov-16): That setting a capture from a script or the python console using the API is blocking is the obvious, necessary behavior to avoid wreaking havoc. I blame lack of sleep. However, it’s useful to think about how the blocking is implemented.
Edit (25-Nov-16): Upon the excellent advice of another user, I wrote simple Auxiliary Module to send serial data to target during capture. See below.
I noticed when working through Tutorial B3-2 (Timing Analysis with Power for Attacking TSB) that when a call is made to self.api.capture1() to set a capture AND when the triggering event is the subsequent beginning of a serial transmission (using self.api.getTarget().ser.write()), for example:
# Stuff. I omitting stuff for brevity's sake
def run(self):
# User commands
self.api.connect()
# Set the relevant parameter in list format including the following
['OpenADC', 'Trigger Setup', 'Mode', 'falling edge'],
['CW Extra Settings', 'Target IOn Pins', 'Target IO1', 'Serial TXD'],
['CW Extra Settings', 'Target IOn Pins', 'Target IO2', 'Serial RXD'],
['CW Extra Settings', 'Trigger Pins', 'Target IO1 (Serial TXD)', True],
['CW Extra Settings', 'Trigger Pins', 'Target IO4 (Trigger Line)', False],
# More stuff. Then iterative setting of parameters
# Here is the code which sets the capture and begins serial transmission
self.api.capture1()
self.api.getTarget().ser.write('UUUU')
# More stuff
Then 1) the capture1() call blocks the transmission, 2) the capture is forced triggered at end of timeout period, 3) then the serial data is sent. In other words capture1() cannot be configured to trigger on transmission from the CW since the call to capture1() blocks waiting for a triggering event. I replicated this also through the Python console. This behavior contradicts the description of self.api.capture1() given in Tutorial B3-1:
"The API allows us to press the Capture 1 button and view the power trace without using the GUI. There are two relevant commands here:
self.api.capture1()
acts as if we’ve just pressed the Capture 1 button;
"
However, through the GUI setting the capture using the button does not block the CW from sending serial messages (and doing anything else) and the triggering works just fine. So I deduce from my experiments that capture1() can only be used when the triggering event is set before the capture1() call or is external event. And importantly there is some difference between pushing the button in the GUI and using capture1() in a script/from the console.
My question is this: Is there a non-blocking way to set a single capture from a script or the console using capture1() that is then triggered by the execution of code (say, to assert a pin or begin serial transmission) that follow immediately after the call to self.api.capture1()?
I hope this is clear! And I apologize if I’ve left out too many details.
Thanks for your assistance!
Gabe