WinAPI - Serial communications, COM-порт по трем проводам Опции

[vazz]

Раньше никогда не сталкивался с необходимостью осваивать WinAPI в части работы с COM-портами, другие способы коммуникации как-то больше волновали. А теперь вот не могу справится с простейшей на мой первоначальный взгляд задачей - реализация асинхронного обмена через "банальный" COM-порт. К COM-порту подключен модем, "понимающий" стандартный набор AT-команд. Вот и решил я далеко не ходить и не разгребать глюки готовых классов и модулей, реализованных другими разработчиками. Лицензионные продукты для своей простой задачи не вижу смысла покупать. Вот пал выбор на WinAPI. Вроде бы и информации в сети валом и msdn внимательно почитал, но у меня то ли неправильно выстроился алгоритм программы то ли дядюшка билли со своими извращенными алгоритмами всевозможных ограничений прав доступа к памяти мешает. Прошу помощи.

Успешно открываю порт

Код

-- kernel32 - подгружаемая библиотека WinAPI-функций
-- comid - номер открываемого порта
-- handle - итоговый указатель на порт
handle = kernel32.CreateFileA("\\\\.\\COM" .. comid, GENERIC_READ+GENERIC_WRITE, 0, 0, OPEN_EXISTING, FILE_FLAG_OVERLAPPED, 0)

Далее я создаю и заполняю структуры BCD и COMMTIMEOUTS. Сохраняю настройки с помощью функций SetCommState, SetCommTimeouts - обе возвращают TRUE.

Код

DCB.BaudRate = CBR_9600;
DCB.ByteSize = 8;
DCB.Parity = NOPARITY;
DCB.StopBits = ONESTOPBIT;
DCB.fBinary = 1;
DCB.fOutxCtsFlow = 0;
DCB.fOutxDsrFlow = 0;
DCB.fDtrControl = DTR_CONTROL_DISABLE;
DCB.fDsrSensitivity = 0;
DCB.fNull = 0;
DCB.fRtsControl = RTS_CONTROL_DISABLE;
DCB.fAbortOnError = 0;

COMMTIMEOUTS.ReadIntervalTimeout = 10;
COMMTIMEOUTS.ReadTotalTimeoutMultiplier = 1;
COMMTIMEOUTS.ReadTotalTimeoutConstant = 100;
COMMTIMEOUTS.WriteTotalTimeoutMultiplier = 0;
COMMTIMEOUTS.WriteTotalTimeoutConstant = 0;

Далее пытаюсь отправить данные в порт

Код

-- data - массив с данными
-- b - указатель на переменную типа DWORD "счетчик байт"
-- t - указатель на буфер с данными
-- n -  кол-во данных в массиве data
local n = Table.Count(data);
local b = MemoryEx.Allocate(4);
local t = MemoryEx.Allocate(n);
if (b and t) then
    -- сброс счетчика байт
    MemoryEx.Fill(b, 4, 0, MEMEX_BYTE);
    -- заполнение буфера данными из массива data
    local c = 1;
    repeat
        MemoryEx.Byte(t + c - 1, data[c]);
        c = c + 1;
    until c > n;
    -- запись в порт
    if (kernel32.WriteFile(handle, t, n, b, 0) == 0) then
        local e = kernel32.GetLastError();
        Dialog.Message("error", e);
    end
end

После попытки записать что-либо в порт функция возвращает 5, т.е. ACCESS DENIED. Что я упустил?

[vazz]

В общем приходится периодически возвращаться к этой теме видимо, хочешь не хочешь, а освоить работу с com-портами мне придется. На текущий момент повспоминал все что было, решил создать простенькое windowed приложение для теста com-портов. Так вот, возвращаясь к ранее обсуждаемой на этом форуме проблеме, сообщаю, что как и ранее открыть порт удается, настроить тоже (проверяю записаны ли настройки непосредственно по поинтеру зарезервированного под них куска памяти). Записать данные удалось (вроде бы тут должно быть "уррра!!!"), но только в одном случае - при открытии порта функцией CreateFile я передаю ей параметр dwDesiredAccess равный GENERIC_WRITE. Если при вызове этой функции я указываю GENERIC_READ + GENERIC_WRITE, то запись в порт не происходит. Порт открываю пока обычном режиме (NOT OVERLAPPED). Вопрос: если я открываю порт в НЕ асинхронном режиме, то я могу открыть его только "в одностороннем режиме", т.е. открываю порт для записи, потом закрываю порт и если мне нужно получить ответ от устройства, то я снова открываю порт но уже в режиме чтения и читаю данные? Бредовенько как-то.. В инете куча примеров где в 100% случаев права при вызове функции CreateFile указываются именно как "GENERIC_READ | GENERIC_WRITE", что за фигня у меня, у кого какие мысли?

[aaarrr]

что за фигня у меня, у кого какие мысли?

Есть такая мысль, что (GENERIC_READ + GENERIC_WRITE) в вашем случае оказывается не равно (GENERIC_READ | GENERIC_WRITE).

[toweroff]

Есть такая мысль, что (GENERIC_READ + GENERIC_WRITE) в вашем случае оказывается не равно (GENERIC_READ | GENERIC_WRITE).

хмм...

Код

#define GENERIC_READ                     0x80000000
#define GENERIC_WRITE                    0x40000000
#define GENERIC_EXECUTE                  0x20000000
#define GENERIC_ALL                      0x10000000

будут они равны, хоть ОРь, хоть складывай

[gerber]

будут они равны, хоть ОРь, хоть складывай

При сложении будет учтен знак, если константы signed.

[toweroff]

При сложении будет учтен знак, если константы signed.

Ну константы как-то не предполагают знак

[jorikdima]

Ну константы как-то не предполагают знак

У вас не типизированные константы, а литералы. Предполагают.
Но я не говорю что проблема в этом.
Странно видеть в 2016 году WinAPI. милиард взяких либ для работы с портами.

[zltigo]

Странно видеть в 2016 году WinAPI. милиард взяких либ для работы с портами.

А Вам в голову не пришло, что сам факт существования "милиард взяких либ для работы с портами" свидетельствует только об их бесполезности. Была бы польза - была бы одна волшебная "либа". А пока есть только одна такая "либа" - WinAPI называется. Остальное графоманские надстройки над API.

[jorikdima]

А Вам в голову не пришло, что сам факт существования "милиард взяких либ для работы с портами" свидетельствует только об их бесполезности. Была бы польза - была бы одна волшебная "либа". А пока есть только одна такая "либа" - WinAPI называется. Остальное графоманские надстройки над API.

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