|
|
|
Работа с СОМ портом, Win2000 |
|
|
|
Feb 15 2005, 10:11
|
Гуру
Группа: Свой
Сообщений: 3 439
Регистрация: 29-12-04
Пользователь №: 1 741
|
Как автор подтопика о программаторе, уточню. Не работает он потому, что писался по канонам хорошего программирования КОМ портов под ДОС. Т.е кроме работы с регистрами UART, он еще работает с регистрами контроллера прерываний- ставит свой обработчик хардверного IRQ 3/4. Если работу с портами UART многие драйвера КОМ устройств для 2000, XP,'эмулируют корректно ( даже некоторые USB ком порты ставили виртуализатор хардвари, и досовые проги вполне корректно с ними работали), то к контроллеру прерываний XP понятное дело не пускает. Все это выяснено при дизасме управляющей программы. Теперь осталось два пути - первое- патчить прогу на предмет обращения к Вин API. Но я не настолько крут в хакинге, чтобы вызвать 32 разрядный API из 16-битного DOS DPMI приложения. Хотя это и возможно. Второе - переписывать целиком управляющую прогу. Что успешно делаеться - переписано несколько ( из сотен) микросхем под винду. Основная проблема- снятие и расшифровка лога обмена между программатором и компом. Он, зараза, может одновременно передавать и принимать данные. А снифера/мониторы Кома под ДОС не работают. Соответственно приходиться писать протокол двумя портами на дополнительном компе. А потом этот лог разгребать для каждой микросхемы в программаторе.
|
|
|
|
|
Feb 17 2005, 08:01
|
Частый гость
Группа: Свой
Сообщений: 137
Регистрация: 3-09-04
Пользователь №: 594
|
Мы пользуемся CPORT под все Windows
|
|
|
|
|
Feb 17 2005, 18:40
|
Частый гость
Группа: Свой
Сообщений: 146
Регистрация: 4-11-04
Из: Московская область
Пользователь №: 1 040
|
Цитата(khach @ Feb 15 2005, 13:11) Не работает он потому, что писался по канонам хорошего программирования КОМ портов под ДОС. Т.е кроме работы с регистрами UART, он еще работает с регистрами контроллера прерываний ... к контроллеру прерываний XP понятное дело не пускает. Это не так. Лично проверил это: WinNT-4 WinXP Prof RUS WinXp Rpof ENG Win2003 Server Enterp. Edition С компами - notebook какой-то там P~100, PII-300, Celeron-1100, PIV~2,66 ДОС-программа с КОМ-портами по прерываниям РАБОТАЕТ ! Мало того - эта программа еще и лезет нагло в видеопамять - и все OK. Чтобы не обманывать научно-техническую общественность зазря, привожу сами программы (программа-терминал + драйвер), файлы "read.me" и все исходные тексты. http://spiprog.chat.ru/comdos.zipили http://spiprog.narod.ru/comdos.zip Программа не просто как то там тестировалась - к ком-порту цеплялся осциллограф. На предмет проверки соответствия летящих байтов, скоростей, стопов и стартов. Все OK по полной программе.
--------------------
- ЗАМЕНЯТЬ ДЕТАЛИ НА ХОДУ ВОСПРЕЩАЕТСЯ !!! -
|
|
|
|
|
Mar 18 2005, 15:59
|
Участник
Группа: Новичок
Сообщений: 34
Регистрация: 12-03-05
Из: Новосибирск
Пользователь №: 3 288
|
Подскажите, у меня такая проблема. Когда собирал мк, написал прогу(а точне собрал уз кусочков) обмена информацией чз СОМ-порт. Это была передача в мк по нажатию клавиши и следом прием. т.е. при обработке сообщения WV_CHAR. Никаких проблем, винда определила, что нажата клавиша, остается только отослать и принять данные. Так я оттестил мк, все работало. Сейчас стоит другой вопрос. Мк должен только посылать данные на комп.А как их принимать я не знаю. Какое сообщение использовать, когда данные пришли? Может кто знает? Мне говорили что-то про пользовательское сообщение. Как можно разрулить с ним?
|
|
|
|
|
Mar 23 2005, 17:01
|
Участник
Группа: Свой
Сообщений: 58
Регистрация: 23-03-05
Из: Москва
Пользователь №: 3 625
|
Программируй на C++Builder - меньше заморачиваться с сообщениями будешь.
Судя по всему интересует асинхронное получение данных по COM порту. Пользовательское сообщение использовать можно, но судя по постановке задачи, опыта у тебя маловато. Не в обиду, хочу как лучше.
пользовательские сообщения описываешь, например, так: #define MY_MSG (WM_APP+10)
заводишь поток(CreateThread), в котором читаешь COM порт (ReadFile). Операция чтения не должна быть OVERLAPPED! По получению данных, ReadFile разблокируется, вызывай тогда PostMessage(MY_MSG) или PostThreadMessage(MY_MSG), в зависимости от того, куда хочешь послать сообщение (окну или потоку). В том месте программы, где обрабатываешь WM_CHAR добавь обработку MY_MSG. Короче, данные из COM порта читаешь в одном потоке, а обрабатываешь в другом.
Можешь поступить проще - работать по таймеру. 1) Заводишь таймер (SetTimer), указывая хэндл своего окна. 2) В том месте, где обрабатываешь WM_CHAR, добавляешь обработку WM_TIMER. Обработка заключается в вызове ReadFile. ReadFile должен быть в этом случае overlapped, иначе он заблокирует твой поток до наступления таймаута, указанного при инициализации драйвера COM порта (SetCommTimeouts).
Уф! И да прибудет с тобой MS Win32 SDK...
|
|
|
|
|
Mar 28 2005, 09:19
|
Участник
Группа: Свой
Сообщений: 58
Регистрация: 23-03-05
Из: Москва
Пользователь №: 3 625
|
Если протокол связи накладывает жесткие временные ограничения (самый жесткач это ответ PC по запросу внешнего устройства через маленькое время), то спасет только собственный драйвер. Если под 98 задача решается, то под 2к при помощи своего драйвера ее тоже можно решить. Самые быстрые варианты управления COM-портом, в порядке возрастания (по собственным ощущениям): 1) DOS на СИ или ASMе 2) WinNT, 2k, XP с собственным драйвером 3) Win95/98 с дос программой 4) Win API 5) WinNT, 2k, XP с DOS программой (работа с портами напрямую) 5й вариант самый медленный из-за приема данных. Данные-то надо забирать из фифо по прерываниям, а они до VDM (VirtualDosMashine) могут долго доезжать. В виндовом приложении чтение можно организовать только полингом регистра статуса (LSR). Оно тебе надо? Это ж тормоза 100%, а на большой скорости данные теряться будут. Если не переубедил - я бы выгрузил стандартный драйвер 2k, настроил порт как в дос, и молотил бы в 0х3F8. Только не понятно зачем это все нужно (запуск дос программ под 2к или в виндовых приложениях). Если протокол опишешь(где какие минимальные задержки), может подскажу как на WinAPI задачку решить, если это вообще реально сделать.
|
|
|
|
|
Mar 28 2005, 11:05
|
Частый гость
Группа: Свой
Сообщений: 146
Регистрация: 4-11-04
Из: Московская область
Пользователь №: 1 040
|
Цитата(_VM @ Mar 23 2005, 20:01) заводишь поток(CreateThread), в котором читаешь COM порт (ReadFile). Можно лишь добавить - пишем в COM-порт из того же потока - WriteFile. (Когда нужно- когда появились данные для вывода). При этом эти операции выполняются строго по-очередно. А иначе - при попытке читать/писать из разных потоков получаются "полные раки".
--------------------
- ЗАМЕНЯТЬ ДЕТАЛИ НА ХОДУ ВОСПРЕЩАЕТСЯ !!! -
|
|
|
|
|
Mar 29 2005, 00:20
|
Участник
Группа: Свой
Сообщений: 58
Регистрация: 23-03-05
Из: Москва
Пользователь №: 3 625
|
Цитата(-Tумблер- @ Mar 28 2005, 14:05) Цитата(_VM @ Mar 23 2005, 20:01) заводишь поток(CreateThread), в котором читаешь COM порт (ReadFile). Можно лишь добавить - пишем в COM-порт из того же потока - WriteFile. (Когда нужно- когда появились данные для вывода). При этом эти операции выполняются строго по-очередно. А иначе - при попытке читать/писать из разных потоков получаются "полные раки". А я что-то не соображу, почему из 2-х разных потоков одновременно читать/писать неполучится . Вот если из 2-х потоков одновременно писать захочется, то да - понадобится синхронизацию реализовывать. А при разделенных записи/чтении в чем проблема?
|
|
|
|
|
Mar 29 2005, 05:36
|
Участник
Группа: Новичок
Сообщений: 25
Регистрация: 28-03-05
Пользователь №: 3 734
|
Спасибо _VM за ответ. Цитата(_VM @ Mar 28 2005, 12:19) ... 1) DOS на СИ или ASMе 2) WinNT, 2k, XP с собственным драйвером 3) Win95/98 с дос программой 4) Win API 5) WinNT, 2k, XP с DOS программой (работа с портами напрямую) ... Варианты 1, 3, к сожалению, не подходят. 2 вариант - немного не понял. Что значит "с собственным драйвером"? Если это с использованием недокументированных I/O функций WINAPI, то это уже имело место быть в giveio и т.д. Вариант 4 пробовал. При реализации на С++ с WINAPI (CreateFile + DCB + ...) - не успеваю по протоколу. Насчет 5, из DOSa, (я так понимаю что из консоли) заморочка для меня будет большая, так как основное приложение WIN32. Я пробую в виндовское оконное приложение воткнуть команды ассемблера для прямой работы с портом, а чтобы не "орала" защита гружу giveio. Причем конфигурирую порт таким же образом, как в ДОСе. Все что посылаю при этом в 0x3F8...0x3FE уходит "в пустоту" Чтение 0x3F8 возвращает ранее записанное туда слово (на выходе порта по прежнему ничего не появляется!), а чтение остальных 0x3F_ возвращает FF. Цитата(_VM @ Mar 28 2005, 12:19) ... я бы выгрузил стандартный драйвер 2k, настроил порт как в дос, и молотил бы в 0х3F8... Возможно, это как раз то, что нужно. Если можно расскажи подробнее. Цитата(_VM @ Mar 28 2005, 12:19) ... Если протокол опишешь(где какие минимальные задержки), может подскажу как на WinAPI задачку решить, если это вообще реально сделать. ... В протоколе 2 "засады": 1) от передачи командного слова от PC до ответного слова устройства - 15...40 мкс. 2) от передачи командного слова от устройства до ответного слово от PC 11 мс. Буду благодарен за помощь!
|
|
|
|
|
Mar 29 2005, 06:04
|
Частый гость
Группа: Свой
Сообщений: 146
Регистрация: 4-11-04
Из: Московская область
Пользователь №: 1 040
|
Цитата(_VM @ Mar 29 2005, 03:20) А я что-то не соображу, почему из 2-х разных потоков одновременно читать/писать неполучится Честно говоря - я тоже. И был бы рад и благодарен, если бы мне обьяснили - почему. Для меня это было неприятным сюрпризом. Но опытным путем удалось установить: Под: WIN95 - никаких проблем. WIN98 - становится неустойчиво WINXP - система виснет так, что только аппаратный сброс. Используя беседы в конфах, удалось выяснить, что не только у меня так. То ли это ошибки библиотек компиляторов (Рихтер весьма прозрачно намекает об этом для VC). То ли это особенности ОС. Я полагаю - возможно и то, и другое. Собственно, это не мешает, если знаешь. Один поток делает ReadFile, проверяет - есть ли для вывода, если есть - WriteFile. Иначе мне сделать не удалось.
--------------------
- ЗАМЕНЯТЬ ДЕТАЛИ НА ХОДУ ВОСПРЕЩАЕТСЯ !!! -
|
|
|
|
|
Mar 29 2005, 07:35
|
Частый гость
Группа: Свой
Сообщений: 146
Регистрация: 4-11-04
Из: Московская область
Пользователь №: 1 040
|
Цитата(Lukomor @ Mar 29 2005, 08:36) В протоколе 2 "засады": 1) от передачи командного слова от PC до ответного слова устройства - 15...40 мкс. 2) от передачи командного слова от устройства до ответного слово от PC 11 мс. Полагаю, с пунктом 1 "API вариант" точно должен справится - почему нет ? Не помню такого, что бы драйвер COM порта у WIN не принял правильно данные даже на самой большой скорости и на не очень сильном компьютере. Со вторым пунктом действительно могут быть проблемы. Тут можно попытаться: 1. поднять приоритет потока приложения повыше . Как можно выше и не запускать другие приложения. 2. отрихтовать вручную (это для win98 - для XP сам смотри как там..): пуск-настройка-панель управления-система-устройства-последовательный порт (1?)-свойства-настройка порта-дополнительно-буфер приема =1-OK.
--------------------
- ЗАМЕНЯТЬ ДЕТАЛИ НА ХОДУ ВОСПРЕЩАЕТСЯ !!! -
|
|
|
|
|
|
4 чел. читают эту тему (гостей: 4, скрытых пользователей: 0)
Пользователей: 0
|
|
|