[alexxx86 0]

Кто может разъяснить зачем нужен makefile?! На просторах интернета внятной информации не нашел. К примеру в некоторых темах пишут что при правки makefile нужно указывать тип микроконтроллера, рабочаю частоту и т. д. Я работаю в atmel studio и там в makefile нет таких пунктов. Просто хочется для общего развития понимать зачем он нужен и почему он бывает разный.

[Johnny81 0]

На просторах интернета информации о make выше крыши, очень странно, что не нашли. Можете начать отсюда и далее по ссылкам.

[zhevak 0]

Кто может разъяснить зачем нужен makefile?!

Makefile изначально использовался в среде типа UNIX, которые построены на парадигме управления задачами посредством команд, которые вводятся в консоли (символьной -- а графических консолей тогда и не было) с клавиатыры. Результат выполнения также отображался в символьном виде на экране тойже консоли. Вместо экрана висплея можно было подключить принтер. А почему бы нет!

 

Ну Вы поняли! Кнопочек и менюшечек не было. Мышей -- тоже. А управлять заданиями, то есть работать на компе было нужно. Вопрос -- как? Единственный выход в те времена -- использование клавиатуры и экрана (принтера). Понтное дело, что при таком раскладе ни о какой графике говорить уже не приходилось. Команды системе отдавались в виде слов, и получение резултата вываливалось на экран тоже в виде слов.

 

Ну это прописные истины. Я их сказал тоько для того, что бы мы понимали друг друга однозначно. Идем дальше.

 

Набирать какжый раз серию команд было неудобно. Поэтому встал вопрос об автоматизации действий программиста (пользователя). Одно из направлений автоматизации было использование скриптовых файлов, в которых команды записывались по-сторочно. Это в некоторой степени аналог виндовых BAT-файлов.

 

Другом направленим автоматизации работы программиста-разработчика было направление makefile. В файле Makefile описывается не последовательность команд, а цели, которые нужно выполнить. Иначе говоря последовательность дейстий для достижения цели определяется не последовательностью строк, а наоснове других соображений. Ну например, если объектный файл уже имеется, то повторно компилировать исходник уже не надо.( Ну это грубый пример. более изящный я сейчас не в состоянии придумать.)

 

В общем, в файле Makefile перечисляются исходные положения -- типа каким компилятором будем пользоваться, где и какие расположены библиотеки, каким линковщиком будем собирать проект, к стати -- имя проекта, состав файлов проекта, зависимости файлов друг от друга, тип процессора, тактовая частота... ну и другие параметры. Всего не перечислить! Да, в общем-то, и нет это нужно. Makefile в самом минимальном варианте тоже рулят. Мне иногда приходится создавать тестовые пректики. Поэтому накидать с нуля Makefile из десятка строк иногда бывает проще, чем адаптировать мега-Makefile из соседнего проекта.

 

В Видовсе принято программировать мышкой. Поэтой причине в Виндовсе Makefile-ы не очень распространены. И правда, какой смысл в файле, если все параметры контролируются средой разработки (IDE), и сама среда уже знает какой компилятор использовать?

 

Если Вы не собираетесь пробовать Линукс, то и заморачиваться особо на эти Makefiles Вам нет никакого смысла. Это в среде Линукса зание Makefile жизненно необходимо.

 

[ataradov 0]

Я работаю в atmel studio

Atmel Studio генерирует Makefile на основе данных проекта и использует его для сборки. Если посмотреть в директории со всякими временным файлами рядом с проектом, то там и найдется Makefile.

 

Atmel Studio так же позволяет указать внешний Makefile. Единственная настройка в этом случае - это путь к файлу.

[zltigo 1]

В Видовсе принято программировать мышкой. Поэтой причине в Виндовсе Makefile-ы не очень распространены. И правда, какой смысл в файле, если все параметры контролируются средой разработки (IDE), и сама среда уже знает какой компилятор использовать?

Обалдеть, а как быть с тем фактом, что все эти движения "мышкой" генерят на самом деле именно makefile (или их эрацы), только жутко корявые и убогие?

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

Это в среде Линукса зание Makefile жизненно необходимо.

Наскальная живопись, увы, возможна везде и в этом отношении IDE позволяющие "программировать" мышкой везде одинаковы и уже в подавляющем числе случаев уже ПОРТИРУЮТСЯ из линуксов в виндовс :)

[alexxx86 0]

zhevak, спасибо за ответ! В общих чертах я понял про makefile. Мне больше не понятно другое, к примеру берем какой нибудь чужой проект с всеми исходниками и makefileом, в makefile указан тип микроконтроллера и рабочаю частота. Или другой пример, решил я почитать про bootloaded, нашел тему где все подробно расписано и есть все исходники и makefile, опять-же там указывается тип и частота. Я работаю в atmel studio 6, там автоматически генерируется makefile, но там нет таких пунктов. Вот мне и не понятно почему где-то указывается тип и частота а где-то нет.

Изменено 14 августа, 2015 пользователем alexxx86

[ataradov 0]

Я работаю в atmel studio 6, там автоматически генерируется makefile, но там нет таких пунктов.

Потому что не нужны они студии. Makefile - это просто список рецептов и зависимотстей между ними. Он может содержать все что угодно.

 

[Johnny81 0]

zhevak, спасибо за ответ! В общих чертах я понял про makefile. Мне больше не понятно другое, к примеру берем какой нибудь чужой проект с всеми исходниками и makefileом, в makefile указан тип микроконтроллера и рабочаю частота. Вот мне и не понятно почему где-то указывается тип и частота а где-то нет.

 

Задача то какая? Взять проект с makefile-ом и собрать его в атмел-студии? Берите исходники, добавляйте их в студийный проект и собирайте. Процессор в студии где-то точно выбирается. Что такое частота? Некий define, заданный в makefile, который потом используется в исходниках? Подозреваю, что в GUI студии есть возможность указать произвольные define-ы...

 

Ну т.е. в makefile все опции компилятора заданы напрямую, текстом. В студии их надо задавать через окно свойств проекта.

 

Makefile потенциально может много больше, чем студия - к примеру дергать какие-то дополнительные утилиты и т.п. Но в простых случаях он без проблем заменяется настройками в окне свойств проекта.

[zltigo 1]

Ну т.е. в makefile все опции компилятора заданы напрямую, текстом.

Не только, есть еще использование переменных enviroment. Ну и управление проектом это не только "опции компилятора". В реальности проект это зачастую вобще не одно изделие, а группа устройств, зачастую даже на разных контролерах и под разные компиляторы. Прелесть ПОЛНОГО контроля, и в том, что я могу описать правила сборки действительно ВСЕГО проекта со всеми вариантами.

 

 

[_Pasha 0]

Наскальная живопись, увы, возможна везде и в этом отношении IDE позволяющие "программировать" мышкой везде одинаковы и уже в подавляющем числе случаев уже ПОРТИРУЮТСЯ из линуксов в виндовс :)

:( А должно быть так, чтобы без напряга переходить к равноправным формам представления информации.

[Johnny81 0]

:( А должно быть так, чтобы без напряга переходить к равноправным формам представления информации.

 

В случае нетривиального make-файла это малореально. Кстати, графические языки программирования сильно большого распространения не получили :)

[zhevak 0]

Мне больше не понятно другое, к примеру берем какой нибудь чужой проект с всеми исходниками и makefileом, в makefile указан тип микроконтроллера и рабочаю частота. Или другой пример, решил я почитать про bootloaded, нашел тему где все подробно расписано и есть все исходники и makefile, опять-же там указывается тип и частота. Я работаю в atmel studio 6, там автоматически генерируется makefile, но там нет таких пунктов. Вот мне и не понятно почему где-то указывается тип и частота а где-то нет.

 

Давайте подумаем вот на какую тему -- а на что, собственно, влияет тактовая частота процессора в программе?

 

Делаю паузу, чтобы Вы сам попробовали ответить на это вопрос.

 

Подумайте хояты минуту, прежде чем читать далее.

 

На скорость сборки проекта или на состав проекта (из каких файлов будет состоять прект) тактовая частота никак не влияет. Это понятно.

 

Тактовая частота влияет на скорость работы самой программы. Тоже абсолютно прозрачно. Однако, код, удачно откомпилированный и залитый в кремний, будет работать как с одной тактовой частотой, так и с другой с другой -- будь они различными хоть в 100 раз! Ну, какая разница с какой скоростью моргает светодиод или опрашивается кнопочка? Нехватает скорость? -- Припаяй другой кварц! Программа принципиально будет работать. Поэтому в этом и предыдущем случае задавать тактовую частоту в мэйкфайле нет ни какого смысла. Этот параметр ведь никак не будет использоваться в программе.

 

Другое дело, когда в вашей программе нужно четко соблюдать время и/или временные интервалы. Нпример, синхроимпульс, который вырабатывает ваше устройство должен иметь длительность ровно 100 мкс. Или последовательный порт UART должен работать на скорости 9600 бод. В этих случаях где-то в программном коде будут вычисляться коэффициенты для таймеров, для UART-ов или количество пустых циклов для программной задержки.

 

Есть два варианта. Первый -- вы вручную (на калькуляторе, на бумажке или еще как-нибудь) посчитли значения коэффициентов, то есть получили числовые константы и напрямую забили их в программый код. Ну, например, вы вычислили, что для задержки 100 мкс вам требуется 36 циклов. Тогда вы тупо пишите:

 

void delay100us(void)
{
  volatile uint8_t i;
  for (i = 0; i <=36; i++)
   ; // do nothing
}

Или для того чтобы UART работал на скорости 9600 бод в регистр UBBRL нужно записать значение 49:

 

...
  UBBRL = 49;
...

В этом коде значение тактовой частоты тоже отсутствует.

 

Во втором случае вы можете в программе задать записать определение констатны, которая соответствует тактовой чатоте процессора. Ну, наприер:

 

#define FCPU (7372800UL)

Тогда в программе для рассчета количества циклов и коэффициента для UBBR прямо в тексте исходного кода може использовать эту константу для вычисления нужных значений:

 

#define FCPU (7372800UL)
#define BAUD (9600)
...
void delay100us(void)
{
  volatile uint8_t i;
  for (i = 0; i <= (FCPU / 324); i++)
   ; // do nothing
}
...
  UBBRL = FCPU / (16 * BAUD) - 1;
...

 

Удобство в этом случае состоит в том, что теоретически вам уже не нужно вычислять все коэффициенты в ручную. Оптимизирующие компиляторы вычисления сделают за вас и в код микроконтроллера попадет уже готовое значение коэффициента. То есть компилятор сгенерирует не команды, вычичляющие коэффициент, а уже готовую констатну. Я сказал -- "теоретически". Практически же, понятное дело, лучше такие вещи все-же проконтролировать. У меня по жизни несколько раз были случаи, когда вычисления вылетали за диапазон допустимых значений. Приходилось код подправлять ручками. Собственно, в этом и состоит труд разработчика-программиста.

 

Идем дальше.

 

Теперь занкомиься с понятием "символ". Вы знакомы с этим понятием в узком круге -- буква, цифта или знак препинания. Компиляторы, линковщики и прочиеутилиты рассматривают понятие "символ" как эквивалент имени констатны, имени переменной, имени функции. То есть несколько более расширено.

 

В нашем предыдущем коде символами являются следующие дефиниции: FCPU, BAUD, delay100ms, UBBRL. Какие-то из символов уйдут при компиляции, какие-то остануться вплоть до elf-файла. Ну, например, FCPU и BAUD скорее всего вы уже не найдете в elf-файле? А вот delay100ms -- он будет отаваться долго. Если вы пишите прогу для компа, а не для микроконтроллера, то этот символ также будет присутствовать и в исполняемом файле, если вы ничего специально не предпримите для его (точнее -- для их) удаления.

 

Так вот, символ -- это какая-то программная единица с уникальным именем.

 

До сих пор мы с вам говорили о символах, которые определены в программном коде. Но символы можно также определить (или задать) вне исходных текстов программы. Например, подставлять их в качестве параметра в строку при вызове компилятора:

 

avr-gcc -mmcu=atmega32 -Wall -Os -DF_CPU=7372800UL -c -o myproga.o myproga.c

 

Это почти реальная строка для компиляции файла myproga.c в объектный файл myproga.o. Здесь компилятор -- avr-gcc, тип процессора atmega32, ну и так далее.

 

Обратите внимание на параметр -DF_CPU=7372800UL. Понятно, что эта конструкция определяет тактовую частоту. Но как! Имя "F_CPU" -- это ни что иное как символ. Конструкция "-D" -- это имя параметра. Черточка '-' говорит компилятору, что далее последует имя ключа. (В Виндовсе обычно используется знак '/' а не черточка.) Буква 'D' -- имя ключа, производное от слова DEFINE. И сразу за именем ключа следут имя символа. С непривычки это , конечно, кажетя одиозным! Чужая идеология, чужие понятия, чужие ценности. Но тот, кто постоянно этим пользуется не видят вообще ни каких проблем. Проблема чистов перестройке мышления. Однако, мы отошли от темы!

 

Так вот. С точки зрения компилятора, ему нет никакой разницы в том, откуда к нему пришел тот или иной символ -- из исходного теста программы или из командной строки. Во время совей работы компилятор составляет таблицы символов. И как в эту втаблицу попадают символы -- дело десятое. Главное чтобы таблица была и была валидной в работе.

 

Ну и наконец нам остается уточнить, что в работе мы используем Makefile. А это занчит, что в Makefile мы можем задать наши определения, например, вот так:

 

MCU=atmega32
CC=avr-gcc
COMMON=-mmcu=$(MCU)

## Compile options common for all C compilation units.
CFLAGS=$(COMMON)
CFLAGS+=-Wall -DF_CPU=7372800UL -Os
...

 

и далее в этом Makefile их использовать для компиляции вот так:

 

 

$(CC) $(CFLAGS) -c -o myproga myproga.c

 

или что тоже самое:

 

avr-gcc -mmcu=$(MCU) -Wall -DF_CPU=7372800UL -Os -c -o myproga myproga.c

 

Ну, вроде бы доходчиво объяснил, откуда что берется.

 

И да! Чуть не забыл. Если вы посмотрите на проекты, в которых используется ARM-ы, то вы увидите, что символы задаются не только в исходниках и Makefile. Символы задаются еще и в ld-файле, который отвечает за сборку проекта. Тут вы найдете такие символы, как адреса начала оперативной памяти, ее размера. начало и размер флешь-памяти. Названия секций (text, data, bss и другие). И многие другие нужные символы.

 

Это по началу кажется очень сложным. Но когда познакомишься с "механикой", то начинаешь приходить к мысли, что ты реально Бог для своего проекта. Всё, абсолютно всё в твоей власти. И ты четко понимаешь как всё устроено и как на выходе получается код. Всё открыто, всё прзрачно. И самое главное -- что нужно сделать, чтобы внести те или иные изменения.

 

Ладно. Много напасал. Бодрости духа вам и здоровья! Остальное добудете сами!

 

[alexxx86 0]

zhevak, Получается что если проект состоит из не скольких файлов, и допустим в каждом файле используется delay функция, для которой необходимо знать тактовую частоту. И чтоб не указывать в каждом файле F_CPU, можно ее указать один раз в makefile. И тогда компилятор сам подставит ее там где она необходима. Я правильно понял?

 

Указав MCU мы сообщаем компилятору с каким микроконтроллером работаем чтоб подключить необходимый файл <avr/ioXXXX.h>?

[zltigo 1]

:( А должно быть так, чтобы без напряга переходить к равноправным формам представления информации.

Хотеть, накарябать мышкой на экране, например, роутер и получить его не вредно, но не реально. Хотя и эта задача словами ставится быстрее и однозначнее - "сделай роутер" :) - и ничего рисовать не не надо :).

 

Я правильно понял?

Ничего Вы не поняли :(. Все, что Вы написали можно сделать разными способами, в том числе, конечно, в make, но это скорее решение через анус, которое рожают, как правило только безумные генераторы маке файлов из всяких IDE сшивающие белыми нитками всякие "универсальные" заготовки в малочитаемое макроме. Первое, что надо сделать, это НЕ читать такой ужас, а просто медленно и спокойно начинать выражать свою мысль. make МНОГО проще, нежели может показаться при попытке изучать его по творениям автогенераторов.

 

[alexxx86 0]

zltigo, Ну если я ни чего не понял, тогда объясните пожалуйста тогда зачем в makefile указывается F_CPU и MCU.