Ideas Test

12 VOTE

Implement better view for decoded protocols

The decoded protocols area is really neat but it's HARD to read. One value per line is really nasty when the protocol is async serial and forms words. Another example is canbus. The traditional view would be for all data bytes to be on the same line so it is easy to see them all at once. I'd like to see the decoded protocol area better format the output based on which protocol is being decoded.

This might be problematic because it seems as if all of the registered protocol handlers dump their output into the same window in time correlated order. That's a really, really odd choice. Each channel should have it's own decoded protocol area to the right of the channel so that each one has a nice view of only that protocol / channel.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Aug 2 2018
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    02 Aug 17:51

    I ended up saving the protocol output to a CSV file, converting that to *.xlsm (Excel with macros), and writing a simple macro to convert the USB data so that everything from the SYNC to EOP is on one line, and just save the start and end times for that group of messages. It was about 30 lines of code.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    02 Aug 17:51

    I would also agree that better views would be nice.

    For I2C - a tree (+/-) view would be useful.
    Every Start event could be a new level and then every transaction up to the next start or stop would be at that level and could be expanded / collapsed.
    This would make examining the starting transaction the highlight and then expand to see what was under if needed / interested in that transaction.

    Also, it would be nice if the Decoded Protocols could be popped out / undocked / new windowed. So it could be viewed separately and resized.

    Then filters on the starting transactions could be applied to see the summary of transactions to a particular device in a nice compact form.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    02 Aug 17:51

    An example of how protocol decoding could be displayed better:
    http://www.pctestinstruments.com/logicport/interpreters.htm

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    02 Aug 17:51

    Strongly agree! The Logic UI is awesome when looking at _signals_ on the scope-like display, for debugging low-level drivers, making sure chip select and interrupt lines are working properly and so on.
    BUT, when working at a higher level, when you want to look at the _data_ that is read and written to a device, the Logic UI is hard to use. That's why my Logic has been sitting on a shelf for many months, and I've been using a dedicated I2C/SPI analyzer from another manufacturer. They have a spreadsheet-like full screen display that shows one transaction per line. Each line shows the start time, the duration of the transaction, the number of bytes transferred, and the first 12 bytes transferred. Clicking on a line causes all of the bytes transferred in the transaction to be displayed in another pane. It's so much easier to understand what's going on at a high level when looking at that sort of one line per transaction display.
    What I would suggest for Logic is that clicking on a button on an analyzer should bring up a separate window with a spreadsheet-like display such as described above.
    If Saleae could implement that feature, Logic would be even more usable and versatile than the competing product. One serious limitation of the competing product is that it only looks at MOSI, MISO, CLK and CS lines. It can't show other signals, such as an interrupt line coming out of a SPI peripheral. If we can't see the interrupt line, and the system that we're debugging hangs, we can't tell if the peripheral failed to assert interrupt, or if the MCU is ignoring the interrupt. So, being able to view other signal lines along with the SPI bus data would be very useful.
    A couple of other ideas to consider along with this one:
    * Make it easy for users to write their own analyzers. For example, it would be extremely useful to be able to decode and display transactions in a high-level fashion, as commands and meaningfully formatted data, rather than just a line of hex bytes.
    * Make it easy to compare traces collected at different times, and highlight the differences. (Also need to be able to mask out unimportant differences, such as times and sequence numbers, so those differences aren't highlighted.) That would make it easier to compare good and bad traces and track down the cause of the differences.
    * Some other suggestions have mentioned wireshark. I'm not familiar with it, but from a brief web search, it looks like it might be useful for analyzing and even comparing bus transactions.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    02 Aug 17:51

    I agree, that this is super awesome but could be improved.
    For example for SPI mode, it would be great to somehow indicate which bytes are sent during the same chip-select session.