Тогда логика подсказывает только одно - выкинуть эту проверку)Сообщение от Vslav
- - - Добавлено - - -
Все понятно, что меня смутило)
У тебя под F1 значится не F1 процессора, а F1 УКНЦ, которая в 2 раз выше.
Итак, по твоему графику подтверждается, что цикл чтения с опережающим RPLY действительно занимает 6 тактов, как на моем графике.
Остается вопрос к эксперту @Alex_K, что он об этом скажет.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Абсолютно ничего не известно.
Вроде, в этих вопросах, я не эксперт. Могу только сказать, что циклам обмена RPLY должно подаваться только после DIN и DOUT. Но предварительная выдача RPLY имеет смысл только для чтения, т.е. если в фазе выдачи адреса не был активен WTBT. Но тут есть тонкий момент - если устройство по фронту SYNC начнёт выдавать данные и RPLY, то на шине AD на некоторое время образуется каша из адреса и данных. Главное, чтобы устройство правильно защёлкнуло адрес (всякие переходные процессы). Процессор уже правильно защёлкнет данные, т.к. он снимет адрес и переключит линии AD в режим входов.
Я думаю, что проблемы в этом вообще нет, т.к. при опережающем RPLY устройство должно выдавать данные по DIN только на следующем такте, поэтому никакого конфликта не будет.
В общем, запишем эту особенность быстрого чтения в список найденных недокументированных возможностей ВМ2. Впрочем, применить это знание на УКНЦ мы все равно не сможем.
Ну главное, чтобы успело выдать, и с учётом всяких задержек, процессор не прочёл нули.
Мы может и не сможем. А ведь есть разработчики всяких контроллеров для УКНЦ, вот они могут и попробовать.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
