Генератор тактовых импульсов "Электроника МК-85"

[Клапауций]

У меня возникла идея, как передать по SPI меньше 8-ми битов.

меня посещала мысль - каким-то образом добивать до 8-ми бит.
аппаратным образом не хотелось, а бит SPIF доступен только для чтения.

ну, ок - тогда можно попробовать так:

Code: Select all

while(!(SPSR & (1<<SPIF))) {/*добиваем до 8-ми бит*/};

в этом случае,сколько бы бит не доставало, корректно дощёлкает до недостающих 8-ми бит.

[Клапауций]

как бы схемотехнически ни была изящна версия контроллера дисплея на только одном AVR, но склоняюсь к мнению, что версия с аппаратным 16-ть бит регистром(будь то на двух 8-мь бит корпусах или в одном 16-бит корпусе) является универсальным решением:
- нет ограничений в 8-ми битности SPI или наличия/отсутсвия интерфейса USI.
- аппаратно: проще и быстрей считывать последние 13-ть или 16-ть бит в порты контроллера по событию SYNC RISING.
- программно: единственное прерывание с очень простым обработчиком.

недостатки:
- на два(если регистр 8-мь бит) или один(если регистр 16-ть бит) корпусов больше.

*если бы я был китайцем, то, наверное, был бы бит палками за разбазаривание народного ресурса, но - нет. мне повезло.

[piotr433]

Мне в руки попал микропроцессор Т36ВМ1-2 с датой выпуска 9109, который передаёт по шине ЖКИ восемь бит данных.

9109.png

Я ещё подумал, что может такая упрощена схема бы заработала:

sch.png

Прерывание INT1 должно срабатывать при обоих фронтах сигнала SYNC (или можно использовать два входы прерываний, один для нарастающего фронта, второй для спадающего).
При спаде сигнала SYNC процессором считывается адрес.
При нарастании считываются данные.

[Клапауций]

спасибо, Piotr.

Мне в руки попал микропроцессор Т36ВМ1-2 с датой выпуска 9109, который передаёт по шине ЖКИ восемь бит данных.

таки, не совсем 8-мь бит.
9-й короткий импульс, как и в версии процессора с 5-ю битами, - присутствует.
при отладке кода подозревал его наличие.
иначе бы не приходилось выключать SPI после получения второго байта и заново не включать по событию SYNC RISING

Code: Select all

ISR(SPI_STC_vect) {
if (mode_byte == 0) {
address = ~SPDR - 0x80;
mode_byte = 1;
}
else                {
data = ~SPDR;
SPCR &= ~(1<<SPE); // выключить SPI
mode_byte = 0;
}
}

ISR(INT1_vect) {
SPCR |=  (1<<SPE); //  включить SPI
if (address <= 0x68 /*0xE8 - 0x80*/) {LCD_MK85[address] = data; print_screen = 1;}
}

Я ещё подумал, что может такая упрощена схема бы заработала:

эта схема будет работать, но немного не так, как нужно.
нужно, что бы пины Q0-Q7 регистра выдавали содержимое регистра в момент изменения логического состояния SYNC и хранили до следующего изменения SYNC.
для этого нужно перевести пин STB регистра в состояние "1", затем в "0" до того как изменится CLK сигналом SHIFT.(пример, конвертации события SYNC RISING в управляющий сигнал для STB в моей схеме - можно посмотреть в приложенной к посту картинко)
предложенная вами схема будет так работать только при изменении SYNC с "1" в "0".
при изменении SYNC с "0" в "1" у нас может остаться ровно один такт времени до изменения SHIFT, что бы успеть считать актуальные на момент изменения SYNC данные, иначе они будут изменены приёмом битов очередной пары байтов.
что сводит на нет желание получить достаточное время для обработки данных контроллером AVR равное времени приёма регистром 16-ти бит или 8-ми бит, в случае использования одного регистра.
в случае использования одного регистра, нужна аналогичная ниже(для двух регистров) схема конвертации изменения SYNC по событию SYNC RISING в управляющий сигнал для STB , но по событию SYNC CHANGE.

[piotr433]

при изменении SYNC с "0" в "1" у нас может остаться ровно один такт времени до изменения SHIFT, что бы успеть считать актуальные на момент изменения SYNC данные, иначе они будут изменены приёмом битов очередной пары байтов.

Очередная пара байтов может появится лишь после ~10 микросекунд (в турбо режиме). Разве это недостаточное время, чтобы успеть считать данные?

Вот здесь, при выполнении команды MODE, происходит самая быстрая передача по шине ЖКИ:

Code: Select all

15BC:	clrb	@#98
15C0:	clrb	@#A0

mode.png

[Клапауций]

Очередная пара байтов может появится лишь после ~10 микросекунд (в турбо режиме). Разве это недостаточное время, чтобы успеть считать данные?

не пара байтов(16-ть бит), а очередной бит может прийти через ~1.5 микросекунды и изменить логические состояния Q0-Q7 - т.к. на пине STB в это время "1".
в то время как пара байтов принимается за ~15 микросекунд - да, этого времени достаточно, что бы всё успеть.

иначе, если всё успевается, то какой смысл в дёргании пином STB? - повесить его на +5V.

лично я горожу огород с внешним регистром, способным принимать данные в реальном времени и хранить их для считывания медленным устройством.

медленным устройством является контроллер AVR с кодом на С++ Arduino.

*судя по картинко - дёргать пин STB регистра вообще не нужно. но почему-то это предположение не подтверждается моей практикой.

[Клапауций]

предложенное мной, схемотехническое решение с 16-ть бит регистром, возможно, избыточно и допускает оптимизации и упрощения.
но, именно такой вариант работоспособен с любым количеством принимаемых бит и паузами между передаваемыми парами байтов.
иначе, есть ваш вариант на интерфейсе USI и мой на SPI - без аппаратных регистров.

[piotr433]

очередной бит может прийти через ~1.5 микросекунды

Я не столкнулся с таким
Очередная загадка...

Кстати, программа использующая USI работает на таком же принципе - адрес считывается из "защёлки" USIBR, данные считываются непосредственно из сдвигового регистра USIDR.

А такая схема бы работала, без изменений в программе?

sch.png

[Клапауций]

очередной бит может прийти через ~1.5 микросекунды

Я не столкнулся с таким
Очередная загадка...

я имел ввиду, что если в программное обеспечение ROM будут прописаны иные таймауты между передачей пары байтов, то аппаратная часть отвалится.
т.к. в документации Т36ВМ1-2 я нигде не видел упоминаний, что наличие таймаута между двубайтовыми пакетами обязательно - отсюда следует мой вывод, что аппаратная часть должна работать, даже, если пакеты 16-бит или 13-бит будут следовать друг за другом с таймаутом, обусловленным частотой SHIFT.

Кстати, программа использующая USI работает на таком же принципе - адрес считывается из "защёлки" USIBR, данные считываются непосредственно из сдвигового регистра USIDR.

я пытался найти что-то подобное в SPI, но - нет.

А такая схема бы работала, без изменений в программе?

ок.
я попытаюсь объяснить, как я вижу контроллер дисплея для МК-85 архитектурно:
- аппаратный регистр принимает биты.
- по событию SYNC RISING содержимое регистра отображается в виде логических состояний Q0-Q7. состояния Q0-Q7 не меняются до следующего события SYNC RISING.
- событие SYNC RISING, так же, является внешним прерыванием для контроллера AVR, который считывает Q0-Q7 в байты портами ввода-вывода. это очень быстро аппаратно и дёшево программно.

в жёлтом прямоугольнике - это у нас время, за которое нужно успеть считать первый байт.(вариант с одним регистром)
вариант с двумя регистрами - вообще дёргать STB не нужно. у нас же таймаут.

т.е. или, как я описал выше - или сотня вариантов попыток проскочить между струй дождя.

[Клапауций]

резюме к посту выше, если сложно объяснил: почему именно аппаратный 16-бит регистр и именно конвертация сигнала SYNC в короткий импульс для пина STB регистра:
- использование 16-ть бит регистра и схемы конвертации SYNC позволяют уменьшить скорость обмена данными между регистром и AVR в 16 раз.
- использование 8-мь бит регистра и/или использование сырого сигнала SYNC позволяют уменьшить скорость обмена данными между регистром и AVR в 8 раз.
- использование 8-мь бит регистра AVR(интерфейс USI, SPI) позволяет работать как бы в реальном времени, но время работы обработчика прерывания ограничено временем приёма 8-мь бит - выходим на те же 8-мь раз.

вывод: вариант с 16-ть бит регистром и схемой конвертации SYNC позволяют работать на в 2 раза более высокой частоте, чем все остальные.

[piotr433]

Спасибо за обстоятельный ответ!

если в программное обеспечение ROM будут прописаны иные таймауты между передачей пары байтов, то аппаратная часть отвалится.
т.к. в документации Т36ВМ1-2 я нигде не видел упоминаний, что наличие таймаута между двубайтовыми пакетами обязательно

Чтобы передать данные по шине ЖКИ, процессор записывает их в диапазон адресов 0x0080..0x00FF. Даже самая быстрая машинная команда clrb (r) выполняемая друг за другом оставляет паузу 11 тактов между передаемой парой байтов (соответствует ~9 микросекунд при тактовой частоте 1.2 МГц). Более короткая пауза вряд ли возможна.

Я запустил такую программу на машинном коде:

Code: Select all

	mov	#A5,r0
	clrb	(r0)
	clrb	(r0)
	clrb	(r0)
	...

Полученный результат:

clrb_(r0).png

[Клапауций]

Более короткая пауза вряд ли возможна.

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

а, вот что:
- если 10 микросекунд достаточно для исполнения обработчика прерывания, то сырой SYNC можно использовать для вызова обработчика прерывания по событию SYNC RISING, а пин STB 16-ть бит аппаратного регистра не дёргать, а повесить на +5V.
- если 10 + 7.5 микросекунд достаточно для исполнения обработчика прерывания, то сырой SYNC можно использовать для вызова обработчика прерывания по событию SYNC CHANGE и использовать 8-мь бит аппаратный регистр или регистр интерфейсов USI, SPI.
- если есть желание использовать ВСЁ физически доступное время: 10 микросекунд паузы и 15 микросекунд времени получения пакета данных, то можно использовать 16-ть бит аппаратный регистр и схему конвертации SYNC в управляющий импульс для STB.

вывод:
кроме того факта, что пауза между пакетами данных нас порадовала бонусом дополнительного времени - ничего не изменилось по сути: имеем всё тот же выбор между двумя вариантами: использованием регистров USI, ISP и аппаратным 16-ть бит регистром.

[Клапауций]

косметические обновления проекта.
https://klapautsiy.github.io/The-displa ... ika-MK-85/

LCD переподключен на другой порт.
"адрес" и "дата" теперь на портах PA, PB.
в Arduino остановлены все таймеры и отключены их прерывания.
эл. схема более удобочитаема.
добавлены пояснительные картинко - куда подключаться на плате МК-85.

*возможно, добавлю вариант с использованием интерфейса SPI, если пойму, что это кому-то нужно.

[Клапауций]

последовательный протокол передачи данных в контроллер дисплея МК-85: описание, физическая реализация.

на момент публикации известны два варианта физической реализации последовательной передачи данных в контроллер дисплея МК-85.(источник: пользователь форума piotr433)

Т36ВМ1-2, 9005, ОП-опытный
Т36ВМ1-2, 9105


Т36ВМ1-2, 9109

[Клапауций]

как по мне, то 9-й бит в 8-ми битном протоколе - это какое-то хулиганство.