В микроконтроллерах в модуле UART есть 9-ти битный адресный режим. Кто-нибудь пробовал организовать связь, используя этот режим между ПК и контроллером? Непонятно как настроить такой режим последовательного порта компьютера. Между двумя контроллерами все ок, но нужно связать с ПК. Заранее благодарен за дельные советы.

Никак, если только речь не идет о вспомогательной функции 9бита при передаче к PC, тогда к нему
можно некоторый доступ через parity получить. Описание 550 чипа не секрет - ознакомьтесь.

Именно по этому пути я и пошел.
Перед передачей из ПК адресного байта в Delphi:
procedure SetCommandByte;
begin
if not Windows.GetCommState(f, dcb) then exit;
dcb.Parity := 3;
Windows.SetCommState(f, dcb);
end;

Перед обычным 8 битовым
procedure SetDataByte;
begin
if not Windows.GetCommState(f, dcb) then exit;
dcb.Parity := 4;
Windows.SetCommState(f, dcb);
end;

И ничего не получается.

Анализ бита Parity или управление им в Windows по-моему геморрой еще тот. Когда-то у нас применяли этот способ адресации при реализации протокола PiNet, но потом отказались. Windows по большому счету чихать хотела на наличие/отсутствие/нарушение parity. Поток данных от COM-порта принимается в любом случае.

Речь не о приеме данных в ПК, а о передаче из него на устройство. Нужно первый байт сделать адресным, последующие обычные 8-ми битовые.

Про какой-нибудь, как обычно левый "компонет" Delphi + Штатный драйвер от MS придется почти наверняка забыть.
Драйверок свой писать, ну а вррбще пожалуй Вам SLIP полагаю стоит посмотреть.

Все на API без компонентов. А что такое SLIP?

Поиск вообще-то помогает. http://rfc.net/rfc1055.html

И чем мне это поможет? Мне нужно как-то портом оперировать.

Насколько я понимаю цель не "портом оперировать". Это стедство достижения цели. Какой?
Полагаю цель выделить начало передачи некого фрейма/пакета? Эта цель достигается в SLIP протоколе не вводя 9 бит.

Нужно передать 2 байта. В первом 9-й бит (понятно что это уже не байт) должен быть установлен в "1", второй с "0" в 9-м бите. И так же 2 байта прием от контроллера.

Пардон. Речь конечно о 8-м бите. Голова уже кругом идет.

Опять средство
Перевожу на понятный язык - нужно передать пакет из двух байт (16 бит). Начало пакета надо знать.
Его отметка 9м битом лишь один из вариантов реализации задачи. Задача отметки битом нормально не реализуема на стороне PC+Windows. Значит придется добавлять байтстаффинг (SLIP), или UUE кодирование, или подобное.

Можно поподробнее? Начало пакета знаем (2 по 9 бит). Прошивку в железе менять нельзя, знаем только протокол по которому можно с ней общаться.

Нужно именно 2 посылки по 9 бит.

Пишите нормальный драйвер ориентированный на выделение двухбайтовых посылок для Win.
Либо пытайтесь выделять прием в PC без 9бита (по крайней мере только иногда по нему подсинхронизироваться удастся) и постоянное перепрограммирование порта перемежающееся flush(). Да, и FIFO отключите.

zltigo, да не запутывайте вы окончательно товарища! Не понимает он с ходу термина "битстаффинг" и принципов транспортного протокола. Отсутствие опыта не порок и дело наживное ИМХО. Если на SLIP ссылку не даете, так хоть на Wake дайте. Зря что ли Леонид Иванович старался, статью писал, примеры и dll-ки выкладывал?
Спецификация протокола WAKE

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

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

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

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

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

Идея использовать 9-й бит, конечно заманчива, но почитайте историю наступания на данные грабли. Предположим, возьмем Виндоуз ХР. Все будет работать, при соблюдении двух условий: если порт открыт, как overlapped и... система достаточно чистая.
Алгоритм следующий:
1. Инициализируем DCB как 9 бит с пробелом.
2. Пишем в порт 1 байт.
3. Опять переиниализируем DCB как 9 бит, но уже с маркером.
4. Пишем данные.
Можно еще лапкой дергать RTS для управления 485 драйвером, все работает.
Но. Если не дай бог, на машине вдруг будет установлен модем, либо драйвер считывателя штрих-кодов, либо виртуальный КОМ, начинается развлекуха. Порт на таком алгоритме просто виснет. В логах системы появляется сообщение, что драйвер устройства выполнил некорректную операцию и выгружен. КОМ порт исчезает из системы.
Обойти эту залипуху можно, если между вторым и третьим пунктом воткнуть операцию
Sleep(1);
Пауза между первым(адресным) байтом и остальным пакетом составляет 5-20 мСек, а если запущен Winamp, то и все 50.
Посему я расслабился использовать этот способ адресации на компортах и никому бы не советовал напрягаться. Проще использовать механизм от MODBUS.

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

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

Тупо? Тупо всегда можно Рассказывайне как там "тупо" под 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

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

Не Break, а SETBREAK и CLRBREAK.Напрягитесь и посмотрите WIN API.
Не задавались вопросом , как работают простейшие программаторы через ком порт?

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

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

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

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

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

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

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

Или полудуплекса , или Вы читаете между строк?
Кстати, а как читаются 1-wire через компорт?Там времена не длинные.
Упоминается дллька COMAPI32, но нигде не нашел ее и исходник.

C передачей полагаю уже выяснили - если вдруг с какого-то бодуна разработчики контроллера предусмотрели работу на скоростях в несколько бод, то все прекрасно складывается .

Просто повторил Ваши слова. Хотите полудуплекс - нехай будет, и симлекс пусть будет.
Рассказывайте как принимать Break-и на стороне PC будете .

Очень просто: посылается символ 0xFC и принимается эхо. Если получили 0xFC - слейв передавал единицу, если 0xF8, 0xF0, 0xE0, 0xC0, 0x80, 0x00 - слейв передавал ноль. С Presence pulse тоже самое, только на другой скорости (ну может передается не 0xFC а 0xF0). И никаких чудес. В 1-wire не нормируется время между битами.

А как со стартовым битом?

Стартовый бит равен нулю, стоповый 1, в UART байт передается младшим битом вперед, получается 0xFC = 0001111111, что и требуется для 1-wire. Если в "эхе" больше трех нулей в начале, значит кто-то линию "придержал", т.е передавал ноль, если столько же - передавалась 1, т.е линию никто не тянул вниз.