Сохранение и загрузка настроек в текством файле

[H4LF]

Найн. Задача сохранять и загружать настройки в файл. Что вовсе не обязательно текстовый.

Йа, ТС написал, что в текстовый, значит надо в текстовый. И не только настройки. Это потом пошли советы писать бинарно. Хотя, может ТС неправильно выразился, а мой старый "компилятор" неправильно понял. Бинарно - конечно будет попроще для реализации в отдельном устройстве, главное не забыть про порядок байт и упакованность/неупакованность структур и другие тонкости, если устройство будет не одно да ещё на разных архитектурах.
Осциллограммы обработанные и "сырые" как-то странно хранить в тексте, но можно. Хотя до 2К байт с осциллограммами вряд-ли получится.
Но в любом случае лучше использовать что-нибудь более-менее стандартное. Тогда и на PC будет проще это обрабатывать, если придётся. Тем более, что "Требуется обмен с другими системами", так что нежелание ТС изобретать свой велосипед вполне понятно.

[Someone]

Йа, ТС написал, что в текстовый, значит надо в текстовый.

Неа. Текст - это его вариант решения задачи

реализовать набор пресетов.

Да, вариант в принципе рабочий, но зело геморройный. Вот например, есть у него в этом текстовом файле имя переменной и её значение. Зачем имя? Только для того, чтобы прочитав строку текста, выделить имя переменной, и если имя = "переменная1", выполнить в программе строку переменная1 = itoa(остаток строки)? Ему ведь потребуется помнить все переменные по имени, типу. Такие проверки строки сгенерируют до хрена кода (относительно встраиваемых, но он-то для такой системы и ищет решение) и выполняться будут не быстро. При добавлении или удалении в программу переменной, надо будет добавлять/убирать её обработку в процедуру чтения и записи, а может и ещё в каких местах программы.

Имея же структуру, всего-то требуется организовать цикл, от 0 до sizeof(структуры) и писать/читать по одному байту, через массив или указатель. Не требуется помнить названия переменных, их количество, тип, переделывать код чтения/записи при добавлении/удалении переменных - структура будет всегда
записана/считана полностью.

[Someone]

Хотя до 2К байт с осциллограммами вряд-ли получится.

Так два кило у него бинарных данных. В текстовом виде, как он написал, будет раз в 10 больше объём.

[akegor]

Осмелюсь догадаться, что текстовый вид нужен для глаз и возможности ручной корректировки.
Если в контроллере организовать структуру структур, которые, скажем, содержат имя переменной, ее адрес, тип и значение, причем (для человека) упорядоченную функционально, то все формирование сведется к одной функции. Так же и чтение в контроллер.
Совершенно нет нужды в произвольном порядке.
Одинаковые устройства с одинаковой легкостью справятся с этой непосильной задачей. Не стоит чрезмерно усложнять.

[H4LF]

Неа. Текст - это его вариант решения задачи

Ну да - мы тут как обычно ищем варианты решения задачи, о которой мало что известно. И ТС об этом даже не просил. Он спросил - известно ли кому-нибудь готовое решение(для эмбедда без ОС) для работы с текстовыми файлами конфигурации. Всё. Может действительно - планируется не только обмен настройками с другими устройствами, но и просмотр и редактирование человеками? Для бинарных - ещё программу писать надо, а текстовый редактор везде есть. Тогда лучше что-нибудь стандартное - как ini или как в никсах.
Но вот для осциллограмм имеет смысл использовать бинарный формат, как например *.wfm у Тектроникса: http://monitor.net.ru/forum/files/wfmtransfer_727.pdf
Но можно и в CSV, у Тектроникса, кстати, есть утилита перевода *.wfm в CSV. Пригодится, если нужно будет скормить данные в какой-нибудь MATLAB или Octave.

При добавлении или удалении в программу переменной, надо будет добавлять/убирать её обработку в процедуру чтения и записи, а может и ещё в каких местах программы.

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

[mike-y-k]

H4LF, ну так и для бинарных есть просмотр и редактирование.
И даже мелькали/встречались программы с возможностью структурного анализа таких потоков (кстати на основе чтения именно описывающих их структур в C нотации) в нормальном для человека формате.
И используя те самые структуры сделать утилиту по выводу/загрузке бинарного/текстового не составит особого труда.

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

[AR_Favorit]

Если использовать правило по добавлению новых элементов в коней

Нажмите, чтобы открыть спойлер

[mike-y-k]

AR_Favorit Спасибо, поправил.
На автокорректор все наступают и даже с некоторой регулярностью.

"Всем свойственно ошибаться" - мрачно бормотал ёжик, слезая с кактуса.

[H4LF]

mike-y-k, Извините, я бы может ещё пофилософствовал о свойственных и несвойственных задачах для микроконтроллеров, удобности/неудобности специальных(и желательно кроссплатформенных) утилит, а заодно и постов бы понабивал... Но не люблю философию - когда из неизвестно откуда взятых предположений делают многозначительные выводы, а на основе этих выводов - ещё более многозначительные. Не конструктивно это. Вот откуда Вы знаете сколько ресурсов у микроконтроллера ТС? Ведь у него Nios II. И какая у него там основная задача? Может сохранение-загрузка с флешки и есть его основная задача, а всё остальное он делает в свободное от этого время?
Если ТС понадобится совет или появится вопрос - он спросит и, надеюсь, даст данные. Тогда можно будет прикидывать дальше.

[mike-y-k]

H4LF, тут совсем не философия, а основы проектирования. По теме были уже и советы, и ссылки. От ТС пока нет информации в развитие темы. А опыт наступания на подобные грабли и выхода из ситуации таки никто не отменял. Такие (такого рода) решения и их последствия встречаются увы весьма часто. Не стоит столь формально сужать обсуждение до "каков вопрос - таков ответ" .