Keil mVision.Соответственно, есть куча разных функций.Одни для одного,другие для другого, где то они пересекаюся и не редко.В общем, как обычно.Вот вопрос-стоит ли собирать их в разные си файлы и делать кучу extern-ов, или лучше все-таки без особой необходимости этого не делать.Может, надо искать золотую середину?Есть ли какие-нибудь критерии,кроме здравого смысла? На что это влияет?Спасибо

Обычно всегда стараюсь чётко разделить программу на модули, как можно более автономные. Функции, описанные в модулях, выносим в h-файл, и в других модулях его подключаем. Всё как обычно. Переменные тоже желательно разделить, для внутримодульного употребления - static.
Да это и не только для АРМ и Кейла, а вообще нормальный стиль программирования.
Потом я беру, к примеру, модуль Indicator.c, перетаскиваю в новый проект и он без единой настройки сразу работает.
А чтобы не было "кучи extern-ов", нужно в модуле группировать данные и функции для работы с этими данными. Чтобы не было глобальных пересечений и взаимосвязей.

Мы обычно поступаем так. Для примера. Одна пара С и Н файлов - все функции для генерации одного типа штрих кода. В этом файле не обязательно все функции нужны кому-то вовне, они, так сказать, "для внутреннего использования". Такие функции объявляем как static, а прототип такой функции помещаем в начало С-файла, а на в Н-файл. В Н-файл - объявления (прототипы) всех "глобальных" функций. Для совместимости с С++ лучше их сразу обрамить описаниями вида:

#ifdef __cplusplus
extern "C" {
#endif
...
...


#ifdef __cplusplus
}
#endif // __cplusplus


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

Чтобы в будущем не путаться где и что, надо продумать систему именования файлов и библиотек.

Модульность-это хорошо.Я это, безусловно, пинимаю.Такой вопрос-если я забью на модульность и совместимость, получу ли я прирост скорости или там свободного места?

Встречный вопрос: а засчёт чего?
Компилятор транслирует исходники функций в объектный код, линкер собирает из объектов файл прошивки. По большому счёту, им без разницы, в одном файле находятся функции или в 10. (20,50).
Скорость и свободное место - понятия взаимоисключающие.
Нужна скорость - inline и unrolling, соответственно теряем место.
Не хватает места - обратная ситуация, приходится жертвовать скоростью.

Советую почитать книгу
"Анализ программного кода на примере проэктов Open Source"
автор Диомидис Спинеллис.
http://oz.by/books/more1011402.html

Начни с этого:

Последнее ,конечно, полезно, но вообще не в тему

Например, компилятор может самостоятельно встроить функции, используемые только один раз и объявленные как static. Экономия на командах вызова, передаче параметров, прологе/эпилоге.
Некторые функции содержат кода меньше, чем накладные расходы на ее вызов. Или функции-обертки, которые при встраивании вообще не генерят кода. Безусловное встраивание таких функций дает выигрыш и в объеме и в скорости. Если функция не static и тело ее в другом файле - компилятор не сможет ее встроить. Таким образом, некоторые функции модуля целесообразно выносить из .c в .h, добавляя к ним квалификатор static. Они могут потянуть за собой другие. Если же функция большая и используется дважды - получим обратный эффект. Такая оптимизация в любом случае происходит при помощи программиста, и порой в угоду читабельности и модифицируемости кода стоит некторые участки оставить неоптимальными. В противном случае придем у ручной правке ассемблерного кода после компилятора.

Цена: 29 826 руб.


А я бы не советовал. За такие деньги? Нифига себе - оупен сорс!

Ну разница все-таки есть.
Если все в одном файле, и функции объявлены как static. Компилятор может сделать более эффективный код (например повставлять инлайнов там где это не указано явно, повыбрасывать неиспользуемые функции, заменить "дальний" вызов на "ближний" для процессоров где это актуально и .т.п.). С т.з. оптимизации компилятору лучше сразу видеть весь код в одном файле, потому что линкер ничего оптимизировать не будет.

Только читаемость когда "все в одном" будет никакой.

Я уже наверно рассказывал байку.
Едут мужики в Белоруссию в командировку.
На поезде.
Проводница заглядывает в купе: - чай будете?
- Ну да...
Взяли по чашечке.
- С вас 120 рублей.

Потом дошло, что беларусских.
</offtop>
2 Сергей Борщ :
я обычно сам ручками пишу __inline__, не надеясь на компилятор

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

В контексте ARM, если inline выполняется условно, то можно получить участок кода из условно выполняющихся команд. Этот участок (например десяток линейных команд) будет подгружаться и выполняться всегда, но ничего не будет делать когда условие ложно. В итоге быстродействие - страдает.

+1. Сам к этому пришёл, основываясь на горьком опыте. Программы стали значительно более читаемыми. И больше не надо держать в голове всё это хитросплетение из глобальных переменных и функций.
Ещё одно правило - комментарий к каждой функции.


Забивание на модульность приведёт к менее читаемой программе, а в ней потери скорости/памяти возникнут сами собой из-за бардака. И вообще, начинать оптимизировать надо только после того, как необходимость оптимизации была доказана измерениями. Иначе это пустая трата времени. Конечно, это не отменяет того, что выбираемые решения и алгоритмы должны изначально быть реалистичными (к примеру, таблица синусов на 100 кБайт не влезет в МК с 32 кБайтами).

Доллары тоже разных стран бывают, но люди сразу их обозначают.
Доллар США - пишут USD.
Тут тоже могли бы писать - белорубль.

Полезность разбиения на логические модули не обсуждается. Полезно и все.
Еще полезно использовать системы отслеживания версий (VSS, Team Coherence и т.п.).

А по поводу кейла и текста (модулей):
1. Если вдруг понадобится разместить массив констант по определнному адресу, то придется
смотреть описание на кейл и переделывать исходный текст, чтобы это сделать.
Подробно см. директиву линковщика "CO". Пример из реального проекта управляющей строки линковщика "?CO?tb_crc8(0FA00H)" - разместить объект tb_crc8 в памяти CODE по адресу 0xFA00.
tb_crc8 - таблица предвычесленных значений tb_crc8[256].

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

Полезность разбиения на логические модули не обсуждается. Полезно и все.
Еще полезно использовать системы отслеживания версий (VSS, Team Coherence и т.п.).

А по поводу кейла и текста (модулей):
1. Если вдруг понадобится разместить массив констант по определнному адресу, то придется
смотреть описание на кейл и переделывать исходный текст, чтобы это сделать.
Подробно см. директиву линковщика "CO". Пример из реального проекта управляющей строки линковщика "?CO?tb_crc8(0FA00H)" - разместить объект tb_crc8 в памяти CODE по адресу 0xFA00.
tb_crc8 - таблица предвычесленных значений tb_crc8[256].

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

Я уже как-то писал и ссылки давал. Современные компиляторы устроены еще более наворочено и, в частности, используется оптимизация кода на уровне линкера. Лично сталкивался с такими штуками еще в Borland C++ 5.5 Вывод очень простой - максимально полно задавать нужные тебе параметры и опции при компиляции проекта, а не полагаться не режимы "по умолчанию" и грамотно применять расширения языка типа inline, volatile и пр.

С gcc (не знаю просто, как с другими) можно при большом желании и на ёлку влезть, и всё такое прочее.
Если указать в командной строке все .c файлы проекта сразу и добавить ключики -combine (объединить промежуточное представление всех файлов в одно целое) и -fwhole-program (и это объединение - вся программа), то он ведёт себя так, как якобы все функции этого общего представления статические, т.е. снаружи "этого всего" никому не нужны и проводит все эти оптимизации (выбрасывание ненужного, inline-подстановки используемого единственный раз либо достаточно мелкого). Для "окончательного релиза" это может и есть смысл делать.

А вот замены вызовов на ближние делает как раз линкер, причём в том числе при линковке нескольких объектников и делает это в том числе со включенными из бибилиотек модулями.
Ключ --relax

Разве уместен разговор о деньгах когда речь идет о проверенной информации ?

П.С. пардон а Вы не подсчитывали сколько денег Вы потратили на интернет читая этот форум ?

извиняюсь за офф.

У меня безлимитка 20 USD в месяц.
Что позволяет копировать, в среднем, в месяц 300-400 электронных книг.
Что значит "проверенная информация"? Это как рыба не первой свежести?

Лучше прочитать одну, чем скопировать 100.
Причём читать удобнее бумагу.
Я бы вот руководство по GCC с удовольствием купил, так не продают уже, ни за какие тысячи...
А на компе есть, 2 версии, русская и аглицкая. Только толку-то мало. С экрана читать тяжело. Особенно после рабочего дня.

М-м... У вас нет принтера?

Вот это зачОт! Спасибо, не знал о такой возможности.

А ещё функции можно дать атрибут externally_visible и её будет видно снаружи даже при ключе -fwhole-program :-)