[beer_warrior 0]

Возможно несколько :bb-offtopic: ,

но мне кажеться, что это касаеться и AVR.

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

(калибровочные таблицы, включение/выключение некоторых функций, порядок реакции на внешние события)

Некоторое время назад здесь обсуждалась возможность использования скриптовых языков (Tcl,Lua) для подобных целей и Evgeny_CD снабдил меня подробнейшей документацией по этому вопросу, за что ему огромное спасибо. :tort:

Но встраивать в каждый проект интерпретатор дело достаточно трудоемкое и для AVR не всегда выполнимое.

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

Придумывать свой формат откровенно лень(да и времени особо нет).

Из стандартных я знаю ini и xml. ini несколько устарел, да и найти на него готовый парсер достаточно сложно. xml мне кажеться слишком громоздким. Я знаю, что есть готовые компоненты для Билдера и классы в MFC для этих типов данных, но мне хотелось бы максимально отвязаться от конкретной среды и иметь код на чистом С/С++, с возможностью включать его куда угодно.

Итак, кто подскажет, или готовый парсер, или достаточно простой текстовый формат, для описания конфигураций. Кто как поступает в подобных случаях.

[prottoss 0]

Возможно несколько :bb-offtopic: , но мне кажеться, что это касаеться и AVR.

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

(калибровочные таблицы, включение/выключение некоторых функций, порядок реакции на внешние события)

 

Вышеприведенная цитата относится почти ко всем, относительно сложным, изделиям бытовой техники: TV, VIDEO, AUDIO etc. Я, конечно, в этом деле не профи, но может быть это как то поможет Вам...

[beer_warrior 0]

Вышеприведенная цитата относится почти ко всем, относительно сложным, изделиям бытовой техники: TV, VIDEO, AUDIO etc. Я, конечно, в этом деле не профи, но может быть это как то поможет Вам..

Замечательно, только эта техника управляется в диалоговом режиме, через пользовательское или системное меню.Меня интересует, чтобы пользователь описывал, допустим калибровочные коэффициеты, в файле и заливал в EEPROM, через UART или USB, не трогая собсно прошивку. С этим все понятно, а вот от перспективы редактировать бинарный файл образа EEPROM думаю пользователь будет не в восторге. Нужен текстовый формат. Причем совершенно все равно будет ли этот файл парситься программой-конфигуратором, или внутри самого девайса. Главное простой и удобный формат этих данных.

[shevek 0]

На мой взгляд редактирование руками XML приближается по сложности к редактированию в бинарном виде

 

Для парсинга внутри устройтва ИМХО проще ini вы ничего не найдете, что вообще может быть проще чем список ключ= параметр?

 

Я бы описал обьектную модель на Си , и возможно сделал для нее несколько оберток для одного\нескольких из скриптовых языков(лично для меня это был бы один из этих: python,ruby, tcl, jscript наверное можно найти и интерпретируемый Си или сделать самому из csh :))

.

Изменено 8 июля, 2006 пользователем shevek

[Atashi 0]

я тоже за ини. зачем усложнять жизнь себе и юзерам?

а если уж проблема с парсером, - да ну его!

просто ОДОА после числа, и никаких имен! или максимум номер в начале строки, с пробелом.

придется, конечно, кому-то быть очень внимательным при вводе, и грубовато... так ресурсы ж хочется экономить, лучше основную прогу на свободу пустить...

[defunct 0]

Замечательно, только эта техника управляется в диалоговом режиме, через пользовательское или системное меню.Меня интересует, чтобы пользователь описывал, допустим калибровочные коэффициеты, в файле и заливал в EEPROM, через UART или USB, не трогая собсно прошивку. С этим все понятно, а вот от перспективы редактировать бинарный файл образа EEPROM думаю пользователь будет не в восторге. Нужен текстовый формат. Причем совершенно все равно будет ли этот файл парситься программой-конфигуратором, или внутри самого девайса. Главное простой и удобный формат этих данных.

Не проще ли просто написать сопроводительную GUI оболочку, которая будет заливать в девайс все что надо. По большей части я поступаю так:

- Вначале пишу подробную доку на еще несуществующие структуры конфигурационных полей (eeprom);

- реализую по доке функциональность конфигурации девайса;

- снабжаю девайс двумя дополнительными командами read/write epprom с указанного адреса и требуемое кол-во;

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

- Оболочка при подключении к девайсу считывает eeprom и отображает пользователю настройки в удобном и понятном виде, а также позволяет изменять эти настройки "мышкой" и заливает их обратно в девайс.

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

 

Tcl/Lui тоже проще разбирать на Host application layer'е.

[Alex B._ 0]

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

Так что наверное лучше идти по пути дополнительной софтовой примочки - отвязать пользователя от того, что там внутри. Если в ТЗ однозначно прописано - правлю сам в любом редакторе - тогда наверное ini-список - параметр-значение.

[defunct 0]

С одной стороны defunct прав (сам так делаю), с другой есть такое желание - отвязать юзера от дополнительных примочек.

....

Если в ТЗ однозначно прописано - правлю сам в любом редакторе - тогда наверное ini-список - параметр-значение.

Не получится все так гладко. В случае с ini-списком все равно должна быть тулза, которая разгребает данные из ини файла и заливает их в устройство. GUI оболочка в этом отношении много лучше.

 

Если есть желание полностью отвязать юзера от дополнительных примочек, тогда достаточно предоставить ему:

- подробную документацию конфигурационных полей. (фактически подробная карта памяти eeprom)

- команды для записи/чтения произвольной ячейки eeprom.

[sensor_ua 0]

Есть у меня весёлая железяка - демокит на PGA309 - такой программируемый усилитель-"кондиционер" для мостовых сенсоров. Все калибровки/конфигурации производятся в обезумевшем от макросов exel-файле, а на выходе безмозглая утилита грузит вниз это всё через компорт. Видел, вроде, на телесиськах в проектах инструкцию на применение activeX в практических целях с exel.

Честно говоря, от пользования таким вариантом остался только один неприятный момент - нужна была какая-то супер-полная версия офиса от мелкомягких, чтобы оно заработало;) но, правда, в доке всё было написано.

[defunct 0]

Есть у меня весёлая железяка - демокит на PGA309 - такой программируемый усилитель-"кондиционер" для мостовых сенсоров. Все калибровки/конфигурации производятся в обезумевшем от макросов exel-файле, а на выходе безмозглая утилита грузит вниз это всё через компорт. Видел, вроде, на телесиськах в проектах инструкцию на применение activeX в практических целях с exel.

Честно говоря, от пользования таким вариантом остался только один неприятный момент - нужна была какая-то супер-полная версия офиса от мелкомягких, чтобы оно заработало;) но, правда, в доке всё было написано.

 

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

 

Не проще ли сразу написать грамотную и красивую утилиту, где все поля конфигурации описаны русским (или англ.) языком и расположены в удобной для поиска форме самими разработчиками девайса. Еще лучше встроить Web интерфейс. Лучше разработчиков все равно никто не сможет сделать утилиту конфигурирования, разве только разработчики совсем не обладают вкусом и никак не заботятся о пользователе. Простота конфигурирования устройства, напрямую зависит от желания разработчков помочь пользователю в этом вопросе. Если разработчику все-равно, что о нем подумает пользователь, тогда утилита будет сложной, кривой, некрасивой и непонятной в использовании. За примерами откровенно г....ых(вставить подходящее по смыслу слово) конфигурационных утилит, которые никогда нельзя делать, далеко ходить не надо (зачастую таковыми являются утилиты, написанные любым крупным гос предприятием СНГ, т.к. вопросы написания конфигурационных утилит на таких предприятиях, как правило, поручаются бывшим студентам-недоучкам). Как говорится, "не буду показывать пальцем", однако в своей практике сталкивался с таковыми и без мата с ними работать никак не получалось.

[SpiritDance 0]

ini несколько устарел, да и найти на него готовый парсер достаточно сложно.

прошу извинить топик дальше не читал. Нате вот лучше библиотечку ANSI C для парсинга ini. Пригодится если не в этом проекте так еще где-нить. :) Я ее уже использовал, при этом пришлось дописать малюсенькую функцию strdup, которую она требовала.

iniparser.rar

[beer_warrior 0]

Спасибо всем, особо SpiritDance за либу.

Ситуация ясна, ini forever :)

[Neuron 0]

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