Управление роботом с компьютера. Новый подход.

Виталий

Цитата:

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

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

mandigit

зачем?

Виталий

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

mandigit

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

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

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

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

Виталий

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

=DeaD=

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

mandigit

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

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

если 2, то я для себя пытаюсь из предложенной идеи найти какие-то полезные кусочки, потому и строю диалог на основе "отрицалова", поскольку поддержавших много и автор будет чувствовать себя вполне уверенно :friends:

Виталий

Цитата:

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

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

Цитата:

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

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

=DeaD=

mandigit писал(а):

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

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

Или это мне одному кажется? :oops:

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

mandigit

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

Виталий

Цитата:

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

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

mandigit

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

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

Правильно?

Scorpio

Я пока никак не могу врубиться в одну практическую вещь. Специальная утилита компилирует функцию для последующей загрузки в МК с учетом конкретного МК? Или для вставки в 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() на ардуино.

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

=DeaD=

mandigit писал(а):

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

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

roboforum.ru

Управление роботом с компьютера. Новый подход.

Кто сейчас на конференции