УЧИМСЯ САМИ, СВЕРХУ ВНИЗ. БОЛЬШИЕ ВСТРАИВАЕМЫЕ СИСТЕМЫ

Целевая аудитория

Предыдущая глава была предназначена для людей, имеющих опыт работы с аппаратными средствами и желающих научиться программированию микроконтроллеров, т. е. имела дело с приближением к встраиваемым системам «снизу вверх». На другом конце спектра мы встречаем людей, обладающих солидным опытом в части написания пользовательского ПО на языках высокого уровня, которые сейчас хотят получить дополнительные знания, касающиеся встраиваемых систем. Обычно эти люди обладают квалификацией, которую я бы описал термином «1Т» (программирование баз данных, HTML-дизайн, разработка приложений на Java и т. д.), и не имеют опыта инженерной работы. Довольно часто в эту категорию попадают старшекурсники, специализирующиеся в области компьютерных наук.

С адаптацией таких людей к реалиям встраиваемых систем немедленно возникают сложности, связанные с тем, что чисто программные проекты для массовых ОС (Windows, Mac OS и т. д.) обычно разрабатываются с учётом того, что характеристики продукта будут сильно меняться в зависимости от вариаций аппаратных средств пользователя. Более того, аппаратные средства ПК до некоторой степени расширяемы и недороги, так что совершенно обычной является практика, когда разработчик ПО требует, чтобы пользователь обеспечил наличие специальных аппаратных средств, таких, как дополнительная память, 3D-видеокарта с аппаратным ускорением и т. д. Во встраиваемых системах выдвижение таких требований неприемлемо.

Разработчик ПО для встраиваемых систем должен уметь:

  • 1. Точно определять ресурсы, необходимые ПО, и управлять их распределением. Это умение определять, какой объём ОЗУ и внешней памяти потребуется ПО при всех мыслимых условиях выполнения с полной гарантией того, что не произойдет выхода за эти границы при каких- нибудь необычных комбинациях входных сигналов. В большинстве случаев также необходимо дать некие гарантии, относящиеся к параметрам работы в реальном масштабе времени (хотя здесь границы часто настолько свободны, что на них не заостряют внимание).
  • 2. Разрабатывать ПО, эффективно использующее доступные системные ресурсы.
  • 3. Разрабатывать ПО, которое при заданных входных условиях не имеет неопределенностей в выполнении (является детерминированным).

Ни одно из этих умений, очевидно, не пользуется большим спросом в сфере разработки ПО для современных потребительских приложений0. Следовательно, им не особо обучают на университетских курсах компьютерных наук. Заметьте, что выражение «программное обеспечение» в данном контексте явно включает в себя и ОС, работающую на целевом устройстве. И наоборот, для разработчиков приложений для ПК ситуация, когда они должны гарантировать нормальное поведение ОС, ненормальна.

Десять—двенадцать лет назад (как я жаловался во введении этой книги) разрыв между разработкой встраиваемого и массового пользовательского ПО был значительно уже. Программисты, съевшие собаку на написании игр и других программ для П К Commodore Amiga или (что даже лучше) для его 8-бит- ных предшественников, таких, как Sinclair ZX Spectrum и Commodore 64, были хорошо подготовлены к тому, чтобы окунуться в разработку ПО встраиваемых систем, работающих в режиме реального времени.

В этой главе вы познакомитесь с несколькими вариантами, на основе которых можно разрабатывать 32-битные (или даже 64-битные) встраиваемые системы с широкими функциональными возможностями. Обратите внима- [1]

ние на присутствующий здесь определитель «широкие функциональные возможности (high-end)». Некоторые 32-битные микроконтроллеры (например, ARM и SuperH) доступны и в значительно урезанных модификациях (обычно без шин подключения внешней памяти), которые предназначены для дешевых систем на одном чипе. Другие 32-битные ядра, многие из которых патентованы, встроены в ASSP (специализированные стандартные продукты), такие, как используемые в DVD-плеерах. Эти категории микросхем и применений скорее относятся к главе 3. В данной главе я специально переношу фокус на сложные встраиваемые системы, где уровень приложения существенно абстрагирован от аппаратной части. Для таких приложений обычно приходится писать сложный код пользовательского интерфейса, часто с элементами графического пользовательского интерфейса (GUI — Graphical User Interface). В качестве примера таких систем можно назвать торговые автоматы (АТМ — Automatic Trade Machine), электронные витрины, управляемые встроенным компьютером, карманные ПК (PDA — Personal Digital Assistant), автоматизированные машины по продаже билетов на киносеансы или компьютеризированные информационные табло на железнодорожных вокзалах и в аэропортах. Обратите внимание, что я намеренно исключаю из этого списка системы реального времени с жесткими ограничениями на время отклика, к которым просто были предъявлены столь высокие требования по производительности, что в них пришлось использовать 32-битный микропроцессор.

Подобно предыдущей главе, я вкратце познакомлю вас с возможностями нескольких популярных мощных платформ. Опять же этот материал не задумывался как вводный курс по реальному проектированию систем на основе данных платформ. Цель данной главы — пролить свет на сильные и слабые стороны более мощных семейств микроконтроллеров, что поможет вам сделать осознанный выбор в вопросе, в каком приложении вы можете сами начать эксперименты с этими семействами.

  • [1] У инженеров вообще весьма специфичный взгляд на прискорбное состояние отрасли создания потребительского ПО. Это одна из причин того, почему непропорциональнобольшое число инженеров работают с ОС с открытым кодом. В них, как и в коммерческихпродуктах, есть ошибки, но они, по крайней мере, дают пользователю возможность этиошибки исправить (несмотря на то, что у большинства инженеров никогда нет свободноговремени, чтобы начать подправлять исходный код).
 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ ОРИГИНАЛ   След >