I've written about the same comparison, but came to a somewhat different conclusion. In my experience Embedded Software development was poor preparation for my later distributed-systems work (I wrote Embedded Software for 10 years, then distributed databases and logging analysis systems for the next 10). Embedded software is so deterministic compared to large-scale systems.<p><a href="https://www.philipotoole.com/a-prayer-for-distributed-systems-developers/" rel="nofollow">https://www.philipotoole.com/a-prayer-for-distributed-system...</a><p>"The idea of monitoring the responsiveness of a read-modify-write cycle is obviously nonsense from a programmer’s point of view (though not so for the microprocessor designer!)."
What the author fails to comment upon is the sheer breadth of embedded applications and focuses almost exclusively on IOT to prove a point about distributed systems (which he does quite well at a medium-high level). The analogy falls apart pretty quickly when you compare webdev to a safety critical system with hard real-time guarantees. Such a system may not have a viable logging framework due to deployment location or security reasons. From a 10,000 foot level I agree with the premise, but I think the title fails to explain the real topic: "similarities between embedded IoT and web development"
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.<p>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.<p>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.<p>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.
I am not convinced. The strongest point to me seems that in a high level views these are both distributed systems, which have to react and interact in real time.<p>On some very rough level significant similarities exist. But I think it is much rather the case that <i>a certain kind</i> of web development is like <i>a certain kind</i> of embedded development.
Web development is a very wide field and so is embedded development. And for very many parts they are very different.
If you are writing your own OS and you have your own scheduler, carefully saving registers before jumping to the new stack pointer, you are doing something no web developer would ever do.<p>The systems are similar on an abstract level, but in the realities of the details they heavily diverge. And this is not very surprising, I think. Afterall the only reason software is useful is because allows abstraction, which allows for generalization.
As someone who cut their teeth in embedded before going into web development, I've seen a significant amount of similarities between the two. The most obvious to me is that now we spend a lot of time connecting prebuilt libraries together - back in the day we wrote everything from scratch. The skills required to interface to a bluetooth library are not any different to say connecting to a map API on a web page... if it all works and does what it says in the docs. At some point your core skills and experience are required in the specific domains to identify and fix bad behaviour (i.e. your bluetooth library isn't working because you have physical antenna issues etc).<p>There is also a large amount of crossover as embedded gains more resources. Often you're working with javascript because your device needs to have an embedded web server with custom functionality. Sometimes you see SQlite on embedded flash, although debatable if they really needed it. Running Linux is far more common and it works pretty much the same regardless if it's on an MCU or a VM in the cloud.<p>The main difference I see is to do with the ease of fixing mistakes in the field. With web development I can usually git push and the issue is fixed for all users. With embedded, I almost never have an internet connection so it's a case of physically sending people to site or product recall to fix the issue if it's serious. Internet connections are becoming more common in embedded so we can remote update, but still the minority in general.<p>Lots of common ground, but just like any discipline it's that last 20% that makes the difference.
I have been thinking on these lines or more specifically; <i>a generalized application of distributed architecture techniques</i> ever since i came across Roman Obermaisser's book; <i>Event-Triggered and Time-Triggered Control Paradigms.</i> and <i>exposure to ideas from the Erlang language/system</i>. From the pov of <i>architecting the structure of the system</i> there are some similarities between Web and Embedded systems but it is at a high abstract level rather than specifics. The key is to understand the difference between <i>Federated</i> (most Web systems) and <i>Integrated</i> (most Embedded systems) and how they directly affect Reliability, Fault-Tolerance, Latency etc. system parameters. It is also the case that due to a low-barrier to entry for Web Development there is a lot of <i>Incidental/Accidental complexity</i> in it which is not the case for Embedded Development (i.e. less forgiving). It would be interesting/educational to do a <i>Commonality-Variability Analysis</i> between the two types of Systems and learn lessons which are more generally applicable.
First,
Thank you for this article.<p>I think embedded system engineers should be more open to learn from other programming domain and try to catch the good things to apply it in the embedded world.
For sure there is some specific constrainsts in the embedded world limiting the usage of web tools. But I agree with you at a system point of view there is a lot of similarities and we could solve a lot of problems by applying the same strategies.<p>I'm an embedded system engineer specialist on robotics. Each robot I worked on have multiple boards (my personal record is 35 boards). Scaling a system like that is an absolute nightmare.
That's why I'm now working on an open-source microservice orchestrator dedicated to critical real-time embedded systems. The concept is to follow the metodologies used to scale complex web applications thanks to a tool able to deal with embedded system specificities.
You can find my Luos lib here : <a href="https://github.com/Luos-io/luos_engine" rel="nofollow">https://github.com/Luos-io/luos_engine</a>
Let me know what you think about it.
Depends a bit what is meant by embedded.<p>On the higher levels of embedded Linux there can be a grain of truth in this (especially wrt asynchronous model).<p>But the lower levels of embedded (both on bare metal MCUs) and on the lower level parts of embedded Linux require hardware skills without a web equivalent. While embedded software developers aren't normally expected to actually design boards they do have to be able read a schematic and review it concerning the software aspects (eg are the components used already well supported in software, are the right debug ports available etc). And quite often you have to debug with an osciloscape or logic analyser. Basic soldering to build cables etc is also very useful.<p>Also a lot of embedded requires understanding and modifying large codebases (eg the Linux kernel) whereas in web development its more about using existing libraries and frameworks more or less as is.
I remember doing a short contract to do some embedded programming.. a change of pace from web dev work. Getting simple things to work in C was sooooo much more difficult than in JS. Debugging also a hell of a lot more difficult. Code change feedback required loading the code files onto the device. Mutexs... And yes it is partially a reflection of my I adequacy with C but I think it's still a valid point
I've been in both fields and I'd dispute some of this post, but I'm not sure what it's trying to say.<p>web is the default entry point for the vast majority of developers these days, and has a much more welcoming leaning curve. Of course it will have a less-hardcore reputation. Look at the ways in which even the developers specializing in webapps attempt to distinguish themselves among the crowd.
I've really only worked in embedded (aerospace mainly), aside from an internship. While I enjoy working on satellites with all the entailed constraints, the relatively low salaries and slow pace of progress have been getting to me. I'm near completing a master's in CS, which should help a bit in elevating myself as a candidate without real webdev experience.<p>For those of you who have transitioned from embedded to web or another high-demand area (ML, distributed systems), how did you find that transition? And for those who've stayed in embedded, what is it about the work that keeps you from leaving?
Like many reader of this site, who are not "front end developers," and hence have watched the constant churn of fads and ever-changing cleverly-named frameworks and tools for churning CSS and HTML and attempting to shore up JS and browser support into something representing a stable and maintainable platformm,<p>and as a reader who worked in embedded for a decade,<p>my instantaneous reaction to this headline was "JFC NO!" prior to even clicking o see if it is e.g. about domain priors or what.<p>Half in rejection of the contention that the actual ecosystem is similar (it's not),<p>mostly in rejection of that idea that it should be ("never again").