С момента выставления сигнала чтения клавиатуры /RDFE до момента получения данных с клавиатуры проходит 2 такта процессора Z80. За время этих двух тактов Атмега должна переключится на программу обработки прерываний, прочитать адресную линию Z80, по этим данным из таблицы (заранее приготовленной) прочитать данные нажатых клавиш и выставить эти данные на шину данных Z80.
Мы очень много хотим от Атмеги по быстродействию. Поэтому, либо разгонять Атмегу, либо останавливать процессор Z80, пока Атмега всё это переварит...
P.S. (даже меньше двух тактов, потому что ещё тратится время на формирование сигнала /RDFE тормозной дискретной логикой)
Последний раз редактировалось krotan; 15.05.2020 в 14:37.
А зачем это? Механическая клавиатура, простите, тоже читает состояние шины Z80?
Мне видится это так. МК выполняет 2 задачи: 1) скан клавиатуры и сохранение в буфер кода нажатой клавиши; 2) и при поступлении прерывания по /RDFE, формирование на своих портах эквивалента сигнала нажатой клавиши.
Частота сигнала /RDFE 400 Гц. Это не очень высокая частота прерываний. Другое дело, что в паузах надо обрабатывать сигнал с клавиатуры. А вот тут я слабо пока владею информацией, но в данной схеме не совсем корректно реализован опрос клавиатуры. Сигнал DAT, на мой взгляд, надо было тоже вешать на прерывание и накапливать код в буфер. Надо бы с кодом разобраться, но как я уже говорил, я ассемблер практически не знаю.
Запросы на прерывание при чтении порта клавиатуры нельзя пропускать ни в коем случае,
тем более что на обработку такого события отводится очень мало времени.
Если одновременно обрабатывать по прерыванию еще и опрос PS/2 клавиатуры,
то неизбежно возникнет конфликт и времени на отработку прерывания от Z80 просто не хватит.
А программный опрос PS/2 клавиатуры хорошо отработан и не вызывает никаких проблем,
даже если время от времени прерывается запросами от Z80, тем более что они идут с такой низкой частотой.
PS. Кстати можно на Спектруме написать такой короткий цикл чтения матрицы клавиатуры,
что контроллер во время пауз не будет успевать отрабатывать PS/2 клавиатуру.
Последний раз редактировалось caro; 15.05.2020 в 15:46.
Пока не пойму в чем тут может быть проблема?
В определении какое прерывание будет в приоритете: PS/2 или /RFE?
Конфликта прерываний тем более не будет, если приоритетным поставить обработку клавиатуры PS/2. Прерывания по архитектуре МК не могут выполнятся одновременно. Я тут полистал информацию и поправлю сам себя же. Это CLK от клавиатуры надо посадить на прерывание, а по нему считывать и накапливать бит из DAT. Так правильнее.
Во всех устройствах клавиатура - это самый медленный источник сигнала. При обработке МК сигнала от кнопки напрямую, задержки на анти дребезг могут составлять до 100 мс! А вы боитесь не успеть клавишу опросить.
МК в шину ZX должен выдавать код последней нажатой клавиши или 0, если клавиша отпущена. То есть этот код просто отдается на шину ZX из буфера по прерыванию /RDFE.
Да пусть будет так, но, повторюсь, кто сказал, что за паузу между этими циклами МК должен раз за разом успевать вычитывать код из клавиатуры PS/2???PS. Кстати можно на Спектруме написать такой короткий цикл чтения матрицы клавиатуры,
что контроллер во время пауз не будет успевать отрабатывать PS/2 клавиатуру.
Я или реально не понимаю проблему, или кто-то изначально усложнил задачу и пытается ее оптимизировать на скорость, а не на алгоритм работы
PS. Мне нужны данные о тактовой частоте клавиатуры PS/2, которая она выдает на вывод CLK. Надо обмозговать и попробовать на свой взгляд переписать этот обработчик. Как я его вижу. Правда я не программист, но попытаться стоит.
Ты ищешь проблему там, где её вообще нет. Контроллер прекрасно успевает работать с PS/2 клавиатурой без каких-либо прерываний, по опросу. А вот с портом Спека не успевает, поэтому на нём и прерывание.
Можно конечно посадить на прерывания то и другое, но тогда не будет хватать ног для данных, т.к. прерывания в МК могут поступать только с некоторых фиксированных пинов и нарушают возможность чтения байта с этого порта.
Последний раз редактировалось krotan; 15.05.2020 в 16:54.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Объясните мне пожалуйста, почему тогда при тактовой частоте до 16 МГц включительно клавиатура и микроконтроллер общаются адекватно, а при бОльшей частоте они уже друг друга не видят?
Это не мой хлеб, но мне интересно это занятие.Пытайся, может станешь программистом.
В общем провел я эксперимент, как и планировал. Закатал ATMega168PA на плату и поставил кварц 25 МГц. Биты конфигурации выставил на внешнее тактирование и разрешил выход тактового сигнала на порт CLKO (РВ0). После подачи питания частотомер показал на этом выводе частоту в 25 МГц. Причем стабильную частоту, без скачков и провалов. Это стало доказательством, что МК дружит с кварцем на этой частоте. Проши прошивку KBD13_M168P_nw_MODIFIEDv5_5_25MHz.hex.
Результат отрицательный. Клавиатура не дружит с МК, Снизил тактовую до 8 МГц, клавиатура и МК заработали на этой частоте. Воспользовался случаем и проверил с какой частотой идет тактирование порта CLK клавиатуры. Всего 137 Гц. Что-то маловато. По вики там частота 10-16 кГц должна быть.
В общем делаю выводы из своего эксперимента. Прошивка не работает, где-то в ней ошибка.
К выше сказанному добавлю еще один глупый вопрос. А почему контроллер должен срабатывать по спадающему фронту /RDFE? Z80 в этот же момент будет считывать код нажатой клавиши или код только защелкнется в буфере и считается на следующем такте?
Вот именно, что читает. А конкретно, читает 8 старших бит шины адреса, потому что они составляют строки на матрице клавиатуры, 5 бит данных - это столбцы. На пересечении адресных бит и бит данных расположены клавиши. В зависимости от того, какой выставлен старший байт порта 0xFE процессором, клавиатура должна выдать на шину данных тот или иной код. МК делает тоже самое. Только если на механической клавиатуре это реализовано развязывающими диодами, то в МК это приходится обрабатывать программно.
С уважением, Александр
Gesha86PK (22.02.2022)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)