The Meta / Goals / Tasks / Bugs Issue

[ryankurte]

see also: https://github.com/orgs/embedded-wasm/projects/4

Goals

Enable cross platform / platform independent embedded application development by providing a common WASI/WITX API for WASM on embedded systems along with runtimes, engines, and supporting libraries to make it super easy to write / alter / mess with embedded devices.

Disclaimer

Everything here is very much a work in progress, we're almost at a point this can be used for simple tasks, but, there's still a lot to do so expect breakages, bugs, and other misadventures (and much of this still only exists in @ryankurte's head)

If you're interested in contributing we'd be chuffed to receive PRs or issues!
Over the longer term we will move this project to a community maintainership model similar to rust-embedded, however, as we are task-rich and time-poor we will operate as a (hopefully) benevolent dictatorship until churn has dropped to manageable levels.

If you are interested in playing with this or contributing you might like to check out the book.

Components

APIs

Low-Level Driver APIs (WASI)

Low-level APIs correspond to physical peripherals in embedded systems, supporting the development of drivers and interaction with the physical world, defined here in embedded-wasm/spec.

• SPI
• I2C
• GPIO
• TIMER - Define Timer API #3

High-Level Driver / Platform APIs (WASI)

High Level / Platform APIs are intended to allow applications to be platform independent and support networked communication

• DISPLAY - abstract interaction with display devices (+ touch / buttons?)
  Define Display API #4
• LED - abstract interaction with LED strings / matricies
• Device/Peripheral - inject peripherals / configuration into application objects to decouple applications from their physical platform
• Publish/Subscribe - publish and subscribe to data / sources, supported by the platform (backed by MQTT, CoAP, etc.)

Management APIs (IP, USB)

External APIs should support interaction with WASI/Embedded capable devices, including discovery, configuration and app loading, and logging from applications.

• Device Discovery - locating embedded wasm capable devices
  (mDNS definitions)
• Application Loading - pushing applications to these devices
  (probably HTTP/WebSocket so we can run browser-based compilers)
• Application Logging - receiving application updates
  (also HTTP/WebSocket for browser adventures, though something rsyslog compatible would also be desirable)

For non-IP use i've also been working on https://github.com/ryankurte/ghostfat for file-based loading of applets into memory, and planning to use this on the nrf52 platform.

Application Manifests

Manifests will provide information about an application, describing hardware requirements to runtimes so applets can be wired and executed on different platforms.

Manifests are currently an early draft / expect this section to be expanded (and based on https://github.com/ryankurte/fwsig)

Runtimes / Engines / Drivers

• wasmtime (rust / linux)
• wasm3 (C / anything)

Platforms

• wasm-embeded-rt (linux)
  • Linux drivers
  • Mock drivers
• esp32-wasm (based on [ryankurte/esp32-pal](https://github.com/ryankurte/esp32-pal, ryankurte/esp32-wasm-base)
• samd52-wasm - USB disk for loading + serial port for logging?

HALs

• Rust
• AssemblyScript
• Go?
• MicroPython?
• C?

Tasks

• Move to generated bindings for the HALs (basically blocked on the stability of a WITX spec, see also: Compatibility with WASI's (ephimeral) specs jedisct1/witx-codegen#8)
  • Update wasm-embedded-hal to generated bindings hal_rs#1
  • Update hal_as to generated bindings hal_as#1
• Move to / find / build a generator for wasm3 / C library
• Automate testing / CI for hals / runtimes / etc.
• Move wasmtime components from rt to rt_wasmtime
  Port wasmtime components from rt rt_wasmtime#2

Bugs

• Return codes for generated wasmtime bindings not passed correctly, use rt_wasm3 for now
  Incorrect return codes from wasmtime bindings rt_wasmtime#1

Improvements

• Refactor / Rework WITX specs / sort out generation so we can use these as canonical definitions in different languages (at the moment only wasmtime uses interface generation)

Questions

Would it be better to run a syscall-style API (with one or two methods that take instructions and objects) than the current wide-surface one?

this would be easier to implement in different runtimes and likely more reasonable for supporting sync/async with a common interface, however, it is important unclear how well defining objects works with WITX etc. (though to be fair, interfaces are also not super workable).

i think this is probably a worthwhile refactoring, but needs more exploration. for context see the draft syscall-experiment branches, everywhere.