Во многие знания многие печали.

Компания, назовем ее 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, языки высокого уровня, и сложные операционные системы являются удивительными средствами и предоставляют возможности, которые для многие встроенные системы абсолютно необходимы. Но они редко соответствуют обещаниям заинтересованных в продажах поставщиков. Мы должны требовать количественных параметры вместо слишком уж часто туманных обещаний, используемых для повышения уровня продаж.

Встраиваемые системы реального времени с ограниченными ресурсами все еще норма, и тем самым они принципиально отличаются от ПК. Тем не менее, слишком многие производители, кажется, рассматривают пространство встроенных решений в качестве расширения рынка настольных систем.