Чем отличались КА1515ХМ1-031 и 1515ХМ2-001?

[Alex_K]

Итак, обновленный тест показал следующие результаты:

Итак, начнем критический анализ:

1) Работа таймера в режиме счета/останова отличается лишь тем, что в режиме счета по фронту PCLK декрементируется счетчик таймера, а в режиме останова сохраняет свое значение.

Интересный момент. Насколько я знаю, в режиме останова содержимое буферного регистра переписывается в счетчик. Да, в режиме СТОП счетчик не декрементируется, но и не сохраняет то значение, при котором его остановили. Узнать, что находится в счетчике в данный момент невозможно, он не выводится ни на какие регистры.

2) Значение из счетчика в регистр текущего значения переписывается по отрицательному фронту PCLK, таким образом, в режиме счета невозможно получить на выходе число, загруженное в буферный регистр, т.к. по переднему фронту PCLK оно декрементируется, а по заднему уже уменьшенное на единицу запишется в регистр текущего значения.

Такое возможно наверное получить, если в режиме ПУСК динамически менять содержимое буферного регистра, и с довольно большой скорость прочитывать содержимое регистра текущего значения. Но нужны доказательства на экран.

3) Флаг нуля счетчика формируется по отрицательному фронту PCLK, если в РЕГИСТРЕ ТЕКУЩЕГО ЗНАЧЕНИЯ, а не в счетчике содержится ноль, не зависимо от режима пуск/стоп. Таким образом можно получить счет от нуля до нуля без переполнения, т.к. пройдя счетчик мы сразу получим значение 0xFFF.

Флаг нуля формируется в режиме СТОП? Интересно, интересно. Да, если остановили таймер, а в регистре текущего значения был ноль до этого, то флаг нуля стоит, но если прочесть регистр текущего значения, то флаг сбросится и уже любое значение, загружаемое в буфер через некоторое время появляется в регистре текущего значения (надо проверить), но флага нуля уже в режиме СТОП установлено не будет. Если в буфер загрузить ноль, то де-факто будет, как-будто это загружено 010000(0x1000), об этом может где-то и писалось.

4) Если в регистре текущего значения в режиме останова находится число 0, то он будет блокироваться вновь и вновь по фронту PCLK, независимо от содержимого счетчика. Таким образом, чтение регистра текущего значения совпавшее с очередным фронтом PCLK, мешает разблокировке регистра текущего значения, с вероятностью тем большей, чем меньше период PCLK.

Т.е. остановили таймер, прочитываем регистр текущего значения бесконечное число раз, а регистре управления бит нуля так и будет стоять? Чего-то не верится.

5) Содержимое буферного регистра записывается в счетчик по фронту PCLK в следующих случаях:
а) Переход флага нуля 0->1
б) Ноль в 0-м бите регистра состояния
в) Новый фронт по линии внешнего события

Ну вот здесь вроде совпали с документацией.

Из-за того, что буферный регистр записывается в счетчик только по фронту PCLK, кратковременная установка нуля в 0-м бите регистра состояния, попавшая между двумя фронтами PCLK (а это до 96 тактов ПП), не окажет воздействия.

Т.е. такой код не окажет воздействия на таймер, особенно чем ближе к 16 мкс?

    MOV    #1,R0
    MOV    #177710,R1
    BIC    R0,@R1
    BIS    R0,@R1

[Titus]

Интересный момент. Насколько я знаю, в режиме останова содержимое буферного регистра переписывается в счетчик. Да, в режиме СТОП счетчик не декрементируется, но и не сохраняет то значение, при котором его остановили. Узнать, что находится в счетчике в данный момент невозможно, он не выводится ни на какие регистры.

Сохраняет свое значение, каждый такт загружаемое по PCLK из буферного регистра, так будет точнее сказать.

Такое возможно наверное получить, если в режиме ПУСК динамически менять содержимое буферного регистра, и с довольно большой скорость прочитывать содержимое регистра текущего значения. Но нужны доказательства на экран.

Зачем такие сложности? Достаточно рассмотреть переходный дамп, который всегда гласит 0->98, при том, что в буферном регистре 99.

Флаг нуля формируется в режиме СТОП? Интересно, интересно.

Да, формируется, см. пункт 3 и 4.

Т.е. остановили таймер, прочитываем регистр текущего значения бесконечное число раз, а регистре управления бит нуля так и будет стоять? Чего-то не верится.

Бесконечное число раз, если только цикл чтения точно совпал по фазе с периодом таймера, а так же попал изначально в нужный такт. О чем написано постом выше в вопросе о глюках. А так - читайте пункт 3 и смотрите тесты вероятностей, которые статистически так же подтверждают эту теорию.

Т.е. такой код не окажет воздействия на таймер, особенно чем ближе к 16 мкс?

    MOV    #1,R0
    MOV    #177710,R1
    BIC    R0,@R1
    BIS    R0,@R1

Это очень медленный код.
Лучше так:

    MOV    #1,R0
    MOV    #177710,R1
    MOV   R0,(R1)
    CLR   (R1)

Да, я это проверял, хотя в тест пока что это не вошло.

[Alex_K]

Сохраняет свое значение, каждый такт загружаемое по PCLK из буферного регистра, так будет точнее сказать.

Но при этом Вы сами пишете, что:

5) Содержимое буферного регистра записывается в счетчик по фронту PCLK в следующих случаях:
б) Ноль в 0-м бите регистра состояния

Как-то не сходится.

Да, формируется, см. пункт 3 и 4.

Ну не смог я увидеть в режиме СТОП и при загруженном в буфер нуле установленного бита нуля в регистре состояния.

Бесконечное число раз, если только цикл чтения точно совпал по фазе с периодом таймера, а так же попал изначально в нужный такт. О чем написано постом выше в вопросе о глюках. А так - читайте пункт 3 и смотрите тесты вероятностей, которые статистически так же подтверждают эту теорию.

Ну а теперь результаты моих тестов на УКНЦ литеры 7 с 1515ХМ2-001:

Скрытый текст

[свернуть]

Запускал как с дисковода, так и с IDE-Flash, результат в принципе один и тот же. Уже и прогрелась, и включал/выключал, но неснятия бита готовности не наблюдалось. Или тоже надо как минимум пятьсот раз запускать?

---------- Post added at 12:39 ---------- Previous post was at 12:36 ----------

Это очень медленный код.
Лучше так:

    MOV    #1,R0
    MOV    #177710,R1
    MOVB    R0,(R1)
    CLRB    (R1)

Этот код ничем не отличается от моего, т.к. байтовые операции MOVB и CLRB также делают предварительное фиктивное чтение. Лучше так:

    MOV    #1,R0
    MOV    #177710,R1
    MOV     R0,(R1)
    CLR     (R1)

[Titus]

Но при этом Вы сами пишете, что:
Как-то не сходится.

Все сходится. Если бы счетчик не хранил текущее значение (а оно все время обновляется по тому же PCLK из буферного регистра), а декрементировал его, то мы бы не получили на выходе неизменнное значение буферного регистра.

Ну не смог я увидеть в режиме СТОП и при загруженном в буфер нуле установленного бита нуля в регистре состояния.

Такую комбинацию я еще не проверял.

Ну а теперь результаты моих тестов на УКНЦ литеры 7 с 1515ХМ2-001:
Запускал как с дисковода, так и с IDE-Flash, результат в принципе один и тот же. Уже и прогрелась, и включал/выключал, но неснятия бита готовности не наблюдалось. Или тоже надо как минимум пятьсот раз запускать?

Нет, не надо 500. На моей УКНЦ это стабильно и четко каждый запуск.
Попробуйте с 1-031.

Этот код ничем не отличается от моего, т.к. байтовые операции MOVB и CLRB также делают предварительное фиктивное чтение. Лучше так:

Да, изначально написал байтовую запись, но потом исправил)

---------- Post added at 12:52 ---------- Previous post was at 12:50 ----------

Видимо, вот и нашли отличие 2-001 от 1-031)

[Alex_K]

Итак, обновленный тест показал следующие результаты:
1) Работа таймера в режиме счета/останова отличается лишь тем, что в режиме счета по фронту PCLK декрементируется счетчик таймера, а в режиме останова сохраняет свое значение.
5) Содержимое буферного регистра записывается в счетчик по фронту PCLK в следующих случаях:
б) Ноль в 0-м бите регистра состояния

Интересный момент. Насколько я знаю, в режиме останова содержимое буферного регистра переписывается в счетчик. Да, в режиме СТОП счетчик не декрементируется, но и не сохраняет то значение, при котором его остановили. Узнать, что находится в счетчике в данный момент невозможно, он не выводится ни на какие регистры.

Сохраняет свое значение, каждый такт загружаемое по PCLK из буферного регистра, так будет точнее сказать.

Все сходится. Если бы счетчик не хранил текущее значение (а оно все время обновляется по тому же PCLK из буферного регистра), а декрементировал его, то мы бы не получили на выходе неизменнное значение буферного регистра.

Так все-таки на расставить все точки над И:
1. Когда остановили таймер, то содержимое буферного регистра копируется в счетчик.
2. Когда остановили таймер, то в счетчике сохраняется содержимое на момент останова.

Что же все-таки верно?

[Titus]

Так все-таки на расставить все точки над И:
1. Когда остановили таймер, то содержимое буферного регистра копируется в счетчик.
2. Когда остановили таймер, то в счетчике сохраняется содержимое на момент останова.

Что же все-таки верно?

1.

[Alex_K]

Нет, не надо 500. На моей УКНЦ это стабильно и четко каждый запуск.
Попробуйте с 1-031.
---------- Post added at 12:52 ---------- Previous post was at 12:50 ----------
Видимо, вот и нашли отличие 2-001 от 1-031)

Рано еще говорить, пока не запускал, подождите чуток.

---------- Post added at 13:40 ---------- Previous post was at 13:25 ----------

Ну вот, загрузился с УКНЦ литеры 7 с 1515ХМ1-031. Сначала с дисковода, потом с IDE-Flash, потом снова с дисковода. Все загрузки происходили на холодную, т.е. после нажатия СБРОСА.

Скрытый текст

[свернуть]

[Titus]

Ну, а что я говорил)

---------- Post added at 13:52 ---------- Previous post was at 13:47 ----------

Надо бы подписать, какие параметры с чего грузились.

[Alex_K]

Надо бы подписать, какие параметры с чего грузились.

А с чего грузились и так видно по промптеру приглашения RT-11.
Поперезагружал еще, выключал/включал питание, главным образом два последних скрина, последний чаще всего.

[Titus]

А с чего грузились и так видно по промптеру приглашения RT-11.
Поперезагружал еще, выключал/включал питание, главным образом два последних скрина, последний чаще всего.

Понятно. Это значит не зависит от привода.
Это 16тактовая УКНЦ или 20?

---------- Post added at 13:58 ---------- Previous post was at 13:56 ----------

Хотя и так понятно, что 20.