Парсер, о котором говорю я умеет следующее.
Наш парсер умеет тоже самое, но его не надо переписывать каждый раз как только вы хотите вызвать другие функции.
roboforum.ru
Технический форум по робототехнике.
Управление роботом с компьютера. Новый подход.
Re: Управление роботом с компьютера. Новый подход.
Наш парсер умеет тоже самое, но его не надо переписывать каждый раз как только вы хотите вызвать другие функции.
Re: Управление роботом с компьютера. Новый подход.
У вас есть реализация которую не надо править каждый раз когда вы поменяли список вызываемых функций, их параметры, тип этих параметров? Show me the code!
Re: Управление роботом с компьютера. Новый подход.
1. Организуем массив1, описыывающий существующие функции:
typedef Tvf struct{
char *fname;
void (*fptr)(char *arglst, int argcnt);
}
2. Парсер при получении строки пробегает по массиву1 в поисках функции, имя которой есть первый параметр в строке. Если такая функция не найда выдается ответ "функция не найдена", иначе идем к пп3
3. Оставшаяся часть строки разбивается по принятому разделителю, формируется массив arglst и передается функции, найденной в пп2.
4. Задача преобразования строк в необходимые типы решается функцией самостоятельно на основе ожидаемых параметров.
typedef Tvf struct{
char *fname;
void (*fptr)(char *arglst, int argcnt);
}
2. Парсер при получении строки пробегает по массиву1 в поисках функции, имя которой есть первый параметр в строке. Если такая функция не найда выдается ответ "функция не найдена", иначе идем к пп3
3. Оставшаяся часть строки разбивается по принятому разделителю, формируется массив arglst и передается функции, найденной в пп2.
4. Задача преобразования строк в необходимые типы решается функцией самостоятельно на основе ожидаемых параметров.
Re: Управление роботом с компьютера. Новый подход.
Вы предполагаете, что это удобно писать все функции в таком виде?
Re: Управление роботом с компьютера. Новый подход.
2mandigit: Ну то есть вы предлагаете по быстрому написать такой же tinyRPC в итоге, или я что-то не понял? 
Re: Управление роботом с компьютера. Новый подход.
Предполагаю, что функции предназначенные для взаимодействия с внешним миром должны подчиняться стандарту. А внешний мир не должен заботится о том, каким именно образом функция решает свою задачу.
Если более удобно - можно выстроить центральный механизм, который будет решать задачу взаимодействия между парсером и функциями. Он будет вызывать функции в их оригинальном исполнении, но этот механизм скрыт от внешней системы. Тогда при добавалении/изменении функции вы будете вносить код только в этот механизм, что значительно скоратит объем требуемых изменений и сделает их достаточно системными.
2Dead
Не понял вопроса. Решается какая-то конкретная задача, в которой есть потребность в тиниRPC и если не использовать ее, то надо предложить замену? Или мы обсуждаем сильные/слабые стороны какой-то идеи?
если 1, то используйте на здоровье tinyRPC или еще что-то, что сочтете полезным, я-же не запрещаю
если 2, то я для себя пытаюсь из предложенной идеи найти какие-то полезные кусочки, потому и строю диалог на основе "отрицалова", поскольку поддержавших много и автор будет чувствовать себя вполне уверенно
Если более удобно - можно выстроить центральный механизм, который будет решать задачу взаимодействия между парсером и функциями. Он будет вызывать функции в их оригинальном исполнении, но этот механизм скрыт от внешней системы. Тогда при добавалении/изменении функции вы будете вносить код только в этот механизм, что значительно скоратит объем требуемых изменений и сделает их достаточно системными.
2Dead
Не понял вопроса. Решается какая-то конкретная задача, в которой есть потребность в тиниRPC и если не использовать ее, то надо предложить замену? Или мы обсуждаем сильные/слабые стороны какой-то идеи?
если 1, то используйте на здоровье tinyRPC или еще что-то, что сочтете полезным, я-же не запрещаю
если 2, то я для себя пытаюсь из предложенной идеи найти какие-то полезные кусочки, потому и строю диалог на основе "отрицалова", поскольку поддержавших много и автор будет чувствовать себя вполне уверенно
Re: Управление роботом с компьютера. Новый подход.
Если более удобно - можно выстроить центральный механизм, который будет решать задачу взаимодействия между парсером и функциями. Он будет вызывать функции в их оригинальном исполнении, но этот механизм скрыт от внешней системы.
Выстроив этот механизм и избавившись (путем кодогенерации) от...
...при добавалении/изменении функции вы будете вносить код только в этот механизм...
вы получите TinyRpc.
Последний раз редактировалось Виталий 30 авг 2010, 17:45, всего редактировалось 1 раз.
Re: Управление роботом с компьютера. Новый подход.
mandigit писал(а):Не понял вопроса. Решается какая-то конкретная задача, в которой есть потребность в тиниRPC и если не использовать ее, то надо предложить замену? Или мы обсуждаем сильные/слабые стороны какой-то идеи?
Я просто пока из того что вы говорите вижу, что вы решая аналогичную задачу плавно строите второй tinyRPC
Или это мне одному кажется?
PS: Нет, только одному
Re: Управление роботом с компьютера. Новый подход.
Не, я второй tinyRPC не строю. Скорее говорю, что для решения подобной задачи не нужно создавать специальный механизм, а они решаются простыми программными средствами, а более важным является идеология построения такого взаимодействия, которая и определяет сложность и функциональность и именно идеология должна решать в основе, а не программный код той-же RPC, даже если он очень хорош.
А если специальный механизм, то он должен обладать какими-то чертами, обосновывающими его применение. Вот и пытаюсь такие черты найти, но пока нету их
А если специальный механизм, то он должен обладать какими-то чертами, обосновывающими его применение. Вот и пытаюсь такие черты найти, но пока нету их
Re: Управление роботом с компьютера. Новый подход.
более важным является идеология построения такого взаимодействия
Вы пытаетесь найти "идеологию" там где ее нет. TinyRpc делается не для идеологии, а для удобства работы.
Re: Управление роботом с компьютера. Новый подход.
Тогда давайте оценим удобство работы?
Я не зря упоминал ранее о терминальном режиме.Какие удобства предоставляет предложенная система? Качество отладки? Управляемость? Масштабируемость? Функциональность?
Из того, что мне бросилось в глаза (возможно это не так - поправьте):
есть программный комплекс, состоящий из библиотеки на стороне хоста и библиотеки на стороне клиента.
мы как-то описываем функции на стороне хоста и далее вызываем их. слой RPC обеспечивает прозрачную для программиста функциональность, передавая на клиента нужный блок данных, клиент получает блок данных , расшифровывает, вызывает соответствующую функцию, передает блок ответа на хост, RPC передает пользовательской программе блок возврата.
Правильно?
Я не зря упоминал ранее о терминальном режиме.Какие удобства предоставляет предложенная система? Качество отладки? Управляемость? Масштабируемость? Функциональность?
Из того, что мне бросилось в глаза (возможно это не так - поправьте):
есть программный комплекс, состоящий из библиотеки на стороне хоста и библиотеки на стороне клиента.
мы как-то описываем функции на стороне хоста и далее вызываем их. слой RPC обеспечивает прозрачную для программиста функциональность, передавая на клиента нужный блок данных, клиент получает блок данных , расшифровывает, вызывает соответствующую функцию, передает блок ответа на хост, RPC передает пользовательской программе блок возврата.
Правильно?
Re: Управление роботом с компьютера. Новый подход.
Я пока никак не могу врубиться в одну практическую вещь. Специальная утилита компилирует функцию для последующей загрузки в МК с учетом конкретного МК? Или для вставки в CAVR, например? Взять тот же замер температуры. ПК запросил у МК текущую температуру по UART. Для этого ПК должен, например, соединиться с датчиком температуры, подключенном к определенным ногам по I2C, перевести полученные данные в удобоваримый вид и передать на ПК. Понятно, что скомпилированный код функции не может учитывать этих аппаратных особенностей. Т.е. все равно придется с ним разбираться и его как-то дополнять. А разобраться с чужим кодом всегда сложнее, чем свой написать. Наверное я что-то недопонял.
Re: Управление роботом с компьютера. Новый подход.
Тогда давайте оценим удобство работы?
Скачайте и оцените. Наверняка появится куча замечаний, мы их постараемся учесть.
Наверное я что-то недопонял.
Это действительно так.
Объясняю. Вы делаете термометр, используя при этом Ардуино.
Для того чтобы прочитать информацию с датчика температуры вы написали какую-то функцию:
- Код: Выделить всё • Развернуть
double Temp()
{
//Здесь вы читаете датчик.
}
Теперь вам понадобилось чтобы у вас была возможность вызвать эту функцию со своего ноутбука к примеру.
Для этого вы добавляете прототип этой функции в код на Ардуино, сигнализируя о том, что именно эту функцию вы хотите сделать удаленно вызываемой.
- Код: Выделить всё • Развернуть
double Temp(); //Прототип
double Temp()
{
//Здесь вы читаете датчик.
}
После этого жмете кнопку "RPC" в Ардуино IDE и получаете файл RemoteObject.cs в котором содержится класс на C#, который позволяет вызывать функции вот таким образом:
- Код: Выделить всё • Развернуть
var arduino = new RemoteObject("COM10", 57600); //Здесь указан порт и скорость по которым можно достучаться до ардуино.
double temp = arduino.Temp(); // Здесь в переменную temp упадет результат выполнения функции Temp() на ардуино.
Вот собственно и все.
Re: Управление роботом с компьютера. Новый подход.
mandigit писал(а):есть программный комплекс, состоящий из библиотеки на стороне хоста и библиотеки на стороне клиента. мы как-то описываем функции на стороне хоста и далее вызываем их. слой RPC обеспечивает прозрачную для программиста функциональность, передавая на клиента нужный блок данных, клиент получает блок данных , расшифровывает, вызывает соответствующую функцию, передает блок ответа на хост, RPC передает пользовательской программе блок возврата.
Вроде всё так, именно это, если я не ошибаюсь, и называется RPC