roboforum.ru

Виталий писал(а):Ну что я могу сказать, да, такие проблемы могут возникнуть, но только на стороне ПК

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

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

Но в любом случае даже простая реализация, без изысков, заслуживает внимания и уважения.

Если бы все было так просто...
Ну вот, простой пример, на ПК два треда - оба одновременно вызывают одну и ту же функцию в контроллере...
А она, допустим, использует глобальные переменные или аппаратные ресурсы (ну таймер, скажем)...

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

Отмечу, что при реализации протокола обмена "в лоб" никто не защищен от этих же самых проблем.

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

Добавлено спустя 5 минут 8 секунд:
А обмен данными у вас как-то реализован?
Грубо говоря, если я удаленной функции передал указатель на строку (Ну или, скажем, индекс в массиве), то... что произойдет?

Michael_K писал(а):Грубо говоря, если я удаленной функции передал указатель на строку (Ну или, скажем, индекс в массиве), то... что произойдет?

Суровые у тебя тесты

=DeaD= писал(а):Суровые у тебя тесты

RPC_print("hello world"); - это безусловно суровый тест

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

Согласен, тест не очень суров. Суровый тест - это ссылочная структура с кольцами

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

В вики описаны ограничения.
Можно сконструировать пока только такие функции:

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

[int | float | double | char*] function([int | float | double | int[] | float[] | double[] | char*], ...);

На мой взгляд этого подмножества функций ложно хватить на большинство задач решаемых роботами.
Ты не можешь вернуть указатель и передать указатель. Тип char* используется за отсутствием встроенного в Си типа string.

Для функции void f(char* p) будет сгенерирован C# прототип void f(string p)

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

RPC_print("hello world"); - это безусловно суровый тест

Это сработает.

Добавлено спустя 1 минуту 25 секунд:

Суровый тест - это ссылочная структура с кольцами

У нас есть поддержка рекурсивных типов данных, но для нее не написан генератор C# кода.

Ну все равно клево!

Добавлено спустя 1 минуту 16 секунд:

Виталий писал(а):На мой взгляд этого подмножества функций должно хватить на большинство задач

согласен

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

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

Может я не очень понял идею?

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

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

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

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

Преимущества какие у такого подхода по сравнению с диалоговым режимом?

Что нужно сделать чтобы построить диалоговую систему?
1. Определить набор команд и параметров к ним
2. Написать функцию разбора команд и параметров
3. Обеспечить передачу данных, реализовав соотв. протокол

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

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

И что здесь такого что нельзя сделать на Ассемблере? =) При использовании RPC код для всего этого будет сгенерирован автоматически.

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

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

Вообще я не знаю как отлаживать программы в принципе. Как и никто другой. Но если вас смущает какой-то конкретный момент - давайте его рассмотрим.
Насчет гибкости в плане изменения функционала - тоже неясно. Функционала чего? Добавить новую функцию в контроллер - всегда пожалуйста.

mandigit писал(а):Преимущества какие у такого подхода по сравнению с диалоговым режимом?

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

Немного оторвусь от понятия RPC.
Мне доводилось сталкиваться с близкими механизмами общения клиента-хоста в процессе доступа к SQL серверам.
Как пишутся такие программы взаимодействия? А очень просто: формируется строка на SQL, которая потом отслылается серверу на исполнение. А почему так делается? Казалось-бы надо сделать функции, которые облегчат жизнь программисту (10, 100, а можут мульон функция Мне кажется, что ответ в том, что систематизируется только то, что используется постоянно и много раз, а именно: передача пакета по каналу связи (вспомните семиуровневую модель), язык взаимодействия с системой (стандарт).
А уже все это можно использовать вручную, через ассемблер или RPC или OCX или еще как-угодно.

Теперь вернемся к RPC.
Задачу, которую решает предложенный RPC можно обобщить так:
"Программа на хост компьютере взаимодействует с программой на борту"
С моей точки зрения наличие явного диалогового режима позволяющего взаимодействовать с бортовой системой является основой, а механизм RPC есть прослойка между пользовательской программой и диалоговым взаимодействием и может быть реализована в удобном для программиста виде (в виде библиотек с базовыми возможностями или в виде классов или DLL или еще как-то)
Вот так примерно оно видется.

А вот организовывать на борту непосредственный код, который взаимодействует с кодом на машине - такой путь мне непонятен, убрали возможность отладки системы без применения программных средств (в диалоговом режиме, контролируя посылаемые команды и отклик системы) и ничего не добавили взамен!?

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