VAvanderZwan·Sep 17, 2017
> The tooling is nearly always C, so it's interesting to see Rust moving into this space. Memory management is not so much of an issue, but multitasking correctness is; perhaps there will be some new micro-RTOS framework with provably correct interrupt handling.
Give Céu a look[0]. It was specifically designed for embedded computing, and compiles to C, making it very easy to interface with existing libraries. It requires no manual memory management, and has very nice structured synchronous reactive concurrency primitives.
(EDIT: I realise that multitasking and concurrency aren't quite the same thing; it also has experimental interrupt support though)
Here's a made-up example for Arduino (for which it has support out of the box[1]). It creates two concurrent fading LEDs at different frequencies, and resetting at the push of a button:
#
Read the rest
include "arduino/arduino.ceu"
input int PIN_02; // button input
output int PWM_05; // LED outputs, remember that pins 5 and 6
output int PWM_06; // have a higher PWM frequency on the UNO
// a code block that concurrently fades an LED in and out
// `pin` the output pin of the LED
// `min` min value of the fade
// `max` max value of the fade
// `delay` number of milliseconds to wait between increasing/decreasing `analogWrite`
code/await Fade_forever(var u8 pin, var u8 min, var u8 max, var uint delay) -> void do
loop do
var int i;
loop i in [min->max] do // fade in loop
if pin == 5 then
emit PWM_05(i);
else/if pin == 6 then
emit PWM_06(i);
end
await delay ms;
end
loop i in [min<-max] do // fade out loop
if pin == 5 then
emit PWM_05(i);
else/if pin == 6 then
emit PWM_06(i);
end
await delay ms;
end
end
end
loop do //endless loop
// if *any* of these three code blocks (trails) end, all of the remaining trails in
// a `par/or` are aborted and code resumes (in this case, the loop restarts).
// By comparison, a `par/and` construct would require *all* of the trails to
// terminate before continuing.
par/or do
await PIN_02; // .. meaning that if a button is pressed, we reset the loop
with
// fade the LED at pin 5 quickly between 64 and 192
await Fade_forever(5, 64, 192, 5)
with
// fade the LED at pin 6 slowly between 0 and 255
// note that because it fades over almost twice range (255 vs 128)
// but not exact, it's around eight times slower, not four, and it
// will slowly go out of sync.
// We can push the button to reset however!
await Fade_forever(5, 0, 255, 20)
end
[0] http://ceu-lang.org/, http://fsantanna.github.io/ceu/out/manual/v0.20/
[1] https://github.com/fsantanna/ceu-arduino