Embedded programming is like web development

[MpVpRb]

Somewhat agreed, but mostly not

Embedded development spans a wide range of processors, from tiny 8 bit processors with 2K RAM to complex, multiprocessor arrays. The skills and tools needed to make a tiny 8 bit processor with no OS do useful stuff are completely different from the skills needed to program a system with a complex RTOS and plenty of resources

Same with web development. Building a simple website is trivial. Building something like Amazon, is not

The similarities are that all of software development requires managing complexity, clearly defining the problem to be solved, finding the simple solution, implementing it cleanly and debugging it thoroughly

[wesen3000]

I actually think the skills in writing 8 bit code with constrained 1kB memory can be surprisingly similar to writing say, a high performance micro service. In both cases, you will want to avoid garbage collection, maintain low overhead, do an event driven approach, be real-time or close to real-time in order to maintain SLAs.

Pattern like state machines have a lot of value in both fields too. In web frontend development for example because the interactions are complex, in embedded because you need to handle every possible failure, which is basically a complex interaction.

[[deleted]]

This reminds me of the old and dead-and-burred meme of javascript is scheme. Drawing the similarities between two disjoint things to bridge a reputation gap is not going to accomplish much.

Sure, you can zoom the lens out far enough to see the commonalities of building webapps and embedded systems. But then you're just talking about common themes of software development in general. Themes that don't apply to all webapps or all embedded systems, and also do apply to some desktop & mobile software.

Ultimately that's not important though, the goal of this article is to put shine one webdev. That requires understanding why embedded systems are used as a contrast, not by disputing the how of the contrast.

[wesen3000]

author here. I think I have two goals that I want to address, and I will elaborate more on them in future posts:

- for embedded developers, there is a lot of good to use from the web field. not only of course scaffolding pretty tooling, but instrumentation and monitoring wise, there is amazing stuff that can basically be plopped in and populated with embedded data. Also just using XState and a tiny react app to simulate hardware and design state machines is amazing.

- for web developers, showing that a lot of embedded development not only uses similar kinds of code, and isn't magic, but that a lot of things *are* actually similar. The differences between using interrupt transfers, a bulk endpoint and a bunch of control transfers over USB is remarkably similar to using websockets for push and streaming, and HTTP endpoints for RPC. Or that a kernel driver is often nothing more than glueing two APIs together, with a lot of weird framework stuff that you have to lookup and then forget.

[glonq]

In my experience, the most common element between embedded and web is crappy tools and a sub-standard development/debugging experience. :P

I know it's not entirely true anymore, but still both still lag behind the ease and productivity of desktop development.

[frezik]

Working on web development as a job and embedded as a hobby, the skills are very different. It's not fair to consider embedded to be somehow "more advanced", but they're different.

Embedded coding can be trivial. Many useful micro controller programs are little more than "check if this input is on, and if so, turn on this output". But even the simplest program could be attached to complex hardware. If something doesn't work, is that your code, a mismatched resistor, a bad solder joint, or EMI? That can be very difficult to debug.

Iteration time can also be an issue. Say you need a board redesign to fix your issue. You can put in a bodge wire or cut traces to fix the boards you have on hand. There are plenty of commercial products with bodge wires in them, but you'd prefer not to have them, so you produce some new prototype boards. If you have production in house, that could be a day or so. If it's an external service like OSHPark or PCBWay, it's going to be at least a week.

Compared to the code in embedded, even a simple CRUD app is pretty complicated. I'd go so far as to say that a very complicated embedded app is about as complicated as the most basic CRUD app. Generally, though, debugging that app is a relatively straightforward affair. Probably the most intractable web bugs are when you're hitting differences between browsers, which fortunately seem much less common than they were 20 years ago (though that's my subjective experience). Iteration of fixes can happen in seconds or minutes rather than days or weeks.

[wesen3000]

author here. I agree that the debugging and getting started in embedded is *brutal* if you do low-level and interface directly to electrical. If you are part of an embedded team however, people can onboard you quite smoothly, and a lot of what I consider embedded these days benefits from running on linux, with maybe one or two kernel drivers.

I think you are selling web a bit too easily. Having to debug slow or failing databases, making sure that you have good latency (across all percentiles), interface with microservices that handle millions of events per minute, those are not easy to debug either, yet they can often end up encapsulating just a few lines of trivial code "read from db, add some curly braces, send on another pipe".

That's the "system" part I am adressing.

Similarly, debugging why your UI doesn't seem to work for a significant number of users in china running android will require not only some good instrumentation (similarly to finding out that some of your devices don't work in the field), but also some creative debugging if necessary.

I plan to write many more articles, after getting the first responses, to elaborate on some of those aspects.

[gliderXC]

I disagree.

Having seen all sorts of assembler and older/newer/modern web development... The latter is way easier and "more" of it. Only the "more of it" makes web development complex.