Багато знань мають багато печалей.
Компанія, назвемо її Acme Products, виробляла дуже популярний продукт, який багато хто з нас використовують щодня (навіть не уявляю про що йде мова, може бути телефони з АОН, але вони були 8битними - Примітка перекладача). Виконаний він на одному 16-бітному процесорі, весь код вміщувався в 256k ПЗУ. Код розвивався протягом десятиліть, патч слідував за патчем, створюючи безлад. Витрати на підтримку збільшувалися рік від року.
Інженери переконав керівництво, що необхідно повністю переробити систему. Не без підстав вони вибрали топовий 32-бітний МК з частотою 200Мгц. Можливо, не до кінця обґрунтовано, піддавшись на заклики сирен, інженери для заміни традиційної ОСРВ ОС вибрали Windows CE з обширною графічною бібліотекою, і численними шарами проміжних шарів ізоляції API від програми, і отримали в своє розпорядження ресурси, необхідні для того, щоб зробити все, що тільки можна уявити собі в майбутньому.
П'ять років розробки і бюджет $40 млн без особливого прогресу. Системне ПЗУ зросло з 256 Кб до 2 Мб, а потім і більше. Коли вони звернулися до мене, то додаток споживав 32 Мб, але містив тільки половину функціональність оригінальної 256 КБ, 16 бітної версії. Натискання кнопки, яка раніше відгукувалася миттєво, тепер оброблялося протягом секунд. Вимоги безпеки системи під великим питанням.
Великі обіцянки виробників «нейтрального коду» породили так багато проміжних шарів, що система зажадала занадто багато процесорного часу, величезного простору коду, і з'їла величезну кількість інженерного часу. Я рекомендував їм скасувати програму і почати все спочатку. Вони так і зробили.
Інша фірма, давайте називати їх ABC Security, розробила безпечні пристрій зв'язку на Pentium Pro. Чверть гігабайт оперативної пам'яті для підтримки версії Linux, ПО проміжного шару, який знову-таки призначений для забезпечення API нейтральним кодом, ще більш API-нейтральний доступ до файлової системи на флешці, ланцюг драйверів пристроїв був такий глибокий і так заплутаний, що міг би привести в замішання самого Лінуса, призвело до створення продукту, який замислювався на десять хвилин, перш ніж увімкнути тональний сигнал після підняття трубки.
Проект був закритий, $2 млн списані у витрати.
Далі був продукт для збору даних, які перенесли з 8051 на Power PC. Інженери замінили простий основний цикл на ОСРВ від відомого виробника, і просту структуру зберігання даних на реальну файлову систему. TCP/IP замінив запатентований механізм синхронного зв'язку в попередньому втіленні. І отримана система теж ніколи не побачив денного світла, тому що не могла впоратися з реальним потоком даних.
Я отримую багато листів від людей, які бажають знати, як використовувати X на якомусь невеликому мікроконтролері, де X є чимось з ряду: C #, Linux, .NET. Реклама в журналах кричить про переваги більш високих рівнів абстракції, складних проміжних шарів, про мови, що гарантують негайне і безболісне повторне використання. Якщо ви не працюєте з Linux або якоюсь версією Windows, ваші застарілі продукти-динозаври приречені на провал на ринку.
У старовину асемблерники могли скласти часи виконання інструкцій, щоб передбачити час виконання коду. Потреби в ОЗУ і ПЗУ були абсолютно ясні. Перехід до C зробив ці вимоги більш неясними, але з невеликим досвідом розробки можна було розумно оцінити вимоги до продуктивності і пам'яті в реальному об'єкті. Але це стає просто неможливим, коли ми втикаємо величезні шматки проміжного коду в наші продукти.
Звичайно, менеджеру важко встояти перед обіцянками продавців, які клятвено запевняють, що новий шар абстракції дозволить застрахуватися від примхливих рішень, прийнятими іншими постачальниками, що перехід до популярної API дозволить нам замінити дорогих «вбудованих» експертів на Visual С++ програмістів з оплатою долар на годину. Тим не менш, витрати, з точки зору пам'яті і циклів процесора, здається, ніколи при цьому не враховуються. Але тільки до тих пір, поки системи не виросла в роздутий код, що працює зі швидкістю равлика, так що її непридатність стає очевидною. У цей момент вже немає вибору, крім повного редизайну. Дорого? Це ваш ставка.
Middleware, мови високого рівня, і складні операційні системи є дивовижними засобами і надають можливості, які для багато вбудованих систем абсолютно необхідні. Але вони рідко відповідають обіцянкам зацікавлених у продажах постачальників. Ми повинні вимагати кількісних параметри замість занадто вже часто туманних обіцянок, що використовуються для підвищення рівня продажів.
Вбудовувані системи реального часу з обмеженими ресурсами все ще норма, і тим самим вони принципово відрізняються від ПК. Тим не менш, занадто багато виробників, здається, розглядають простір вбудованих рішень в якості розширення ринку настільних систем.