feed_queue: rename routines for submission of a single sample value Common feed queue support originated from input module RLE compression. Its API would accept a single sample value and optionally repeat that value several times. Rename the routines and its parameter for improved awareness. Adjust existing callers: The asix-omega, atorch, kingst-la, rdtech-tc, and rdtech-um acquisition device drivers, as well as the protocoldata, stf, and vcd input modules. See a word diff for the essence of the change.
kingst-la2016: add another supported LA2016 model (bytes 0x0b 0x10) Add the 11 (16) magic bytes combination (in hex: 0x0b 0x10) which adds a more recent Kingst LA2016 device to the list of supported models. This addresses the device identification part of bug #1825.
kingst-la2016: adjust sample memory interpretation for LA5032 The 32-channel model in the Kingst LA series uses a different sample memory layout than 16-channel models. The previously encoded assumption of 3x (u32 + u8) to hold 32 channels within the same 15 bytes as other models was incorrect. User feedback in bug #1805 suggests that the transfer size and the sequence number size differs as well. Thus the packet count per transfer differs, too. LA5032 holds 6 packets within a transfer that spans 32 bytes. Reported-By: Roman Shishkin <redacted>
kingst-la2016: update developer comments, motivated by LA5032 support User feedback in bug #1805 provides information on the sample memory layout for the 32-channel model in the Kingst LA series. Adjust comments for improved readability/maintainability, and for awareness of variants across different models. Rework the send_chunk() comment. This routine deals with captures to the device's internal RAM. Memory layout differs quite a lot between models with 16 and with 32 channels. Rephrase the stream_data() comment. This routine deals with continuous streams of uncompressed data which bypasses the device's local memory. Reported-By: Roman Shishkin <redacted>
kingst-la2016: unbreak streaming mode for LA5032 The Kingst LA series models share the same streaming mode memory layout. All channels' chunks are 16 bits wide. The previous version worked for 16-channel devices, this change unbreaks the 32-channel device LA5032. This fixes the streaming aspect of bug #1805. Reported-By: Roman Shishkin <redacted>
kingst-la2016: add another supported LA5016 model (bytes 0x0c 0x10) User Daniel reports in bug #1799 that an LA5016 as of 2022-08 uses magic byte values which were not listed in earlier implementations. Add the very 12 (16) combination (in hex: 0x0c 0x10) which the user reported. As well as 12 (0) for good measure -- most other models have this "wildcard" entry, too.
kingst-la2016: rephrase magic bytes in table of known models Prefer the hex presentation for magic bytes retrieved from EEPROM to identify Kingst LA models. Adjust the models[] array and diagnostics. As a byproduct this keeps the table layout stable in future versions. [ See a word-diff for the essence of the change. ]
kingst-la2016: cope with 800MHz base clock for 500MHz models The LA5016 uses an 800MHz base clock to derive the samplerate from. And communicates divider 1 to configure the 500MHz rate. And does support the 200MHz rate (divider 4). Which also makes the 10kHz lower boundary unavailable on some models. Update the capture configuration logic, the config API routines, and associated comments. Discuss how streaming may make finer grained rates tables desirable (but stick with 1/2/5 for now).
kingst-la2016: introduce base clock independent from max samplerate The LA1010 devices are said to use an 800MHz base clock to derive the samplerate of up to 100MHz from. Add this information to the list of known devices, and adjust the samplerate dividier code path. Keep value 0 in that column for all devices where the base clock and the maximum samplerate are identical. For awareness during maintenance. Make the untypical devices stand out.
kingst-la2016: add more device types and their EEPROM magic numbers Extend the EEPROM content check which identifies device types. Inspect the full set of four bytes before falling back to weaker checks of two bytes per copy. Prefer the longest run of consistent data that is found first. Some devices are said to require inspection of byte[2] in addition to byte[0], to tell different models apart which share the same byte[0] value. This was exclusively tested on LA2016 hardware. The details were derived from the https://github.com/AlexUg/sigrok implementation (which claims support for LA1010, the LA50xx details may be untested there as well). The model database also includes items which are not supported by this driver implementation, to provide the maximum amount of information to users which became available during scan.
kingst-la2016: comment on FPGA register at offset 0x0004 (unused) The vendor firmware optionally keeps reading u32 values from the FPGA register at offset 0x0004 outside of acquisition periods. To present the input pin's current level and changes "in real time" in the GUI. The sigrok driver does not use this information, but it's useful to have the comment in the source code.
kingst-la2016: add support for streaming mode, works for 16 channels Implement support for streaming mode and announce the SR_CONF_CONTINUOUS config key. Automatically enable streaming mode for devices which don't have local memory. Device identification, firmware download, and capture setup are identical to "normal mode" as the vendor calls it. But the sequence of submitting USB transfers by the host and starting capture data transmission on the device differs. The phase of supervising the hardware driven acquisition does not apply. Capture data is immediately streamed to the host after initiating the acquisition. The capture data memory layout dramatically differs. Samples are not compressed, and samples taken at several points in time are kept in the same memory cell. Processing is a little more expensive, bits need more shuffling. Lack of compression makes the acquisition in stream mode heavily depend on the reliability of USB bulk communication. The vendor software assumes a 300Mbps boundary, and also enforces it by disabling channels depending on the samplerate. The sigrok driver accepts any user specified configuration, and merely warns for high amounts of traffic. Local tests successfully communicated 320Mbps. Slow samplerates result in slow arrival of more sample data, which periodically gets flushed to improve usability. Thresholds when to start pushing may need tuning. This implementation was tested with LA2016 and up to 16 channels. Other devices are untested, especially LA1010 which lacks local memory and thus exclusively supports streaming, and devices with 32 channels where capture data memory layout may differ from devices with 16 channels (yet to get verified).
kingst-la2016: move USB bulk transfer handling to helper routines Concentrate all support code which handles USB bulk transfers for the capture data download in a set of helper routines: memory allocation and release, submission and cancellation including re-submission after a previous completion. Submit host side transfers earlier, between the configuration and the start of USB bulk transfers in the device. Allocate transfers and their buffers at the first acquisition start. Keep allocated buffers across several acquisition periods. Relase transfers and their buffers when the device closes. Allocate buffers of fixed size (always 256KiB, no longer depends on the remainder of the currently downloaded capture data). Acquisition stop cancels all currently submitted transfers, and does postprocess their (cancelled) completion without re-submitting. This avoids "spilling" pending transfers into the next acquisition cycle. Name the helper routines in preparation of using multiple transfers. Stick with a single transfer in this commit to simplify review. Use a longer USB receive timeout (500ms for capture data, in contrast to 200ms for control transfers).
kingst-la2016: move capture download details out of USB xfer handling Ideally the USB transfer handling logic and the interpretation of the downloaded capture data would not be as intertwined. The current implementation assumes a rather specific capture model ("normal mode" as it's called in the vendor software), and would not work in streaming mode. Move as many details out of the receive_transfer() routine and into the send_chunk() data processing routine as we can. Which only leaves error code paths and USB transfer re-submission, which get addressed in a subsequent commit.
kingst-la2016: spew pretty FPGA register dump for development support Implement a pretty registers dump, and call it when the FPGA bitstream content gets checked and when hardware controlled acquisition completes. Generate this FPGA registers dump at spew log level, accept a caller provided address range to further reduce verbosity as needed. This is mostly motivated by developer's curiousity. To suport research when previously unknown models are seen. Or to see which other details are available as an acquisition executes. Or to check whether some of the previously written configuration could be read back.
kingst-la2016: unconditionally construct MCU firmware filename Always call the MCU firmware download routine that is implemented in the protocol.c source file when the api.c scan routine executes. But only conditionally load the MCU firmware to the probed device when strictly necessary. This makes filename information available to users since these details are essential for the operation of a device, yet keeps intimate firmware implementation details in the appropriate location in the implementation.