This crate attempts to implement the IEE488.2 / SCPI protocol commonly used by measurement instruments and tools.
- IEEE 488.2
It does not require the std library (ie it's
no_std compatible) or a system allocator (useful for embedded).
API is unstable (as of 0.2.*)
The crate does not support any transport layer, it only reads ascii-strings (
[u8]) and writes ascii responses.
It does not implement any higher level functions/error handling other than SCPI parsing and mandated registers/commands(optional).
Using this crate
scpi to your dependencies:
The API is still work in progress so the minor version should be specified.
These features are by default turned OFF.
extended-error- Allows extended error messages of the form
<error code>, "error message;extended message". Requires more data and program memory.
std- Use std library, note that libm feature can be disabled with std.
These features are by default turned ON.
unit-*- Creates conversion from a argument [and suffix] into corresponding uom unit. Disable the ones you don't need to save space and skip uom.
Look at the
example for how to create a tree and run commands.
SCPI is strictly ASCII and will throw a error InvalidCharacter if any non-ascii
(>127) characters are encountered (Exception: Arbitrary data blocks).
This library uses ASCII
[u8] and not Rust UTF-8
to/from_bytes() to convert in between them.
String/arbitrary-block data may be converted to str with the try_into trait which will throw a SCPI error if the data is not valid UTF8.
Context::run(...) function aborts execution and returns on the first error it encounters.
Execution may be resumed where it aborted by calling exec again with the same tokenizer.
User commands will often use functions which may return an error, these should mostly be propagated down to the parser by rusts
The documentation often uses the term 'throw' for returning an error, this should not be confused with exceptions etc which are not used.
Limitations and differences
These are the current limitations and differences from SCPI-99 specs (that I can remember) that needs to be addressed before version 1.0.0. They are listed in the rough order of which I care to fix them.
- Response data formatting, currently each command is responsible for formatting their response. Done
- Better command data operators with automatic error checking. TryInto and TrayFrom traits are implemented for Integer, float and string types
- Automatic suffix/special number handling. Supports all SCPI-99 simple suffixes and decibel
- Provide working implementation of all IEEE 488.2 and SCPI-99 mandated commands. All IEEE488.2/SCPI-99 mandated commands have default implementations.
- Quotation marks inside string data, the parser cannot handle escaping
"inside their respective block (eg "bla ""quoted"" bla"). The parser properly handle
""but it's up to user to handle the duplicate
- Expression data, not handled at all. Supports non-nested numeric-/channel-list expressions
- Provide a reference instrument class implementation
- Error codes returned by the parser does not follow SCPI-99 accurately (because there's a fucking lot of them!).
- Working test suite. Better than nothing I suppose
Nice to have
Not necessary for a 1.0.0 version but would be nice to have in no particular order.
- Double-precision float (
Contributions are welcome because I don't know what the fuck I'm doing.
example- A simple example application used for testing
scpi- Main library
scpi_derive- Internal macro support library, used by
scpito generate error messages and suffixes (enter at own risk)
This project is licensed under the MIT License, see LICENSE.txt.