Home

A command/response system for controlling microcontrollers

Current status: In development
Current version: To be announced

---

What is Zscript?

Zscript ("zed-script", and formerly Zcode) is a simple text-based command/response system, designed to make it easy to control microcontrollers (MCUs) over various communications protocols, eg ethernet, serial ports or I2C. It is loosely inspired by G-code, the control language used by many automated machine tools.

---

What's so special?

• Simple syntax - requests and responses are designed to be reasonably straightforward to use and understand, for both human- and computer-generated commands.

     # Set pin 4 to HIGH, and receive Status response OK to confirm
     Z42 P4 V1
     !S
  

• Modular and extensible - commands are implemented as modules, with space for user-defined commands. Standard modules include I2C, UART, SPI, USBC-PD. Modules defined declaratively in YAML.

• Client libraries, in Java (and Python, to come) - generated from declarative modules.

    commPortConnection.send(PinsModule.digitalWrite()
        .setPin(4)
        .setValue(1)
        .build());
  

• Embedded scripting - Zscript programs can be compiled in or loaded onto the device dynamically, to run in the background or in response to triggers.

• Introspection - device capability and version info is available

• Small, efficient and configurable - you can remove features and modules so you don't pay for what you don't use.

• Device addressing - Zscript commands can be tunnelled from one device to another over serial, I2C etc.

    # Send echo command to device using I2C (module 5) bus 1 address 0x62, and receive response.
    @5.1.62 Z1 A2
    [email protected] A2 S
  

• Portable - implemented on ARMs and Arduinos, with PICs to come soon.

• Interactive - simple REPL (read-eval-print-loop) supported.

---

Purpose

Zscript makes it really easy to try out your hardware, and then control it from another computer. This helps with:

• Interactive experimentation and prototyping:

  • you can try out talking over buses or reading/setting pins while you get everything right.

• Service-based approach:

  • define custom operations as commands in user-defined modules, and treat them as hardware services invoked by a command system. It's RPC for hardware.

• Testing:

  • you can capture command sequences as scripted tests, and run them for conformance / regression testing.

Further resources

• Development log