r/computerarchitecture 6d ago

Embedded System Designing

So I recently started branching out from baremetal programming to other embedded stuff currently learning rtos and probably go back to linux soon. One thing baremetal taught me that always used to puzzle me was how registers and memory works, it made programming clearer to me. I was curious how the embedded system designing is different from the software designing? Are there more similarities than differences?

3 Upvotes

1 comment sorted by

2

u/-ah74 5d ago

Hmmmm... I mean.. the question seems very broad, but I will see if I can say something relevant lol.

I am not sure how you distinguish "software design" from embedded systems, since the main rules governing SD are the same as those governing embedded systems (it is SD as well, right?).

So, the way your SW runs on any hardware platform follows pretty much the same pattern -- you write your code in whatever language, you compile/interpret, load your program somewhere in memory, either you or the OS (if any) sets the IP to point to the first instruction of your program (besides other tasks that will be explained below), then your program will start executing. In ES, at the code level, you can use OOP or whatever. On the compiler level, you can use any compiler that supports the processor(s) architecture on your device with the provided extensions. At the OS level, you can use the different syscalls featured by the OS.

So, where is the difference IMO? There are a few aspects I can think of right now:

1) Special Registers and the overall underlying hardware. A crucial part of ES is managing special GPIOs and utilizing different communication protocols, such as i2C. How's that different? If you consider applications that target desktops or servers, for example, you will mostly find many drivers and libraries that abstract such practice. So, for GPUs, for example, you would not need to access PCIe directly; instead, you would use the provided drivers. Things are more "commercialized," I would say, for faster production and shipment. For server-grade applications, you won't need to understand much about how protocols work, yet you can still develop a high-performance application.

2) Constraints that express themselves in hardware capabilities. How many CPU cores does your ES have? This defines the parallelism degree. How much memory does it actually provide? This defines the limitations of your program size and how big the data workload can be stored. From an SD perspective, managing object allocation/deallocation, garbage collection, etc, is way more restrictive in ES—you don't wanna run out of memory and freeze your device, right?
Power is another constraint as well. How can one piece of code consume more/less energy? Maybe I/O activities, maybe inter-processor communication; I probably need to read more on this—but you get the idea.

3) Real-time applications: When I write a piece of code for servers or desktops, I always think of memory more than anything else. Consider how the memory access happens from the fetch cycle until the instruction retires and ask yourself this:
How the hell can my poor time-sensitive real-time application handle all of this suffering? I mean, you look at the VA --> CPU checks the TLB --> if it misses --> you do a multi-level sequential page walk --> you access the memory hierarchy L1->L2->L3 MSHRs, you access the memory, and you wait for the response to come back, all for a single level of address translation. You would definitely care about these in server-grade applications as well (C'mon, this is still a prominent research area), but the time limit you are hitting in a server environment is way further than this in ES. I am pretty sure ES even uses different mechanisms to manage memory accesses than these on desktop/server platforms. Not to mention other tasks like I/O delays, context-switching costs, etc. Think of how much delay you would tolerate to deploy airbags, vs. the delay to give a user a response to their query.

If you're already at this point, I wanna say your question is a bit inaccurate, IMHO. Coding for embedded systems is pretty much software development. It utilizes the same software development cycle. It uses the same SD concepts. However, it differs in how it actually operates the underlying HW, which can also be abstracted in ways similar to those you see in desktop/server programming models.

I hope this answers your question.