Skip to content

Firmware

Status: prototype. This is new and incomplete: its commands, files and behavior may change or be removed in any release.

termapy ships the device-side sources a monitor compiles in to speak its protocols, so getting them is one command, not a trip to the repository. /firmware lists what ships; .copy writes it into your tree.

Target Language Files Guide
mem C termapy_mem.c, termapy_mem.h Memory
json C termapy_json.c, termapy_json.h JSON integration
/firmware                          what ships: target, language, files, size
/firmware.copy                     every module of the shipped language into the config's firmware/
/firmware.copy lang=c              the same, naming the language
/firmware.copy mem folder=fw       one module into fw/ under the config's folder, created if missing
/firmware.show json                open termapy_json.c in the system viewer
/firmware.dump mem termapy_mem.h   print one file to the terminal

A module's files follow its language: in C a module is a .c and its .h, so mem is termapy_mem.c and termapy_mem.h; a language with one file per module ships one. Like everything termapy writes for a config, the copy lands in that config's folder: its firmware/ by default, and a relative folder= is under the config's folder too, never wherever termapy was started. An absolute folder= puts it in your firmware project instead; over MCP that needs host-wide file access. The reply names the full path. .copy never overwrites: a file already in the folder fails the whole copy before anything is written, so a module you have edited stays yours. lang= names the language when the sources ship in several; today everything ships in C, so it is never needed. Over MCP, /firmware.dump is how an agent reads a source: the file's text is the command's value.

Each module is strict C99 with no dependency beyond the standard headers. The suite compiles both against a host harness (tests/test_firmware_mem.py, tests/test_firmware_json.py), so the shipped source is the tested source.