[EdgeAligned 53]

1. Скажем так. По натуре, не люблю беспорядок, даже "творческий". Поэтому, собрав разный чужой и свой опыт разнообразных вариантов, пришел к некоему среднему знаменателю, более-менее просто описывающему структуру в общем. И на верхнем уровне папкки рабочего проекта выглядят так:

App (Application)
Middleware
RTOS_Source (если используется)
System
Drivers
Docs

В App находится в том числе и файл main.c (.cpp), а так же файлы и папки, содержащие верхний уровень абстракции - уровень приложения.
Middleware - утилиты и сторонние библиотеки, связь между системным и прикладным уровнем.
RTOS_Source - исходники ОС, если оная используется. Структуру её каталогов сохраняю оригинальной и не изменяю файлы - это хорошая практика, и если обновляется версия ОС, просто берется новое и вставляется один-к-одному. Да и порядок всегда в порядке. Эту папку можно поместить в папку System, но я вынес её отдельно для удобства. 
System - стартап, начальный конфиг микроконтроллера, прочее общесистемное, не имеющее отношения к конкретному проекту.
Drivers - ну это и так понятно. Исторически сложилось, что при создании проекта файлы CMSIS среда кладет в папку Drivers, поэтому там их и оставляю.
Папка Docs - документация в стиле doxygen, если требуется. Нередко туда же по потребности кидаю даташиты, чтобы при переносе проекта с компа на комп иметь под рукой документы на то, с чем работаю в данный момент.
Насколько глубоко используется вложенность папок? В среднем, один-два-три уровня, раскладывая в папки по принадлежности - котлеты к котлетам, макароны к макаронам. За исключением сторонних исходников, там оставляю всё как есть.

2. Папки App и System, плюс те, которые требуются для сторонних исходников, например для FreeRTOS. Ну и два пути для CMSIS, сгенерированные автоматически при создании проекта. Это  - минимально требуемый конфиг путей. Все остальные пути и инклюды в файлах среда разработки может сгенерировать автоматически. Так же, при ручном прописывании инклюдов и последующем рефакторинге или перемещении, среда так же может автоматически вносить изменения. Хорошая среда разработки должна иметь инструментарий для автоматизации рутинных операций.

Да, встречал вариант организации, когда есть папка inc (include), куда навалены все заголовочники. Тоже вариант, используется например в исходниках FreeRTOS, достаточно хорошо показан пример. Подходит для тоого, чтобы явно указывать папку, которую нужно подключать в путях проекта.

[Arlleex 131]

Понял, спасибо. Примерно похожих подходов придерживаюсь и я. Правда, папок и уровней вложенности несколько больше.

Например, папка sources (рядом с файлом проекта IDE) содержит папки (в порядке иерархичности):

• application (здесь находятся исходники "верхнего" уровня приложения, в основном это main);
• services (тут живут сервисные процессы (задачи) RTOS, которые запускает и контролирует application);
• middleware (сюда помещается все заимствованное ПО "промежуточного" звена: RTOS, сетевые или USB-стеки, например, и т.д.);
• generic (некая библиотека обобщенных алгоритмов: всякие расчеты CRC, кодирование, шифрование и т.д.);
• platform (платформо-зависимые потроха).

Такой структурой "вырисовывается" практически любая архитектурная модель embedded ПО, коих рисуют в интернетах великое множество.

Естественно, внутри каждого каталога уже есть некая конкретика: например, в platform лежат папки drivers и target. В первой - драйверы "железа", во второй - все что относитя к целевому вычислительному компоненту - будь то МК, CPU или что-то среднее.

Естественно, содержимое некоторых папок уже совсем не конкретизировано, та же папка platform/drivers будет иметь совершенно различное наполнение, в зависимости от потребностей проекта.

Это что касается исходников. Рядом с sources у меня еще лежит, например, папка utilities: тут кладутся различные проектные хелперы - скрипты формирования бинарников, их "редактирования" для внеднерия контрольных сумм, совмещения нескольких бинарей (например, загрузчика и основного ПО) и т.д.

[EdgeAligned 53]

Поскольку в обсуждаемой сфере нет единых утвержденных стандартизованных правил, подобных ЕСКД в машиностроении и строительстве, то разбивка по каталогам и их названия делаются так, как понятно самому себе или как принято в вашей рабочей группе или организации. Именно потому и существует такое великое множество разнообразных вариантов структуры и наименований. В принципе, даже файл main.c и функция main() не являются обязательными названиями - можно назвать как угодно.

Да, а всёж хорошо было бы иметь ЕСКД в этой сфере 🙂 Тут и "нормоконтроль" подтянется, и графы "Разраб.", "Пров.", "Утв." появятся. "Т.контр.", "Н.контр." - всё строго, не забалуешь - нормоконтроль завернет проект с нестандартным именем каталога или неверной раскладкой файлов 🙂 
Ну а пока что остаются просто некие соглашения, принятые в рабочей группе, или некий путь "джедая", выбранный одиночным разработчиком.