Да, забыл добавить. Библиотека GxTFT адаптирована под STM32 (FSMC) и DUE HVGA TFT.
SPI, конечно работать будет медленно с DUE. В одном приборе нужно было применить дисплей с шиной SPI и микроконтроллером SAMD21E18A. Ну очень медленно, как черепаха. Но выход нашелся. Применил вместо SAMD21E18A модуль ESP32. У него еще есть режим ускоренного SPI (признаюсь не стал подробно изучать этот режим). Но изображение так и летает. :-).
Куда то тему завели в никуда, полная заливка нафиг не нужна в примерах картинки ТС, и он правильно сказал "не разбирается", пусть у исполнителя голова болит как выводить. Всё реально, вопрос цены и нормального ТЗ.
и судя по стр. 36 и стр. 63, докуманта на ILI9341 , читать по серийному интерфейсу , всеже можно
Во-первых: зависит от конкретной платы и сначала попробуйте.
Во-вторых: даже если чтение работает, это ничего вам не даст.
ну во первых я не до конца понимаю зачем вам надо считывать данные из памяти экрана , я просто привел пример того что это теоретически возможно .
rst пишет:
mixail844 пишет:
как это делается на уровне библиотеки ? полагаю есть простой цикл типа :
Вы сначала попробуйте, а потом полагайте. Если "так" будете что-то рисовать, будете очень долго ждать. ;)
Калькулятор в руки и считать сколько займёт ваше рисование по SPI. Особенно - таким образом.
PS: Все расчёты я привёл выше.
ок , считаем :
экран 480 х 320 пикселей , диагональ ~ 576 пикселей.
* 2 байта на пиксель = 1153 байта и еще * 3 (перемещение адреса графической памяти и прочие расходы) = 3459 байт = 27672 бит.
судя по скорости со страницы 242 , минимаьное время цикла записи 1го бита = 100нс . т.е вся запись займет 27672 бит * 100нс = 0.0027672с т.е. 2.7672 миллисекунд.
ну и наконец, демонстрация на принципиальная возможность : ссылка на ютуб
сылка на гитхаб с описанием автора ,что интерфейс SPI
не мое, но знал что такое возможно ибо когда то попадался мне большой ютубный плейлист с разными экранчиками ,библиотеками, интерфейсами ,контоллерами где демонстрировалась возможность той или иной комбинации.найти не удалось
rst пишет:
PS: Все расчёты я привёл выше.
сдаеться мне ,в сообщении #30 у вас ошибка : делить надо на 100е9
ну во первых я не до конца понимаю зачем вам надо считывать данные из памяти экрана , я просто привел пример того что это теоретически возможно .
Для начала попробуйте что-нибудь нарисовать на подобном экране. Самостоятельно. А не вызывая какие-либо библиотеки. Чтобы понять как оно работает.
mixail844 пишет:
экран 480 х 320 пикселей , диагональ ~ 576 пикселей.
* 2 байта на пиксель = 1153 байта и еще * 3 (перемещение адреса графической памяти и прочие расходы) = 3459 байт = 27672 бит.
судя по скорости со страницы 242 , минимаьное время цикла записи 1го бита = 100нс . т.е вся запись займет 27672 бит * 100нс = 0.0027672с т.е. 2.7672 миллисекунд.
Несёте полный бред!
Какие "время цикла записи 1го бита = 100нс"? Вы понимаете что такое SPI? Как он работает? Работали когда-нить с SPI и с экранами по SPI? Работали когда-нить с ILI9341? Как на SPI-шине выглядит операция записи в ILI9341?
Видно что совершенно не разбираетесь в обсуждаемом вопросе.
Советую сначала попробовать поработать, а не нести подобную чушь.
mixail844 пишет:
сдаеться мне ,в сообщении #30 у вас ошибка : делить надо на 100е9
Вот когда найдёте МК с тактовой 100ГГц тогда и будете делить на 100e9. :-)))))
А пока обсуждаемый МК (STM32F411) имеет тактовую всего 100МГц.
ну и наконец, демонстрация на принципиальная возможность : ссылка на ютуб
Какое там разрешение экрана? Какое время обновления картинки?
По этому можно только очень примерно оценить время обновления. И похоже что оно там очень большое. Вполне возможно что даже 1 секунда или более на весь экран. И экран вполне может быть 320x240.
Да даже если 320x480, то такое большое время обновления - явно не устроит автора.
Но главное что по этому видео видно (даже на таком простом примере, но главное - реальном) - без обновления всего экрана на каждый кадр не обойтись. Ну т.е. - обойтись то можно, но будет гораздо медленнее чем обновлять весь экран сразу.
PS: Ещё раз советую сперва обрести практический опыт и внимательно почитать мануал, а не нести чушь.
куда-то и правда тему занесло. Все задачи тут вполне решаемые. Если найти дисплей с 8ми-битной параллельной шиной - то и пинов хватит, и рисовать можно будет прямо в экранной памяти. Не знаю про 320х480, но 240х320 точно есть 8битные. В принципе, можно наверно и 16битную шину попытаться впихнуть на блекпил - там порядка 32х GPIO. В крайнем случае можно клавиатуру с ее 9пинами повесить на расширитель.
Короче, ТС-у посоветую больше не поддерживать флейм, а договариваться с конкретным человеком. Его задачка вполне реальная.
Какое там разрешение экрана? Какое время обновления картинки?
Добрый день всем!
Не понимаю почему такая проблема с применением дисплея.
Для тех задач, которые сообщил заказчик быстродействия вполне достаточно.
К примеру у меня один из приборов выводит синусоиды токов 3 фазы и различные графики работы механических устройств. Данные поступают с оптических энкодеров. Прибор разработан для энергоснабжения.
Если найти дисплей с 8ми-битной параллельной шиной - то и пинов хватит, и рисовать можно будет прямо в экранной памяти. Не знаю про 320х480, но 240х320 точно есть 8битные.
8-битной вполне хватит. И для 320x480.
А клавиатуру можно частично совместить с этой шиной по ногам, параллельно (сигналы сканирования по-крайней мере). Без всяких расширителей.
куда-то и правда тему занесло. Все задачи тут вполне решаемые. Если найти дисплей с 8ми-битной параллельной шиной - то и пинов хватит, и рисовать можно будет прямо в экранной памяти. Не знаю про 320х480, но 240х320 точно есть 8битные. В принципе, можно наверно и 16битную шину попытаться впихнуть на блекпил - там порядка 32х GPIO. В крайнем случае можно клавиатуру с ее 9пинами повесить на расширитель.
Короче, ТС-у посоветую больше не поддерживать флейм, а договариваться с конкретным человеком. Его задачка вполне реальная.
Полностью согласен!
Из схем выше видно что я применяю 8 битный дисплей на шине FSMC. К тому же еще и тачскрин применил.
Не понимаю почему такая проблема с применением дисплея.
Проблем никаких нет. Просто некоторые деятели, которые совсем не в теме, зачем-то пытаются доказать, что и по SPI и без видеобуфера в ОЗУ МК можно сделать быстрый вывод. :)))))
Я ещё в самом начале сказал: или параллельная шина или видеобуфер в ОЗУ МК. Должно быть хотя-бы что-то из этого. И не будет проблем.
PS: Ещё раз советую сперва обрести практический опыт и внимательно почитать мануал, а не нести чушь.
мне лень писать развернутый ответ, так как вы их всеравно не читаете и флейм разводить тоже не хочеться.
не знаю чего вы вцепились в "полное обновление экрана"
да с SPI работал но не с экранами . но вообще с экранами и графическими драйверами работал.
ок , насчет 100е6 , я не вникал что это у вас за число и откуда оно взялось и вы не написали из какого потолка оно взялось.я подумал что это время записи бита(и вместо нано у вас микро)
к слову о практическом опыте : ссылка на виде на бесплатномн файл хостингиге , там же и можно глянуть видео без звука https://filebin.net/iyy23ui5rotblpnn
экран 480 х 800, вроде.параллельная шина на LTDC
rst пишет:
promavto пишет:
Не понимаю почему такая проблема с применением дисплея.
Проблем никаких нет. Просто некоторые деятели, которые совсем не в теме, зачем-то пытаются доказать, что и по SPI и без видеобуфера в ОЗУ МК можно сделать быстрый вывод. :)))))
Я ещё в самом начале сказал: или параллельная шина или видеобуфер в ОЗУ МК. Должно быть хотя-бы что-то из этого. И не будет проблем.
и я не говорил что не нужен буфер совсем,я сказал что не нужен полноэкранный буфер.
Не понимаю почему такая проблема с применением дисплея.
Проблем никаких нет. Просто некоторые деятели, которые совсем не в теме, зачем-то пытаются доказать, что и по SPI и без видеобуфера в ОЗУ МК можно сделать быстрый вывод. :)))))
Я ещё в самом начале сказал: или параллельная шина или видеобуфер в ОЗУ МК. Должно быть хотя-бы что-то из этого. И не будет проблем.
а вывод быстрый в данном вашем предложении это сколько?
а то я вот тут баловался - 130 миллисекунд, на orangePI еще быстрее.
У меня есть работающий проект: STM32F429 + LCD 320x240 (ILI9341). Подключен по SPI. Отрисовка идёт во внутреннюю ОЗУ МК. Потом весь кадр заливается в ILI9341 через SPI + DMA + DMA2D. Видеобуфер - 16-цветный (две точки = 1 байт).
Проверял на разных SCLK SPI до SCLK=45МГц - всё стабильно работает. На SCLK=45МГц передача всего видеобуфера занимает около ~30мсек.
Конечно ещё нужно время на отрисовку. Но если это критично и есть лишнее ОЗУ, то можно сделать две страницы: одну рисуем, другую - передаём. Я не делал - мне быстродействия с одной страницей вполне хватает: в GUI есть динамические элементы (вращающиеся (довольно быстро) многоугольники, бегущие строки и т.п.) - всё бегает без тормозов.
andycat пишет:
P.S. Сорри что опять тему не в ту степь пнул.
Я думаю - ТСу всё равно будет полезно. Для общего развития. ;)
Откликнулись в самом начале, но я хотел бы найти исполнителя в СПб, чтобы передать ему комплектацию, кроссплату итд. Он собрал бы макет и провели бы испытания. На этом первый этап работ был бы завершен с оплатой.
И потом приняли решение, что делать дальше.
а то я вот тут баловался - 130 миллисекунд, на orangePI еще быстрее.
Если нужно график перерисовывать и несколько цифр на кой фиг перестраивать и переписывать буфер экрана весь ? Да хоть и по точкам - нарисовал точки, стер точки, стер знакоместо, нарисовал символ (причем только тот, что изменился), ну не 60 fps и что ?
Если нужно график перерисовывать и несколько цифр на кой фиг перестраивать и переписывать буфер экрана весь ? Да хоть и по точкам - нарисовал точки, стер точки
Например затем, что перерисовать весь - может оказаться многократно быстрее, чем "по точкам".
А рисовать "по точкам" - вообще глупость неимоверная. Разве что если стоит задача сделать как можно более тормозной код.
Да, забыл добавить. Библиотека GxTFT адаптирована под STM32 (FSMC) и DUE HVGA TFT.
SPI, конечно работать будет медленно с DUE. В одном приборе нужно было применить дисплей с шиной SPI и микроконтроллером SAMD21E18A. Ну очень медленно, как черепаха. Но выход нашелся. Применил вместо SAMD21E18A модуль ESP32. У него еще есть режим ускоренного SPI (признаюсь не стал подробно изучать этот режим). Но изображение так и летает. :-).
В выбранном автором STM32F411 нет FSMC. Если верить даташиту.
Согласен, нет. Но если проект на этапе разработки, можно подобрать STM32 на который есть библиотеки Ардуино.
Но это решение заказчика. Мы здесь так - просто пообщаться вечерком. Может и наши советы кому то помогут. :-).
Куда то тему завели в никуда, полная заливка нафиг не нужна в примерах картинки ТС, и он правильно сказал "не разбирается", пусть у исполнителя голова болит как выводить. Всё реально, вопрос цены и нормального ТЗ.
А когда автор сляпает схему наугад - болеть голове будет уже поздно.
А когда автор сляпает схему наугад - болеть голове будет уже поздно.
Скорости можно достичь думаю: 320*480*2/(100e6/4/8) = ~0.1 сек - полное обновление экрана.
Этой скорости обновления вполне достаточно.
Во-вторых: даже если чтение работает, это ничего вам не даст.
ну во первых я не до конца понимаю зачем вам надо считывать данные из памяти экрана , я просто привел пример того что это теоретически возможно .
Калькулятор в руки и считать сколько займёт ваше рисование по SPI. Особенно - таким образом.
PS: Все расчёты я привёл выше.
* 2 байта на пиксель = 1153 байта и еще * 3 (перемещение адреса графической памяти и прочие расходы) = 3459 байт = 27672 бит.
PS: Ещё раз советую сперва обрести практический опыт и внимательно почитать мануал, а не нести чушь.
куда-то и правда тему занесло. Все задачи тут вполне решаемые. Если найти дисплей с 8ми-битной параллельной шиной - то и пинов хватит, и рисовать можно будет прямо в экранной памяти. Не знаю про 320х480, но 240х320 точно есть 8битные. В принципе, можно наверно и 16битную шину попытаться впихнуть на блекпил - там порядка 32х GPIO. В крайнем случае можно клавиатуру с ее 9пинами повесить на расширитель.
Короче, ТС-у посоветую больше не поддерживать флейм, а договариваться с конкретным человеком. Его задачка вполне реальная.
Добрый день всем!
Не понимаю почему такая проблема с применением дисплея.
Для тех задач, которые сообщил заказчик быстродействия вполне достаточно.
К примеру у меня один из приборов выводит синусоиды токов 3 фазы и различные графики работы механических устройств. Данные поступают с оптических энкодеров. Прибор разработан для энергоснабжения.
Фото экрана и фрагменты схем прибора.
А клавиатуру можно частично совместить с этой шиной по ногам, параллельно (сигналы сканирования по-крайней мере). Без всяких расширителей.
куда-то и правда тему занесло. Все задачи тут вполне решаемые. Если найти дисплей с 8ми-битной параллельной шиной - то и пинов хватит, и рисовать можно будет прямо в экранной памяти. Не знаю про 320х480, но 240х320 точно есть 8битные. В принципе, можно наверно и 16битную шину попытаться впихнуть на блекпил - там порядка 32х GPIO. В крайнем случае можно клавиатуру с ее 9пинами повесить на расширитель.
Короче, ТС-у посоветую больше не поддерживать флейм, а договариваться с конкретным человеком. Его задачка вполне реальная.
Полностью согласен!
Из схем выше видно что я применяю 8 битный дисплей на шине FSMC. К тому же еще и тачскрин применил.
Я ещё в самом начале сказал: или параллельная шина или видеобуфер в ОЗУ МК. Должно быть хотя-бы что-то из этого. И не будет проблем.
Я ещё в самом начале сказал: или параллельная шина или видеобуфер в ОЗУ МК. Должно быть хотя-бы что-то из этого. И не будет проблем.
и я не говорил что не нужен буфер совсем,я сказал что не нужен полноэкранный буфер.
Я ещё в самом начале сказал: или параллельная шина или видеобуфер в ОЗУ МК. Должно быть хотя-бы что-то из этого. И не будет проблем.
а вывод быстрый в данном вашем предложении это сколько?
а то я вот тут баловался - 130 миллисекунд, на orangePI еще быстрее.
http://arduino.ru/forum/otvlechennye-temy/programmirovanie-32-kh-razryad...
P.S. Сорри что опять тему не в ту степь пнул.
а то я вот тут баловался - 130 миллисекунд, на orangePI еще быстрее.
http://arduino.ru/forum/otvlechennye-temy/programmirovanie-32-kh-razryadnykh-mk?page=21#comment-631297
У меня есть работающий проект: STM32F429 + LCD 320x240 (ILI9341). Подключен по SPI. Отрисовка идёт во внутреннюю ОЗУ МК. Потом весь кадр заливается в ILI9341 через SPI + DMA + DMA2D. Видеобуфер - 16-цветный (две точки = 1 байт).
Проверял на разных SCLK SPI до SCLK=45МГц - всё стабильно работает. На SCLK=45МГц передача всего видеобуфера занимает около ~30мсек.
Конечно ещё нужно время на отрисовку. Но если это критично и есть лишнее ОЗУ, то можно сделать две страницы: одну рисуем, другую - передаём. Я не делал - мне быстродействия с одной страницей вполне хватает: в GUI есть динамические элементы (вращающиеся (довольно быстро) многоугольники, бегущие строки и т.п.) - всё бегает без тормозов.
С учетом результатов обсуждений открою новую тему с формулировкой задачи по варианту №2 )
С учетом результатов обсуждений открою новую тему с формулировкой задачи по варианту №2 )
что, никто так и не откликнулся?
Когда возникает такая жаркая теоретическая дискуссия - это верный знак, что в ветке нет людей. способных реально выполнить этот заказ :)
Откликнулись в самом начале, но я хотел бы найти исполнителя в СПб, чтобы передать ему комплектацию, кроссплату итд. Он собрал бы макет и провели бы испытания. На этом первый этап работ был бы завершен с оплатой.
И потом приняли решение, что делать дальше.
а то я вот тут баловался - 130 миллисекунд, на orangePI еще быстрее.
Если нужно график перерисовывать и несколько цифр на кой фиг перестраивать и переписывать буфер экрана весь ? Да хоть и по точкам - нарисовал точки, стер точки, стер знакоместо, нарисовал символ (причем только тот, что изменился), ну не 60 fps и что ?
на кой фиг перестраивать и переписывать буфер экрана весь ?
а мне и не надо переписывать весь экран :) я ж говорю - баловался.
это ТС тему замутил.
А рисовать "по точкам" - вообще глупость неимоверная. Разве что если стоит задача сделать как можно более тормозной код.