I don't think this is broken in user space. The problem is that when you issue
a measurement command it is not known how many bytes it will return. This is
probably due to ASCII output being very common in T&M devices instead of raw
data (int, float etc). The ASCII formatting is done in the device and this
returns just a string which may or may not be terminated by the term char.
This is of course not true for all T&M devices, but the majority works this
way.
I admit that the above produces a lot of overhead, but it's just a fact that
T&M devices work this way, including ours for most of their data processing
(not all though).
I think the USBTMC spec is quite clear on how it should be implemented on
messaging level. Basically when you issue the command "*IDN?" the device
will process this and return the device ID string. The length of this string
is set in the TransferSize of the 12 byte header that the device returns. The
problem when you issue a read command is that the read command does not yet
know how much data to expect. It should issue the REQUEST_DEV_DEP_MSG_IN
first and set the TransferSize value high enough.
In the USBTMC_488 extension you find an example (chapter 3.3.1 page 7) that
shows the REQUEST_DEV_DEP_MSG_IN TransferSize being set to 64 although the
actual data being returned from the device is less (only 36 bytes).
What you do see in practice is that when someone would issue a read command
and asking for less bytes than are available is that the user program may
handle this as a warning telling the user that he did not request all
available data.
Stefan's driver works exactly the way I would expect from a users point of
view. Whether the implementation can be improved is another issue, but the
behaviour is correct and compliant with other usbtmc drivers on other
platforms.
Regards,
Marcel
--
