Skip to content

v2.10.0

Choose a tag to compare

View all tags
@robdobsn robdobsn released this 25 Oct 11:52
· 22 commits to main since this release
v2.10.0
2acf4a6

raftjs 2.10.0

This release adds device type management to raftjs: building, checking and pushing a Raft device's device type file (records it loads at startup, so devices can be added or changed without rebuilding firmware). It also adds two web apps built on it, more reliable file uploads, and label-keyed device actions. Changes since 2.8.1; 2.9.x wasn't published.

Device type management (new)

  • DeviceTypeFileManager (status, type table, records, pull, push): runs a device's type file, given a RaftConnector.
    • Reads the status, the device's type table and its records (devman/typeinfo ... full=1).
    • pull() reads back the device's file.
    • push() uploads a file under another name, has the device check it, applies it after an optional confirmation, waits for the restart and verifies the device loaded it (CRC and per-entry outcome). It stops if the device already has the file, or if the device's file changed since it was read. There's a dry-run option.
  • buildTypeFile, typeFileCrc: build a type file the way RaftCore's AssembleDeviceTypes.py does, byte for byte, so the device's CRC agrees. Each record is classed as new, override, unchanged (left out) or policy, with where it's decoded and init-code needs. The file carries _sources, a record of what it was made from.
  • mergeDeviceTypeSources, resolveDeviceTypeSelection: read and resolve DeviceTypeSources.json selections with the same rules as a RaftCore build.
  • RaftCoreCatalogue, readGitHubSource, recordsFromFiles, deviceTypeLockText:
    • read RaftCore's published record catalogue (per release, on RaftCore's GitHub Pages site);
    • read git sources on GitHub at the commit a ref resolves to;
    • read local record files;
    • write the lock file exactly as a build does.
  • compileDeviceTypeCommand (the record command grammar) and checkDeviceTypeCode / checkDeviceTypeRecordCode (the decode-code check): GitHub sources with code outside the decode language are refused, as a build refuses them.
  • parseDevTypeJson / writeDevTypeJson: JSON as RaftCore's Python tools read and write it. Key order is kept (JavaScript would move keys like "26" ahead of "12.5"), numbers keep their text, and output matches Python's.
  • DevManTypeFileStatus and DevManTypes fields: raftCore, recordFormat and decode (what the firmware can decode on the device), protected on types a system device expects, and TYPE_FILE_MAX_BYTES_DEFAULT_PSRAM (262144). These need firmware from RaftCore 1.62.0; older firmware omits them.

All of this is tested against test vectors shared with RaftCore's Python, so the two stay in step.

Apps

  • Device Types (apps/devtypes, published at https://robdobsn.github.io/RaftCore/devtypes/app/):
    • browse and search RaftCore's records (by name, manufacturer, class or I2C address);
    • connect to a device by Bluetooth or USB serial, and see its devices, unidentified addresses and type table;
    • build a type file from RaftCore's records, GitHub sources and local files (or a project's imported DeviceTypeSources.json and lock), push it, and read it back;
    • download the setup as a project.
  • Raft Flasher (apps/flasher): flash a Raft build to an ESP32 over USB from Chrome or Edge.
    • It reads flasher_args.json as raft flash does, or an ESP Web Tools manifest, and shows the partition table and app version.
    • It checks image sizes and the chip, offers everything, firmware only, or file system only, and verifies each image by MD5.
    • It will be published at https://robdobsn.github.io/RaftCore/flash/ once RaftCore's Pages workflow is updated.
  • Dashboard:
    • the device type file panel uses DeviceTypeFileManager (check, apply, wait for the restart, verify, download);
    • a touch strip visualizer (vt: "touchstrip") for 1D multi-touch sensors such as the Trill Flex.

File uploads

  • Recovery from lost blocks: each batch is sent from the latest ack. Acks arriving while a batch is going out count, and late acks behind one already received are ignored.
    • With RaftCore's in-step acks, an upload that loses blocks mid-batch no longer waits for the device's 1 s timer ack each time. In a simulated test, 200 blocks with 6 lost took 5.4 s instead of 12.9 s.
  • WebSocket: uploads ask for 4000-byte blocks (were 500). The device's reply still decides the size. On an ESP32-S3 writing to SD card this was about 1.8x faster (52 KB/s against 29 KB/s with 800-byte blocks).

Device actions

  • Map actions can use label keys (e.g. Trill _conf.mode: centroid/raw/..., ENS160 mode, QwiicButton LED: off/on/breathe). Before, the dashboard parsed every key as a number and couldn't send these.
  • Only _conf.rate goes through setSampleRate(); other _conf.* map actions write their mapped value.

Upgrading

  • sendAction takes Array<number | string> (was number[]), in both DeviceManager and the RaftDeviceMgrIF interface. For a map action, pass the map key, which may be a string. Callers passing numbers are unaffected. A class implementing RaftDeviceMgrIF must widen its sendAction parameter type.
  • _conf.* map actions other than _conf.rate used to go through setSampleRate(); they now write their mapped value directly.
  • Firmware fields: the new DevManTypeFileStatus fields are optional. With older firmware they're absent and everything else works.
Assets 2
Loading