roboforum.ru

Я понял утилита собственно "пишет" свой протокол обмена с ПК, автоматически его расширяя при добавлении новых функций. С классом на ПК все понятно, а ответную (ответственную за обмен) часть кода для Адруино кто делает и в виде чего?

Скачайте, откройте готовый пример и все увидите сами. Файл Sketch.pde

Преимущества данного "нового подхода":

1. Быстрота имплементации обмена между PC и одним микроконтроллером;

2. Хороший уровень абстракции (для программиста всё прозрачно и не надо думать - нажал кнопку и всё готово);

Недостатки:

1. Накладные расходы на нижележащий протокол обмена (обычно tcp/udp, в данном случае неожиданный UART), как следствие возможна перегрузка канала при передаче потоковых данных (звук/видео);

2. Накладные расходы на обработку ошибочных ситуаций (потеря запроса/ответа, перезапросы, ожидание ответа, разрыв канала связи);

3. Невозможность multicast обмена с несколькими контроллерами одновременно;

4. Клиент-серверная архитектура, причём микроконтроллер всегда выступает в роли сервера (или я не прав?), что может негативно влиять на потребление;


Наверно по этим причинам и не прижился RPC в embedded. Хотя свои ниши у этого решения есть.

Про недостатки:
1) UART + видео? Сделать это все на мосту через TCP\UDP не составит труда, я думаю
2) Это всегда и везде есть
3) Даже на UART это можно сделать

2 Сергей:

1. Разговор не про UART, а про RPC;
2. Где-то больше, где-то меньше, в данном случае больше;
3. Разговор не про UART, а про RPC;

1. Накладные расходы на нижележащий протокол обмена (обычно tcp/udp, в данном случае неожиданный UART), как следствие возможна перегрузка канала при передаче потоковых данных (звук/видео);

Я не согласен. Дело в том, что перегрузка будет связана с низкой пропускной способностью канала, а не с накладными расходами на передачу. Реализация той же функциональности через UDP или TCP - не представляет сложности.

...неожиданный UART...

Помоему вполне ожидаемый...

2. Накладные расходы на обработку ошибочных ситуаций (потеря запроса/ответа, перезапросы, ожидание ответа, разрыв канала связи);
...
2. Где-то больше, где-то меньше, в данном случае больше;

Больше по сравнению с чем?

3. Невозможность multicast обмена с несколькими контроллерами одновременно;

Сейчас невозможно, но мы исправим это к вечеру. =)

4. Клиент-серверная архитектура, причём микроконтроллер всегда выступает в роли сервера (или я не прав?), что может негативно влиять на потребление;

Микроконтроллер может просыпаться по прерыванию от UART или другого канала связи.

Для упражнения можно посчитать стандартную задачу - передачу кодированного звука (пакеты 160 байт каждые 10 мс, допустим по UDP). С учётом потери пакетов, перезапросов и обработки с использованием RPC более чем уверен, что обычный подход с распарсиванием UDP пакетов будет намного устойчивее и быстрее. Хотя для описанной Вами в самом начале задачи (есть датчик температуры, берём из него данные, т.е. быстродействие не критично) данное решение очень даже подходит.

P.S. Спорить не хочу, Вы спросили почему данное решение не нашло применение во втраиваемых системах - я высказал своё мнение.

В UDP на каждый пакет передается восемь служебных байтов. в UDP/IP - 28.
Я не уверен, что реализация TinyRPC сильно хуже (скорее всего даже лучше).

А вот "почему данное решение не нашло применение во втраиваемых системах" - это другой вопрос.

И причин, по-моему, несколько:

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

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

Третье. Во встраиваемых системах (в том числе распределенных) используются многие разные интерфейсы связи и протоколы передачи, разные типы данных, различные способы организации памяти. Это затрудняет выработку "стандарта RPC". Насколько я знаю, общепринятого стандарта нет также и в "компьютерном" мире, хотя технология используется (может быть я тут не прав).
Отсутствие "стандарта" означает отсутствие удобных инструментов (тех же библиотек или генераторов шаблонов).

Если честно мы не планировали передавать потоковое видео или аудио. Для этого есть свои алгоритмы, протоколы...

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

Насколько я знаю, общепринятого стандарта нет также и в "компьютерном" мире, хотя технология используется (может быть я тут не прав).

Есть реализации претендующие на стандарт.

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

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

1. Дело еще в том, что встраиваемые системы должны отличаться надежностью. А надежность и частые изменения в программном обеспечении низкого уровня - вещи слабо совместимые, как минимум исходя из принципа "почему солнце каждое утро встает на востоке, а садится на западе? ... ТЫ НИЧЕГО НЕ ТРОГАЛ? - Нет. - И не трогай. Так надо"

А отсюда и отсутствие необходимости в частых пересмотрах протокола, и как следствие отсутствие жесткой необходимости в фреймворке.

2. Далеко не всегда все компоненты системы (а особенно прикладной софт ПК и низкоуровневые устройства на МК) разрабатывает один и тот же человек\фирма, а значит скорее всего разработчик железа не всегда знает из какой среды разработки будут вызывать его функции, поэтому самый простой выход для него - обеспечить какой-то классический (интерфейс + протокол) типа CANBUS, RS485, 1-wire или тому подобный + прописать спецификацию команд\запросов в терминах этого протокола.

Вот из всего этого и получается, что относительно редко нужно в таком прямом виде RPC.

PS: Всё это не умаляя его полезности, удобства и нужности в существенном классе случаев.

А надежность и частые изменения в программном обеспечении низкого уровня - вещи слабо совместимые...

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

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

Концепции пока нет, но она появиться... со временем.

Ребят, а давайте уже не будем про сферических в вакууме... Это бессмысленно - нужен ли тачскрин "сферическому роботу", нужен ли RPC "сферическому эмбеддеру"...
Давайте говорить "роботу-пылесосу нужен тачскрин", "контрорллеру стиральной машинки нужен RPC".

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

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

Подумалось, что может быть имеет смысл расширить (или сузить?) идею "чистого RPC" до генератора парсеров? Но это все равно оффтопик!

Добавлено спустя 3 минуты 21 секунду:

Виталий писал(а):Нам нужен удобный инструмент. Мы его делаем. А для того чтобы было полезно и другим - делаем для Ардуино.

Весь смысл работы в этой фразе - ни к чему эти теоретизирования.
Люди делают инструменты для себя. Да еще и о других не забывают.
Молодцы, что еще сказать.

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

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

Конечно, здорово, если парсер сгенерируется автоматически, а вот из чего его генерять и как - это уже вопрос реализации.

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

Или независимый пользователь решил написать свою программку для управления купленным лифтом (скажем вынтегрировать его в свою систему контроля доступа) - и что?

Я вообще не думаю, что "универсальное" решение существует, или даже если оно возможно, то будет широко востребовано. Но в каждом конкретном случае - "универсальное" и не нужно!

Ну вот я выпустил следующую версию контроллера лифта не на пике, а на арме - что делать?

Перекомпилировать код. Код TinyRpc системонезависимый. Написан на Си.

порядок аргументов другой, инты теперь 32-х битные, и вообще жава...

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

Или независимый пользователь решил написать свою программку для управления купленным лифтом (скажем вынтегрировать его в свою систему контроля доступа) - и что?

Дело в том, что TinyRpc - подкласс протокола JSON-RPC. Так что это как раз для нас.
- Мы можем отдать ему C# класс для доступа.
- Мы можем сгенерировать ему класс доступа для любого другого языка.
- Мы можем сгенерировать описание протокола в виде XML, а он при помощи XSLT преобразует его в необходимый код.
- Мы можем сгенерировать описание протокола в виде JSON объектов.