4 ms·
(author here) Thanks for reading. Fully agree on web being both more forgiving, and ultimately more complex than embedded development. I do think however that
by larve 4y ago
(author here)
Thanks for reading. Fully agree on web being both more forgiving, and ultimately more complex than embedded development.
I do think however that a C-spin loop can benefit from knowing JS promise style. One of my proudest libraries is a monadic task system based on futures, that handles cancellation, introspection, error handling and user interaction, in a static memory constrained system. It makes some more complex interactions like:
- move the motor until the limit switch is hit
- if the limit switch is not hit within 15 seconds, activate the fan for 5 seconds
- if the motor controller fails to respond, then activate the fan but show a red LED
- if at any point the temperature sensor goes above 30C, interrupt the motor moves by slowing down the motor first
- if at any point the user cancels, turn on the fan before slowing down the motor to a stop
This makes for a mad state machine, but is actually not that complex in a task kind of write up.
I plan to write much more about this topic, including the fact that embedded is a lot of "library" work (managing datasheets and different architectures and sensor versions and register locations), while web work can be a lot of "keeping up with the joneses" (in terms of UX, frameworks, cloud tech, etc...).
- raxxorraxor 4y agoOh, I agree. It would be nice if state was encapsulated for the respective tasks. Other routines don't need some global state to read the limit switch of similar non-related sensor inputs. Do you have that library published somewhere?