Быстродействующая софтовая обработка протокола клавы PS/2 на процессоре ВМ2.

Уважаемые господа, предлагаю по возможности привести примеры софтовой обработки протокола PS/2 клавы в составе М-ЭВМ на DEC - процессоре. Для конкретизации - предположим, имеется регистр 177632, в котором бит со значением 020000 - тактовый сигнал с клавы, бит
со значением 010000 - данные с клавы. Соответственно, при отсуствии сигнала в указанных битах содержится программное значение "0", а при приходе сигнала - "1". Другие биты регистра заняты др. задачами. Частота данных ( тактового сигнала с клавы ) - порядка 40 кгц, быстродействие процессора - МС1201.02. Можно использовать все регисты и всё ОЗУ ( десятки килобайт ). Привязка к какой-либо ОС - ненужна. Можно еще и прерывание "100" вектора задействовать.
http://storage9.static.itmages.ru/i/...72815f62e4.jpg

Если верить википедиям, что КР1801ВМ1 выполнял 500к операций регистр-регистр, то обработку одного бита нужно осуществить прочитав/записав не более 10-12 слов из памяти, включая операции чтения кода программы. При этом чтобы не потерять битики нужно отслеживать оба состояния тактового сигнала. Возможное решение: повесить тактовый сигнал на 15 или 7 бит и проверять командой TST/TSTB, после чего делать условный переход, ну а данные повесить на 0 или 7 бит, считывать командой MOVB, после чего командой ROR или ROL сдвигать в старшую часть регистра накопителя. Если 177632 предварительно положить в регистр, то на каждый шаг потребуется прочитать два слова программы и одно слово/байт из регистра, то есть в 10-12 слов мы укладываемся. Единственный сложный момент заключается в том, что пока мы входим в прерывание, стартовый бит скорее всего уже пролетит и времени на сохранение регистров наверно уже не останется. Тут возможен вариант, ничего не сохраняя, просто читать регистр() и складывать в стек, чтобы по времени полностью перекрыть передачу байта, ну а потом, сохранив состояние программы, вытаскивать и разбираться где какой бит. Если какие-то обработчики запрещают прерывания, то чтобы байты не пролетали мимо, есть вариант удерживать тактовый сигнал в низком уровне, как будто мы собираемся что-то начать передавать, а в тот момент когда мы готовы принять байт отпускать его на некоторое время и следить не начнёт ли клавиатура передачу, но делать это нужно будет достаточно часто, чтобы у клавиатуры буфер не переполнился.

add: посмотрел не про тот процессор, учитывая что ВМ2 раза в два шустрее, то задача несколько упрощается.

А почему программно, а не аппаратно?
Контроллер клавиатуры Интел 8042 и его клоны, наверное, дают в подарок на радиорынке. Работает хорошо и легко вешается на МПИ.
К тому же сразу будет контроллер PS/2 мыши. Протокол реализует двунаправленный. Можно лампочками поморгать.
Если аппаратно самому, то вроде должен заработать трехрублевый КР580ВВ51 в асинхронном режиме (8бит данных+четнечет+1 стоп) с внешним клоком прям с PS/2 разъема (тока клок инвертировать надо).
И на МПИ сядет. И обвязки почти не надо (кроме инвертора и пары резюков). Ног не 40, а 28 всего-то.
Другие подходящие контроллеры асинхронных последовательных портов подобрать не удалось, потому что надо, чтоб умел работать с внешним клоком x1, а они все x16 хотят...

О существовании 8042 я в курсе не первый десяток лет.
Дело в некотрой недоставаемости годной i8042 / W83C42 в Москве по вменяемым ценам в к-ве от 5 шт. одинаковых.
В Митино единственный продавец этих БИС не в курсе о существовании цен ниже 500 руб, да и то они у него - в общем, из мусорки...

А какое время входа в обработчик прерывания на реально работающей вм2? Если по клоку с PS/2 вызывался бы наш обработчик, где бы мы ногой подергали и на осциллографе увидели, как с запасом по времени. А если до следующего клока время есть - то мы очередной бит задвинем и выйдем из прерывания. В прерывание нас занесет 1+8+1+1 раз.
11 состояний у автомата 0(старт)-1-2-3-4-5-6-7-8-9(четнечет)-10(стоп). Нужна переменная где хранится номер состояния.
И разобраться с запретом-разрешением прерываний внутри нашего обработчика. Прерываний на ножках процессора вроде несколько, а программного управления контроллером нету.
Если с прерываниями гибкости нету, то по-первому клоку нас занесет в наш обработчик где мы программным опросом отследим изменения клока (10раз) и каждый раз будем делать действие, соответствующее номеру клока в протоколе - то ли бит с шины данных считывать и сдвигать рез-тат, то ли паритет проверять или сохранять результат. При программном опросе с условным переходом нужно не зависнуть...

Но лучше сначала посмотреть на осциллографе и оценить времянку.

svinka, осциллограф тут особо не нужен, за 1 бит (при скорости 40 кГц) процессор(10 МГц) успеет выполнить примерно 25 операций выборки/чтения/записи. 2 операции уйдёт на сохранение счётчика команд и флагов, в конце одна уйдёт на выборку команды возврата и 2 на восстановление счётчика и флагов, итого получается 5. Еще 5 операций нужно зарезервировать на завершение выполнения команды основной программы, потому что возможна команда, требующая 3 операции выборки, 2 чтения и 1 запись. В итоге остаётся 15 операций на полезную работу. Минимум 1 операция это команда перехода на обработку нужного бита, 4 операции понадобятся на правку этой команды, остаётся 10 операций. Всё что мы в данном случае успеем, это прочитать регистр с очередным битом и положить его в память, а собирать полученный байт придётся в конце. Для основной программы мы выигрываем порядка 10 операций на каждый бит, которые потом потеряем на сдвиге байта, чтении бита из памяти, наложении маски и добавлении к байту. В общем, одно прерывание, собирающее полученный байт сразу, ничуть не хуже, чем прерывание на каждый бит.

А Я НАШЕЛ ИНФУ ЧТО СКОРОСТЬ ТАМ ДОЛЖНА БЫТЬ ОТ 10 ДО 16КГЦ

svinka, в первом сообщении автор заявляет 40кгц, зачем ему столько не ясно, возможно в современных компах порт ускорили, в русском инете вообще упоминаются 80 и 300кгц. Задачу сильно может упростить промежуточный контроллер, если за такую идею не закидают помидорами. Даже при сохранении последовательного обмена, можно снизить нагрузку на ВМ2, если принимать от него синхронизацию. То есть контроллер складывает байты в буфер, выставляет запрос прерывания, ВМ2 выдаёт синхроимпульсы и считывает байт, а контроллер запрос прерывания снимает.

Цитата:

---

Сообщение от blackmirror

svinka, в первом сообщении автор заявляет 40кгц, зачем ему столько не ясно, возможно в современных компах порт ускорили, в русском инете вообще упоминаются 80 и 300кгц. ...

---

Вот это да !
Я то смотрю - какие там 30 кгц ! Там при самом скоростном дампе состояния порта проходит 3-4 слова и биты меняют значение !
Кстати, намерил тут, что с условием до-и-после ветвления процессор ВМ2 имеет быстродействие в районе ВМ1 ( подозревается 250 т. ком в 1 сек ) - более точно напишу на днях. А лимон натягивает за счет конвеера - когда команды без ветвления в цепочке.
Методика дампа :
002000 : 012700 003000 012701 001000 012702 177632 011220 077102

Цитата:

---

Сообщение от blackmirror

svinka, в первом сообщении автор заявляет 40кгц, зачем ему столько не ясно

---

Автору хватило бы и 10 :)

MM, миллион натягивается в случае, когда нужно прочитать код команды длиной в одно слово, а больше никаких обращений к памяти не требуется. А к примеру команд 063737 xxxxxx yyyyyy, выполнится в 6 раз меньше, потому что занимает три слова, выполняет два чтения и одну запись. Если у вас изменение читаемого слова вызвано изменением синхросигнала, то как раз и получается, что на 1 бит ВМ2 успевает прочитать около 25 слов. А клава у вас точно 40 кГц выдаёт?

Результаты измерений при частоте 1806ВМ2 - 5.5 мгц, 0 тактов ожидания ОЗУ :
1. Тест :
001000 : 012700 177632 012701 000000 012702 000100 012703 002000
001020 : 011023 077202 077107 000000
Время - 35 сек.
Производительность дампа - порядка 120 т. записей в 1 сек. К-во проходов цикла - порядка 4.194.304.
2. Тест :
001000 : 012700 177632 012701 000000 012702 000100 012703 002000
001020 : 011023 077201 077107 000000
Время - приблизительно 17.5 сек, т.е. холостой ход.
Итого производительность команды 011023 - в районе 250 т. при наличии ветвления.

- - - Добавлено - - -

3. Тест :
001000 : 012700 177632 012701 000000 012702 000001 012703 002000
001020 : 011023 011023 011023 011023 011023 011023 011023 011023
001040 : 011023 011023 011023 011023 011023 011023 011023 011023
001060 : 011023 011023 011023 011023 011023 011023 011023 011023
001100 : 011023 011023 011023 011023 011023 011023 011023 011023
001120 : 077201 077146 000000
Результат - 11 сек, т.е. 4.194.304 списываний регистра, быстродействие - 381 т. ком.
*
Как ниже отметили, реальный результат - 190 т. ком/с, т.к. к-во комад - 2097152 = 65536*32

MM, 3й тест записан неправильно, 001120 : 077201 077146 000000 - здесь получается холостой внутренний цикл. Вообще циклы лучше местами поменять и 65536 итераций делать во внутреннем, тогда результаты измерений будут точнее. И еще непонятно почему в первых двух тестах в R2 грузится 64, а в третьем 1, команд 011023 там 32 штуки, так что грузить нужно 2.

Тогда соответственно пересчитать по получившимуся времени. Спасибо за детект еррор.
Соответственно, 32*65536/11 сек= 190 т. ком.
А число 77201 - так, для затычки, т.к. оно исполнится проходом с крайне небольшой задержкой.
*
Довольно скоро опубликую тему с описанием конструктива, где все эти пироги тусуются.

- - - Добавлено - - -

http://storage4.static.itmages.ru/i/...04f445356c.jpg
Где в R4 - адрес массива данных индикатора ( указан вольно ) , 177636 - регистр данных 16-сегментного индикатора, 177632 младший байт - адрес подключения номера индикатора, значение 377 - младший знак, значение 376 - 1-й знак и т.д.
Соответственно, результат - в R0 - данные с PS/2 порта в виде 1 байта.
С адреса 152 идет набор битов в R0.
Если быстродействия не хватит - тогда сначала заготовка данных, потом их анализ.

Предварительные результаты тестирования текста из скриншота выше показывают на достаточность быстродействия ВМ2.
Вот только текст так никто и не смотрел - там по адресу 142 должно быть 001402 - т.к. код с клавы передается в прямом виде, а не инверсном.
Кстати, восьмеричный код клавиши "пробел" - 51 ( Хекс - 29 ).

- - - Добавлено - - -

Время между передачами байтов одного кода клавиши - более 300 мкс .

Если кто добренький и грамотный - посоветуйте, как сделать обработку котов - через перевод в ASCII или только по номеру кнопки БК ? :v2_dizzy_keyboard:

Цитата:

---

Сообщение от MM

Если кто добренький и грамотный - посоветуйте, как сделать обработку кодов - через перевод в ASCII или только по номеру кнопки БК ? :v2_dizzy_keyboard:

---

В каком виде выдавать результат зависит от того куда это будет включаться:
1) если в новодел вместо ВП1-014 то естественно в ASCII(?) - правильнее в эквивалент того что выдаёт 014 :)
2) если для замены БК-шной клавы то в коды для замыкания контактов клавиатурных разъёмов на плате БК, такой контроллер уже есть на АТМеге...