Crates.io | trenchcoat |
lib.rs | trenchcoat |
version | 0.5.1 |
source | src |
created_at | 2022-10-29 16:53:59.926699 |
updated_at | 2022-11-14 03:56:59.681294 |
description | JavaScript-ish virtual machine for embedded, LEDs, hot code reload, etc. |
homepage | https://github.com/spookyvision/trenchcoat |
repository | https://github.com/spookyvision/trenchcoat |
max_upload_size | |
id | 701100 |
size | 1,138,897 |
A questionable combination of JavaScript (in syntax), FORTH (in spirit) and MicroPython (in terms of scope and being a wild mix of weird and kinda cool).
$deity
, why?esp32-idf
image size and thus turnaround time can be a bit of an obstacle.This is the live code editor (observe changes to the hsv(...)
call in the last line) + in-browser rendering, alongside hot code reload sent to a no_std
,no_alloc
microcontroller.
extremely fast turnaround, no noticable delay between code change and web app/mcu update
Care has been taken to keep runtime platform, language and language dialect generic. This means:
trenchcoat
on a PC, a microcontroller, or in the browser.for
loops? Maybe in the next release…heapless
collections, and those are unfortunately wasteful for the trenchcoat
use case.
Therefore as of version 0.5
even the no_std
STM32F4 app uses an allocator instead. no_alloc
support might be removed at some point, but it's kept around for now.Right now the main goal is getting pixelblaze support to mature, so that's also what these instructions will focus on.
The general approach is:
res/
, though as of version 0.5
only rainbow melt.js
is verified to work - lots of implementation details are still missing!console-compiler
to compile bytecode to disk (.tcb
for "TrenChcoat Bytecode" is a suggested file extension) and "somehow" have your firmware access it, e.g. via include_bytes!
. If you want to update via http but your mcu is connected via UART (e.g. the bundled stm32f4-app
), launch http-to-serial.py /dev/YOUR-SERIAL-DEVICE
as a bridge.Executor
, start()
it once and call do_frame()
as many times as you wish to produce LED colors. On no_std
, "current time" needs to be advanced manually from some timer source (the example app reuses the frame task's scheduling interval). Executor::exit()
is optional.Feature flag sets to pick:
["full"]
["compiler", "log", "use-std"]
["defmt"]
or ["defmt", "alloc"]
when you have an allocator
std
support): ["log", "use-std"]
(note: logging is entirely defunct at the moment until I fix the macros)
probe-run
setup.f4-peri
crate; you can also use SPI1+PB5 by using the spi
feature instead of the default spi_alt
. f4-peri
also supports the SK9822/APA102 protocol if you prefer a more stable LED.cd console-compiler
cargo run -- -f pixelblaze -i ../res/rainbow\ melt.js -o "../res/rainbow melt.tcb"
cd ../stm32f4-app
# probe-run is required
cargo rrb app
at this point you can either send the .tcb
data over via cat ../res/rainbow melt.tcb > /dev/<USB UART>
, or spin up the web code editor & python web-to-uart bridge for live editing fun!
try increasing HEAP_SIZE
in src/bin/app.rs
.
Package directory: esp32-c3-app
You need a working Espressif native toolchain installation - more details here.
copy config.toml.example
to config.toml
and edit your wifi & LED settings. The current firmware supports WS2812 and APA102/SK9822 LED protocols via features ws2812
(data pin only) and apa102
(clock and data pins) respectively.
Build, flash and run using cargo espflash --release --monitor /dev/<ESP UART HERE> --features WS_OR_APA
. The station (device) IP will be printed on successfully joining the wifi network. Put this IP in the web app config.toml
list of endpoints=
and start the web app (or use console-compiler
& curl
to POST new bytecode to http://<station ip>/
).
Should not be too much work to port since the C3 app uses esp-idf
, any takers?
TODO, up next!
(a cool bear spawns from an adjacent universe)
cool bear: Browser? As in ... you're running a rudimentary JavaScript virtual machine ... in the browser ...
author, in straightjacket: you got that exactly right. With no performance-boosting offload support whatsoever!
On the bright side, we don't need a separate compilation step as part of our build. Because the compiler also runs in the browser, muahahaha
on every change to the code editor window, the web app tries to compile the source to bytecode and broadcasts it to all configured endpoints.
Copy web-app/config.toml.example
to web-app/config.toml
and set:
endpoints
: list of bytecode recipients - http://localhost:8008/
is the listen address of http-to-serial.py
in case your target does not have its own web server. Note: if you build your own web server, it must offer at least minimal CORS support (see http-to-serial.py
for further details)pixel_count
: number of LEDs to render in-browserinitial_js_file
: initial contents of the editor window, populated via build.rs
dioxus-cli
to run.cargo install --git https://github.com/DioxusLabs/cli # their stable version seems broken atm
cd web-app
dioxus serve
$browser http://localhost:8080/
log
/defmt
) logging macros courtesy of dirbaio and whitequark