Ideas Test

48 VOTE

Trigger on Protocol Analyzer match

Software should allow for specifying a trigger condition based on a protocol result.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Aug 2 2018
  • Planned
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 2, 2018 18:21

    Hello...?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 2, 2018 18:21

    What is the progress on this task after 1.5 years?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 2, 2018 18:21

    Yes, I would absolutely agree here. Triggering on a specific bus event is key for successful debugging, in many embedded designs.

    I would suggest to include the following triggering for I2C:
    Start, repeated start, stop, NACK/missing acknowledge, address, data

    For SPI: Start of frame, end of frame, type of frame, data, identifier, identifier and data (combined), missing acknowledge. And bit stuffing error as a later option.

    Give this a go, and you will gain many new loyal customers, I am sure of.

    Cheers,

    M.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 2, 2018 18:21

    Absolutely agree! This single feature would boost the capability of your analyzer to compete with much more expensive devices. Why store tons of captured data, then sift through it looking for that particular sequence when the tool can simply trigger on the sequence? Would save storing all that data too. I2C, SPI, just about anything that you can define a sequence for.

    Doing it in hardware if possible would be best (fastest) but if you have to do software processing, that's ok (slower, better than nothing.)

    While you're at it, why not include other triggering options. A before B, analog level, etc. Take a look at what Tektronix or Agilent offers. I realize you probably can't do all of that, but you can sure get close!

    Thanks!

    - Kevin