Пусть располагается, имя файла не играет большой роли. Мы точно так же можем включить в interrupt.c заголовок Timer.h с тем же содержимым, ничего принципиально не изменится. Клиенты видят единственную функцию для доступа к счетчику тиков, внутрь модуля доступ закрыт.

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

Не совсем так. Функцию записи можно вынести в отдельный интерфейс, скажем, TimerModify.h . Этот интерфейс включаем лишь в те избранные модули, которые имеют право модифицировать часы. Все остальные работают с таймером через общедоступный интерфейс только на чтение. Это принципиально отличается от глобального варианта, ведь выставив объект на всеобщее обозрение, мы теряем дальнейший контроль над его модификациями.

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

Хорошо, а как обработчик будет модифицировать статик переменную-счетчик, если она расположена в timer.c? Инклуд timer.h ничего не даст... Во всяком случае как в примере выше.
Вторую часть сейчас почитаю...
Почитал. Но возражения есть. Которые не совсем удобно приводить на абстрактном примере - лучше конкретный - безо всяких дополнительных фишек типа проверок допустимости действий и значений. Если не трудно, на примере выше...

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

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

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

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

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

Немного не так. Мы договорились, что вынуждены разместить все обработчики внутри interrupt.c . Счетчик тиков (статический) также локален в этом модуле, и в нем же определена (глобально доступная) функция доступа к счетчику. Объявлена она в интерфейсном модуле timer.h, который включает interrupt.c и все клиенты, которые заинтересованы в получении текущего времени.

Хотя не вижу объективных причин группировать все обработчики прерываний от логически независимых устройств в один модуль. Большой модуль - это всегда лишние проблемы.

Т.е. реализация функции в interrupt.c, а прототип - timer.h? А в interrupt.h как указать прототип функции доступа? Получается сам модуль timer вырождается в прослойку, не особо нужную (что останется в timer.c?). Предложение вынести обработчик в interrupt.c было сделано, чтобы показать что он не должен быть привязан к конкретному си-модулю. Сейчас мы тики считаем, потом флаги ставим, периферию вкл/откл и т.д. По этой логике получается, что все эти разнородные данные, структуры и макросы надо вставлять локально именно в тот модуль, где находится сам обработчик, несмотря на то что логика построения модулей будет рушится? Когда появится чуть времени, я сделаю специальный тестовый компилируемый проект на winavr, на котором можно потренироваться и увидеть воочию.

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

Точно.

interrupt.h может вообще не понадобиться. Весь сервис модуля прерываний, который обслуживает несколько разнородных ресурсов, мы можем вынести в независимые интерфейсы типа timer.h, pwm.h, uart.h и так далее. Главный принцип - "меньше знают, крепче спят". Тот модуль, которому нужен таймер, необязательно работает с UART, и наоборот. Если кому-то нужно несколько ресурсов этого модуля - пусть инклюдит несколько интерфейсов, остальные не видят лишнего.

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

Для подобных задач (например, модификация флагов по событиям от таймера и т.п.) есть очень красивое решение - паттерн MCH (Model-Conductor-Hardware). Он очень похож на паттерн "Модель-Вид-Контроллер", по которому строятся многие приложения для настольных компьютеров, и эффективно отделяет оборудование от логики приложений. Но к нему вернемся при случае, а то получится большая каша. Сначала поставим точку на глобальных объектах, а то погонимся да двумя зайцами.

См. выше (MCH).

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

Вопрос: как избавиться от глобальной переменной?

Ответ:
1. Ограничить видимость этой переменной в пределах модуля (в C это static, для Pascal пример см. выше).
2. Создать глобальную функцию для доступа к содержимому этой переменной на чтение и поместить ее объявление в интерфейс (в С это заголовочный файл).
3. Если нужна модификация содержимого переменной, сделать глобальную функцию для записи значения в переменную и поместить ее объявление в интерфейс. Если право на запись нужно ограничить, то вынести эту функцию в отдельный привилегированный интерфейс, который доступен только некоторым модулям.

Вопрос: какую пользу мы получим от этого?

Ответ: Прежде всего защиту от случайной модификации значения глобальной переменной. Не каждый модуль, имеющий доступ к значению, может его изменить. Кроме того, исключены коллизии имен (например, в случае опечатки). Также можно включить контроль целостности значений (например, если у нас есть глобальная структура календаря в формате день-месяц-год, функция записи не позволит записать в него 47 число 15-го месяца).

Вопрос: чем мы за это заплатим?

Ответ: Возможно, небольшими накладными расходами на вызов функции во время выполнения программы, плюс несколько "лишних" строк в исходниках.

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

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

Вопрос:
Являются ли глобальные переменные вселенским злом?

Так вроде бы это и есть те самые глобальные переменные, о которых мы говорили. Объявление extern совместно с определением без оного создаст глобальный символ в объектном файле, который виден всем желающим.

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

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

Только в том модуле, в котором есть второе дублирующиеся объявление. Аналог инклуда интерфейса.

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

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

Для контроллеров - однозначно, скорее потому, что других все равно фактически нет, выбирать не из чего. Для "больших" приложений давно уже слабоват, да и немудрено, при таком почтенном возрасте... Он еще ЭВМ-монстров третьего поколения помнит.

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

а можно ссылочку, а лучше сразу перевод.

Конечно. Перевел я пока только две из них, самые вводные:

http://club.shelek.ru/viewart.php?id=335
http://club.shelek.ru/viewart.php?id=337

Оригиналы находятся на сайте фирмы Atomic Object, которая является разработчиком упомянутых инструментов для тестирования:

http://www.atomicobject.com/pages/Papers
http://www.atomicobject.com/pages/Embedded+Practices

Здесь я выбрал статьи, которые относятся непосредственно к MCH:

http://www.atomicobject.com/pages/Searc ... &q=MCH#477

Ну и еще с недавних пор я, не надеясь на дырявую память, веду небольшой дневничок, куда заношу заметки о прочитанных книгах и статьях. Там должно быть кое-что из других источников: http://forum.shelek.ru/index.php/topic,26526.0.html

пасиб.