Hello Helge,
I have been researching the LA2016 a little to see if I can help with
the Sigrok integration. In summary, I would say it cannot work on Linux
or Windows at present.
There are certainly issues in the protocol.c [1] file, for example some
FPGA SPI register addresses are wrong; CTRL_THRESHOLD should be 0x68 and
CTRL_TRIGGER should be 0x20. So, I don't understand how this could have
been tested, unless the manufacturer has recently changed the fw and
FPGA bitstream.
That brings me to the next issue; the bitstream extracted from the OEM
software using the python script [2] is different to the bitstream
downloaded to the LA by the OEM software. I have some experimental code
here to run the LA and found that while the LED would fade in/out as
normal the unit would not run correctly. I then extracted the bitstream
directly from the OEM software USB packets (it was different) and my
experimental setup ran fine with that. So, either the python extractor
code is somehow causing bitstream errors or the OEM is obfuscating the
on-disk bitstream.
Adjacent to the board LED there is an SO8 IC, no useful markings. It is
a challenge-response authentication device, with one-wire UART comms on
pin 3 at 12900 baud. Some of the 'unkown commands' mentioned in
protocol.c are related to this device. One of those commands reads a
serial number as shown in the OEM software 'About' box. However, the
purpose of this device is to prevent their software working with any
cloned boards and shouldn't prevent any hardware functions. I recommend
the 'unkown commands' (bRequest 96) are ignored/removed.
IMO using the OEM fw and bitstream is an interim workaround, and a
workaround should not be confused with a solution :-) It would be a
better user and developer experience if we had open solutions; the fw is
not too complicated (the FX2 is just passing bytes around, controlling
endpoints) but the FPGA is perhaps a little tricky.
Anyway, if anyone on this list has an LA2016 (or LA1016) working with
PulseView, please let me know your setup and where you got the
bitstream.
Best regards,
Kevin
[1] src/hardware/kingst-la2016/protocol.c
[2] https://sigrok.org/wiki/Kingst_LA2016
On 2021-01-04 06:14, Helge Kruse wrote:
Am 03.01.2021 um 16:39 schrieb Gerhard Sittig:
Sorry, but I cannot see how this is "a compiler bug".
Well, the C standard doesn't specify how the compiler builds the layout
of structs. The GCC add an implementation specific extension with the
__attribute__ to force packing of the struct. If the source code
specifies to pack and the compiler doesn't pack it is, hmm at least
strange. But there comes the -m-ms-bitfield option to the game. I
actually curious how this evolved. I didn't found the story behind
this.
The number
of leading underscores in the application source code should make
the alarm bells go off, screamingly loud.
Do you mean the underscores in __attribute__((__packed__) or did I
missed something else?
The proper thing to do is what you suggested. Use structs for
internal application purposes. Translate the data at boundaries
between the application and a communication channel, where one
specific memory layout is expected. Leave the application part as
transparent as it should be, don't "constrain" your application
with the details of a physical transport. BTW using packed
structs in the transport conversion isn't right either, it's as
non-portable as packed structs in application code are.
I found this in several OSS projects and use it in my personal
applications too. But if the sigrok coding style at least discourages
the use, I will improve my idea and use the write_uXX/read_uXX
functions
for the conversion between transfer layout and information struct in
the
application.
I am not the author/maintainer of the LA-2016 driver, but I hope to
contibute to the project.
Moving existing drivers that suffer from portability issues can
be considered low hanging fruit for those who want to help other
users, and unbreak the operation of existing drivers in
environments where they did not work before. Such a proper fix
would no doubt get accepted into mainline, since it's a clear
improvement, not just moving the problem to a different location.
So, let's do it.
Best regards,
Helge
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
