Is embedded systems a subset of the systems programming field?

Question

I am a little unsure about the distinction between systems programming and embedded systems fields. Both definitions are pretty straightforward:

1. If we produce software targeting other software, we are in the systems programming field (e.g, some daemon, an OS piece of software, etc). It differs from the application programming (AKA computer programming) because we don't build an executable program to an user.
2. If we are programming something to be embedded into a microcontroller or a microprocessor, we are in the embedded systems field.

Embedded systems seems to be a subset of the systems programming since it also provides some feature to a more complex system and does not target an executable program to the final user (in some case, we don't even have a final user.) The unique distinction that makes me see embedded systems as a subset of system programming is that this "more complex system" is not necessarily another piece of software. Rather, it can be (and possibly is) some electronic or mechatronic system (e.g., a coffee machine.)

Is that correct?

Answer 1

Groupings and labels are often just vague labels meant to ease communication so don't get hung up on it.

For what purpose are you trying to determine the distinction? Groupings are ultimately arbitrary so without a defined purpose there's no point to trying to group things because you can group anything any way you like. Even if the distinction between two groups is fuzzy, it does not mean the group labels are useless if they ease communication most of the time. This holds true for any kind of grouping or labeling. In reality, things are what they are and don't need to be fall into two clearly different groups or subgroups.

For example, the most general definition embedded systems in general refer to processing that is integrated into a system that performs a rather specific purpose. But more complex embedded systems can have operating systems that run applications, with each application having its own responsibility in the system. If you also remember that general purpose computers exist, then the presence or absence of applications or operating systems cannot be used to identify whether a system is embedded or not.

Things in the real world don't need to fall into the distinct categories that humans make up. There's nothing stopping from some things under one label from overlapping with another labels, or being a subset of another label, or any possible combination of the two.

Fretting over such distinctions can actually be counterproductive when you try and use them. For example, I already outlined how there's partial overlap and subsetting earlier, but if I actually heard someone say "systems programming" I would assume they were talking about an operating systems, device drivers, or other low level system that were NOT part of an embedded system, even though a lot of that could and sometimes falls into the realm of embedded systems. Conversely, if they said "embedded systems" I would not be surprised if they did or did not talk about OS because sometimes embedded systems have that and sometimes they don't. That's because if the distinction really mattered, I would expect them to not be using such vague labels.

It's like blue and green. No one sits there splitting hairs to determine when exactly blue turns into green. You just use the terms with a general understanding, and with the expectation that if the distinction really mattered then the RGB, CYMK, or wavelength would be used instead of just the labels "blue" and "green".

That's a lot of words to say to simply say: Don't worry about what they really mean. The vague understanding you have is good enough and you will adapt to various usage in context. Trying to make it distinct is counterproductive and a waste of effort.

Answer 2

Embedded systems programming can typically be one of:

• Microcontroller programming without RTOS - "bare metal".
• Microcontroller with RTOS.
• DSP programming.
• HDL programming of FPGA.

Systems programming generally refers to programming close to an OS such as Linux or Windows, including writing drivers for PC hardware or networking. This has almost nothing in common with embedded systems programming, embedded is not a subset.

One of the few things they do have in common is that the C programming language is very dominant for these type of applications. C does make a distinction in the language itself between hosted systems (systems programming) and freestanding systems (embedded).

• Embedded systems programming comes with complete freedom over memory and addresses. The programmer has exclusive access to 100% of the system resources and may often access physical addresses directly. You have free access to execution time, although in case a RTOS is used, code execution will be scheduled.

  Whereas systems programming has memory restrictions, restricted access to hardware, virtual addresses only, specialized addressing methods such as as kernel mode, ASLR etc. The systems programmer need to take resources used by the OS as well as applications in mind. Memory allocation happens through the OS. Program execution is scheduled and controlled by the OS.

• In embedded systems, pretty much all forms of programming is deterministic real-time applications, meaning that you can predict in advance how long a task will take and when it will be done. Real-time programming could be said to be a subset of embedded programming.

  In systems programming, real-time guarantees do not exist and a task can in theory take forever to complete - you can only simulate real-time as done in computer games. But then things such as CPU/graphics/network "lag" may happen since, neither the OS nor the TCP/IP protocol guarantee any real-time deadlines.

• Embedded systems do not necessarily come with a GUI or obvious way to implement the concepts of "streams" stdin/stdout as done in systems programming. Freestanding C compilers/standard libraries need not support the whole of the C standard library but are free to implement a subset, whereas a Hosted C compiler/standard library must implement all of it. Freestanding systems have relaxed rules for the format of main().

• In systems programming you always work against a well-defined API and/or ABI as stated by the system. How drivers are supposed to be written and how access to hardware happens is controlled in detail by the rules of the OS.

  In embedded systems you have complete freedom but might also be forced to "re-invent the wheel". Traditionally, pre-made source and drivers for a certain microcontroller have not been available, though that situation has improved a lot over the last decade. Nowadays there are often example code of drivers which you can look at or use directly.

• In microcontroller/DSP/FPGA applications, hardware peripherals are tightly integrated with the CPU and the address bus is most often a fast, internal one. You have direct control over hardware registers and many modern hardware peripherals support DMA directly between hardware and RAM. In systems programming, hardware is pretty much only accessed through external bus interfaces (USB, SATA, PCI etc).

• Embedded systems are often very resource-restrained compared to hosted systems. Microcontrollers are clocked significantly slower than PC CPUs and they are often single core. A FPU with fast floating point handling is not available on low- to mid-range MCUs. Memory in terms of RAM/stack as well as flash is very restricted, whereas PCs have in comparison seemingly limitless amounts of it.

• Embedded systems have true ROM memories that can be directly addressed, whereas hosted systems can only access ROM through (in comparison) very slow external bus interfaces to a hard drive. Therefore embedded systems tend to have all/most of the executable code in ROM, whereas hosted systems always upload all executable code in RAM.

• Microcontroller programming is intimately connected to electronics and so a microcontroller programmer must know at least basic electronics. Whereas a system programmer could get away with not even knowing about Ohm's Law.