[bureau 0]

Вопрос стоит в том, какой формат конфигурационного файла проще использовать... ?

 

К примеру...

Есть идея использовать один конфигурационный файл, в котором будет указано куча параметров, как на микроконтроллере так и для чтения/записи этих параметров внешней программой

Использовать XML, да можно, а есть ли библиотека (parcer) для работы с XML файлами на стороне микроконтроллера?

Может кто знает иные варианты как можно реализовать работу с файлами конфигурации на стороне микроконтроллера?

 

[Гость TSerg]

Если есть доступ к файловой системе на основе какого-либо носителя, то проблема вообще непонятна.

Используйте тот формат, что удобнее.

[bureau 0]

А можно чуть поподробней? В какую сторону копать?

Cortex M3, SD-card...

 

[Ruslan1 16]

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

очень хорошо делить файл на [секции], внутри которых иметь строки вроде "параметр=значение"

Парсить такое элементарно, это практически стандарт.

 

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

 

Нечитаемые по "F3" форматы очень сильно не рекомендую- одни проблемы от них, разве что хотите что-то скрыть или защитить. Но это всегда выходит боком при эксплуатации и обслуживании, создаете больше проблем чем решаете.

 

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

 

вот это как основу можете взять: https://en.wikipedia.org/wiki/INI_file

[Сергей Борщ 119]

посмотрите minINI.

[aaarrr 63]

Использовать XML, да можно, а есть ли библиотека (parcer) для работы с XML файлами на стороне микроконтроллера?

XML не надо, INI или JSON, если нужны более сложные структуры, чем параметр=значение.

[Kane 0]

Использовать XML, да можно, а есть ли библиотека (parcer) для работы с XML файлами на стороне микроконтроллера?

Как вариант, можно попробовать формат JSON. Он проще XML да и в Сети полно разных парсеров. У нас JSON-парсер под STM32 занимает ~4К flash, не больше.

[Ruslan1 16]

посмотрите minINI.

скорректированная ссылка

[AHTOXA 14]

У меня в закладках ещё есть inih.

(Сам не применял, когда понадобилось парсить ini-файл, сделал свой велосипед по-быстрому).

 

[jenya7 0]

XML не надо, INI или JSON, если нужны более сложные структуры, чем параметр=значение.

ну если сравнить

JSON:

{"menu": {
  "id": "file",
  "value": "File",
  "popup": {
    "menuitem": [
      {"value": "New", "onclick": "CreateNewDoc()"},
      {"value": "Open", "onclick": "OpenDoc()"},
      {"value": "Close", "onclick": "CloseDoc()"}
    ]
  }
}}

XML

<menu id="file" value="File">
  <popup>
    <menuitem value="New" onclick="CreateNewDoc()" />
    <menuitem value="Open" onclick="OpenDoc()" />
    <menuitem value="Close" onclick="CloseDoc()" />
  </popup>
</menu>

как по мне ХМЛ выглядит проще и читабельней.

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

 

ИНИ файлом проблемно описать сложносоставные структуры.

Изменено 23 ноября, 2016 пользователем Jenya7

[AlexandrY 3]

Вопрос стоит в том, какой формат конфигурационного файла проще использовать... ?

 

Если будете использовать голые XML или JSON, то сразу встанет вопрос о динамической типизации параметров.

Т.е. распарсите вы данные и в каком типе будете их хранить? В текстовом? В специальных структурах с идентификатором типа?

Обращение к таким данным нарушит ограничения быстроты доступа и вынудит делать критические секции.

 

Чтобы параметры хранились в нативном типе с минимальным временем доступа у вас кроме самого файла параметров должен быть еще и модуль с декларациями всех параметров на нативном языке и модуль сериализации параметров в разные протоколы.

 

Т.е. спрашивать здесь надо не как кодировать параметры в файле, JSON-ом там или CSV, потому как это мелочь. А спрашивать надо как автоматом генерировать фреймворк параметризации.

 

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

Как пример можно назвать SNMP менеджеры.

 

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

[xvr 12]

Еще можно посмотреть в сторону yaml (хотя с непревычки выглядит несколько дико :) )