fix corrupted compound command results #127
Conversation
…ONN_COPY Fix corrupted output when using chained queries and single queries with multiple return values. NETCONN_NOCOPY can only be used in cases like *IDN? where the buffer is const, which is used in tests and is probably why it hasn't been discovered. netconn_write() documentation calling NETCONN_COPY "inefficient" may get people to generally avoid it, even if NETCONN_NOCOPY **cannot** be used, as is the case in SCPI_Write(). There would need to be a mechanism either for freeing buffers after use without copying, or one to ensure the corresponding tcp frame has been received by the client. Considering SCPI performance only really matters when low latency is key, or transfer of large amounts of block data is required - while at the same time the target has small amounts of memory and low performance - NETCONN_COPY is the obvious safe choice for this project. "When passed the flag NETCONN_COPY the data is copied into internal buffers which are allocated for the data. This allows the data to be modified directly after the call, but is inefficient both in terms of execution time and memory usage. If the flag is not set then the data is not copied but rather referenced, and the NETCONN_NOCOPY manifest is provided for backwards compatibility. *The data must not be modified after the call*, since the data can be put on the retransmission queue for the connection, and stay there for an indeterminate amount of time."
|
Please keep in mind, that the library itself was never designed with multiple sessions in mind. It can fail hardly in more complex cases. E.g. if you allow two simultanouse clients and one sends in one TCP packet So in my opinion, the only correct way of solving this is to introduce real multi session ability. The easiest approach would be to have multiplle |
|
I've been wondering about possible benefits for multiple sessions. While it's again not an issue with scpi-parser itself but a defect in the example I aim to resolve, a single line* sent in a single session, like
seems to produce garbled output. When sending
no issue is observed, though I haven't tested sending the commands in one go (only consecutively to ensure correct syntax and results). In its current state I believe the server example implementation has no means to manage the buffers it passes to netconn_write(), and its documentation points out that the buffers need to stay valid for an indeterminate amount of time (when kept in the re-send queue). Copying buffers via NETCONN_COPY takes more resources, but I think it's the only legitimate way to use netconn_write() in the current example implementation. Other approaches will need a handler to be called when the tcp packet has been successfully received, or output to be written directly to a TX buffer.
|
|
But, I don't understand the rest of the PR. SCPI specification allows multiple |
The other two commits probably need to be in another branch and require some more thought / a separate PR. This PR can then focus on 9afb267. |
|
So, can you please remove the other two commits so this can be easilly merged? |
MisterHW
force-pushed
the
multiple-commands
branch
2 times, most recently
from
c5c59d7 to
9afb267
Compare
MisterHW
changed the title
|
two commits removed.
will be revisited in another PR. |
When compound commands are used, e.g. in a scenario where the application controls hardware with multiple channels we found that some some parts go missing. *IDN?;*IDN? works, other queries that would return "0;1;2" only return "0;".
fix:
use netconn_write(u->io, data, len, NETCONN_COPY). NETCONN_NOCOPY is not allowed here, as data doesn't stay valid until sending is complete. See https://doc.ecoscentric.com/ref/lwip-api-sequential-netconn-write.html for details.
enhancement:
provide SCPI_ResultCommand() to facilitate prepending results with the command in question.
example: MEAS:VOLT:CH1?;CH2?;CH3?;CH4?:MEAS:CURR:CH1?
reply (prepend on): MEAS:VOLT:CH1,0.123;MEAS:VOLT:CH2,2.048;MEAS:VOLT:CH3,1.337;MEAS:VOLT:CH4,0;:MEAS:CURR:CH1,0.42
reply (default): 0.123;2.048;1.337;0;0.42