3 ms·

I am an embedded dev and use web technologies for visualization. I don't think anyone said one is more hardcore than the other. 15 years ago web developers were

I am an embedded dev and use web technologies for visualization. I don't think anyone said one is more hardcore than the other. 15 years ago web developers were laughed at, but that changed when it got far more complex. Saying it today is just a signature for your ignorance. Still, there is a huge difference in my opinion. C and Javascript are quite different to write, test, debug and deploy. I have not a deep understanding of web development and don't care much about the latest frameworks or the latest approach to solve something. I just use it for visualization purposes, which are fairly restricted on embedded systems most of the time. Quite the contrary to web solutions. There is a contrast to your average C spin-loop and some exaggerated JS promise chain. Also I think some parts of embedded development are easier, especially bare metal applications. Only static memory allocation for example, predictable common access to shared memory between main loop and interrupt subroutines. On the other hand you don't just execute some unit tests on your machine. You probably need specialized software. The complexity of the system as a whole is far lower than all the monkeys involved in displaying a website. The hardware to use is most often far less general than a webbrowser and you really need to read the manual and system specification of your CPU of choice. Of course embedded systems also include the usual linux box. This kind of embedded development is far more comparable to classical application development. Getting desktop OS to do I/O beyond keyboard/mouse/display comes with its own perils. In practice these systems mostly interface lower level systems that do specific tasks while providing interfaces to networking. All in all these are pretty distinct worlds in my opinion.

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 ago
  Oh, 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?

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 ago
Oh, 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?