On Thu, 2021-03-11 at 08:26 +0100, Helge Kruse wrote: > > Am 10.03.2021 um 14:15 schrieb Kevin Grant: > > > > Hello Gerhard, > > > > On 2021-03-08 18:25, Gerhard Sittig wrote: > > > >> Is the basic operation fundamentally broken, or are just not all > >> of the product's features available while the device _can_ be > >> used to get captures and inspect or process the waveforms? In the > >> former case I'd agree to "not supported", in the latter I would > >> not. > > > > It appears to work at least partially for some users. > > Input threshold adjustment uses the wrong FPGA registers and wrong > > algorithm for threshold voltage DAC setting. > > Trigger setups use the wrong FPGA registers (won't work). > > Sampling setups also use the wrong FPGA registers. > > So, quite broken IMHO. > > This could be the result of the OEM changing the FPGA bitstream, > > perhaps deliberately to scupper sigrok support. Or just some mistakes. > > > Yes, the basic operation is fundamentally broken. The implementation > uses a construct of packed structs to layout USB reports. The packed > attribute is suppressed for some reasons in the MXE cross compile > configuration for the whole libsigrok project. This results in USB > reports for LA2016 with wrong content and length. The affected USB > reports are used to send essential parameters to the device. Therefore > the basic operation is fundamentalliy broken for at least one of the > supported platforms. There are some Git repositories around with > bugfixes including yours, Kevin's and mine. This is a good development, > but it's not available to the user who downloads an official version or > a nightly build.
Are you, Helge and Kevin, talking about several different issues that are not related to each other? You can safely assume that I am aware of the USB transfers topic and the portability issues of packed structs, having been an active part in the communication about that. I remember having provided feedback on that, and having amended your submission to help make it acceptable. Haven't I, just in the very days that these messages were sent? With the construction and interpretation of USB transfers having been addressed in the meantime, and the driver being portable across platforms again, what else remains (function wise)? Still haven't seen an update to the wiki device page, despite your repeated and deeply felt urge that users should be able to find the information at some place. The above quotation suggests that the driver could have been written against one version of the vendor firmware (perhaps without stating it?), while you notice issues when using a different firmware version? Or is the driver not operational with the firmware that it was created and tested with initially? If the driver depends on the firmware version and does not check (or may not even be able to check), and this gets "fixed" by making the driver depend on a different firmware version (which still is neither identified nor checked) -- is this an improvement? I'd guess that the driver would be as broken as it is considered now. And thus would cease working as expected when used in combination with yet another firmware version. Notice that I'm speculating here, neither having access to the device nor its version or several versions thereof, not being able to verify or exclude any of these speculations. While other messages in the thread suggest that firmware images extracted from multiple vendor software versions are binary identical? Or is this a reference to identical versions of several unsupported (since untested, because not available at the time of the driver's creation) firmware versions? Again, with neither the device here nor better information all I can do is guess. Which illustrates that getting the available information on record somewhere (in a "non-volatile" form) is more important than any code changes which don't address the issue of not knowing the current status and the origin of current issues. Just make sure to clearly mark version dependencies, and separate arbitrary implementation details from generic design limitations. > So the Kingst-LA2016 is not supported for at least one platform. I am > not sure what the status at https://sigrok.org/wiki/Kingst_LA2016 should > express. If it means "works for at least one platform" it is supported. > Since sigrok is a cross-platform project it should mean "works for all > platforms that you find at https://sigrok.org/wiki/Downloads. If the > second meaning is intended, the current information is wrong. The next > girl that buys that device to use it with sigrok on Windows would be > disappointed. Gotta ask the maintainers about that. Won't speak for them. Only can observe and conclude from what else is usually done in the wiki for most other devices. virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
