Ols improvements 2024 part1 #251
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On my unit with Demon Core v3.07, I don't see a stage-dependent delay. Thus, set the delay so that in my tests, the trigger point lines up with the edge of a test signal.
Because in RLE mode, we don't know how many samples we could read. The limit that we tell the hardware is only the limit in number of compressed samples, not the number of uncompressed samples.
The number of samples to be received is pretty clear if no RLE is being used. But if RLE is being used, the number of raw samples must be counted. For now, read samples until we time out. This should work for RLE and non-RLE, but may break if the device is connected via a high-latency network connection.
If the devices times out during a transfer, it can be that num_samples is smaller than trigger_at_smpl.
In my experiments, this helped when not all data was read from the device. Otherwise, sigrok-cli would just hang.
cnt_samples_rle was larger than num_samples in RLE mode. Instead of correcting that, use num_samples instead.
Previously, sample_buf_size was reset at a different time than the sample buffer itself. Reset both at the same time for consistency.
…of 4 The exact number must be known when reading data so that we can read the right number of samples without incuring a timeout penalty.
Even with RLE enabled, we know how many samples to expect: Exactly the configured number, no less, no more. Thus, when that number is received, begin processing immediately. Also, put a warning so that we can get to know if the calculation is off. Since this works, the timeout can be bumped to provide for better usability if the logic sniffer is used over a slow network connection.
We're talking about 20 kB, so there's little need to go back to the event loop in between. But there's also no reason why we should go back to the event loop if we can read more data immediately.
Why just read a single byte when you can read a whole sample?
Due to the nature of RLE, the number of samples from the start to the trigger point is unknown. What is known is that the hardware triggers still records a given number of raw samples to its sample memory. When reading and expanding these raw samples from the back (remember, OLS sends the recording back-to-front), remember the expanded sample position from the back and then map it back to the right position from the front once the total number of expanded samples is known.
Draft
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Assorted changes to the OpenBench Logic Sniffer driver: