This crate attempts to implement the IEE488.2 / SCPI protocol commonly used by measurement instruments and tools.
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).
Add scpi to your dependencies:
[dependencies]
scpi = "0.x"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.arbitrary-utf8-string- Allows UTF8 arbitrary data block,#s"Detta är en utf8 sträng med roliga bokstäver. Checked by the parser and emits a InvalidBlockData if the UTF8 data is malformed. This is not a part of the SCPI standard
These features are by default turned ON.
build-info- Includes build info in the library and creates aLIBrary[:VERsion]?command macro to query it.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 str, use 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.
The 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 ? operator.
The documentation often uses the term 'throw' for returning an error, this should not be confused with exceptions etc which are not used.
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
'and"inside their respective block (eg "bla ""quoted"" bla"). The parser properly handle''and""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
Not necessary for a 1.0.0 version but would be nice to have in no particular order.
- Double-precision float (
f64) support.
Contributions are welcome because I don't know what the fuck I'm doing.
Project organisation:
example- A simple example application used for testingscpi- Main libraryscpi_derive- Internal macro support library, used byscpito generate error messages and suffixes (enter at own risk)
This project is licensed under the MIT License, see LICENSE.txt.