Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USBTMC read loop doesn't work when reading entire buffer at once #214

Open
noopwafel opened this issue Aug 2, 2020 · 2 comments
Open

USBTMC read loop doesn't work when reading entire buffer at once #214

noopwafel opened this issue Aug 2, 2020 · 2 comments
Assignees
Labels
bug Something isn't working

Comments

@noopwafel
Copy link
Collaborator

The code in the USBTMC driver to split up a large read into smaller ones doesn't work when you read the whole buffer at once.

For example, consider the case where you read one byte (the case I hit with the DS1000D/E): then bytes_fetched == bytes_requested is true after the first loop iteration (which is not good, it should have terminated). Amusingly, the timeout kind of makes the situation worse, because when the read times out it returns -1, which means m_data_in_staging_buf ends up being zero.

I'm not sure of the 'right' way to fix this, I'm not sure what legacy driver problem the loop is trying to avoid. Locally, I just changed the #if 0 to #if 1, to use the non-workaround code, which works fine.

@noopwafel noopwafel self-assigned this Aug 2, 2020
@azonenberg azonenberg added the bug Something isn't working label Aug 2, 2020
@tomverbeure
Copy link
Contributor

After spending a fair amount of hours with a combination of Siglent scopes, Tek scopes, USBTMC, VXI-11, and GPIB, and the Linux kernel, the only certainty is that the whole ecosystem of test and measurement protocols is riddled with bugs, very much broken, and that the only way to make sure a configuration works is to test that specific configuration and fix things that are broken. However, if you do that in a generic way, chances are high that you'll break other configurations in the process.

The USBTMC kernel driver for older Linux kernels (e.g. the default kernel for Ubuntu 18.04) has explicit work-arounds for Rigol oscilloscopes (see rigol_quirk), The USBTMC driver on my Siglent scope completely hangs when it sees something it doesn't like, such as data packet requests larger than 2032 bytes (only a scope reboot helps), etc.

Weirdness in the code that you're looking at must be seen in that context: my first goal was to get something going that more or less works for my specific configuration, with the hope that others would step in with their configuration to make things better overall.

I wrote down some unstructured notes here: https://github.com/tomverbeure/siglent_remote/blob/master/README.md.

The way forward is probably to have specific command line configuration parameters that allows the user to select this or that code path and hope that things eventually work.

For example, consider the case where you read one byte (the case I hit with the DS1000D/E): then bytes_fetched == bytes_requested is true after the first loop iteration (which is not good, it should have terminated). Amusingly, the timeout kind of makes the situation worse, because when the read times out it returns -1, which means m_data_in_staging_buf ends up being zero.

That looks indeed like a bug. Not sure what I never hit that case.

I have no objections against changing the #if 0 to #if 1 for now.

@noopwafel
Copy link
Collaborator Author

Thanks for the detailed response and the notes! I appreciate having the driver in the first place, being able to fix it by just switching the #if constant is also amazing.

It sounds like a parameter might make sense for now, and then in the longer-term, some kind of quirks system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants