HW engineers are quite busy. Every year they release greater (in terms of speed, power consumption, functionality, flexibility, security etc.) chips that we can use in our products.

In the beginnings of the computer industry, the division of work between HW and SW was clear. All computation was to be done by SW on the CPU, and interaction with the external world (incl. networked computers, storage devices, printers, other peripherals, users) was to be done by HW. This basis also implied a clear and stable interface between HW and SW.

The advent of HW-accelerated graphics started changing this status quo. When the work was constrained to a specific form, HW was much faster and more efficient in doing it than SW. This introduced the design problem of how to distribute the work between HW and SW.^[1]Studied under the broader term architectural exploration.

Today, when using an application-specific processor, we are given a lot of capabilities provided by the HW: accelerating 2D, 3D and vector-based graphics; image manipulation; video encoding and decoding; network protocol tasks like checksum calculation; management of flash-based media; cryptography calculations etc.^[2]How much BSPs are lagging behind to keep up with the offered features is also an interesting discussion, maybe later. And when we decide to develop our own HW on an FPGA, the decision to implement some of the functionality on HW or SW is fully under our control and responsibility. Continue reading The increasing complexity of HW-SW interface →

Hi there,

I’d like to share some introductory slides to UML I prepared previously for a training. Nowadays it is quite an essential knowledge for all kinds of SW developers, and this might help for newcomers.

Please find it here: UML Preliminaries

Have a nice weekend,

Dogan

In embedded systems, we tend to use a lot of threads. Not for computational efficiency, but for coping with a complex environment. They are useful for interacting with the parallel operating HW parts, different external parties (incl. user) we are communicating with etc.

To coordinate our multiple threads, we need to use a good deal of IPCs ^[1]Inter-process communication, I’ll use this term to refer to all kinds of synchronization primitives in this post, whether inter-process or intra-process., e.g. mutex locks, events, semaphores, shared memory regions.

These IPCs offer tempting division points in our system, and thereby sometimes become the interface between the subsystems. However, in fact they are not well-suited for this purpose for a number of reasons: Continue reading IPCs don’t make good APIs →

Hi there,

I’m a software architect working on embedded systems, but generally interested in all kinds of software-intensive systems.

Please stay tuned for thoughts and experiences about software architecture practices. And feel free to respond, I’d love to get in touch.

Dogan