по поводу нескольких файлов, где в каждом используется функция delay...
если в каждом файле есть реализация данной функции, то при каждой компиляции исходников потребуется определение всех задействованных имён
в коде.
если в компилируемых файлах нет реализации, а существует просто ссылка (которая в коде обозначена) на delay, то определение потребуется только там
где будет написан код ссылающийся на неё. Т.е. при компиляции исходника содержащий функцию delay.

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



всё очень просто. Если какое либо имя у Вас вызывает вопрос - то смотрите кому оно скармливается. Ну например компилятору.
Далее вызываете из командной строчки компилятор с ключом помощи и читаете про ключик который стоит перед этим именем.
Далее становится понятно, что либо это использует сам компилятор(как пример) как управляющее слово, либо он его передаёт
в пространство имён на этап компиляции(как пример).

Именно в makefile, а не, например, в Вашем персональном хидере, исключительно по дурости для "удобства" автогенератора запихивающего в один файл все, что попало.

1. Про F_CPU.

Да. В целом Вы поняли правильно.

Знающие люди выше уже заметили, что __символ__ F_CPU можно опрелеить где угодно! С точки зрения компилятора процесс компиляции будет успешет, если вы зададите значение в:

1) файле исходного кода (если их будет несколько, то нужно позаботиться о том, чтобы во всех файлах значения были одинаковыми. Иначе все времена разъедутся. Я думаю, это очевидно, разяснять не буду.)

2) в каком-нибудь хэдерном файле, который вы включаете в исходные файлы с помощью директивы препроцессора #include. В этом случае вам уже не понадобится ползать по множеству файлов и согласовывать значения --источник значения находится в одном месте.

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

4) в Makefile. Наверно это наиболее правильное место для указания тактовой частоты. Makefile -- это пульт управления проектом, поэтому всё глобальное лучше выносить сюда. По крайне мере то, что касается всех файлов проекта, уже не придется искать по всем файлам проекта. Однако, по большому счету, значение F_CPU в процессе работы мэйкфайла так или иначе попадат в командную строку при вызове компилятора. То есть это пять же разновидность случая 3).


2. Про MCU. Я не знаю как сейчас делается в Виндовых компиляторах (уже лет 7 как избавился от неё). Я расскажу как это делается в gnu-компиляторе под Линуксом. А как оно будет под Виндой, я думаю, по аналогии Вы и сам догадаетесь.

Допустим, в командной строке при вызове компилятора вы передаете параметр MCU=atmega328p.

В каждом файле с исходным кодом должен быть "прописан" хэдер:



Причем, эта директива должна прискутствовать в любом исходнике независимо от типа AVR-микроконтроллера. Иначе говоря, сегодня вы пишите код для ATMEGA168P, а завтра вам нехватило ресурсов и вы решили перейти на ATMEGA328P. Для этого шага вам достаточно поменять тип процессара в Makefile. Ползать по всем исходникам не надо!

Теперь идем в директорий /usr/lib/avr/include/avr и открываем файл io.h. В нем есть такие строчки:



Ага! Значит, комппиялтор подцепит правильный заголовочный файл, где определены регистры и другие ресурсы нашего микроконтроллера.

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

Ну, вот так, господа! В компиляторе "зашита" таблица соответстви этих имен. То есть компилятор из командной строки считывает "atmega328p", затем производит поиск в этой таблице, и в таблицу символов попадет "__AVR_ATmega328P__", а не "atmega328p". А далее, всё идет традиционно. Зачем так это сделано, я не знаю.

zhevak, Спасибо вам большое, за подробные и развернутые ответы!!! Вроде более менее все уяснил)))

А чем эта вдруг стала какой-то особо глобальной и какой-то особенной? Чем это число лучше какой-нибудь другой частоты, типа SPI, или немалого количества ключей условной компиляции? C чего это она вдруг стала касаться всех файлов проекта? И почему это вдруг остальные можно "искать по всем файлам проекта", а ее нельзя? Вообще-то никакие дефиниции не стоит искать по всем файлам и посему правильно сложить их в ОДИН общий заголовочный файл, а не разбрасывать по разным да еще в make запихивать для полного счасттья

А за такое, как Вы описали, вообще надо бить больно. Вместо того что-бы написать в одном общем хидере
#include <avr/iom328p.h>
разводится пляски с MCU. Ну откуда сие растет понятно - из демок - там один исходник для какой-либо супер-программы типа "контроллер светодиода", которой пофиг под чего ее компилируют, посему и один "универсальный" исходник, да и один развестый make кторый собирает за раз 999 прошивок. Реальность обычно другая, но попугайничают по образу и подобию


А вот за это действительно Спасибо!

А вот тут препроцессор будет громко материться:

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

-- У тебя мама был? Папа был? А почему злой, как собака?

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

Я у Вас, или кого либо простил что-то исправить? Вроде нет. А вот Автор, точно спрашивал, как и что делать.

Я могу, посему НЕ пользусь и посему считаю необходимым не только благодарить, но и критиковать, то чем НЕ пользуюсь и что приходится переделывать за творцами (а то и "творцами" ) реализующими прежде всего свои собственные цели.
А лично Вам http://electronix.ru/forum/index.php?showt...t&p=1358239 я спасибо говорил. И еще не раз могу повторить - спасибо! Спасибо за то, что взяли на себя труд ПОДРОБНО начать разьяснять непонимающим приемы работы и один из инструментов, который позволяют им НЕ быть рабами всяких "атмелов" c их "студиями" с галочками.

@zltigo
Мои извинения. Наверно я не правильно Вас понял.

Все номально!

нетривиального makefile вообще как-то не хочется... потому что они никогда не работают как надо.

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

Рискну пойти против течения... но в абсолютному большинству makefile не нужен, и более того, ошибочно построенный makefile опасен для собираемого проекта. Для сборки и работы с проектами, состоящими из 10-20 файлов, вполне достаточно скрипта или bat-файла в духе

Основное преимущество makefile перед подобного рода скриптами сборки заключается в возможности построить четкую иерархию проекта, то есть зависимости одних файлов от других, и при модификации одного файла не пересобирать все файлы заново, а только те, которые зависят от отредактированного файла. В этом же состоит и опасность - при неправильно описанной иерархии проекта можно попасть в ситуацию, когда файл отредактирован, а изменения не вступают в силу по причине того, что make не видит изменения цели сборки, и соответственно не перекомпилирует нужные файлы. Особенно это касается заголовочных файлов.
Поэтому если весь проект компилируется не более 10 секунд, смысла влезать в ручное написания makefile нет никакого, проще пересобирать всё. Ощутимую экономию времени make приносит на проектах объема порядка линуксового ядра.

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

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