Realtime Functional Reactive Programming
summary
Erlang is ported to RTEMS and runs on the GRiSP/Trisport hardware so developers get 300 MHz CPU and 64 MB RAM usable from Erlang with drivers for Pmods. Scheduling uses an earliest‑deadline‑first scheme, heaps are preallocated and per‑process GC is deferred into a recovery window, and message queues are bounded or dropped to meet deadlines. A 15‑node conveyor prototype with RFID/inductive sensors and stepper drivers actually keeps pellets from falling off in the demo.
AI-written summary · about
chapters (36)
- 0:00Introduction
- 0:32Why do we want realtime
- 3:40Hard realtime
- 5:22Soft realtime
- 6:35Garbage collection
- 10:41Memory allocation
- 12:53Auto restart
- 13:49Scheduling
- 18:05Watchdog
- 19:06Trisport
- 19:32WiFi
- 19:52Connectors
- 20:13ARM CortexM7
- 20:41GPIO ports
- 20:52Switches
- 21:13NOC
- 21:42Debugger
- 21:56Pmode Mods
- 24:31Pmode Demo
- 25:16Software Stack
- 25:50Networking Stack
- 26:05Drivers
- 27:44Stepper Motors
- 31:29Controllers
- 32:38Demo
- 36:00Shipping
- 36:11Wpa2
- 36:28Inverse Port
- 37:14Cross OTP
- 38:11Encapsulation
- 38:56Flow Graph
- 40:03Partial Build
- 40:49Automatic System Startup
- 42:05Protocol Stacks
- 43:10EFL
- 43:54Use cases
related talks
29mWhat is Functional Reactive Programming?
28mReactive Programming on the Bare Metal:A Formal Model for a Low-Level Reactive Virtual Machin
26mFRP and Functional Game Programming
46mFunctional Reactive Programming
24mThread-Safe Reactive Programming
34mReactive Architecture
58mRSocket – new Reactive cross-network Protocol
37mStreaming and event-based programming using FRP and RxJS