Люди помогите дописать драйвер для модема застрял на ерунде какойто. После отправки AT команды ATS7=60&K3N1 стандартный дайлер винды начинает слать, одну за другой команды AT но при это нечего не читает. По сути у меня больше проблемы с наполнением блока IRP_MJ_DEVICE_CONTROL может кто помочь я подробнее изложу проблему ?
Или кто может литературу подкинет по написанию драйверов для Modem'ов ? В частности инфу по ioctl блоку покуда в DDK почти нечего нет
Люди добрые ну помогите хоть кто не будь я уверен здесь должны быть профи вот лог который создает Free Serial Port Monitor. Строчка под номером «89» последняя из нормальных после начинается какая-то чепуха, и данные больше не считываться звонилкой, хотя буфер в модеме наполняется ответами. Причем что интересно что при запуске теста на notebook’e второй подопытный ком иногда код отрабатывает не пойму почему и происходит дозвон но соединения нет комп зависает в дампе удалось узнать что ошибка связанна с освобождением IRP пакета. Но локализовать и нормально устранить ошибку сложно покуда все выше сказанное отрабатывает раз от раза. Конфигурация Машин PC-1 CPU P4 2800C 512Mb Intel865G GF64Mb 440MX HDD80SB Windows XP SP1 PC-2 - notebook Crusoe 1000MHz 256Mb ALI7101 SIS315E16MB HDD30SB Windows XP SP2 _1022203448__Log.rar
читай мануалы по AT командам. Значит чего-то драйвер не фильтрует, к примеру вот такой чудный символ " >"
Да я уже зачитался по поводу этих АТ команд, но проблема в том, что если проанализировать работу модема с помощью программы «Bus Hound» которая демонстрирует обмен данными модемом с драйвером, то видно, что модем успешно отвечает на эту команду типа «ATS7=60&K3N1». Но при запуске Free Serial Port Monitor картина меняется, покуда она анализирует обмен данными уже с пользовательской программой (проще сказать с сервисов по дозвону). Выходит, что запрос на чтение не идет единственный способ который я нашел дизассемблировать стандартную звонилку в Windows и узнать чаво она там творит. Да кстати написанный мною тест по аналогии обмена данными с модемом как это делает стандартная звонил-ка, не выявил никаких задержек или ошибок все происходит мгновенно и без проблем.
AndreyZi исходники диалеров лежат на codeproject.net. Не помню как называется, но делал ее русский программер (мелочь, а приятно). А твой драйвер напрямую с модемом общается?! Ведь можно же было через TAPI...
Ура мне удалось найти ошибку, вся проблема оказалась в бесконечном ожидании ЭХО от Модема в моем супер драйвере. Ну то бишь если было послана команда «AT.» то я ожидал ответа типа «AT…OK..» (где точки символы типа 0x0D 0x0A) забыв совсем, что после посылки спец команды эхо исчезает и на логе это четко видно поэтому последующие чтение в асинхронном режиме некогда не возвращает управления. В общем как всегда причина в кривых руках ведь это мой первый опыт в написании драйверов. А ошибку искал аж 3 недели пока не дизассемблировал стандартный дайлер, точнее одну из библиотек “unimdmat.dll вызов UmInitModem” и там до меня дошло что для работы используются асинхронный стандартный API такие как ReadFileEx и WriteFileEx. И получается в данной картине, сначала система пытается прочитать один байт, потом записывает команду результат которой должен быть считан а тока после этого получает ответ причем считывает при током запросе исключительно один байт. Вот такие пироги. «Наверно все это описано где ни будь в доке но вот такой я человек учусь на своих ошибках». Но самое обидное, что на этом проблемы не закончились и раздобыть всю глубину мысли заложенную в “IOCTL_SERIAL_WAIT_ON_MASK” пока не удалось. Единственное что я узнал, что после получения сообщения типа “CONNECT” драйвер должен освободить IRP захваченный ранее через “IOCTL_SERIAL_WAIT_ON_MASK” и сообщит мол соединение создано ну я написал совсем глупый как мне кажется код мол проверяется после каждой команды а не CONNECT ли считан и если да то освобождаем IRP пакет. И получилось так, соединение происходит, но без обработки остальных МАСОК ожидания мой драйвер просто не может нормально читать и писать данный, и ответы от сервака опять не читаются и лежат мертвым грузов и буфере, а звонил-ка тем временем, без остановки пытается запихнуть свои запросы на сервер. Картина как всегда веселая. И так опять «Вопрос» ну прям как в «О счастливчике» кто ни будь может подкинуть доку толковую или исходники по обслуживанию IOCTL_SERIAL_WAIT_ON_MASK запроса буду очень благодарен. [back=]А твой драйвер напрямую с модемом общается?! Ведь можно же было через TAPI...[/back] Модем, для которого я пишу драйвер, является USB, ну поэтому приходится на прямую точнее с драйвером по обслуживанию шины USB стоящей ниже по стеку драйверов.
