Средства и методы разработки

Как у меня собираются некоторые проекты и почему не годится MPLAB. Во-первых структура в файловой системе. Есть главный каталог проекта и в нём лежат все исходники и прочие нужные файлы (скрипты, файлы данных и т.п.) общие для всех платформ, для которых может собираться проект. Так же есть каталоги, в которых лежат файлы специфичные для данной конкретной платформы (это может быть конкретная печатная плата, возможно с другим MCU другого семейства, или синтетическая платформа -- симуляция на PC) -- исходники, makefile и т.п. И есть каталоги в которых лежат библиотеки или файлы общие тоже для всех платформ, но которые как-то обособлены логически. Все эти каталоги находятся в главном каталоге проекта. Симуляция на PC подменяет слой связанный с железом, иногда целиком более высокоуровневые модули (например модуль клавиатуры, чтоб не эмулировать побитную передачу через 1-wire на PC, сразу коды клавиш даются) программной симуляцией которая скриптуется из Tcl. Это служит трём целям: во-первых есть GUI на Tcl/Tk заменяющий аппаратный стенд с кучей переключателей и лампочек, во-вторых возможна какая-то форма автоматизированного тестирования (скрипт задаёт какие-то воздействия и проверяет какая на них реакция), в-третьих можно руками задать любые нужные воздействия для отладки (через GUI абсолютно всё не предусмотришь). Симуляция на PC нужна для отладки, т.к. средства отладки на PC гораздо более мощные, чем MPLAB проф. уровня. Для сборки проекта нужно перейти в каталог проект/платформа и там делать make. Там местный makefile первым делом подгружает ../Makefile для получения каких-то платформо-независимых правил сборки. Обычно к ним относится список модулей проекта которые присутствуют независимо от того, сборка на какой платформе осуществляется. Так же макроопределения для C-препроцессора независимые от платформы или зависимые, но вычисляемые единообразным образом для всех платформ. Так же переменные самого make, пути для поиска исходников, правила сборки дополнительных программ (для PC) нужных для работы с проектом -- это всё в общем ../Makefile. А в Makefile специфичном для платформы уже специфичные для данной платформы правила сборки: какой компилятор и как вызывать, с какими опциями и для каких файлов. Список модулей нужных именно для данной платформы, в дополнение к общему списку для всех. Специфичные макроопределения для C-препроцессора и т.п. Почему такая структура файловой системы. Не знаю, так сложилось исторически. Но это удобно для самой программы, т.к. в пути поиска (gcc -I dir и VPATH у make) включается текущий (.) каталог и каталог верхнего уровня (..). И файлы для разных платформ могут иметь одинаковые имена (не надо никаких сложностей с исходниками) и автоматически будут найдены нужные. Соответственно платформо-независимое размещается в каталоге ".." (относительно каталога в котором сборка), платформо-зависимое в каталоге "." Большинство .o файлов собирается с настройками по-умолчанию и оптимизацией -Os. Но часть файлов имеют специфичные опции для компилятора заданные в Makefile. Это может быть другая оптимизация, отключение warnings, другие опции C-препроцессора. Некоторые .o могут добавляться или не добавляться в проект, а также меняются имена .o полученных из одного .c (чтоб не получалось, что логически разные модули получают одно имя при разной компиляции, а .c файл один, ибо он конфигурируется через define на разный выходной результат), а также меняются макросы для C-препроцессора в зависимости от переменных make переданных из командной строки. Это нужно для компиляции в рамках одной платформы для немного разных версий печатной платы или если на печатную плату устанавливается несколько разные внешние модули. Makefile подразумевает не единственную цель. Некоторые цели делают какие-то вещи на PC (например, формирование образа файла для программирования во внешнюю flash память), некоторые цели формируют из тех же .c файлов проекта отдельные программы для какой-то очень минимальной формы unit-тестирования, для получения отдельных программ для работы с прибором для наладки (железа), для загрузки файла во flash и т.п. Makefile так же строит зависимости, чтоб знать какие .o пересобирать при изменении каких .c, .h и т.п. Это важно, т.к. пересборка всего (rebuild) процесс не быстрый, с одной стороны, а при наивной ассоциации .o->.c не все варианты учитываются (т.к. можно поменять .h, что всё кардинально меняет, или некоторые .c включаются в другие .c, или некоторые .o получаются из .c с другими именами) и наивная ассоциация может потратить много времени на выяснение "почему не работает", когда после пересборки всего вдруг начинает работать. И на это можно натыкаться изо дня в день на протяжении нескольких лет (у нас сотрудник сидел, чтоб не голословно, который регулярно через это искал ошибки которых нет, ещё он регулярно редактировал файлы из каталога другого проекта с тем же именем, пересобирал и опять не работает...) Это делается как описано в инструкции на Makefile, через gcc -MM. Для сборки в режиме debug и release тоже меняются макросы и некоторые опции сборки... Используется библиотека. В основном на замену (частичную) C библиотеки. Библиотека, чтоб не линковать ненужные .o и не думать головой, какие из них (не)нужные. Библиотека (пере)собирается тут же, в каталоге для нужной платформы, при необходимости. C-файлы обрабатываются макропроцессором m4 (http://caxapa.ru/403133.html). Иначе было нельзя сделать некоторые штуки, штатного препроцессора для этого недостаточно. Процесс компиляции выглядит примерно так:

set -o pipefail && $(CC) $(CPPFLAGS) -E $< | m4 -s -P | $(CC) $(CFLAGS) -c -o$*.O -x -c - && bbe -b "/$(shell pwd | sed s,/,\\\\x2f,g)/:/\\x00/" -e "r 0 $<\x00" -o $@ $*.O; rm -f $*.O

Всё что после bbe -- это для исправления абсолютных путей в C30 ввиду их непонимания MPLAB... и вообще обычно не нужно. Часть прошивки идёт не в ПЗУ контроллера (см. ссылку выше), а во внешний файл для PC (контроллер выдаёт коды, которые через этот файл декодируются). Для этого нужен objcopy -- вырезать из .cof этот файл в отдельный bin. Чего нет в xc16... Собственно вот и вся премудрость. В чём неудобство без makefile: не работает "make" собственно в mplab. Будешь забывать нажимать "rebuild all" -- будешь по пол-дня искать загадочные глюки. Не будешь забывать -- нужно очень терпеливо и долго ждать. Потом нужно все настройки из Makefile перенести в опции проекта в mplab. И это очень неудобно делается потому, что в Makefile оно во-первых разом видно на экране, а тут нужно тыкать мышой в каждый файлик и вводить нужное (потому ещё, что оптом для группы файлов не задать) и легко что-то пропустить (вывод (ls *.o; ar t *.a) | wc -l показывает 201 файл...) Для каждой отдельной цели -- отдельный mplab проект и всё с начала... Потом опции распиханные по разным makefile и проектам mplab будут рассинхронизированы между собой и ищи глюки. Объяснить для mplab нестандартные варианты: .o из другого .c, сборка .o через m4, генерируемые .c или .s файлы и т.п. -- нереально вообще. Т.е. нужно перед F10 в mplab запускать тот же make, а в mplab вставить промежуточные уже файлы. Несколько по-идиотски.