[vitko 0]

Есть устройство на AVR - считыватель карточек, включенный в разрыв PS/2-клавиатуры. При считывании карточки клавиатура блокируется и устройство от имени клавиатуры передает код карточки в виде скан-кодов. Проблема в том, что если в это время дергать PS/2-мышкой, передача идет со сбоями.

Может кто-то что-то посоветовать?

[=GM= 0]

Проблема в том, что если в это время дергать PS/2-мышкой, передача идет со сбоями.

Когда передаёте от имени клавы, какие клоки используете?

[GDI 0]

Мышка же к другому порту подключается или я не в теме? Надо искать почему это происходит, может по питанию сбой или на сигнальные линии наводка, может банально пс2 контроллер на материнке загнулся - на другой машине не пробовали? Может еще и мышку блокировать вместе с клавиатурой?

[vitko 0]

С питанием и наводками все ОК.

PS/2-мышка использует ту же линию клока, что и PS/2-клавиатура, соответственно, если мышкой дергать, она занимает линию клоков, освобождая ее после каждой посылки на несколько миллисекунд. Мое устройство подключено к ПК, параллельно ему через ключи подключена клавиатура - если надо передать код карточки, ее сигнальные линии на время передачи отлючаются.

У реальной клавиатуры комп всегда может переспросить, если был сбой, а мой девайс просто шлет данные - вот и проблема, как узнать, дошли они или нет. Ведь ПК вроде бы АСК по приему байта не выдает, или я не прав ?

[rezident 0]

Насколько я помню в протоколе PS/2 интерфейса не предусмотрено квитирования передачи, т.е. подтверждение правильного приема не передается. Для устройств ввода достаточно чтобы его данные передавались без ошибок, а воспринял или нет PC эти данные дело уже десятое. Нажать еще раз кнопку или подвигать мышкой пользователь всегда может, визуально определив, что на его действие нет реакции PC.

[AndryG 0]

rezident, совершенно верно - квитирования нет.

 

Если вы говорите, что мышка занимает CLK (я работал только с одной клавой), то "дружное" прижимание CLK на землю клавиатура должна воспринять как запрос на передачу ей команды... что-то не вяжется.

 

Если есть ... поделитесь ссылками на описание работы мышонка и клавы вместе -- самому интересно, как они расходятся по шине (я думал что это два независимых порта)

[zltigo 1]

Если вы говорите, что мышка занимает CLK (я работал только с одной клавой), то "дружное" прижимание CLK на землю клавиатура должна воспринять как запрос на передачу ей команды... что-то не вяжется.

У мышки и клавиатуры разные CLK

(я думал что это два независимых порта)

Так и есть.

[Dimmy 0]

не знаю, как клавиатура на мышь, но мышь на порт клавиатуры влияет и именно по CLK. Как то делал устройство, висящее на PS/2 на MSP430. Поначалу решил проблему установив мышь на ЮСБ. Потом решил это программно. Дело было 2 года назад - плохо помню. Но по-моему просто при высоком CLK со стороны клавы опрашивал вход CLK (уже в процессе передачи). Если он 0 - то начинал передачу сначала.

 

Кстати, насчет квитирования. Цитирую Гука, проверял - работает:

"Клавиатура может начать передачу данных в произвольный момент, когда интерфейс находится в покое. Клавиатура формирует старто­вый бит (низкий уровень) на линии KB-Data и первый импульс KB-Clock, что яв­ляется сигналом контроллеру(имеется ввиду контроллер на стороне матери) о необходимости начала приема. После подъема KB-Clock она выводит 0-й бит данных на линию KB-Data, а затем и следующий им­пульс KB-Clock. Контроллер должен «защелкивать» принятый бит данных по спа­ду KB-Clock. Так передаются все 8 бит данных и бит паритета, дополняющий чис­ло единичных бит до нечетного. После синхроимпульса бита паритета контроллер клавиатуры (имеется ввиду контроллер на стороне матери) должен сформировать импульс KB-Clock, подтверждающий прием байта (Ack). Если весь байт с битом паритета не будет получен контроллером за 2 мс, контроллер прекращает прием данного байта и фиксирует ошибку тайм-аута."

Изменено 4 июля, 2007 пользователем Dimmy

[rezident 0]

Вот в этом сообщении я уже приаттачил страничку с описанием PS/2 и диаграммами. Там на рисунках и в описании указано в чем различие передачи Host-to-Device и Device-to-Host.

P.S. это для Dimmy пожалуй.

[Dimmy 0]

Эту статью я видел. Ну и посмотрите на рисунок 2. то что там называется STOP - у Гука это ACK. В Вашей статье не указано - кто инициатор этого сигнала. Инициатор - хост. Это и есть квитирование. Кстати, в этой статье есть ответ как обрабатывать клок от мыши:

The host may inhibit communication at any time by pulling the Clock line low for at least 100 microseconds. If a transmission is inhibited before the 11th clock pulse, the device must abort the current transmission and prepare to retransmit the current "chunk" of data when host releases Clock.

В принципе так, как я описывал выше.

[rezident 0]

Device-to-Host communication это передача от девайса (мышки или клавы) данных в PC. Host-to-Device Communication это наоборот - от PC к мышке или клаве.

А теперь внимательно прочитайте описание проблемы vitko. И с какой именно стороны эта проблема возникает.

[Dimmy 0]

Совершенно с вами согласен!!! :-) И я о том-же. Рисунок 2 Device-to-host. Но инициатор сигнала STOP (ACK) - ХОСТ!

Впрочем, мы уходим от темы - человек задал вопрос - как побороть конфликт с мышью. Я ответил. Конфликт действительно ЕСТЬ. Не раз натыкался - при активности мышки хост манипулирует клоком клавиатуры подтягивая его к 0. Возможны два варианта, когда это произойдет:

1. Во время передачи данных от девайса к хосту. (он самый маловероятный, т.к. в этот момент хост делает то же самое с клоком мышки, заставляя прекращать передачу от нее). В этом случае необходимо в процессе передачи считывать значение пина CLK когда этот самый клок ДЕВАЙСОМ же и отпущен (выход с открытым коллектором). И если CLK подтянут к нулю - прекращать передачу. Подождем для уверенности 2мс - и снова передадим те-же данные. А то что данные приняты ХОСТОМ - определяем по наличию ACK. Он как-раз 11-й. А в Вашей же статье (to Rezident):

"If a transmission is inhibited before the 11th clock pulse"

Если надо - схему сопряжения которую использовал приаттачу

2. Линия CLK подтягивается к 0 во время простоя девайса. Это более вероятный вариант. По сути в данном случае хост сигнализирует, что в данный момент обрабатывается мышка. Я обрабатывал его в прерывании по пину (вход CLK на девайс). В прерывании отслеживал состояние пина DATA. Если DATA в 1 - то это либо ACK (если до этого мы что-нить передавали), либо запрет на передачу нашим устройством (как раз этот случай мы и рассматривали). Его обрабатывать не надо - просто ничего не передавать. А если в момент когда CLK со стороны хоста подтянут к 0 и DATA в 0 - то это запрос от хоста на передачу в наше устройство. (HOST_RQ_BIT в моем случае)

Вот кусок - он для MSP430:

;-----------------------------------------------------------------------------

; прерывание от Хоста (по CLK)

;-----------------------------------------------------------------------------

P2_INT:

bic.b #0x02,P2IFG

bit.b #DIN_BIT,&P2IN

jc HostAck

bis #HOST_RQ_BIT,Flags

bic #LPM3, 0(SP) ; Decode = Active in Mainloop

reti

HostAck: bis #HOST_ACK_BIT,Flags

bis.b #WDTIE,&IE1 ;разрешим прерывания от WDT

reti

Изменено 4 июля, 2007 пользователем Dimmy

[zltigo 1]

Впрочем, мы уходим от темы - человек задал вопрос - как побороть конфликт с мышью.

Для начала абсолютно непонятно, откуда растут ноги у конфликта.

1. У всех виданных мной IBM/PC железяк PS/2 порты заводятся в контроллер совершенно независимо

и физически не могут влиять друг на друга.

2. Прерывания от контролера хоста для PS/2 портов тоже раздельные.

3. У кого-нибудь мышка хоть когда-нибудь _реальную_ клавиатуру сбивала :)

 

Посему, если 'конфликт' имеет место быть, то варианты:

1. Что-то не то железяка по диаграмме выдает и вышибает мозги контроллеру хоста и он как-то замешивается с мышью.

2. Просто драйвер обслуживающий девайс написан неправильно и конфликтует с той-же мышью.

 

Для направления на путь истинный могу извлечь из архива писанную в 80x годах дамповалку сканкодов, добавить в нее пару строчек активизации (через загруженный дрвайвер мышки) мышинного курсора - ну и попробуйте сбить мышкой сканкоды от реальной клавиатуры :).

[Dimmy 0]

Для направления на путь истинный - см пост выше. Это не конфликт - а запрет хостом на передачу данных вторым устройством. Не знаю, с какой целью это сделано - но проведите простой эксперимент - ткнитесь осцилом на CLK клавы и подвигайте мышью. Сразу все поймете. Клава - штатная. Я и сам поначалу долго парился :07: Зато щас все работает как часы. (устройство, которое разрабатывал - клавиатура управления музыкальным автоматом + управление по ИК)

[zltigo 1]

Это не конфликт - а запрет хостом на передачу данных вторым устройством.

Дошло :) В предыдущем Вашем посте не сразу понял несколько двусмысленную фразу "хост манипулирует". Что недоработано в девайсе vitko теперь стало совершенно очевидным.