All SW-intensive systems have a lot generic functionality^[1]i.e. functionality not specific to the product, e.g. network protocols, XML parsing, graphics, and therefore contain a lot of generic components developed by external vendors. Sometimes the requirements force us to modify some of the behavior implemented in those components.

One of proper solutions is implementing the desired behavior via the decorator pattern. This keeps our modification dependent only on the interface of the component and not the implementation. Sometimes, however, the access provided by the interface is not sufficient to provide the desired functionality. For example, if you need to change a driver’s interaction with HW, most likely you won’t find the necessary “hook point” in the driver’s upper interface, since it cleverly hides HW-level specifics from the higher layers. Another by-the-book solution is pushing the change to the mainline, as open source community always recommends with good reason. But let’s focus on the remaining problematic cases. Continue reading Nice ways of changing external code →

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