Summary: | SPI decoder displays correct data in PulseView screen, exports some incorrect values | ||
---|---|---|---|
Product: | PulseView | Reporter: | Mike <linse> |
Component: | Protocol decoding | Assignee: | Nobody <nobody> |
Status: | RESOLVED WORKSFORME | ||
Severity: | major | CC: | Gerhard.Sittig, soeren |
Priority: | Normal | ||
Version: | 0.4.1 | ||
Target Milestone: | --- | ||
Hardware: | x86 | ||
OS: | Windows | ||
Attachments: |
text file, data exported from PulseView SPI decoder
.sr file for bug 1417 |
Description
Mike
2019-09-18 21:41:47 CEST
Thanks for your report. Can you please attach an .sr file that we can use to reproduce the issue? ping Created attachment 545 [details]
text file, data exported from PulseView SPI decoder
The SPI decoder's display of hex data within PulseView is correct. The exported text file produces incorrect representation of the hex data, for example:
1E1 hex is represented as 1.00E+01
It looks like some feature of the export process is turning the hex
values into incorrect decimal values using scientific notation.
This seems to occur with any data that originates as nEm hex, in which n and m
are numeric. The cases that I'm seeing originate mostly as 3-digit hex values,
so I'm not sure what would happen if the original value were 32E19h, for
example. Maybe it would be exported as 32.00E+19.
Thanks for the comment but this is not an .sr file. Hi Soren No, this is not an sr file, it's the text file that is exported using the export function that is provided within PulseView. I found that the mishandled representation occurs in the case in which export is used in the original PulseView session that captured and decoded SPI data, AND it also happens in the case in which I've loaded a previously saved sr file to PulseView, then exported the text file from the selected row of SPI hex data. In other words, what's relevant to my bug report is that the process for creation of the text export file it mishandling hex data which has the form that I described. In my present task, I'm using the logic analyzer and PulseView to intercept data from an analog-to-digital converter. I export that data from PulseView as a text file, then import that text file to Excel or Libre Calc for further analysis. The text file that's delivered by PulseView contains the erroneous data representation that I've noted. Mike Well, if I can't reproduce the issue, I can't really fix it, and you're the first and only person to have encountered it. I've tried to reproduce it and failed and another member from the community also failed in reproducing it, so there has to be something special about either your data or the environment that PV runs in. I'm not trying to be an ass here, I'm just saying that without being able to reproduce the issue, the chances of fixing this bug are rather slim... Created attachment 546 [details] .sr file for bug 1417 Comment on attachment 546 [details] .sr file for bug 1417 SPI decoder setup for .sr file for bug 1417 CLK D6 MISO D4 CS D2 chip select active low Clock pol 1 Clock ph 1 MSB first Word size 24 As Soeren mentioned, the problem does not reproduce everywhere universally. We tried with UART data in the past (when your capture was not available yet, notice that the maintainer and other persons spent their time trying to reproduce the issue), and I just tried again with your SPI data. The issue that you report here does not reproduce for me. The above communication suggests neither does it for the Pulseview maintainer. So if it's not the data and not "the software" (in the general sense), it must be something local or the platform which triggers the unexpected behaviour. ... 359682029-359682453 SPI: MOSI data: 1DE 360482597-360483011 SPI: MOSI data: 1D5 361283042-361283456 SPI: MOSI data: 1CF 362083552-362083966 SPI: MOSI data: 1E2 362883999-362884413 SPI: MOSI data: 1DA 363684483-363684908 SPI: MOSI data: 1E3 364484970-364485394 SPI: MOSI data: 1EE 365285439-365285863 SPI: MOSI data: 22B 366085907-366086321 SPI: MOSI data: 1E5 366886418-366886832 SPI: MOSI data: 1EC 367686844-367687258 SPI: MOSI data: 1D0 368487321-368487735 SPI: MOSI data: 1F0 369287801-369288225 SPI: MOSI data: 1EC 370088314-370088728 SPI: MOSI data: 1EB 370888760-370889174 SPI: MOSI data: 1F4 371689293-371689707 SPI: MOSI data: 1F1 372489756-372490170 SPI: MOSI data: 1ED 373290254-373290668 SPI: MOSI data: 1F1 374090697-374091111 SPI: MOSI data: 206 374891209-374891623 SPI: MOSI data: 1FE ... Does the 9bit UART example data of the sigrok-dumps repo work for you? This file also contains patterns \d+E\d, and work as expected here. ping Closing the report due to user inactivity and the inability to reproduce at several sites in several attempts. Feel free to re-open when input data or instructions become available which allow to reproduce the issue. |