Добрый день! Работаю на МК с fat fs. Подскажите пожалуйста как грамотнее и красивее организовать хранение параметров в файле, затем самим контроллером парсить и модифицировать отдельные значения в таком файле?

сделать структуру, которую целиком сохранять как отдельный бинарный файл. Для модификации читаете файл в структуру в ОЗУ, модифицируете отдельное поле структуры, сохраняете файл. Это самый легкий и быстрый путь если структуры небольшие и есть достаточно ОЗУ (для скорости доступа еще хорошо если длина файла не более одного кластера).
Можно конечно и по сдвигу работать с тем же файлом: читать-модифицировать только нужное поле (известное количество байт, начиная с известного сдвига от начала файла).

Но на самом деле вариантов много, и все зависит от текущей ситуации и от того какая оптимизация важна (по ОЗУ, по длине кода, по скорости выполнения, по длительности доступа к носителю....)

Имхо, гораздо удобнее иметь текстовый конфиг:

• Человекочитаем (можно достать карточку и глянуть, что там);
• Можно отредактировать на ПК;
• Можно спокойно добавлять параметры, и файл по прежнему прочитается;
• Это круче, наконец!

Несомненно. Единственный минус - процедура модификации получается достаточно громоздкой.

Модификации - в смысле считал/изменил/сохранил? Или имеется в виду добавление нового параметра в прошивке?

Да.

Хотя сама ситуация очень нетривиальная- правка файлов контроллером.
Если это конфиг: он правится на компьютере
Если это собираемые данные: они не правятся а дописываются или файл утилизируется целиком.

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

Вот довольно небольшая реализация

Зависит от сценария использования параметров.

Раньше использовал очень простой подход.
Объявлял все параметры как члены одной структуры. И сохранял эту структуру одной командой fwrite в файл.
Первоначально файл создавался в файловой системе самой программой при первом запуске со значениями по умолчанию.
Далее параметры правились через какой-нить интерфейс пользователя в дивайсе.

Сложнее приходилось когда надо было этот файл заранее создать в FS, чтобы избавить пользователя от ручного ввода.
Тогда писалась программа на PC.

Этот метод и поныне благополучно используется в промышленных дивайсах.
Например в частотных преобразователях OMRON которые славятся своей универсальностью и в которых параметров более трех сотен используется такой примитивный метод.
Все параметры они умудрились представить одно или двух байтными числами каждое со своим масштабированием. Никаких проблем с типизацией. Адаптировано для правки на 4-х позиционном 7-и сегментном индикаторе. Удобно при работе через протокол MODBUS. Для компа имеют свою специализированную программу.
Но это настоящий кошмар для наладчиков.
Каждый год с выходом новой версии прошивки частотника старые файлы параметров перестают подходить к новой партии частотников. И надо опять искать того гуру который конфигурировал параметры чтобы их заново адаптировать.

Потом я перешел на текстовые файлы в стиле .INI где параметры хранились в виде пар [имя]=[значение]
Информация о типах переменных по прежнему хранилась жестко в программе.
Но в .INI файлы можно добавлять коментарии. Это сильно упростило передачу таких фалов в управление в чужие руки.
Поначалу был примитивный парсер .INI файлов и юзеры из под копьютеров с разными операционками умудрялись туда внедрять невидимые служебные символы от которых парсер сбивался. Появилась необходимость делать валидатор .INI файлов с неясной доморощенной спецификацией.

И тогда я перешел на формат JSON.
Он прежде всего интересен своей точной спецификацией. Его можно проверить в куче онлайн валидаторов. Т.е. гарантируется абсолютная синтаксическая чистота.
В JSON параметры хранятся также в формате [имя]=[значение], но при этом еще и в виде иерархических структур.
Тип параметров можно описать в самом файле JSON. Очень удобно для передачи строковых параметров. Поддержка UTF8, т.е. строки могут быть на любом языке.
Наличие у каждого параметра имени сильно упрощает обращение к ним из скриптов или при создании HTML страниц редакторов параметров.
Обратная генерация JSON файлов правда несколько сложновата, поскольку для embedded дивайсов я не нашел исходников такой фичи.
Это связанно с тем, что нет единого стандарта на представление JSON структуры в памяти контроллера.
Я пока остановился на древовидных структурах в динамической памяти реализованных на списках.
Генерацию реализовал, но без сохранения форматирования, а без форматирования JSON становиться нечитабельным.

Спасибо за наводку на JSON!
Куда читабельнее xml'я!

Размер архива напугал. Оказывается, там pdf

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

Спасибо за minini. Цель данной задачи - реализовать "закладки" в mp3 книгах, т.е. они будут прописаны в ini файле на самой SD карте. В догонку сразу второй вопрос: в проекте есть также настройки (структура приведена ниже) , которые должны сохраняться во внутренней флеш-памяти STM32. Как это лучше сделать?

А вот это явно просится в бинарный файл. Если, конечно, структура не будет меняться в каждой новой версии ПО.