Bug 789 - sr_scpi_send_variadic() adds a terminating newline for all transports, even when it is not required
Summary: sr_scpi_send_variadic() adds a terminating newline for all transports, even w...
Status: CONFIRMED
Alias: None
Product: libsigrok
Classification: Unclassified
Component: Other (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-01 10:33 CEST by mrnuke
Modified: 2016-05-01 15:47 CEST (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mrnuke 2016-05-01 10:33:59 CEST
commit 055804e89ea0f6b4145040a0eeb2f4e6951692fe changed the behavior of the SCPI backend to add a terminating newline to every command.

Actual behavior:
This has two negative side-effects:

1) Debug prints now have a superfluous newline:
sr: [00:00.158694] scpi_gpib: Successfully sent SCPI command: 'VOUT?
'.

2) The terminating newline is not needed on all transports (e.g. GPIB). Some GPIB instruments behave subtly different when encountering linefeeds. For example, the HP 3457A will hold the GPIB bus, which causes causes noticeable slow-downs on a GPIB bus with more than one device.

Expected behavior:
It is left up to the individual transport driver to decide whether or not to add terminating characters.
Comment 1 Stefan Brüns 2016-05-01 15:47:46 CEST
(In reply to comment #0)
> commit 055804e89ea0f6b4145040a0eeb2f4e6951692fe changed the behavior of the
> SCPI backend to add a terminating newline to every command.
> 
> Actual behavior:
> This has two negative side-effects:
> 
> 1) Debug prints now have a superfluous newline:
> sr: [00:00.158694] scpi_gpib: Successfully sent SCPI command: 'VOUT?
> '.

The debug output should escape any non printable characters. SCPI allow to transport binary data.

> 2) The terminating newline is not needed on all transports (e.g. GPIB). Some
> GPIB instruments behave subtly different when encountering linefeeds. For
> example, the HP 3457A will hold the GPIB bus, which causes causes noticeable
> slow-downs on a GPIB bus with more than one device.

Actually this should be made a device specific parameter. There are GPIB devices, e.g. from Anritsu, which need a TermChar as these ignore the EOI line.

Can you clarify what you mean by "hold the GPIB bus"? A compliant device *should* terminate reading and start processing if it sees a) the termination character, b) an asserted EOI line, c) both at the same time.