roboforum.ru

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

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

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

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

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

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

=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# кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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