#include - оптимальное использование директивы

[hacker7]

"Так вот вопрос - где та грань, которая будет самой правильной? "
Зависит от ситуации.
Смотря какой проект.
Если собирается с готовых кусков, то играем в те игры, какие там. Нужно корректно состыковать, чтобы работало, хоть это и некрасиво и неправильно, но если заработает, то и будет правильно.
Если делаю сам почти с 0 (а это на поверку куда удобнее и легче, чем кажется), то делаю три файла. Первый - это код в стиле старых первых Паскалей. main в конце, остальные процедуры в порядке, обратном использованию (т е те, на которые ссылаемся, выше). Второй файл - это собственный .h , в котором описаны глобальные переменные. Их немного. Третий файл - ещё один .h, в котором только константы, в т ч настроечные. Всякие системные stdio.h и т п тщательно инклудируем в соотв с инструкцией к оным, и не иначе. И не забываем, т к употребление библиотечных ф-ций БЕЗ соотв include может как бы пройти, на самлм деле будет незаметное неправильное с типами данных.

[mike-y-k]

CERGEI1982, своя ось - это просто очень много датчиков, иногда с совсем не очевидными связями… Так что после сотого датчика можно и повысить свой уровень.

Собственно все высокоуровневые обертки как раз и есть попытка изобразить для программиста некую операционную систему.

Дальше уже вопрос из начала hollywar - а нужно ли это?
Кому-то проще решать сразу и системные и прикладные задачи, а кому-то ближе прикладное программирование и проблемы с железом он предпочёл бы вынести из сферы своих интересов. Тут чисто вопрос о фломастерах, а о них спорить совершенно бессмысленно.

[Исбанни]

main в конце, остальные процедуры в порядке, обратном использованию

Весь код в одном файле - так далеко не разгонишься. Хватит только на примитивные мигалки или опрос датчика и УАРТ. А если больше, то это будет то, о чем писал Эдди - файл на 15-20 тысяч строк.

собственный .h , в котором описаны глобальные переменные.

Да, попробуйте инициализовать переменную в файле .h ))

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

[mike-y-k]

STM32F0, достаточный для класса задач уровень абстракции системного уровня от прикладного - уже операционная система.
Собственно они и создаются для исключения ситуации со 101-ым .
Ну а если он не был учтён в исходной абстракции, то просто поправить ее под новые реалии.
Таки новое устройство или протокол в любой OS с достаточной долей вероятности требуют новых драйверов, смены API, протоколов ядра, компонентов ядра, самого ядра,…

[eddy]

mike-y-k, когда-то мне хотелось иметь линукс на МК. Сейчас же, когда есть дешевые процессоры, в этом смысла никакого нет: собираем аппаратную часть на МК безо всякого лишнего говна вроде ртосей, а все вычисление, сеть и т.п. оставляем почти полноценному компьютеру — одноплатнику.

[eddy]

Даже СИ для разных МК со своими прибабахами.

Да ну нафиг! Это где же так? Разве что всякие типичные для конкретного компилятора прагмы...

[eddy]

полтора компилятора

Нет кошерных компиляторов кроме gcc. Все остальное - шлак! SDCC я пользуюсь лишь из-за того, что нет порта gcc для STM8 (а начал я пользоваться sdcc еще в 2009-м что ли, когда PIC надо было по-быстренькому запрограммировать для управления шаговиком через CAN-шину — что под рукой было, от того и пришлось плясать).

[parovoZZ]

Ну тогда такой вопрос.
Где же прописывать пины стандартных портов - SPI, USI, I2C, UART и пр.? И неотъемлемые пины SPI - CE? В файле SPI.h или в файле (ах) драйвера (ов) устройства (ов)?

[mike-y-k]

Вот от качества серого вещества действительно многое зависит.
Если писать код строго на стандарте языка и все зависимое от конкретного железа выносить отдельно - получается минимум проблем при смене железа.
В таком варианте нужно только часть связанную с железом поправить, а не переписывать весь код.
Собственно спецификацию ANSI C/C89/ISO C сейчас поддерживают видимо все компиляторы, значительная часть поддерживает C99. Следование стандартам уже даёт минимизацию геморроя и гарантию переносимости.
Собственные исходники более чем 20 летней давности практически без правок использую… (K&R и ANSI C в чистом виде ).

parovoZZ, планируете только на конкретном МК или семействе - как удобно, планируете переносить или сделать для множества разнотипных - уже стоит подумать о способе вынесения аппаратно зависимой части отдельно и алгоритм писать строго на стандарте.
Собственно в make для этого определяется переменная архитектуры и ее значение в соответствующей переменной уже определяет куски, подставляемые препроцессором.
Да и для локальной версии такой подход вполне подходит - назначения ног вполне выносятся в make и нет необходимости иметь разный/поправляемый код для нескольких плат с разной разводкой или под разные корпуса…

PS В общем случае двух переменных ARCH и ARCH_V вполне хватит
Для множества ARCH типа STM32,MSP430
С наборами вариантов типа STM32F030_1,MSP430F2_4 можно иметь переносимый код без лишней головной боли, с настройкой при компиляции и получением результата в нужных папках. Дальше только залить и пользоваться…

[Исбанни]

В файле SPI.h или в файле (ах) драйвера (ов) устройства (ов)?

Файл SPI.h - это уже и есть заголовочник драйвера интерфейса SPIю В принципе, можно в одной паре файлов совмещать драйвер подключаемого устройства (например, внешнего АЦП или дисплея) и драйвер интерфейса МК. Я это и показывал в коде еще в начале темы, на первой странице, оба варианта. как больше нравится, так и пишите.
Драйвер SPI содержит основные функции:
- SPI_Init
- SPI_Deinit
- SPI_Send
- SPI_Receive
- и макросы или инлайновые функции дергания CS.
Дефайны пинов выносить в SPI.h не нужно, поскольку они используются только в SPI.c.

Если не хотите слишком мелко дробить файлы, можете драйвер подключаемого устройства писать в одну пару файлов: device_drv.c, device_drv.h.
При этом дефайны пинов так же будут лежать только в device_drv.c, потому что они дальше нигде не нужны. Как бы поймите одну простую вещь: device_drv.h нужен только для связи драйвера устройства с остальной прогой, а значит, в него не надо пихать то, что больше нигде в проге использоваться не будет. Вам нигде, кроме этого драйвера, не будет нужен номер пина у MOSI.