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

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

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

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

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

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

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

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

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

Так и есть.

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

Сообщение отредактировал Dimmy - Jul 4 2007, 18:41

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

Эту статью я видел. Ну и посмотрите на рисунок 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.
В принципе так, как я описывал выше.

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

Совершенно с вами согласен!!! :-) И я о том-же. Рисунок 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

Сообщение отредактировал Dimmy - Jul 4 2007, 21:52

Для начала абсолютно непонятно, откуда растут ноги у конфликта.
1. У всех виданных мной IBM/PC железяк PS/2 порты заводятся в контроллер совершенно независимо
и физически не могут влиять друг на друга.
2. Прерывания от контролера хоста для PS/2 портов тоже раздельные.
3. У кого-нибудь мышка хоть когда-нибудь _реальную_ клавиатуру сбивала

Посему, если 'конфликт' имеет место быть, то варианты:
1. Что-то не то железяка по диаграмме выдает и вышибает мозги контроллеру хоста и он как-то замешивается с мышью.
2. Просто драйвер обслуживающий девайс написан неправильно и конфликтует с той-же мышью.

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

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

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