Работа с СОМ портом, Win2000 Опции

[uvw]

Здравствуйте, уважаемые!
Если кто сталкивался, помогите плизз. Долбаюсь уже 2 недели, и ничего не получается. Ситуация следующая: Есть некий контроллер и общается он с компьютером через RS232, в Win98 все работает, а вот Операционка Win2000
блокирует прямое обращение к портам. Мне подсказали прогу WinDriver для обхода этой проблемы... но опять-же, для LPT порта там есть стандартная заготовка, которая прекрасно работает... а о СОМ порте ни слова. Сразу оговорюсь, я не являюсь системным программистом и с железом дел никогда не имел... а тут пришлось Искренне надеюсь на Вашу помощь. Заранее спасибо.
З.Ы.
Я впервые на этом форуме, и вполне возможно что запостил тему не совсем в тот раздел куда следовало бы.
ЗЗ.ЫЫ
Работать с этой штукой через CreateFile/ReadFile/WriteFile тоже не получается,
в ReadFile постоянно нули возвращаются, хотя команда сформирована верно и контроллером принята...

[Dimonira]

Мужики, вы, похоже так и не поняли. Дело не в умении программировать хост компьютер для обмена по последовательному порту. Поэтому что толку предлагать разные либы и пакеты.
Дело в том, что, видимо, порт контроллера полудуплексный. Т.е. он может в один момент времени либо передавать, либо принимать. Так вот он изначально стоит на приём. Для переключения его на передачу (как я думаю) ему, видимо, надо послать нужную команду, в ответ на которую контроллер что-то выдаст. Просто так он сам, похоже только принимает данные, поэтому передавая ему просто всякую ересь (для тестирования обмена), ответа от него не дождётесь. Надо поддержать протокол, т.е. читать инфу по контроллеру.
Даже если у контроллера полный дуплекс, то не факт, что он просто так должен что-то выдавать пока его не попросишь.

[SergM]

Мужики, вы, похоже так и не поняли. Дело не в умении программировать хост компьютер для обмена по последовательному порту. Поэтому что толку предлагать разные либы и пакеты.
Дело в том, что, видимо, порт контроллера полудуплексный. Т.е. он может в один момент времени либо передавать, либо принимать. Так вот он изначально стоит на приём. Для переключения его на передачу (как я думаю) ему, видимо, надо послать нужную команду, в ответ на которую контроллер что-то выдаст. Просто так он сам, похоже только принимает данные, поэтому передавая ему просто всякую ересь (для тестирования обмена), ответа от него не дождётесь. Надо поддержать протокол, т.е. читать инфу по контроллеру.
Даже если у контроллера полный дуплекс, то не факт, что он просто так должен что-то выдавать пока его не попросишь.

Да, но речь-то идет о ПРОГРАММАТОРЕ! И, насколько я понимаю, инициатором обмена информацией с программируемым устройством должен быть в данном случае именно программатор. А он этого не делает. Кроме того, автор темы пишет, что под ДОС и Win9x он у него работает (или работал и уже не работает? - если уже не работает, тогда действительно, надо разбираться с железякой). А проблемы возникли под NT, что закономерно, т.к. NT не позволяет (без драйверов, нормальных, которых нет, или "псевдо") работать напрямую с портами. Точнее, не с самими COM портами, а с их управляющими регистрами. А именно так и работает (судя по написанному в теме) программка для этого программатора.

Лучше, пожалуй, действительно не морочить себе голову, а работать с ней так, как и работали - из-под ДОС-а.

[khach]

Как автор подтопика о программаторе, уточню. Не работает он потому, что писался по канонам хорошего программирования КОМ портов под ДОС. Т.е кроме работы с регистрами UART, он еще работает с регистрами контроллера прерываний- ставит свой обработчик хардверного IRQ 3/4. Если работу с портами UART многие драйвера КОМ устройств для 2000, XP,'эмулируют корректно ( даже некоторые USB ком порты ставили виртуализатор хардвари, и досовые проги вполне корректно с ними работали), то к контроллеру прерываний XP понятное дело не пускает.
Все это выяснено при дизасме управляющей программы. Теперь осталось два пути - первое- патчить прогу на предмет обращения к Вин API. Но я не настолько крут в хакинге, чтобы вызвать 32 разрядный API из 16-битного DOS DPMI приложения. Хотя это и возможно.
Второе - переписывать целиком управляющую прогу. Что успешно делаеться - переписано несколько ( из сотен) микросхем под винду. Основная проблема- снятие и расшифровка лога обмена между программатором и компом. Он, зараза, может одновременно передавать и принимать данные. А снифера/мониторы Кома под ДОС не работают. Соответственно приходиться писать протокол двумя портами на дополнительном компе. А потом этот лог разгребать для каждой микросхемы в программаторе.