Действительно, работает Не знал...

Причем 'полный' вариант, который Nikola Kirov предпочитает:
#include "./ARM/ATMEL/i2c.h"
Тоже возможен.

Вообще-то, если Вы говорите о закладке:
Workspace -> <Имя проекта>->Options->C/C++Compiler->Preprocessor

То там в Aditinal include directories:(one per line) путь к include файлам надо указывать без точек перед $POJ_DIR$.... Примерно вот так:


Вышеприведенная запись заставляет искать include-файлы в:
1) Каталоге с самим проектом
2) подняться на 2 вышележащих каталога, найти там директорию Include и поискать инклюдники в ней

Приведенный выше случай каталогов выглядит вот так:


Сообщение отредактировал Николай Z - Nov 4 2007, 18:32

В каталоге с проектом include-файлы ищутся по умолчанию и без записи $PROJ_DIR$\

Проверил Ваше утверждение и удалил верхнюю строку, где один только $PROJ_DIR$\ и получил сразу ненайденные *.h файлы, которые лежат в дирректории самого проекта...

Вывод - ваше предположение - ошибочно как минимум на моей версии...

Сообщение отредактировал Николай Z - Nov 6 2007, 08:33

Проверьте как минимум стандартный tutorial от IAR и убедитесь в обратном.
Я, в свою очередь, имею несколько маленьких проектов, где все исходники и хедеры находятся в папке с проектом. НИКОГДА не снабжал свои проекты строкой $PROJ_DIR$\ (по началу просто не знал о ней). Все файлы видятся с любой версией продукта.
Дело может быть вот в чём, согласно старым добрым Кернигану и Ричи строки #include "file.h" ищут файлы в той же директории, что и исходный файл, строки #include <file.h> ищут файл в директории тулчейна.
Возможно, что Ваши исходники (в отличие от хедеров) лежат не в директории проекта.

Дело в том, что исходники файлов и файл проекта лежат в разных директориях в общем случае - это ни Кернигану, ни Ричи не противоречит... Посмотрите например стандартный проект FreeRTOS. На нем все и проверялось. Проект и пара настроечных файлов лежать в корне - рядом с файлом RTOSDemo.eww в директории ARM9_STR91X_IAR, а исходные файлы в поддиректориях этого проекта - ниже по дереву. Как только убирается $PROJ_DIR$\ - так сразу настроечные файлы FreeRTOSConfig.h, лежащие рядом с RTOSDemo.eww - перестают находиться. Вы же говорите о других файлах - которые расположены в разных подиректориях проекта ниже корневой проекта. Совершенно нормальное положение для файлов любого достаточно большого проекта. И ни к тулчейну ни к исходныс *.c файлам с соответствующим им - упомянутый файл FreeRTOSConfig.h отношения не имеет...

Так что все-таки IAR не зря в свои примеры сам включает $PROJ_DIR$\ - я и взял указанный выше пример - прямо из его exemple-сов и хотя в нем все в одной подиректории - сами IAR-овцы вставили эту строку. В простейшем случае - она возможно и не нужна, но в случае развесистого дерева поддиректорий - частенько необходима и проект FreeRTOS - тому подтверждение..

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

Во всяком случае - указать ее недолго и не вредно. Хуже не указать - а потом искать причину ошибок

Сообщение отредактировал Николай Z - Nov 6 2007, 18:29

То есть вы полагаете, что достаточно указать корень, а все поддиректории "развесистого дерева" будут подключаться автоматически?

А Вы бы прочитали внимательно все от начала и поправку от IgorKossak- и все было бы понятно...

Это я пояснял IgorKossak зачем нужна самая первая строчка в описании путей, которая показывает на корневую директорию проета и не более того.

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

Т.е. ответ на Ваш вопрос - коль скоро Вы его задали такой: Нет я так не полагаю и не утверждал нигде этого - как раз должны быть указаны все необходимые для поиска *.h файлов поддиректории, поскольку компилятор по умолчанию (замечу по теории будет) будет их искать только в директории toolchain-а(или если хотите - в дирректории системных библиотек) и в поддиретории, где расположены текущие *.c файлы. Первые - системные *.h файлы задаются #include <имя.h>, а вторые немного иначе: #include "имя.h"
Полностью я способности IAR-компилятора не исследовал, а вот поправку IgorKossak - я не принял на основании прямой проверки на примере стандартного проекта FreeRTOS - о чем ему и написал.

Сообщение отредактировал Николай Z - Nov 6 2007, 21:18

Так читал. То, что он пишет - мне понятно. И сам использую:
#include <stdint.h> // искать в папке тулчейна
#include <avr/io.h> // искать в подпапке avr тулчейна
#include "Hardware.h" // лежит в той же папке, что и текущий .c
#include "./Radio/Modem.h" // лежит в поддиректории Radio относительно .с-файла, в котором эта строка.
И все работает согласно K&R.Идея FreeRTOS замечательная, а вот написан он левой ногой. Поэтому вместо явного указания пути к файлу относительно корня проекта там все инклюды указаны без путей и как костыль все пути добавлены в список поиска. Т.е. конечно, FreeRTOS без этой строчки не собирается, но это не значит, что такую тактику надо слепо копировать.

Мне тоже понятно его логика и она "по науке" - правильна, если Кернигана и Ричи - следует считать наукой...

Но мой подход - он от сохи... За длительное время использования разных компайлеров я хорошо выучил, что наука-наукой, а отклонения от нее есть сплошь и рядом - потому прежде чем ему отвечать я и проверил, что есть истина в контексте IAR, а что нет. И на основании этой проверки написал ему ответ - ибо практика и прямой эксперимент - есть критерий истинности любой науки..

Тем более что даже по науке - никто не обязывал компилятор искать основной конфигурационный файл в той директории, где собственно лежит файл проекта *.pww
Он обязан искать - к примеру - файл uart.h там где лежит uart.c c #include "uart.h" и рвно там же файл "bla-bla.h", если в файле uart.c есть #include "bla-bla.h", но никак не в дирректории с файлом *.pww или какой либо другой дирректории - пусть она даже и содержит другие файлы проекта, который в проекте FreeRTOS положен этажом выше...

У Вас в IAR - есть выбор - или указывать нужные Вам директории прямо в #include - как относительный путь к ним, либо относительный путь не указывать, но прямо указать в описанном выше мной поле положение директорий для includ-ов, что на мой взгляд - гораздо предпочтительнее в случае проектов типа FreeRTOS, иначе можно просто зшиться при перекрестных ссылках из одной поддиректории проекта в другую... Это в принципе - полезное расширение канонов от бракоделов Кернигана и Ричи...

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

Что же до проекта FreeRTOS - то я не стал бы так категорично его хаять как Вы...
Досточно качественно он скроен. Во всяком случае - пока никаких существенных отклонений от заявленных параметров я в нем не обнаружил...
Запустился на нашей целевой плате с половины пинка... Легко поднялся TCP/IP на ethernet 10/100 и web-cервер...
С UArt-ами таймерами и обработкой прерываний ноль проблем, с запуском 1Гбит-ethernet - тоже... SNMP - тоже жив и хорошо себя чуствует... Остались только пара шагов на пару месяцев и изделие в первом приближении уже готово... А реально начали с ним бодаться - только во 2-й половине августа...
И целевая плата - это совсем не эволюшн-борд... И даже близко к ней не лежит...
======================================
PS: Почему Керниган и Ричи - бракоделы? Это просто - когда они разрабатывали язык С - во время учебы в аспирантуре и работали по совместительству(кажется в лаборатории Bell) - они явно пропустили науку именуемую у нас "теория грамматик и теория языков программирования" - в итоге ими был рожден весьма несистемно устроенный язык C, который в силу неизвестных нам обстоятельств - стал промышленным стандартом и наказанием программистов.... Наверное из-за всех наших предыдущих грехов от момента появления первого компьютера, на котором программировала еще легендарная Ада Лавлейс...

Сообщение отредактировал Николай Z - Nov 6 2007, 23:43

Если будем считать наукой стандарт, это устроит нас обоих? В части #include стандарт согласен с K&R, или наоборот. Если имя файла указать в кавычках - он будет искаться относительно той директории, в которой находится включивший файл, потом (если включен через второй-третий) относительно тех директорий, в которых располагаются эти файлы и так далее пока не дойдет до компилируемого .с, и если и в этой папке не найдет - будет искать в директориях компилятора. Если же файл указан в угловых скобках, то он сразу ищется _только_ в директориях компилятора. Когда вы указываете Additional Include dirs вы добавляете их в список директорий компилятора. Так что зря вы на уважаемых людей (K&R)...Я согласен с таким подходом. Но пока не вижу, в чем поведение IAR отличается от указанного в стандарте?
Согласен, объясняете вы правильно. Теперь смотрите на свою картинку: Вот тут лежит проект для IAR (файл) *.eww тут же *.c и *.h файлы этого проекта Вот тут и закралась неоднозначность. Для этих файлов инклюды будут искаться. А для файлов (в вашем случае ОС), которые лежат в совсем отдельной папке - нет. Нарушена древовидная структура проекта. Консенсус.
Я бы не стал его так категорично хаять, как вы. Как оказалось - он честно выполняет то, что предписано стандартом. Ну а если человек использует его методом Монте-Карло (научного тыка), то тогда конечно, "особенности реализации".

Я хаял не сам проект, а стиль, в котором написаны исходные коды. Структуру #include мы уже посмотрели. Посмотрите в опциях компилятора перечень подавленных варнингов. Писать так - хороший стиль? Эти варнинги убрать легко, но почему-то этого не делается. Обратите внимание, что задачи общаются с ОС, передавая объекты как void*. Компилятор лишен возможности контролировать соответствие типов. Вы можете взять указатель на char и передать его как семафор. Скомпилится молча, но будет ли работать? Непонятно зачем это сделано - чтобы скрыть от пользователя описания структур? Плюсов этого не видно, а минусы я перечислил.

Приводите аргументы. Я не знаю, какие науки _вы_ изучали, а мне язык С кажется устроенным весьма системно. И что-то не слышал про "наказание" от тех, кто им профессионально владеет. Возможно, вы пропустили науку, именуемую "изучение языка высокого уровня С"?

Выдержка из "Полного справочника по C++. 4 издание" автор Г. Шилдт.

Кавычки и угловые скобки, в которых указываются имена включаемых файлов, определяют способ их поиса на жестком диске. Если имя файла содержится в угловых скобках, он должен находиться в каталоге, указанном компилятором. Обычно это каталог INCLUDE, предназначенный для хранения всех заголовочных файлов. Если имя файла заключено в кавычки, как правило, его поиск выполняется в рабочем каталоге. Если файл не найден, поиск повторяется так, будто имя файла содержалось в угловых скобках.

PS. Добавить нечего.

Стиль составления структуры проектов может быть разный у разных программистов.
Для простейших проектов это хранение всех исходников с хедерами (их не более 10) в одной папке с файлами проекта.
Для сложных поектов это древовидная структура папок, которую представил alexander55 и которая применяется, скажем, в Linux и в очень многих проектах в сообществе Open Source.
На эту тему, в общем, спора не возникает, но вот в чём вопрос, зачем держать в корневой папке проекта .c и .h файлы, где по смыслу должны лежать лишь eww, ewp и некоторые служебные файлы среды? Ведь это разные сути.
Ведь это же крайне неудобно (опять же на мой взгляд) хотя бы с той точки зрения, что выделив исходники в отдельную папку их можно всей папкой скопировать и перенести в другой проект. С большими проектами я именно так и работаю, отсюда и моё недоумение тем, что же можно искать в папке $PROJ_DIR$\
В результате вышесказанного мои проекты выглядят примерно так:

"Согласен, объясняете вы правильно. " © - Ваш же...

Это претензия к разработчикам.. Но никакая наука им это не запрещает. И стандарт об этом по-моему ничего не предписывает. Хороший стиль Unix - наверное этому препячтствует - там обычно make-файл рядом с корневыми файлами проекта или в директориях ниже - но он как бы стиль, но не стандарт.


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

А никто с этим и спорить не собирается - минусы тут есть... Но у кого их нет? Покажите мне хоть одного "идеального" разработчика -и я найду у него минимум 10 минусов - было бы желание...
В данном случае - минусы пересиливаются несомненными плюсами разработки и при желании легко снимаются без особенных трудов.

Я полагаю - это тема отдельного разговора, если об этом есть желание поговорить - тут все-таки немного другая тема...

Тем не менее могу назвать то, что обычно относят к недостаткам C, когда рассматривают его с точки зрения теории т.н. "системно построенных" языков.
Вот эти претензии:
1) Слабая типизация объектов... Пример тому - именно упомянутые Вами забитые warning-и... Вернее - это следствие слабой типизации.
2) Плохая "структуризация" программы, которая приводит к тому, что компилятор легко сбивается из-за простой забытой ";" , "," или "скобки" настолько, что даже не способен определить место ошибки... Это приводит к тому, что он диагностирует ошибку зачастую весьма далеко от места ее появления и Вам приходится просматривать в поиске этого места 3-4-5 или больше страниц текста.
3) Синтаксис провоцирующий написание весьма маловразумительных, но очень коротких выражений, кторые мало кто кроме самого автора способен понять за короткое время... Которые никак не повышают эффекитивность работы ни компилятора(сложно написанное и краткое - почти всегда компилируется хуже), ни эффективность работы человека пишушего или вынужденного разбираться в таком коде...

Я думаю - для ответа Вам названных и известных еще 20-ть лет назад недостатков C - более чем достаточно... Если нужно - то продолжение этого перечисления Вы легко найдете в соответствующих форумах где этих "религиозных дискуссий" тьма.

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