Добрый день, форумчане! 
У меня есть проект, разработанный на Qt C++, который работает с последовательными портами (аппаратными RS-232) под windows 7 используя boost. Gui сделан с использованием Qt Quick. Мне необходимо перенести проект на windows 8.1 под WINRT и добавить новые функции.
В процессе переноса столкнулся со следующими проблемами:
- Под winrt отсутствует поддержка последовательных портов (USB CDC, конвертеры - не вариант).Решается проблема с использованием костылей Brokered Component, писанном только на C# в visual studio.
- Далее надеялся подгрузить то что получилось (dll) в Qt с использованием Active Qt. Однако Active Qt не поддерживается для winrt.

Может кто-то уже сталкивался с подобными проблемами? Подскажите самый простой способ перенести проект и подружить Qt, QML, C++ , boost, STL и VS2013, WINRT, C#, MS COM.

Я C# совсем не знаю и учить ради работы с Rs-232 желания особого нет. Также нет знаний и желания переписывать gui на XAML. Идеальный вариант - подгрузить в qt библиотеку, работающую с com портом, а всё остальное сделать в Qt. Но как это сделать?

В Qt 5 есть поддержка QSerialPort. Для старых версий её можно скачать отдельно и подключить к проекту. Она у Вас не работает?

QSerialPort тоже работать не будет под WinRT. Если бы под WinRT были API для работы с com портом, то и boost и Qt тоже бы уже давно поддержали работу с com портом. Нужно использовать Win32 API для работы с com портом в WinRT через Brokered Component. Или ждать и надеяться, что Microsoft добавит эти апи под winrt.

Как вариант, использовать FTDI чип с драйвером D2xx: http://www.ftdichip.com/Support/Documents/...nRT%20Guide.pdf

(но, раз USB конвертеры - не вариант - то не вариант  )

У меня в XP все было наоборот. COM на материнке отсутствует, используется
1) гаджет, втыкающийся в USB, имеющий два COM порта на выходе
2) Bluetooth-USB на компьютере, Bluetooth-COM на внешнем устройстве, причем второй Bluetooth перед этим нужно подлючить к компьютеру через гаджет из первого пункта для настройки.
Через двайвера этих гаджетов USB превращается в COM, причем номер порта может поменяться при перезарузке.
В программе используется QSerialPort - как работать с USB напрямую из Qt я не знаю.
Наколько я понял, с новым Windows это работать не будет.

WinRT делали для создания календариков, просмотра рецептиков и прочей никому не нужной хрени, по крайней мере, пока создается именно такое впечатление. Т.е. явно не для такой низкоуровневой работы, уж если там нельзя полноценно работать с COM\DCOM, то ожидать чего-то большего - оптимистично. Хотя работы в этом направлении ведутся(для 10ки).

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

ЗЫ я так понимаю, Вы использовали Qt, собранную для WinRT, и в лоб решить проблему переноса не получилось?

Этот ответ добавлен с нового Винграда - http://vingrad.com

Даже в этом случае не понятно как подключить .winmd в Qt, что равнозначно с решением на основе Brokered Component, т.е. снова использовать Visual Studio и переписывать GUI на XAML.

У меня тоже создаётся такое впечатление.   

Да, Qt для WinRT. В лоб решить не удалось.

Я, конечно, не силён в серверах, но вот меня настораживает взаимодействие Qt и WCF сервиса. Это возможно? Или будет легче уже XAML выучить?  
Или можно как-то обойтись без WCF?

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

Это сообщение отредактировал(а) math64 - 8.12.2015, 09:05

Может это может что-то прояснить (слайды 15-25): https://channel9.msdn.com/events/BUILD/BUILD2011/HW-747T

(взято из конца https://social.msdn.microsoft.com/Forums/en...appsfordevices)

Там вроде-как рассказывают про доступ к кастомным девайсам.

Еще вариант (если есть возможность использовать USB) - это использовать WinUSB API (хотя я не уверен что в WinRT это возможно). В этом случае можно передвавать данные и конфигурить сериал порт можно через USB пайпы (но надо смотреть даташит конкретной микрухи). Так, например в Android делают..

UPD: Посмотрел на описание как это делается для FTDI - там именно такая тема. Девайс устанавливается как "универсальное USB устройство". Для этого достаточно просто написать свой *.inf файлик в котором указать VID/PID и может что-то еще (надо посмотреть как там в FTDI делается). И тогда просто дергаем WinUSB-шные функции и наслаждаемся. 

Но если сериал порт втроенный в ARM - то это дохлый номер, IMHO.. 

UPD: А Bluetooth, Wifi не устраивают?



Это сообщение отредактировал(а) kuzulis - 7.12.2015, 21:17

В общем, всё это здорово, но, грубо говоря, необходимо запилить свой драйвер совместимый с WinRT. Кратенький обзор, пример, CustomDevice класс.


А причём здесь WCF? =) Можно и с ним, конечно, но это уже на Ваш выбор.


В особо тяжёлых случаях это может быть та же машина.

Этот ответ добавлен с нового Винграда - http://vingrad.com

Это вообще не вариант. Напоминает ералаш про батарейки к часам http://www.youtube.com/watch?v=uG2sgVH-r7o



Вопрос не в том, как запилить драйвер, а как его подключить и использовать в Qt Creator, чтобы не переписывать GUI на XAML.

Если писать новый проект с нуля в Visual Studio на C# + XAML, то проблем вообще никаких нет. Мне же нужно, чтобы проект оставался в Qt, где GUI написаны на QML и работали ком порты.


А можно пример, как сделать по-другому? (используя Qt)

Через QTcpSocket, что с той, что с другой стороны. Или в WinRT QTcpSocket не работает? В целом у меня работало и в случае, если со стороны сервера был QTcpSocket, со стороны WinRT их сокеты.


А GUI переписывать не нужно, тут вопрос стоит в том, как взаимодействовать с COM-портом, верно? Так вот, чтобы наладить это взаимодействие, силами одного Qt можно и не обойтись, т.к. осуществлять передачу команд и данных через сокеты - это костыль в чистом виде из-за ограничений данной подсистемы.

Собственно, пока что предложено два варианта как осуществить взаимодействие с COM-портом:
1) Написать драйвер совместимый с WinRT и работать с ним через CustomDevice. Ссылку на пример я выложил.
2) Костыльнуть, разбив искомое приложение на клиент/сервер.

Пишешь в Visual Studio сервер, без ГУИ, который делает тоже самое:

Твоя программа через сокеты подключается к этому серверу - разница в использовании QTcpSocket вместо QSerialPort, оба наследуются от QIODevice, поэтому разница будет только в конструкторах.

Добавлено через 13 минут и 15 секунд

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

Спасибо всем откликнувшимся!
Остановился на варианте клиент/сервер на одной машине. Клиент работает в winrt, а сервер в win32.