This crate attempts to implement the IEE488

2 / SCPI protocol commonly used by measurement instruments and tools

scpi

This crate attempts to implement the IEE488.2 / SCPI protocol commonly used by measurement instruments and tools.

  • SCPI-1999
  • 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.*)

Scope

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

Add scpi to your dependencies:

The API is still work in progress so the minor version should be specified.

Features

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.

Getting started

Look at the example for how to create a tree and run commands.

Character coding

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.

Error handling

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.

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 ' 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

Nice to have

Not necessary for a 1.0.0 version but would be nice to have in no particular order.

  • Double-precision float (f64) support.

Contribution

Contributions are welcome because I don't know what the fuck I'm doing.

Project organisation:

  • example - A simple example application used for testing
  • scpi - Main library
  • scpi_derive - Internal macro support library, used by scpi to generate error messages and suffixes (enter at own risk)

License

This project is licensed under the MIT License, see LICENSE.txt.

Versions

Find the latest versions by id

Information - Updated Jun 19, 2022

Stars: 17
Forks: 1
Issues: 0

Repositories & Extras

rust_embedded_starter

Boilerplate für Embedded Entwicklung mit Rust mit Flash und Debug automatik

rust_embedded_starter

Embedded rust HAL (hardware abstraction layer) for the STM32WL

This is a work in progress, it is unstable, incomplete, and (mostly) untested

Embedded rust HAL (hardware abstraction layer) for the STM32WL

Embedded Rust Template

This template is based on stm32f4xx-hal

Embedded Rust Template

A Rust embedded-hal HAL for all MCUs in the STM32 F7 family

This crate is largely inspired by the awesome work done here:

A Rust embedded-hal HAL for all MCUs in the STM32 F7 family

For use with the AnyLeaf pH and RTD sensors in Rust on embedded systems, and...

For use with the AnyLeaf pH and RTD sensors in Rust on embedded systems, and single-board computers

For use with the AnyLeaf pH and RTD sensors in Rust on embedded systems, and...

An embedded rust no_std driver for the AHT20 temperature and humidity sensor, forked from Anthony...

An embedded rust no_std driver for the AHT20 temperature and humidity sensor, forked from Anthony Romano's docs

An embedded rust no_std driver for the AHT20 temperature and humidity sensor, forked from Anthony...

embedded-rust-H2AL

Hardware abstraction layer - abstraction layer

embedded-rust-H2AL

cargo-pio = Cargo + PlatformIO

Build Rust embedded projects with PlatformIO!

cargo-pio = Cargo + PlatformIO
Facebook Instagram Twitter GitHub Dribbble
Privacy