You'd be even more impressed if you saw just how little resources they have to use (ram, storage, cpu), or how old of a C standard they have to work with. I have a few friends that work on this.
You'd be even more impressed if you saw just how little resources they have to use (ram, storage, cpu), or how old of a C standard they have to work with. I have a few friends that work on this.
I am indeed impressed but not at all surprised considering what we used to get to the moon!
Seems like Java is popular at Garmin.
And also — sadly — Monkey C. I cannot imagine what possessed them to invent their own scripting language for wearable device apps. It's sort of like JavaScript but worse and with minimal third-party tooling support.
https://developer.garmin.com/connect-iq/monkey-c/
it kinda sucks, but with the constraints it's at least understandable. they wanted an extremely lightweight language with a bytecode VM which could be ported to whatever MCUs in 2015, while also strictly limiting the functionality for battery usage reasons (and, uh, product segmentation/limiting third party access).
These days I'd say "sounds like wasm" but I guess 2015 was a bit before that took off.
There have been enough bytecodes since UNCOL in 1958 to chose from, and embedded is full of them, nothing special about WASM.
Sounds like p-code.
While I might not trust C code more than Java in life saving equipment, I would trust a median C developer over a Java one.
Given the amount of CVEs that would be a bad bet.
High integrity computing is full of pain staking processes, exactly because no one trusts C developers to do the right thing.