On middleware

In many knowledge, many sorrows.

The company, let's call it Acme Products, produced a very popular product that many of us use every day (I can’t even imagine what we are talking about, there may be phones with caller ID, but they were 8-bit - the translator's note). It is executed on a single 16-bit processor, all code fit into a 256k ROM. The code has evolved over the decades, the patch followed the patch, creating confusion. Support costs increased year by year.

Engineers convinced the management that it was necessary to completely redo the system. Not without reason, they chose a top-end 32-bit MK with a frequency of 200 MHz. Perhaps not fully justified, yielding to the calls of sirens, engineers chose Windows CE with an extensive graphic library, and numerous layers of intermediate layers of API isolation from the application to replace the traditional RTOS OS, and received the resources necessary to do all their work. that one can imagine in the future.

Five years of development and a budget of $ 40 million without much progress. The system ROM has grown from 256 KB to 2 MB, and then more. When they contacted me, the application consumed 32 MB, but contained only half the functionality of the original 256 KB, 16 bit version. Pressing the button, which previously responded instantly, is now processed in seconds. System security requirements are a big question.

The big promises of manufacturers of the “neutral code” gave rise to so many intermediate layers that the system required too much CPU time, huge code space, and ate a huge amount of engineering time. I recommended that they cancel the program and start over. They did just that.
')
Another firm, let's call them ABC Security, has developed a secure communication device on the Pentium Pro. A quarter GB of RAM to support the Linux version, middleware software, which is again designed to provide the API with neutral code, even more API-neutral access to the file system on the flash drive, the chain of device drivers was so deep and so messed up into the confusion of Linus himself, led to the creation of a product that was conceived for ten minutes before turning on the dial tone after lifting the tube.
The project was closed, $ 2 million was expensed.

Next was a product for collecting data that was transferred from the 8051 to the Power PC. Engineers have replaced a simple main loop with RTOS from a reputable manufacturer, and a simple data storage structure with a real file system. TCP / IP replaced the patented synchronous communication mechanism in the previous incarnation. And the resulting system also never saw daylight, because it could not cope with the real flow of data.

I get a lot of letters from people who want to know how to use X on some small microcontroller, where X is something of a number: C #, Linux,. NET. Magazine advertising screams about the benefits of higher levels of abstraction, complex intermediate layers, languages ​​that guarantee immediate and painless reuse. If you do not work with Linux or any version of Windows, your outdated dinosaur products are doomed to failure in the market.

In the old days, assemblers could add up execution times to predict code execution times. The requirements for RAM and ROM were absolutely clear. The transition to C made these requirements more obscure, but with little development experience, it was possible to reasonably evaluate the performance and memory requirements of a real object. But it becomes impossible when we insert huge chunks of intermediate code into our products.

Of course, it’s difficult for a manager to resist the promises of vendors, who solemnly assure that a new layer of abstraction will allow to insure against whimsical decisions made by other vendors, that switching to a popular API will allow us to replace expensive “embedded” experts with Visual C ++ programmers with a pay dollar in hour. However, the costs, in terms of memory and processor cycles, never seem to be taken into account. But only until the system has grown into bloated code that runs at the speed of a snail, so that its unsuitability becomes apparent. At this point, there is no choice but to complete redesign. Expensive? This is your bet.

Middleware, high-level languages, and complex operating systems are amazing tools and provide capabilities that many embedded systems absolutely need. But they seldom correspond to promises of suppliers interested in sales. We must demand quantitative parameters instead of too often vague promises used to increase sales.

Embedded real-time systems with limited resources are still the norm, and thus they are fundamentally different from PCs. However, too many manufacturers seem to see embedded solution space as an extension of the desktop market.