nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 18 Mar 2024 23:36



Reply to topic  [ 105 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next
Генератор тактовых импульсов "Электроника МК-85" 
Author Message
Banned
User avatar

Joined: 29 Jun 2018 08:48
Posts: 413
Reply with quote
piotr433 wrote:
У меня возникла идея, как передать по SPI меньше 8-ми битов.

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

ну, ок - тогда можно попробовать так:
Code:
while(!(SPSR & (1<<SPIF))) {/*добиваем до 8-ми бит*/};

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


07 Sep 2018 13:23
Profile
Banned
User avatar

Joined: 29 Jun 2018 08:48
Posts: 413
Reply with quote
как бы схемотехнически ни была изящна версия контроллера дисплея на только одном AVR, но склоняюсь к мнению, что версия с аппаратным 16-ть бит регистром(будь то на двух 8-мь бит корпусах или в одном 16-бит корпусе) является универсальным решением:
- нет ограничений в 8-ми битности SPI или наличия/отсутсвия интерфейса USI.
- аппаратно: проще и быстрей считывать последние 13-ть или 16-ть бит в порты контроллера по событию SYNC RISING.
- программно: единственное прерывание с очень простым обработчиком.

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

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


07 Sep 2018 15:50
Profile
Novelist
User avatar

Joined: 14 Aug 2018 14:30
Posts: 49
Location: Szczecin, Польша
Reply with quote
Мне в руки попал микропроцессор Т36ВМ1-2 с датой выпуска 9109, который передаёт по шине ЖКИ восемь бит данных.
Attachment:
9109.png
9109.png [ 4.91 KiB | Viewed 9341 times ]

Я ещё подумал, что может такая упрощена схема бы заработала:
Attachment:
sch.png
sch.png [ 8.28 KiB | Viewed 9330 times ]

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


09 Sep 2018 10:01
Profile WWW
Banned
User avatar

Joined: 29 Jun 2018 08:48
Posts: 413
Reply with quote
спасибо, Piotr.
piotr433 wrote:
Мне в руки попал микропроцессор Т36ВМ1-2 с датой выпуска 9109, который передаёт по шине ЖКИ восемь бит данных.

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

Code:
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;}
}


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

эта схема будет работать, но немного не так, как нужно.
нужно, что бы пины 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.


Attachments:
MK-85_CD4093BE_P_SYNC.png
MK-85_CD4093BE_P_SYNC.png [ 2.84 KiB | Viewed 9318 times ]
09 Sep 2018 19:17
Profile
Novelist
User avatar

Joined: 14 Aug 2018 14:30
Posts: 49
Location: Szczecin, Польша
Reply with quote
Quote:
при изменении SYNC с "0" в "1" у нас может остаться ровно один такт времени до изменения SHIFT, что бы успеть считать актуальные на момент изменения SYNC данные, иначе они будут изменены приёмом битов очередной пары байтов.

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

Вот здесь, при выполнении команды MODE, происходит самая быстрая передача по шине ЖКИ:
Code:
15BC:   clrb   @#98
15C0:   clrb   @#A0

Attachment:
mode.png
mode.png [ 5.88 KiB | Viewed 9300 times ]


09 Sep 2018 22:58
Profile WWW
Banned
User avatar

Joined: 29 Jun 2018 08:48
Posts: 413
Reply with quote
piotr433 wrote:
Очередная пара байтов может появится лишь после ~10 микросекунд (в турбо режиме). Разве это недостаточное время, чтобы успеть считать данные?

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

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

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

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

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


09 Sep 2018 23:52
Profile
Banned
User avatar

Joined: 29 Jun 2018 08:48
Posts: 413
Reply with quote
предложенное мной, схемотехническое решение с 16-ть бит регистром, возможно, избыточно и допускает оптимизации и упрощения.
но, именно такой вариант работоспособен с любым количеством принимаемых бит и паузами между передаваемыми парами байтов.
иначе, есть ваш вариант на интерфейсе USI и мой на SPI - без аппаратных регистров.


10 Sep 2018 00:59
Profile
Novelist
User avatar

Joined: 14 Aug 2018 14:30
Posts: 49
Location: Szczecin, Польша
Reply with quote
Quote:
очередной бит может прийти через ~1.5 микросекунды

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

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

А такая схема бы работала, без изменений в программе?
Attachment:
sch.png
sch.png [ 13.65 KiB | Viewed 9259 times ]


10 Sep 2018 04:07
Profile WWW
Banned
User avatar

Joined: 29 Jun 2018 08:48
Posts: 413
Reply with quote
piotr433 wrote:
Quote:
очередной бит может прийти через ~1.5 микросекунды

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

я имел ввиду, что если в программное обеспечение ROM будут прописаны иные таймауты между передачей пары байтов, то аппаратная часть отвалится.
т.к. в документации Т36ВМ1-2 я нигде не видел упоминаний, что наличие таймаута между двубайтовыми пакетами обязательно - отсюда следует мой вывод, что аппаратная часть должна работать, даже, если пакеты 16-бит или 13-бит будут следовать друг за другом с таймаутом, обусловленным частотой SHIFT.
piotr433 wrote:
Кстати, программа использующая USI работает на таком же принципе - адрес считывается из "защёлки" USIBR, данные считываются непосредственно из сдвигового регистра USIDR.

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

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

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

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

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


Attachments:
zzzz.png
zzzz.png [ 81.24 KiB | Viewed 9255 times ]
10 Sep 2018 05:37
Profile
Banned
User avatar

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

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


10 Sep 2018 06:36
Profile
Novelist
User avatar

Joined: 14 Aug 2018 14:30
Posts: 49
Location: Szczecin, Польша
Reply with quote
Спасибо за обстоятельный ответ!

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

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

Я запустил такую программу на машинном коде:
Code:
   mov   #A5,r0
   clrb   (r0)
   clrb   (r0)
   clrb   (r0)
   ...

Полученный результат:
Attachment:
clrb_(r0).png
clrb_(r0).png [ 6.94 KiB | Viewed 9220 times ]


10 Sep 2018 12:07
Profile WWW
Banned
User avatar

Joined: 29 Jun 2018 08:48
Posts: 413
Reply with quote
piotr433 wrote:
Более короткая пауза вряд ли возможна.

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

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

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


10 Sep 2018 16:56
Profile
Banned
User avatar

Joined: 29 Jun 2018 08:48
Posts: 413
Reply with quote
косметические обновления проекта.
https://klapautsiy.github.io/The-displa ... ika-MK-85/

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

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


10 Sep 2018 18:47
Profile
Banned
User avatar

Joined: 29 Jun 2018 08:48
Posts: 413
Reply with quote
последовательный протокол передачи данных в контроллер дисплея МК-85: описание, физическая реализация.











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

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

Т36ВМ1-2, 9109
Image


12 Sep 2018 03:18
Profile
Banned
User avatar

Joined: 29 Jun 2018 08:48
Posts: 413
Reply with quote
как по мне, то 9-й бит в 8-ми битном протоколе - это какое-то хулиганство.


Attachments:
8-bit1.png
8-bit1.png [ 7.8 KiB | Viewed 9132 times ]
12 Sep 2018 03:22
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 105 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next

Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.