[jcxz 242]

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

По поводу синтетического скриншота- в нашем случае так не получится- часть данных на экране динамически меняется, возможно с вариантом digital phosphor ( послесвечение)

Не вижу проблемы. Затухающий постепенно объект: Задаём цвету объекта атрибут "затухание" с коэффициентом K (каждый квант времени цвет объекта умножается на K пока не станет меньше какого-то порогового) и стартовой точкой T (момент времени). При скриншоте защёлкиваем текущий цвет объекта вместе с координатами и прочим. Теперь в любой момент времени объект можно отрисовать в том состоянии, когда он был захвачен.

Цитата

и еще пользователь может делать курсорные измерения задавая обьекты пальцем на тачскрине- кто его знает что он там наваяет.

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

А если юзер не рисует, а передвигает какие-то готовые объекты на экране - так ещё проще - нужно только запомнить текущее их расположение. Зачем всю историю перемещений хранить?

PS: Впрочем - хозяин-барин, решать вам. Но я не вижу никакой насущной надобности в чтении видеопамяти.

[khach 44]

Возвращаясь к началу. Кто-нибудь двунаправленный буфера с автовыбором направления типа TXB0108 или подобных на QSPI использовал?

Техас инструментс рекомендует тут https://e2e.ti.com/support/logic/f/151/t/627998 lsf0108 для этого использовать. Вроде TXB0108 имеют теж же параметры плюс защита.

 

[jcxz 242]

8 минут назад, khach сказал:

Кто-нибудь двунаправленный буфера с автовыбором направления типа TXB0108 или подобных на QSPI использовал?

Сталкивался. Правда на UART. Тот ещё глюкодром! Имхо - использовать такое следует только если по-другому ну вообще никак.

[khach 44]

UART это намного медленне- на QSPI скорости под 100 мгц, переключение направлений передачи-приема и нет совсем сигнала выбора направления шины. Пытались это симулировать используя таймеры процессора для подстчета тактов передачи команы и адреса  на шине, но это такой геморрой оказался.

[jcxz 242]

15 часов назад, khach сказал:

UART это намного медленне- на QSPI скорости под 100 мгц, переключение направлений передачи-приема и нет совсем сигнала выбора направления шины.

Скорость тут при чём? Проблема у меня была видимо в том, что этот шибко "умный" транслятор уровней TXB0106 переключался тогда, когда ему вздумается. В том числе иногда переключался даже навстречу сигналу вывода! И я на своём TXD видел какую-то хрень. 

[khach 44]

2 hours ago, jcxz said:

Проблема у меня была видимо в том, что этот шибко "умный" транслятор уровней TXB0106 переключался тогда, когда ему вздумается.

А в чем была причина такого поведения разобрались? Пока нашел достаточное количество вариантов применения TXB0108 в для согласования уровня в отладчиках типа JTAG st-link итд. Т.е интерфейсы достаточно высокоскоростные, некоторые с измерением направления на-ходу.  Вроде работать должно. Но конечно надо пробовать. могут еще грабли с задержками вылезти при переключении направления, но это надеюсь побороть настройками QSPI.

[jcxz 242]

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

А в чем была причина такого поведения разобрались?

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

Вот эта плата:  https://www.mikroe.com/gsmgnss-2-click#heading1

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

Пока нашел достаточное количество вариантов применения TXB0108 в для согласования уровня в отладчиках типа JTAG st-link итд.

Это ни о чём не говорит. Вы их пробовали? Вышеуказанная плата тоже продаётся вовсю. Но когда подключал к ней свой МК - работало-более-менее стабильно, когда подключал USB-UART-переходник, начинало периодически (или постоянно глючить).

[khach 44]

50 minutes ago, jcxz said:

 Но когда подключал к ней свой МК - работало-более-менее стабильно, когда подключал USB-UART-переходник, начинало периодически (или постоянно глючить).

Судя по аппнотам, если источник сигнала не имел push-pull  выходов а только  Open-Drain то допустимая скорость падала драматически - со 100 мгц до 1 мгц. И надо применять серию  TXS а не  TXB .  А большинство переходников USB-UART не имели мощных push-pull выходов. Может в этом проблема была?

PS. Biasing Requirements for TXS, TXB, and LSF Auto- Bidirectional Translators

Ps2. Моя ситуация полностью описана в Voltage Level Translation Guide на 6 странице

Quote

SD Card, Memory Stick, and MMC Voltage-Translation Transceivers
with ESD Protection and EMI Filtering
TXS0206, TXS0206A, TXS0206-29

 

[backa 1]

 

On 9/19/2019 at 2:34 PM, khach said:

кто нибудь встречал подключение FTDI-шного LCD контроллера серии FT81x по QuadSPI шине к STM32G4 или подобным контроллерам?

Если еще актуален этот вопрос то я дела на Texas-ом арме TM4C1294 и FT813. Использовал этот контролер ввиду полного отсутсвия свободных ног у АРМ для подключения графического дисплея (на момент корректривовки проекта ). Пришлось немного покорпеть над их доками и примерами (даже вел успешную переписку с техподдержкой FTDI (вполне дружелюбную и "по-делу") ).

Для простых интерфейсов и ограниченных возможностях при подключении дисплея - вполне себе ГОДНЫЙ контролер. Но в следующий проект вряд-ли заложу когда-либо ввиду серьезных ограничений в прямом доступе к видеопамяти (хотя и эти ограничения были успешно преодолены). Некое подобие оссилограффа даже сделал для контролля формы входного сигнала))) Для всяких поделок не комерческих вполне можно использовать

[khach 44]

19 hours ago, backa said:

Если еще актуален этот вопрос

Конечно актуально, если можете рассказть о граблях которые встретились или поделится ссылками на открытый код который использовали при такой реализации. К сожалению не знаю особенности реализации QSPI у TM4C1294  поэтому без понятия, подойдет ли код к STM32. А почему только для некоммерческих поделок? Лицензии? Зависает при длительном использовании? Я пока воюю с переделкой платы типа https://www.hotmcu.com/5-graphical-lcd-touchscreen-800x480-spi-ft810-p-286.html которая разведена под обычный SPI и поэтому крайне тормозная. А линии SPI буферированы однонаправленными буферами поэтому так просто на QSPI не переделать. Да еще и BGA корпус TXS0206  проблем добавляет для макета. Там, судя по внутреннему устройству, линия CLK не двунапарвленная и на нее надо отдельный преобразователь уровней городить в отличиии от линий данных если использовать TXS0108 вместо TXS0206.

[jcxz 242]

29 минут назад, khach сказал:

Я пока воюю с переделкой платы типа https://www.hotmcu.com/5-graphical-lcd-touchscreen-800x480-spi-ft810-p-286.html которая разведена под обычный SPI и поэтому крайне тормозная.

А может использовать не quad-, а dual-SPI? Будет уже быстрее. FT81x вроде его поддерживает и ноги используются те же, что и в обычном SPI. С однонаправленными трансляторами уровня конечно всё равно что-то делать придётся, но только с одним вроде как....

[khach 44]

Dual или quad - уже без разницы, все равно направлением управлять. можно даже 8 канальный SPI - процессор поддерживает, но контроллера экрана такого нет.

Грабля была пока я не нашел первый рисунок, потому что пытался пустит клок тоже чере двунаправленный буфер. Жалко, что CLK-feedback не поддерживается аппаратно, а то можно было бы учесть задержку в кабеле. У STM32H7 для этого есть интересный блок задержек. Жалко, что не выведен на отдельный пин.

 

[backa 1]

2 hours ago, khach said:

платы типа https://www.hotmcu.com/5-graphical-lcd-touchscreen-800x480-spi-ft810-p-286.html которая разведена под обычный SPI и поэтому крайне тормозная

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