Добрый день.

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

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

1. Использовать DLL, где и предоставить необходимые функции.
Большой плюс решения - очень просто как для меня - писателя DLL, так и для клиента - писателя основной программы.
Минус - нет совместимости между DLL, созданной разными компиляторами, или требуются неудобные телодвижения для использования "неродной" DLL. Отсюда проистекают ограничения на использование клиентской программой языка программирования.

2. Написать OPC сервер.
Плюсы. Есть стандарт, кроме самописной программы можно использовать какую-нибудь SCADA систему. Нет никакого навязывания языка программирования для клиента.
Минусы. Сложность. Конкретно нам придется заказывать разработку сервера на стороне. Клиент должен иметь программиста с подходящей квалификацией.

3. ??? что еще можно придумать. В нулевом приближении требования такие. Простота реализации как для меня, так и для клиента. Без навязывания клиенту языка программирования.

А не надо из DLL классы плюсовые экспортировать.
Лет восемь назад писал именно такого применения DLL-ку.
Внутри С++ для того, что было мне удобно.
Наружу только стандартный для Win интерфейс, местами с регистрацией call-back-ов пользовательского приложения, вызываемых моей DLL, в духе

Собирал её GCC (mingw32), использовалось это с Delphi. Уж более разные компиляторы поискать надо.

Это то понятно.


Хм... я в dll-ках не специалист, но беглый поиск показал, что dll от Visual C++ и С++ Builder несовместимы между собой без всяких ++. Тут еще надо поразбираться. На данный момент рассматриваю использование dll как наиболее верояное решение. Но может еще кто чего интересного подскажет.

Есть ещё технология OPC и DDE.
Но это зависит от пользователя. Некоторые могут и не понять.
А вот в АСУ ТП - это стандарт. Нативно поддерживается практически всеми SCADA-ми.

Устройство должно стать WEB сервером и предоставлять WEB сервисы на основе SOAP с описанием на WSDL.
Это будет самый универсальный и дальновидный подход.
Эти штуки есть во всех серьезных языках и фреймворках - .NET (С++, C#, VB), Delphi, PHP, Python, Java, JavaScript ...

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

Возможный вариант при малом потоке управления: что-то типа wake протокола для обмена. Ещё вариант, более сложный, реализуемый в измерительной аппаратуре: на приборе стоит сервер, например, telnet. Клиент посылает запросы в формате SCPI (NI). Реализовано в генераторах R&S SMC100A и других. Клиент (Ваш пользователь) пишет приложение на чем ему удобно. Потребуется оценка необходимой скорости обмена и выполнения действий. Прибор должен иметь соответствующую периферию для обмена и ресурсы. В R&S SMC100A стоит linux.

Идея сделать сервер из самого устройства заманчива, но возможно ли это, если физическое соединение USB HID.

Не знаю. Наверно можно сделать, если из USB сделать виртуальный коммуникационный порт (COM/ttyx). Для прибора и для хоста соединение по последовательному каналу. Протоколы поверх такого соединения ложатся, скорость только мала. Сам не проделывал.

Кстати, wake поверх последовательного порта и ложиться, там прибор слэйвом идет. Такое делал.

Вообще-то я предполагал, что потребуется слегка переписать фирмваре устройства.
Если XML применяемый в SOAP слишком тяжелый для каналов передачи, то можно было бы использовать формат JSON и либы JSONP.
Это сужает круг совместимых фреймворков, но может оказаться перспективней, поскольку на JSONP плотно сидят фреймворки Google и Yahoo.

Но можно конечно и промежуточный локальный сервер-шлюз сделать для перевода локального проприетарного M2M протокола в JSON поверх HTTP.
Какой пользовательский интерфейс можно сделать в броузерах на основе бесплатных либ можно посмотреть например здесь: http://jqueryui.com/
Плюс тут в том, что пользовательский интерфейс совместим с кучей броузеров и операционок, а писать его могут разработчики WEB страниц которые как правило дешевле тех же писателей на Delphi.



Переделайте HID на RNDIS. Даже проще будет.

Не знаю, я тоже не специалист.
Но мой преемник на той работе несколькими взмахами кистей над клавиатурой дорисовал в исходниках той dll-ки пару #include и стал модифицировать/пересобирать её в более привычном ему Visual-C++. Всё до сих пор работает с программой из-под дельфи.

Да, там только с декорированием имен надо аккуратно. Но все это легко решаемо.

Пока останавлюсь на dll способе как самом простом и удобном. А поверх этого потом можно будет добавить все что угодно.

Это откуда такие сведения? Несовместимы, как правило, не dll, а lib, у них действительно разный формат, но у Борланда есть утиль, который их преобразует. К примеру, у меня не возникало трудностей использования dll от Agilent в их библиотеке VISA к IEEE-488 контроллеру. Использовались эти DLL как для С++ Builder'a, так и для QT4 с mingw. Все работает.

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

Да это все от отсутсвия базовых знаний в этой области. Я в этом сразу признался. Сейчас читаю об этом и потихоньку все становится на свои места. А пока