чтение из порта = 0x3fe

Shasik



Вот и здрово, проблема разрешилась. Действительнро, я искал про iomap по форуму (помню, что было пару лет назад), а про "драйверские" статьи Four-F просто не подумал. А самому про это рассказывать - долго и тоскливо, надо объяснять про TSS, про iomap, про различия в обработке доступа к портам в Win9X и WinNT и т.п.



Quantum

На 3х моих компах утверждение совершенно справедливо.



Оффтопиком и не пахнет. И вот с этого места, пожалуйста, поподробней. Итак, тезис от Quantum: современные микросхемы UART умеют самостоятельно определеть скорость последовательной передачи данных.



IMHO, не соответствует (и не может!) действительности! Это можно только программно, причем если известно, _что_именно_ посылается. Впрочем, а вдруг...



Итак, Quantum, вот 2 компьютера. Соединены 0-модемным кабелем. Один из этих компьютеров - мой, и я посылаю _нечто_ с _неизвестной_ скоростью.



Quantum, вперед. Объяснения в студию. Думаю, что это действительно интересно и полезно.

 

drmad

Во-первых, всегда известно, что скорость может быть либо 110, либо 300, ..., либо 19200, ... +/- некоторые отклонения в пределах терпимости PLL.



Во-вторых, нужно уточнить, что _нечто_ передаётся по протоколу RS232, т.е. каждый байт упаковывается во фреймы вполне известного формата:



Первым идёт стартовый бит. Далее идут n битов данных, где, обычно 5 <= n <= 8. Потом ещё может быть бит чётности. В конечном счёте, обязательно должен присутствовать как минимум 1 стоповый бит. Наличие/отсутсвие бита чётности, кол-во стоповых битов и кол-во битов данных заранее известно. Единственной инкогнитой является скорость.



Если вышеизложенные уточнения действительны, то есть 2 пути решения: софтовый и хардовый.



Софтовый характерен для устройств, в которых вообще нет UART и её приходится эмулировать кодом микроконтроллера. Поиск в гугле по ключевому слову autobaud или ABR выдаёт кучу наработок в этом плане. Сам когда-то делал autobaud для uc Motorola HC08, который прекрасно определял одну из 2х возможных скоростей (600 и 1200, если правильно помню) и делал это по первому (любому!) полученному байту. Фрейм был таким:

Код (Text):

1. start x x x x x x x x odd stop

Контроллер читал данные со скоростью в 16 раз превышающую максимальную (1200 x 16), как рекомендуют во всех доках по RS232 и сохранял биты данных в буфер как если бы скорость была 1200. Потом проверял чётность и stop bit. В случае ошибки "растягивал" данные и продолжал читать уже со скоростью 600.



Без использования бита чётности, конечно, алгоритму понадобится хотя бы ещё один байт для полной уверенности.



В самих UART'ах же присутствует более простое решение с использованием банального PLL и большого буфера для временного хранения входящих данных. UART начинает читать биты с максимальной скоростью и постоянно корректирует фазу при любом фронте / спаде. В большинстве случаев получается точно определить скорость ещё на первом байте, если этот байт не 0x00 или 0xFF. В даташитах Texas Instruments есть более точное описание, но я что-то пока не могу найти нужную доку...



Зачем это всё нужно? Я знаю как минимум одно устройство, которое передаёт данные по RS232 с переменной скоростью. Скорость зависит от кол-ва ошибок при передаче/принятии данных (из-за шума в кабеле, а кабель длинный). В документации этого модема ясно сказано, что устройство не совместимо со старыми моделями UART, которые не поддерживают ABR.

 

Quantum



скорость может быть либо 110, либо 300, ..., либо 19200,



В соответствии со стандартом на RS-232 - да. Но на практике иногда встречаются внешние устройства (например, телефонная станция КВАНТ с цифровым интерфейсом СТЫК-2), которые ведут обмен на скоростях типа 100 и 150 бод.



Единственной инкогнитой является скорость.



Вторая "инкогнита" - содержимое блока данных. Третья "инкогнита" - количество битов в этом блоке. Ну и так далее. Кстати, стартовый бит - это просто переход с высокого уровня сигнала на низкий и в чистом виде не отличим от группы нулей.



Да, я теперь верю, что современные UART-ы способны это делать, но, например: 1) с обеих сторон должны стоять одинаковые микрухи; 2) они должны работать в специальном режиме "распознавания скорости", который опять-таки зажигается не сам, а извне, программно. В этом режиме они гонят друг другу определеный формат кадра. Вот меня и интересовало в этом топике, как зажечь этот режим в современных микрухах, если это вообще возможно.



А про 3 машины, порты которых сами подбирают скорость, очень извиняюсь, но НЕ ВЕРЮ. Скорее всего, дело просто в том, что BIOS по умолчанию инитит все порты в одинаковый режим (b=2400, d=8, s=1, p=none) и никакого дополнительного согласования просто не нужно. Совет Shtasik-у остается прежним: скорость - инитить самому обязательно!



Да, Quantum, все-таки спасибо за инфу, и заранее спасибо, если все-таки появится линк на описание этой самой микрухи от Техасских Приборов.

 

Да, и вдогонку к самому себе. Вот пример реализации autobaud-a: http://www.radioradar.net/docs/microchip_shim.php . Скорость абы какого сигнала распознана быть не может, калибровочный символ (8 нулей) все-таки нужен!

 

Придурок ( это я сам про себя ), конечно же 8 единиц, а не нулей!

 

чо то я не фкурил а в чём вопрос то ??? если прога работала в досе, причём говоришь нормально работала, ну и открой ты для ntvdm свободный доступ к портам железяки в карте iopm, запусти giveio и пользуй, тока изначально совет рубануть доступ к драйверу этого самого порта, забань его и дело с концом, если не уверен что еще какой софт туда через драйвер не полезет, чтоб не мешался.

 

drmad

Первый способ ABR (старый, софтовый) с такими устройствами работать не будет, хотя можно адаптировать алгоритм под эти конкретные скорости. В общем, этот способ не универсален, в отличии от фазового синхронизатора.

Изначально было сказано, что автоматом можно определить только скорость.

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

UART всё время готова "налету" сменить скорость. Для этого и предназначен PLL. Чтобы минимизировать возможность ошибки, желательно чтобы устройство, по чьей инициативе снизилась или увеличилась скорость, послало легко распознаваемый патрон вроде 101010..., но это не обязательно.

Модем работал, хотя я всегда инициализировал порт на максимальную скорость. Parity checking был включен, кажется, что тоже логично, т.к. облегчает работу ABR. Подключить осциллограф к порту не пришло в голову, т.к. не было повода не доверять докам.

Ну, это же ламерская реализация. Мой алгоритм для 2х скоростей (выше описан), но с parity и то более продвинутый.

Кажется, оно, хотя детального описания синхронизатора я тут уже не вижу.

 

drmad

Quantum

Ну фига себе вы тут понаписали! :-0



CARDINAL

- если честно то из этой фразы мне понятны лишь отдельные слова =(( если не сложно, немного поподробнее.

 

Shtasik

Первосвященник предлагает продолжать использовать досовскую прогу на XP/2000, т.е. - NT. Досовские проги в NT запускаются через эмулятор доса, который называется ntvdm. Досовские проги через эмулятор не всегда работают.



Потом он ещё, как вариант, предлагает использовать giveio. Это такой хакерский драйвер, который открывает доступ к портам для пользовательского кода. Тоже не даёт 100% гарантии, что будет работать. Этот giveio и подобные игрушки работают где-то в половине случаев и склонны глючить, не говоря ещё что нарушают безопасность NT.

 

безопасность NT они при грамотном использовании не нарушают, если в данном контексте речь идёт только о com портах, то проблемы могут быть только в случае совместного использования данного девайса без синхронизации между пользователями последнего. Что бы этого не было, можно пойти на радикальные меры, просто забанить serial.sys, чтоб не давать ему ирпы, повесить над ним фильтр. А если по уму делать, то писать тебе софтину под винду и не мучить задницу, потому как кроме сего прочего, как я понял, еще и прерывание от него обрабатывать надо. Пиши драйвер кароче свой, ничо сложнова там нету )))

 

Привет всем еще раз! К сожалению со старым логином Shtasik что-то случилось, поэтому пишу под новым.



Значит так, написал драйвер результат все тот же - возвращает постоянно 0xff.

Попытался использовать giveio, результат тот же!

Взял прогу досовскую (которая нормальные результаты выдает) посмотрел дизассемблером, вроде ничего особенного!

Написал ассемблерную вставку (использовав giveio) код чтения один в один с досовским, результаты разные =((

Пожайлуста, хелп, сроки горят!

 

сроки ужо сгорели ? ))

 

Не думал что из-за com-порта можно столько написать В своё время сам с ним натрахался
ИМХО, писать дрова - последнее дело, если конечно не требуется использовать линии com-порта не стандартным образом (как было в моём случае). Дрова - дело серьёзное придётся перекомпилить для новой версии ОС, не забывать о многопроцессорности и многоядерности. Так что лучше всего написать софт в UserMode с потоками событиями и отложенным чтением.
И насчёт постоянных FF в регистре... может просто порт сгорел ?
Ещё был случай у меня с мамкой от MSI, тамшлейф выноса com'а с матери наружу был не правильный.

 

CARDINAL
Maveric

Ух...ну блин я и намучался с этим делом =))
благо написание драйвера оказалось не столь сложным дело. Теперь у меня все ок для WIN200/XP! Спасибо всем вам!

НО теперь на надо для WinCE (тут я полный профан), подскажите плиз, хоть куда за помощью обращаться =(