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

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

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

В исходники любимой либы глянуть не можешь? Там всё понятно вроде.

FILE_FLAG_OVERLAPPED

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

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

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

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

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

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

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

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

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

Не в тему, но что ты такого делаешь, что тебе нужны одновременно UE и работа с com-портом?

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

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

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

#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;
}

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

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

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

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

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

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

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

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

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

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

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

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

занятно, спасибо