LINUX.ORG.RU

Не открывает последовательный порт - access denied

 ,


1

1

Есть программа на Qt5 и на Linux она работает великолепно и стабильно. На богомезком офтопе простейший последовательный порт через QSerialPort работает вроде нормально. Но как только я пытаюсь встроить работу с портом используя прости господи win api - программы отказываются открывать порт по имени:

CreateFile(L"\\\\.\\COM4", ...
Не хочет. Такие имена тоже не признает:
\\Device\\ProlificSerial0
\\Device\\Silabser0d"
А ведь их мне выдает QueryDosDevice.

Так вот, как только я запускаю нативный С++ код win api он выдает ошибку 5 - access denied. Я пытаюсь встроить работу с портом в приложение с Unreal Engine 4.

После запуска в рамках приложение UE4 программа на Qt5 и QSerialPort тоже прекращает работать и при попытках открыть порт вещает: ERROR: can't open port «COM4» «Отказано в доступе.»

Что делать? Заказчик согласился в скором времени перейти на Linux, благо UE4 на Linux я собрать смог. Но чтобы Linux победил в этой фирме - сначала нужно чтобы заработало в оффтопе. Помогите, пожалуйста, кто знает как с этим бороться? Что я делаю не так, какие права не выставляю? Запускаю же под админом - ну что может быть ацесснее?

Почему не винфак? Я нигде не шляюсь по виндовым ресурсам, увы, не знаю даже где вопрос задать. Просто хочу чтобы уважаемая публика видела насколько мерзкая эта платформа офтоп10, и вообще офтоп как таковой. Я пишу в 99% случаев кроссплатформенные программы и за рамки Qt5 мне редко приходится выходить, и добрый Qt оберегает мою психику от всех ужасов и недостаткой форточной платформы.

Добавлено: потыкался с QSerialPort - можно хоть сто раз загружать программу и порт всегда нормально открывается. Т.е. Qt5 действительно корректно работает и позволяет обращаться по именами «старого стиля» типа COM4. Первое же обращение через CreateFile и всё - бобик сдох.

CreateFile нормально открывает «COM4», винда то причем, пользуешься всякой фигней.

CreateFile('COM4',GENERIC_READ or GENERIC_WRITE ,0,nil,OPEN_EXISTING,FILE_FLAG_OVERLAPPED,0); ну и на си примерно так же.

ilovewindows ★★★★★ ()
Ответ на: комментарий от d_a

Да, я пытался смотреть исходники QSerialPort. Прочитал на SO что в офтоп10 имя порта получается каким-то замудрёным чуть ли не GUID. И что там особый путь получения этого имени, которое откроется. Но оказалось не так, иногда тестовая программа открывала именно по COMx, пока не понял как воспроизвести эти редкие удачные условия.

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

Спасибо, попробую с этим флагом. В примерах не попадалось.

это асинхронный вввод\вывод, он тебе сейчас только проблем создаст.

jo_b1ack ★★★★★ ()
Ответ на: комментарий от jo_b1ack

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

Пробовал смотреть при помощи handle64 (аналог pidof) - не показывает что что-либо занимает файл порта.

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

Перезагружался само собой.

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

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от hateyoufeel

Да тренажерно-симуляторную тему, а там будь то подключение к БД или просто последовательный порт - всё приходится делать с некоторыми осложнениями, например Qt5 не встроить классы. Можно конечно связать через IPC и уже без ограничений, но в моем случае это избыточно.

В общем, нужно управлять устройствами через RS-485 в зависимости от того, что происходит в визуальной сцене. С этим всем разобрался - споткнулся о тупой ком порт блин...

I-Love-Microsoft ★★★★★ ()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

Хм, а не вижу проблемы

#include<windows.h>
#include<stdio.h>
int main()
{
  HANDLE hComm;

  hComm = CreateFile("\\\\.\\COM1",                //port name
                      GENERIC_READ | GENERIC_WRITE, //Read/Write
                      0,                            // No Sharing
                      NULL,                         // No Security
                      OPEN_EXISTING,// Open existing port only
                      0,            // Non Overlapped I/O
                      NULL);        // Null for Comm Devices

  if (hComm == INVALID_HANDLE_VALUE)
      printf("Error in opening serial port");
  else
      printf("opening serial port successful");

  CloseHandle(hComm);//Closing the Serial Port

  return 0;
}
Пример собрался gcc и спокойно работает с ХП по 10ку

anonymous ()
Ответ на: комментарий от anonymous

Иногда у меня это тоже срабатывает, и я не понимаю что я делаю так когда оно иногда возвращает не INVALID_HANDLE_VALUE.

В среде UE4Editor при пересборке старая DLL/SO отключается, подключается новая. Ожидаю что в момент выгрузки старой версии, процесс прибивается и порт освобождается. Но что если это не так? Спасибо анонимусу, навел на мысль - попробую CloseHandle в деструктор пихнуть...

I-Love-Microsoft ★★★★★ ()
Ответ на: комментарий от d_a

Супер-workaround: USB шнурок вытык, втырк again = работает 1 раз :)

Смешно, но пока придется с этим решением пожить... Это я к тому, что CloseHandle почему-то не помогает, хотя декструктор точно вызывается и CloseHandle вызывается. Беда

I-Love-Microsoft ★★★★★ ()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

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

Morin ★★★ ()
Ответ на: комментарий от Morin

Тем не менее, через QSerialPort работает как часики, что потенциально отметает проблемы с железом, либо код Qt каким-то образом обходит данное затруднение.

И да... через USB хаб не пробовал, нужно попробовать.

I-Love-Microsoft ★★★★★ ()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)

Вантузятники как обычно говнокодят.

За эти «\\\\\\\\\» руки оторвать надо. Используй boost filesystem не ленись прочесть rtfm.

И да для порта используй boost тоже. Boost aerial port.

invy ★★★★★ ()
Последнее исправление: invy (всего исправлений: 2)
Ответ на: комментарий от Morin

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

В итоге, проблему удалось решить тем, что я завязался на события BeginPlay и EndPlay, и вот они то как раз вызывались надежно в паре. Теперь срабатывает надежно.

I-Love-Microsoft ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.