[Microdevice 0]

Спасибо всем откликнувшимся. Будем изучать материал по вашим ссылкам.

[OgRom 0]

Мы наступали на подобные грабли.

(В качестве 9 бита использовался бит четности, установка parityMark/paritySpace)

2 распостраненные засады:

1) Переключение с parityMark на paritySpace при выполнении программы происходит раньше, чем байт будет выдан через UART (освободится сдвиговый регистр). В результате на линию будет выдан байт с состоянием paritySpace.

2) При попытке реализации задержек с использованием функции sleep между адресным байтом и байтом данных возникает пауза, не меньшая времени переключеня задач Windows (10 мс для Win2K). Многие устройства эту паузу принимают за срыв посылки.

[Microdevice 0]

Мы наступали на подобные грабли.

(В качестве 9 бита использовался бит четности, установка parityMark/paritySpace)

2 распостраненные засады:

1) Переключение с parityMark на paritySpace при выполнении программы происходит раньше, чем байт будет выдан через UART (освободится сдвиговый регистр). В результате на линию будет выдан байт с состоянием paritySpace.

2) При попытке реализации задержек с использованием функции sleep между адресным байтом и байтом данных возникает пауза, не меньшая времени переключеня задач Windows (10 мс для Win2K). Многие устройства эту паузу принимают за срыв посылки.

Похоже у нас то же самое. Как Вы боролись с этими проблемами?

[OgRom 0]

Похоже у нас то же самое. Как Вы боролись с этими проблемами?

 

1) WIN95,98,ME - непосредственная работа с UART (контроль состояния завершения выдачи). В связи с вымиранием вышеуказанных ОС неактуально :)

 

2)NT семейство - програмная реализация задержек, без использования команд sleep, используем GetTickCount. При этом в NT семействе ни один из применявшихся нами способов избежать паузу в 10 мс между адресным и последующим байтом не позволяет...

[a_electronic 0]

Идея использовать 9-й бит, конечно заманчива, но почитайте историю наступания на данные грабли. Предположим, возьмем Виндоуз ХР. Все будет работать, при соблюдении двух условий: если порт открыт, как overlapped и... система достаточно чистая.

Алгоритм следующий:

1. Инициализируем DCB как 9 бит с пробелом.

2. Пишем в порт 1 байт.

3. Опять переиниализируем DCB как 9 бит, но уже с маркером.

4. Пишем данные.

Можно еще лапкой дергать RTS для управления 485 драйвером, все работает.

Но. Если не дай бог, на машине вдруг будет установлен модем, либо драйвер считывателя штрих-кодов, либо виртуальный КОМ, начинается развлекуха. Порт на таком алгоритме просто виснет. В логах системы появляется сообщение, что драйвер устройства выполнил некорректную операцию и выгружен. КОМ порт исчезает из системы.

Обойти эту залипуху можно, если между вторым и третьим пунктом воткнуть операцию

Sleep(1);

Пауза между первым(адресным) байтом и остальным пакетом составляет 5-20 мСек, а если запущен Winamp, то и все 50.

Посему я расслабился использовать этот способ адресации на компортах и никому бы не советовал напрягаться. Проще использовать механизм от MODBUS.

 

Sorry, поправка, я пробел с маркером перепутал.

[muravei 3]

Может, я чего не понимаю, но почему нельзя программно эмулировать передачу 9 бит? Как на Мк без УАРТа.

Тупо дергая ТХ, сделать стартовый ,данные(9бит) и стоп.

Если не ставить рекордов скорости.

[zltigo 0]

Тупо дергая

Тупо? Тупо всегда можно :) Рассказывайне как там "тупо" под WINNT API чем-нибудь дергать и так-же "тупо" опрашивать.

[muravei 3]

Рассказывайне как там "тупо" под WINNT API чем-нибудь дергать и так-же "тупо" опрашивать.

Тупо так.

hCom=CreateFile(COM.c_str(),GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);

EscapeCommFunction(hCom,SETBREAK); //1

EscapeCommFunction(hCom,CLRBREAK); //0

[zltigo 0]

EscapeCommFunction(hCom,SETBREAK); //1

EscapeCommFunction(hCom,CLRBREAK); //0

А что такое Break, слабо было узнать? Ну оочееееннь длинииииинный 0 Вы сгенерите а что дальше? Особенно интересует длительность фазы после передачи Break. Ну и с приемом как?

[muravei 3]

А что такое Break, слабо было узнать?

Не Break, а SETBREAK и CLRBREAK.Напрягитесь и посмотрите WIN API.

Не задавались вопросом , как работают простейшие программаторы через ком порт?

[xemul 0]

Не Break, а SETBREAK и CLRBREAK.Напрягитесь и посмотрите WIN API.

Не задавались вопросом , как работают простейшие программаторы через ком порт?

С каким дискретом и с какой стабильностью Вы можете формировать временной интервал под NT-образными средствами WinAPI?

Вы не задавались вопросом, почему в тырнете столько стонов на тему "Простейший программатор ххх работает на компе моего друга Васи, а на моем не хочет"?

[zltigo 0]

Не Break, а SETBREAK и CLRBREAK

Нет именно Break.

Set и Clear это уже управление Break-ом - посылкой длинного стартового бита с длительностью гарантированно превыщающей длительность всего фрейма (включая стоповые биты) на заданной скорости. Никаких аппаратных или драйверных средств для задания и соблюдения длительности Break и тем более паузы между Break не предусмотрено. Определения длительности Break (полько пороговое превышение) и пауз между Break-ами тоже не предусмотрено, что ставит крест на приеме.

"Простейшие программаторы" закончили свое существование на Win9x. На WinNT они уже не жильцы, если, естествено, под них не написан свой драйвер. Написание своего драйвера снимает и проблему с передачей 9 бита через Parity.

[a_electronic 0]

Вообще то для любителей тупо подергать за порт под 200/ХР есть прямые функции обращения к драйверу. Работают раз в 10 быстрее, чем обычные АРIшные. Кроме этого, есть еще такая штука. называется giveio.sys, с еепомощью можно достать любые I/O регистры и подергать за что угодно. Только UART сэмулировать не получится. поскольку винда - не система реального времени. Синхронные интерфейсы в мастер режиме - скоко угодно, но не UART.

[muravei 3]

Set и Clear это уже управление Break-ом - посылкой длинного стартового бита с длительностью гарантированно превыщающей длительность всего фрейма (включая стоповые биты) на заданной скорости.

Причем превышаюшей навсегда- при посылке SETBREAK и CLRBREAK? вывод ТХ , задерживается в выбранном состоянии значительно дольше чем фрейм состоповыми битами, до момента пока не будет послан противоположный.

Кстати , про скорость и про дуплекс никто не намекал.

[zltigo 0]

...до момента пока не будет послан противоположный.

Естественно, поскольку, как я уже писал, НИКАКИХ средств для управления длительностью не предоставляется - все на уровне приложения. К чему это Ваша ремарка? К тому, что если махать Break раз, например, в минуту, (ну ладно с временными интервалами более-менее точно обеспечиваемыми Win и его RS232 драйвером) то оно "прокатит" для медленнооооой передачи?

Кстати , про скорость и про дуплекс никто не намекал.

Да не намекал. Намеком это действительно назвать сложно:

И так же 2 байта прием от контроллера.

Это прямое указание на необходимость дуплекса.