2.3.2. Краткая история языка Си
Наш разговор о Си был бы неполным, если бы мы кратко не остановились на происхождении этого языка. Для более полного погружения в эту тему советуем обратиться к книге [8]. Ниже по тексту параграфа мы даем краткое изложение одного из разделов этой книги.
Первая версия языка Си была разработана в середине 60 ых годов для разработки операционной системы Unix в лаборатории Bell. Один из самых первых разработчиков этого языка, Кен Томсон (Ken Thompson), решил, что требуется язык для создания более сложных языков программирования. Он создал такой язык и назвал его «B». В процессе развития своего творения Томсон постоянно боролся с ограничением ресурсов памяти, что теперь очень похоже на встраиваемые системы. Деннис Ричи (Dennis Ritchie) решил расширить язык «B» свойством генерировать малый по объему код, который сможет соперничать с кодом, написанным на ассемблере. В 1973 году важнейшие свойства этого нового языка «C» были получены.
Возрастающая популярность Си заложена в его переносимости. Компиляторы Си были созданы для многих платформ (так в сообществе разработчиков называют процессорное ядро МК), отчего его популярность еще больше выросла. Наиболее бурно Си стал использоваться в 80 годах, когда стал основным языком для создания программ персональных компьютеров.
Американский национальный институт стандартизации (American National Standards Institute — ANSI) в 1982 году учредил комитет X3J11 для разработки стандарта языка Си. В 1989 доклад комитета был передан в Международную организации стандартизации (International Organization for Standardization — ISO) и международную электротехническую комиссию (International Electrotechnical Commission — IEC) и был утвержден в качестве стандарта ISO/IEC 9899-1990. За этим стандартом последовало неизбежное развитие языка, которое было узаконено в 1999 стандартом ISO/IEC 9899. И Си стал языком, который наиболее часто используется в компьютерной индустрии.
2.4. Оптимальная стратегия — программирование на Си и на ассемблере
Итак, мы установили, что предпочтительно программировать встраиваемые системы на языке высокого уровня. И в качестве такого языка мы обоснованно выбрали язык Си. Но и ассемблер имеет свои преимущества. Так на каком языке мы все таки будем программировать встраиваемые системы?
Практика применения языка Си и ассемблера показывает, что оптимальный результат, как с точки зрения экономии времени на разработку, так и по времени исполнения программы, можно получить, используя в одном проекте сразу два языка программировании: и Си, и ассемблер. Основная часть прикладной программы, в которой производятся преобразования данных, будет написана на СИ, в то время, как критичные по времени реализации фрагменты алгоритма, следует оформить на ассемблере. Кроме того, ассемблер иногда используют для программной поддержки некоторых внешних по отношению к МК периферийных ИС. Драйверы обмена с такими ИС обычно требуют многократного переключения отдельных линий портов МК, что в компиляторах Си для некоторых МК удобнее выполнить на ассемблере. Еще один случай обязательного включения ассемблерного фрагмента в текст основной программы на Си мы продемонстрируем на примере использования команд ассемблера 68HC12/HCS12 для преобразования данных по правилам нечеткой логики (см. гл. 7).
Ранее мы упомянули, что конструкции языка Си как нельзя лучше сочетаются с методом структурного проектирования. Настало время познакомиться с этим методом.
2.5. Структурное проектирование
Несколько следующих параграфов мы посвятим изложению основных идей метода структурного проектирования. Для создания этого раздела мы использовали материалы, изложенные в [1, 7], а также опыт собственных разработок. Метод структурного проектирования не гарантирует обязательного успешного завершения проекта. Однако этот метод значительно увеличивает вероятность создания за ограниченное время качественной системы, полностью совместимой с управляемым объектом.
2.5.1. Основные положения метода структурного проектирования
Теория. Метод структурного проектирования — это регламентированная последовательность действий, которая позволяет разработать структуру аппаратных и программных средств встраиваемой системы, удовлетворяющих техническим требованиям к проектируемому устройству.
Первым шагом этой последовательности действия является как можно более полное описание технических требований к будущей системе. В подавляющем большинстве случаев технические требования формулирует не тот, кто потом реализует систему. Поэтому технические требования должны быть как можно более точно доведены до исполнителя. Исполнитель обязан подробно исследовать предложенные ему технические требования, понять их обоснованность и согласованность. Представьте себе трагедию разработчика, который выполнил систему, работающую правильно, но по неправильному техническому заданию! Разработчик потратил время и деньги на проект, но он не нужен заказчику! Кто виноват? Вывод: структурное проектирование использует определение проблемы как путь к определению решения этой проблемы.