-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redesign of trigger API #216
Comments
Arbitrary triggers are a frustrating thing to express in a generic way given that (a) you want some things to be first-class GUI, e.g. threshold levels and (b) every scope probably has different limitations on exactly how flexible you can be. I would suggest implementing something 'good enough for now' before trying to build something which might be 'universal enough'. Two example non-trivial things I use a lot with my pico3k, in case they inspire anyone:
|
"Good enough for now" was the initial goal (edge triggers only). This is, however, rapidly becoming insufficient. |
Proposal: Oscilloscope::SetTrigger() takes a pointer to a polymorphic Trigger object (presumably owned by the OscilloscopeWindow). Each derived class, such as EdgeTrigger or I2CProtocolTrigger, will have configuration fields specific to its own use, and may derive input from one or more channels of the instrument. Use a dynamic creation method similar to what we have in the Oscilloscope and ProtocolDecoder classes. Add a method to Oscilloscope to return a vector of supported trigger types for populating a dropdown in the (currently extremely spartan) trigger properties dialog. We can then use RTTI to check the currently enabled trigger and enable special UI elements, or use something generic like we currently use for ProtocolDecoder properties if there's no special-case GUI logic. The groundwork for this will be (relatively) easy to do, and it's extensible with additional trigger types very easily. |
So you can handle combinations of triggers by just making a wrapper Trigger class? I think "hardcoding" knowledge of the triggers via RTTI in the GUI is inevitable + makes sense. And add method(s) to the Oscilloscope class where it gives you the limitations for a specific trigger, if any? e.g., whether hysteresis offsets are supported, or whether it's possible to add another trigger to a boolean combination. |
I think I'm going to PoC this by implementing a few basic trigger types in the proposed new API, then see how it works. |
This also ties into #100, and is blocking things like I2C protocol trigger support as well. |
Discuss.
The text was updated successfully, but these errors were encountered: