roboforum.ru

Парсер, о котором говорю я умеет следующее.

Наш парсер умеет тоже самое, но его не надо переписывать каждый раз как только вы хотите вызвать другие функции.

зачем?

У вас есть реализация которую не надо править каждый раз когда вы поменяли список вызываемых функций, их параметры, тип этих параметров? Show me the code!

1. Организуем массив1, описыывающий существующие функции:
typedef Tvf struct{
char *fname;
void (*fptr)(char *arglst, int argcnt);
}

2. Парсер при получении строки пробегает по массиву1 в поисках функции, имя которой есть первый параметр в строке. Если такая функция не найда выдается ответ "функция не найдена", иначе идем к пп3

3. Оставшаяся часть строки разбивается по принятому разделителю, формируется массив arglst и передается функции, найденной в пп2.

4. Задача преобразования строк в необходимые типы решается функцией самостоятельно на основе ожидаемых параметров.

Вы предполагаете, что это удобно писать все функции в таком виде?

2mandigit: Ну то есть вы предлагаете по быстрому написать такой же tinyRPC в итоге, или я что-то не понял?

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

2Dead
Не понял вопроса. Решается какая-то конкретная задача, в которой есть потребность в тиниRPC и если не использовать ее, то надо предложить замену? Или мы обсуждаем сильные/слабые стороны какой-то идеи?
если 1, то используйте на здоровье tinyRPC или еще что-то, что сочтете полезным, я-же не запрещаю
если 2, то я для себя пытаюсь из предложенной идеи найти какие-то полезные кусочки, потому и строю диалог на основе "отрицалова", поскольку поддержавших много и автор будет чувствовать себя вполне уверенно

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

Выстроив этот механизм и избавившись (путем кодогенерации) от...

...при добавалении/изменении функции вы будете вносить код только в этот механизм...

вы получите TinyRpc.

mandigit писал(а):Не понял вопроса. Решается какая-то конкретная задача, в которой есть потребность в тиниRPC и если не использовать ее, то надо предложить замену? Или мы обсуждаем сильные/слабые стороны какой-то идеи?

Я просто пока из того что вы говорите вижу, что вы решая аналогичную задачу плавно строите второй tinyRPC
Или это мне одному кажется?

PS: Нет, только одному

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

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

Вы пытаетесь найти "идеологию" там где ее нет. TinyRpc делается не для идеологии, а для удобства работы.

Тогда давайте оценим удобство работы?
Я не зря упоминал ранее о терминальном режиме.Какие удобства предоставляет предложенная система? Качество отладки? Управляемость? Масштабируемость? Функциональность?

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

Правильно?

Я пока никак не могу врубиться в одну практическую вещь. Специальная утилита компилирует функцию для последующей загрузки в МК с учетом конкретного МК? Или для вставки в CAVR, например? Взять тот же замер температуры. ПК запросил у МК текущую температуру по UART. Для этого ПК должен, например, соединиться с датчиком температуры, подключенном к определенным ногам по I2C, перевести полученные данные в удобоваримый вид и передать на ПК. Понятно, что скомпилированный код функции не может учитывать этих аппаратных особенностей. Т.е. все равно придется с ним разбираться и его как-то дополнять. А разобраться с чужим кодом всегда сложнее, чем свой написать. Наверное я что-то недопонял.

Тогда давайте оценим удобство работы?

Скачайте и оцените. Наверняка появится куча замечаний, мы их постараемся учесть.

Наверное я что-то недопонял.

Это действительно так.
Объясняю. Вы делаете термометр, используя при этом Ардуино.
Для того чтобы прочитать информацию с датчика температуры вы написали какую-то функцию:

Код: Выделить всё

double Temp()
{
//Здесь вы читаете датчик.
}


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

Код: Выделить всё

double Temp(); //Прототип
double Temp()
{
//Здесь вы читаете датчик.
}


После этого жмете кнопку "RPC" в Ардуино IDE и получаете файл RemoteObject.cs в котором содержится класс на C#, который позволяет вызывать функции вот таким образом:

Код: Выделить всё

var arduino = new RemoteObject("COM10", 57600); //Здесь указан порт и скорость по которым можно достучаться до ардуино.
double temp = arduino.Temp(); // Здесь в переменную temp упадет результат выполнения функции Temp() на ардуино.


Вот собственно и все.

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

Вроде всё так, именно это, если я не ошибаюсь, и называется RPC