[khach 33]

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

Все это выяснено при дизасме управляющей программы. Теперь осталось два пути - первое- патчить прогу на предмет обращения к Вин API. Но я не настолько крут в хакинге, чтобы вызвать 32 разрядный API из 16-битного DOS DPMI приложения. Хотя это и возможно.

Второе - переписывать целиком управляющую прогу. Что успешно делаеться - переписано несколько ( из сотен) микросхем под винду. Основная проблема- снятие и расшифровка лога обмена между программатором и компом. Он, зараза, может одновременно передавать и принимать данные. А снифера/мониторы Кома под ДОС не работают. Соответственно приходиться писать протокол двумя портами на дополнительном компе. А потом этот лог разгребать для каждой микросхемы в программаторе.

[Dimonira 0]

Я как-то пропустил слова о реверс-инжиниринге.

Тогда всё понятно. Ломаете чужую IP.

В вашем случае по-моему проще снять протокол обмена, понять его, а дальше наваять свою программу.

[Serjio 0]

Мы пользуемся CPORT под все Windows

cport_3.0.zip

[-Tумблер- 0]

Не работает он потому, что писался по канонам хорошего программирования КОМ портов под ДОС. Т.е кроме работы с регистрами UART, он еще работает с регистрами контроллера прерываний  ... к контроллеру прерываний XP понятное дело не пускает.

 

<{POST_SNAPBACK}>

 

Это не так.

Лично проверил это:

WinNT-4

WinXP Prof RUS

WinXp Rpof ENG

Win2003 Server Enterp. Edition

 

С компами - notebook какой-то там P~100, PII-300, Celeron-1100,

PIV~2,66 ДОС-программа с КОМ-портами по прерываниям РАБОТАЕТ !

:tongue: :tongue: :tongue:

Мало того - эта программа еще и лезет нагло в видеопамять - и все OK.

 

Чтобы не обманывать научно-техническую общественность зазря,

привожу сами программы (программа-терминал + драйвер),

файлы "read.me" и все исходные тексты.

 

http://spiprog.chat.ru/comdos.zip

или

http://spiprog.narod.ru/comdos.zip

 

Программа не просто как то там тестировалась - к ком-порту

цеплялся осциллограф. На предмет проверки соответствия

летящих байтов, скоростей, стопов и стартов.

Все OK по полной программе.

 

:tongue: :tongue: :tongue:

[Angel 0]

может кому пригодиться h__p://www.rs232.ru/

[PowerF1 0]

Подскажите, у меня такая проблема.

Когда собирал мк, написал прогу(а точне собрал уз кусочков) обмена информацией чз СОМ-порт. Это была передача в мк по нажатию клавиши и следом прием. т.е. при обработке сообщения WV_CHAR.

Никаких проблем, винда определила, что нажата клавиша, остается только отослать и принять данные. Так я оттестил мк, все работало.

Сейчас стоит другой вопрос. Мк должен только посылать данные на комп.А как их принимать я не знаю. Какое сообщение использовать, когда данные пришли? Может кто знает?

Мне говорили что-то про пользовательское сообщение. Как можно разрулить с ним?

[_VM 0]

Программируй на 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...

[Lukomor 0]

Подскажите пожалуйста! Есть проблема работы с СОМ из под W2K с прямым доступом. Пробовал различные драйвера giveio/userport/porttalk/totalio - безуспешно. Данные в порт (0х3F8) уходят, но на выходе не появляются (проверял осциллографом). При запуске из w98 все работает (хотя там драйвера эти не нужны). К сожалению не могу перейти на WINAPI - протокол обмена конечного устройства не позволяет (из-за временнЫх задержек). Может кто с такой ситуацией сталкивался?

[_VM 0]

Если протокол связи накладывает жесткие временные ограничения (самый жесткач это ответ 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 задачку решить, если это вообще реально сделать.

[-Tумблер- 0]

заводишь поток(CreateThread), в котором читаешь COM порт (ReadFile).

 

Можно лишь добавить - пишем в COM-порт из того же потока - WriteFile.

(Когда нужно- когда появились данные для вывода).

При этом эти операции выполняются строго

по-очередно. А иначе - при попытке читать/писать из разных

потоков получаются "полные раки".

:)

[SergM 0]

А для отладки софта, работающего с СОМ под Windows, иногда удобно использовать драйвер виртуальных СОМ портов Virtual Serial Ports Driver

 

Он позволяет создать нужное количество пар COM портов , соедининенных виртуальными кабелями типа "null-modem". Виртуальные СОМ порты с точки зрения софта ничем не отличаются от реальных.

[_VM 0]

заводишь поток(CreateThread), в котором читаешь COM порт (ReadFile).

 

Можно лишь добавить - пишем в COM-порт из того же потока - WriteFile.

(Когда нужно- когда появились данные для вывода).

При этом эти операции выполняются строго

по-очередно. А иначе - при попытке читать/писать из разных

потоков получаются "полные раки".

:)

<{POST_SNAPBACK}>

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

[Lukomor 0]

Спасибо _VM за ответ.

...

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.

 

... я бы выгрузил стандартный драйвер 2k, настроил порт как в дос, и молотил бы в 0х3F8...

Возможно, это как раз то, что нужно. Если можно расскажи подробнее.

 

...

Если протокол опишешь(где какие минимальные задержки), может подскажу как на WinAPI задачку решить, если это вообще реально сделать.

...

В протоколе 2 "засады":

1) от передачи командного слова от PC до ответного слова устройства - 15...40 мкс.

2) от передачи командного слова от устройства до ответного слово от PC 11 мс.

 

Буду благодарен за помощь!

[-Tумблер- 0]

А я что-то не соображу, почему из 2-х разных потоков одновременно читать/писать неполучится

 

Честно говоря - я тоже. И был бы рад и благодарен,

если бы мне обьяснили - почему. :(

Для меня это было неприятным сюрпризом.

Но опытным путем удалось установить:

Под:

WIN95 - никаких проблем.

WIN98 - становится неустойчиво

WINXP - система виснет так, что только аппаратный сброс.

Используя беседы в конфах, удалось выяснить, что не только

у меня так.

То ли это ошибки библиотек компиляторов (Рихтер весьма

прозрачно намекает об этом для VC). То ли это особенности ОС.

Я полагаю - возможно и то, и другое.

Собственно, это не мешает, если знаешь.

Один поток делает ReadFile, проверяет - есть ли для вывода,

если есть - WriteFile.

Иначе мне сделать не удалось.

:)

[-Tумблер- 0]

В протоколе 2 "засады":

1) от передачи командного слова от PC до ответного слова устройства - 15...40 мкс.

2) от передачи командного слова от устройства до ответного слово от PC 11 мс.

 

Полагаю, с пунктом 1 "API вариант" точно должен справится - почему нет ?

Не помню такого, что бы драйвер COM порта у WIN не принял

правильно данные даже на самой большой скорости и на не очень

сильном компьютере.

 

Со вторым пунктом действительно могут быть проблемы.

Тут можно попытаться:

1. поднять приоритет потока приложения повыше . Как можно выше и

не запускать другие приложения.

2. отрихтовать вручную (это для win98 - для XP сам смотри как там..):

пуск-настройка-панель управления-система-устройства-последовательный порт (1?)-свойства-настройка порта-дополнительно-буфер приема =1-OK.

 

:)