[Arlleex 131]

Планирую в один девайс заложить OLED экранчик графический. Нашли подходящий, но у него параллельный интерфейс 6800 (контроллер SSD1309).

МК - какой-то из STM32F4xx будет, поэтому грех не посадить этот экран на FSMC, чтобы маппить видеобуфер экрана прямиком в адресное пространство.

Полез смотреть на диаграмму записи в экран в даташите на SSD1309. Ок, все понятно. Самое главное, какое-то время надо держать данные после строба ↓ сигнала E.

Дальше полез смотреть диаграммы доступа FSMC, нашел наиболее подходящий режим записи. Примерно раскидал, к каким сигналам FSMC подключать экран.

CS экрана я подцеплю к NEx, E экрана - к NOE. Однако, как никак, мне надо удерживать данные с FSMC (в том числе используемые линии адреса) какое-то адекватное время.

Смотрю на диаграмму FSMC и вижу следующее (картинка взята из забугорных тредов с примерно похожими обсуждениями)

И это время не специфицировано (я не нашел сходу в описании).

Одно дело, если бы МК работал на какой-то маленькой частоте, и огрызок на картинке растянулся бы на сотни нс, может быть. Но я планирую работать на максимуме (168...180 МГц), ибо электроэнергию экономить не нужно.

Имеет ли смысл шину данных (и используемые адресные линии) пропустить через "прозрачную" D-защелку?

[aaarrr 63]

29 minutes ago, Arlleex said:

огрызок на картинке растянулся бы на сотни нс

Огрызок никуда не растянулся бы. А одного HCLK hold дисплею не достаточно?

[Arlleex 131]

1 час назад, aaarrr сказал:

Огрызок никуда не растянулся бы.

Почему? Он был бы 1 (судя по картинке, примерно) HCLK. И в случае пониженной частоты получившийся 1 HCLK в наносекундах был бы больше, чем при бОльшей частоте HCLK.

Цитата

А одного HCLK hold дисплею не достаточно?

Документация на SSD1309 пишет минимум 20 нс. Хотя диаграмма там та еще вырви глаз

[Arlleex 131]

О, наткнулся на https://community.st.com/t5/stm32-mcu-products/issue-with-using-lcd-with-fmc-in-sram-mode-stm32h743/td-p/335864,

где наш участник @__inline__ уже задавал такой же вопрос, даже привел линк на здешний тред https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=148029.

Буду разбираться.

[aaarrr 63]

30 minutes ago, Arlleex said:

судя по картинке, примерно

А в даташите написано, что никакого хвоста нет и в помине:

th(Data_NWE) Data hold time after FSMC_NWE high =  THCLK–1 ns

[Arlleex 131]

2 минуты назад, aaarrr сказал:

А в даташите написано, что никакого хвоста нет и в помине:

th(Data_NWE) Data hold time after FSMC_NWE high =  THCLK–1 ns

Ооо... Еще лучше Спасибо. Буду вглядываться, спасет ли меня режим NAND.

[Obam 30]

CS экрана я подцеплю к NEx...
А не к NWE разве? Гарантированное снятие (1 ц HCLK) при достоверных данных.
NEx, NOE к R/W#, E не?

[repstosw 18]

8 hours ago, Arlleex said:

И это время не специфицировано (я не нашел сходу в описании).

Я уже давно писал тут об этом.  Но не был услышан.

У FSMC этот кусок времени - 1 CLK.  Всё.

Нашёл решение. Нужно запустить шину в режиме NAND.  Там этот холд регулируется.

 

 

Изменено 26 июня, 2023 пользователем repstosw

[AVI-crak 0]

On 6/25/2023 at 10:38 PM, Arlleex said:

И это время не специфицировано (я не нашел сходу в описании).

Время свободной шины BUSTURN -   FSMC целиком блокируется на несколько тактов, линия данных отключается, но емкости дорожек и контактов достаточно для удержания уровня. в режиме NAND возможно аппаратное управление контактом дисплея "команда". Надо просто добавить немного логики. 

[Arlleex 131]

4 часа назад, repstosw сказал:

Нашёл решение. Нужно запустить шину в режиме NAND.  Там этот холд регулируется.

Да, регулируется. Я с голой памятью NAND ранее не работал, нужно детально разбираться в тонкостях маппинга регистров управления SSD1309 и самого видеобуфера на адресное пространство FSMC.

Я не уверен, что для NAND режима FSMC видеобуфер будет таким же линейным массивом в адресном пространстве МК, как было бы в случае режима SRAM. Ведь в NAND, как никак, адрес байта памяти весьма длинный.
 

7 часов назад, Obam сказал:

NEx, NOE к R/W#, E не?

Нет, конечно. Посмотрите на диаграмму FSMC. Там даже инвертируя внешней логикой не получится форма сигналов, требуемая по спецификации SSD1309.

[repstosw 18]

1 hour ago, Arlleex said:

Да, регулируется. Я с голой памятью NAND ранее не работал, нужно детально разбираться в тонкостях маппинга регистров управления SSD1309 и самого видеобуфера на адресное пространство FSMC.

Не нужна никакая NAND и знания о ней.   Всё будет точно также, как и в случае FMC в SRAM режиме.

Порт команд (A=0) и порт данных (A=1). Всё.

 

1 hour ago, Arlleex said:

Я не уверен, что для NAND режима FSMC видеобуфер будет таким же линейным массивом в адресном пространстве МК, как было бы в случае режима SRAM. Ведь в NAND, как никак, адрес байта памяти весьма длинный.

Ваш дисплей имеет буфер с авто-инкрементом адреса?  Или запись произвольного пикселя?

Ещё раз:  забудьте о NAND.   Будет всё также как и с обычным FMC.

[Arlleex 131]

11 минут назад, repstosw сказал:

Ваш дисплей имеет буфер с авто-инкрементом адреса?  Или запись произвольного пикселя?

Да, автоинкремент поддерживается, запись произвольного пиксельного байта (минимальная запись) тоже.

[jcxz 184]

19 часов назад, Arlleex сказал:

Планирую в один девайс заложить OLED экранчик графический. Нашли подходящий, но у него параллельный интерфейс 6800 (контроллер SSD1309).

И не жалко вам столько ног МК отдавать? При том, что точек то - кот наплакал: 128x64?

И не будет ли проблем с сигналами NBLx? Или планируете только словами писать?

[Arlleex 131]

24 минуты назад, jcxz сказал:

И не жалко вам столько ног МК отдавать? При том, что точек то - кот наплакал: 128x64?

Ноги все равно лишние останутся... Жалко, конечно, с одной стороны, но подходящих мне экранов по складским запасам магазинов и цене я больше не находил...
 

Цитата

И не будет ли проблем с сигналами NBLx? Или планируете только словами писать?

А я их не планирую подключать вовсе, все пересылки же будут байтовыми, а LCD-контроллеру пофигу на NBL.

[Arlleex 131]

Почитал я про работу в NAND режиме, все равно без внешних компонентов не обойтись для моего экрана - как минимум нужна инверсия строба E и формирование этого самого строба.

Хрень редьки не слаще, поэтому я решил разработать дешманиский аппаратный патч на логических элементах и регистрах.

Самый подходящий для коррекции режим FSMC - это режим "Mode B" SRAM из-за наличия в этом режиме выходного сигнала NADV (он указывает окончание фазы предустановки адреса)

Теперь по порядку - стыковка этих сигналов с сигналами дисплея.

1. Ножка D/C экрана (данные/команды) подключается к адресной линии A10.
Чтение/запись адресного пространства > 1024 байт (размер области вывода 128x64 пикселей) будет устанавливать режим DATA.
В противном случае контроллер экрана воспринимает операцию как COMMAND.

2. У практически всех экранов (в т.ч. моего) ножка R/W предполагает 1 на чтение, 0 на запись.
Глядя в документацию на SSD1309, видно, что уровень на R/W (как и на D/C) должен быть установлен как минимум за 20 нс перед опусканием CS.
Из всех сигналов FSMC на роль R/W подходит NOE, только для подачи на R/W экрана этот сигнал надо инвертировать.

3. Что касается ножки CS экрана. Из даташита на SSD1309 видно, что уровни на D/C и R/W должны быть уже стабильны на момент опускания CS.
Из FSMC торчит сигнал NADV, который переключается спустя настраиваемое время ADDSET в тактах HCLK, а затем держит полученный уровень в течение DATAST + 1.
Из диаграмм FSMC не совсем понятно состояние "хвоста" сигнала NADV после установки NEx (то ли он установится в 1, то ли сбросится в 0, то ли восстановит уровень до опускания NEx)...
Чтобы гарантировать, что CS экрана будет лог. 0 только во время DATAST + 1, а во всех других случаях лог. 1, нужно связать NADV с каким-то гарантированно известным сигналом. Это NEx.
Нехитрой таблицей истинности описывается, что CS должен быть 0 только тогда, когда NADV равен 1, а NEx равен 0. Получившийся лог. элемент не стандартный - И-НЕ с одним инверсным входом.
Из разных микросхем строить не придется, благо существуют дешевые и широко распространенные универсальные элементы - 1G57, например. Максимальное время распространения у него 6.3 нс.

Т.е. на данный момент тайминги синтезированных сигналов D/C, R/W и CS полностью соответствуют документации на контроллер экрана.

4. Сигнал строба E. Проблемный товарищ. Даташит неоднозначен, противоречит немного описание предоставленной там картинке. Исходя из диаграммы, я уверен на 99%, что он нужен только для записи.
Ладно, хрен с ним. Для записи требуется, чтобы заранее предустановленный в 1 E упал в 0 в пределах действия CS (т.е. когда CS равен 0). Когда конкретно - документация молчит.
А вот что документация точно требует, так это минимум 40 нс предустановки данных перед поднятием CS (при завершении цикла доступа). Т.е. E должен дернуться где-то перед поднятием CS.
Глядя на диаграммы FSMC на запись, виден идеальный кандидат - сигнал NWE. Только его инвертировать надо.

5. Самое интересное - шина данных. Тот самый дебильный короткий "хвост" FSMC, который не удовлетворяет времени удержания данных в контроллере экрана...
Т.е. надо защелкивать данные, чтобы они оставались на шине "подольше". Например, до следующей транзакции. В этом поможет регистр-защелка 74HC373.
У этой микросхемы все данные со входа на выход "застывают", когда на вход LATCH прилетает лог. 0. Конечно же, эта лапка цепляется к сигналу E (тот, что инверсный NWE FSMC).

6. Пункт 5 обеспечил выполнение требования времени удержания данных после деактивации CS. Хорошо, но как читать данные с экрана, буфер то однонаправленный?
Замкнуть входные линии на соответствующие выходные прямо накоротко. И чтобы не было КЗ (когда шины FSMC и дисплея переводятся на выходные), надо рулить сигналом OE регистра-защелки.
Ранее сигнал R/W был получен из NOE путем инверсии. Глядя на диаграмму FSMC, видно, что в зоне "за телом транзакции" NOE восстанавливает свое состояние. А мне надо, чтобы оно сохранялось.
Соответственно, ставлю D-триггер. Защелкивать буду R/W по спаду CS (т.е. в момент начала фазы данных по диаграмме). Выход триггера хранит флаг, что делалось в предыдущей транзакции.
Если предыдущая транзакция была на чтение, то защелка будет отключена от шины до начала падающего фронта CS текущей транзакции. Этим обеспечивается, что данные выставляет только дисплей.
Если же предыдущая транзакция была на запись, то защелка в активном прозрачном состоянии, не мешает FSMC выводить данные.

Но вообще бы нужно держать данные в защелке ровно до начала нового спада NEx. Т.е. весь цикл ADDSET держать защелку в отключении (OE = 1).

Это все мысли вслух. Записка для себя))