roboforum.ru

Здравствуйте!

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

Название предлагаемого подхода - Remote Procedure Call (http://ru.wikipedia.org/wiki/Remote_Procedure_Call).
Его смысл заключается в том, что мы можем вызывать функции одного адресного пространства (микроконтроллера) из другого адресного пространства (компьютера).

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

Мы реализовали такую функциональность для Ардуино.
Более подробная инструкция по использованию http://bitbucket.org/sources/tiny-rpc/wiki/Home
Готовый пакет: http://bitbucket.org/sources/tiny-rpc/d ... -21.08.zip

Пример. У вас есть робот который должен управляться с компьютера, и пользоваться датчиком температуры.
Вы написали в Ардуино примерно такой код:

Код: Выделить всё • Развернуть

void Move(int vl, int vr)
{
    // Set left (vl) and right (vr) wheel velocity 
}

double Temperature()
{
    // Read temperature sensor
}

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

Код: Выделить всё • Развернуть

void Move(int vl, int vr);
double Temperature();

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

Я не думаю что причина именно в этом.
Ничто не мешает прокидывать "наверх" не такие функции как я показал, а функции работы с периферией.
А DLL-ка по-сути у нас и формируется, даже лучше чем DLL-ка. =)

похожий подход используется в Urbi.
Cоздаётся urbi-объект UObject, который выполняет роль драйвера(промежуточного слоя) между Urbi и роботом(Arduino). Получается, что промежуточный слой берёт на себя протокол общения с роботом, предоставляя внешнему слою прозрачные интерфейсы(значения величин, вызов методов/функций).

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

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

Ну в общем круто, сам буду смотреть может где применю, но специфично!

Вы кстати на английском языке к своей штуке будете писать документацию, чтобы продвигать за границей?

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

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

Зачет.
Но эт все здорово, пока не начались треды, реентерабельность, сборщики мусора, и всякие прочие "области видимости", "времена жизни", "создания объектов"... (не говоря уже о дебаге например)
Боюсь, что полноценный RPC - очень непростая в реализации штука.

Ну что я могу сказать, да, такие проблемы могут возникнуть, но только на стороне ПК, где они уже решаются более-менее цивилизованными средствами. Не думаю, что понадобится реализация этого на контроллера. У нас простая задача - вызвать на контроллере определенную функцию и вернуть результат.

Че-то я не очень понимаю как ПК поймет где находится контроллер и как к нему подключится.

Ну для доступа к контроллеру автоматически создается класс RemoteObject, в конструкторе которого и указывается тот последовательный порт к которому подключен контроллер.

Код: Выделить всё • Развернуть

RemoteObject arduino = new RemoteObject("COM20", 57600);

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

В том то и дело, что ничего не надо поднимать. Ты просто пишешь функцию для МК, помечаешь ее как remotable и она автоматом добавляется в класс RemoteObject(), а протокол обмена и его реализация генерируются автоматически.

А к Processing ее прикрутить можно?

Да, можно.

P.S. Добавил короткое видео в заглавное сообщение.