On Wed, May 27, 2020 at 10:46 PM Gerhard Sittig <gerhard.sit...@gmx.net> wrote: > Is this covered by the SCPI spec? Thought CR/LF was the canonical > EOL condition, but don't know the spec by heart, so could be wrong.
SCPI-1999 doesn't seem to go that "low level". But it would seem this is covered in IEEE 488.2-1992. Looking the spec "response message terminator" is defined as: NL + ^END NL is defined in the spec as ASCII 0x0A i.e. line-feed (or LF). But it seems bit unclear if ^END could be interpreted as carriage-return (ASCII 0x0D)... [OffTopic: Based on spec it would seem existing sr_scpi_get_string() breaks the spec since it strips "CR" from the response message (if it happens to end in "CR"), which it really shouldn't do (?) since according to spec anything before NL is part of the message....] Would it be acceptable to not squash/collapse arbitrary CR/LF combinations, but just add specific case/exception for "<LF><CR>" at the end of received message? (as "<LF>" and "<CR><LF>" are being squashed already...) Since it would seems like any existing devices that libsigrok is accessing using the "SCPI" code must be always terminating their response message with <LF>, or things would not work... So adding this special case to treat "<LF><CR>" at the end of received data as "<LF>" should not break anything? Or would you recommend going the route of completely separate driver for these GW-Instek bench meters? (extending scpi-dmm driver seemed good choice to avoid having lot of "redundant" code...) -- Timo <t...@iki.fi> _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
