Ruslan1 17 4 марта, 2020 Опубликовано 4 марта, 2020 · Жалоба 13 hours ago, jcxz said: При чём тут DMA? Разбиваете весь видеобуфер на N частей по M пикселей каждая. Конвертируете (процессором конечно) пиксели из первой части через таблицу преобразования цветов в промежуточный буфер отправки. Запускаете отправку из этого буфера в SPI (посредством DMA). Пока идёт передача пикселей первой части, параллельно конвертируете вторую часть во 2-й промежуточный буфер, в конце конвертирования - ожидание завершения DMA-передачи 1-й части и запуск 2-й части (естественно - на семафоре ОС). И снова - конвертируете следующую часть и так далее. В результате - конвертирование займёт времени намного меньше чем собственно передача по SPI (если конечно писать с умом). PS: Ещё больше эффект от такого метода будет если цветов только 16. А, ну так и я могу :) Дополнительная загрузка процессора тут неслабая получается, экономия памяти сомнительная (нужно буфер под оригинальный сжатый массив и под DMA). Но в каких-то ситуациях этот путь может и быть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 4 марта, 2020 Опубликовано 4 марта, 2020 · Жалоба 1 час назад, Ruslan1 сказал: Дополнительная загрузка процессора тут неслабая получается И как это вычислили? У меня в проекте, сделанном подобным образом (только с 4-битным цветом), загрузка процессора таким выводом на LCD - я точно не помню сколько, но что то меньше 10%. Это при SCLK=40 МГц. На 20МГц будет ещё меньше. Даже на ассемблере не стал оптимизировать, ибо - ерунда. Это "неслабая"? 1 час назад, Ruslan1 сказал: экономия памяти сомнительная (нужно буфер под оригинальный сжатый массив и под DMA). Но в каких-то ситуациях этот путь может и быть. Экономия почти в 2 раза (для 8-битного цвета) или почти в 4 раза (для 4-битного) - это "сомнительная"? Экономия в несколько десятков КБ внутренней ОЗУ. И рисование не во внешней медленной, а во внутренней, значительно более быстрой памяти. Плюс - отсутствие всяких заполнений одним цветом и связанных с этим тормозов, мерцаний и других артефактов. И то что: В 27.02.2020 в 16:36, Ruslan1 сказал: что у этого контроллера ILI9341 нет специальной команда "заполнить CGRAM указанной величиной" как бы намекает на то что, по мнению разработчиков этого чипа, никто в здравом уме не станет так делать - стирать, а потом рисовать поверх. А ожидается, что нормальный путь - рисовать в отдельной памяти и засылать в ILI уже готовое изображение. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 5 марта, 2020 Опубликовано 5 марта, 2020 · Жалоба 7 hours ago, jcxz said: И как это вычислили? У меня в проекте, сделанном подобным образом (только с 4-битным цветом), загрузка процессора таким выводом на LCD - я точно не помню сколько, но что то меньше 10%. Это при SCLK=40 МГц. На 20МГц будет ещё меньше. Даже на ассемблере не стал оптимизировать, ибо - ерунда. Это "неслабая"? Убить на такую"оптимизацию" дополнительно 10% процессорного времени- это непозволительная роскошь для меня. У меня сейчас там задач 30 крутится, некоторые из них уже довольно ресурсоемкие (DSP). 7 hours ago, jcxz said: Экономия почти в 2 раза (для 8-битного цвета) или почти в 4 раза (для 4-битного) - это "сомнительная"? "сомнительная"- потому что не на пустом месте. Нужно дополнительно буфер под DMA, и "почти в два раза" превращается во что? в "почти в полтора раза"? Или предлагается по 1 килобайту гонять и часто отвлекаться на создание буфера? в таком случае нужно будет очень часто в эту низкоприоритетную задачу переходить, тормоза при прорисовки на экране из-за задержек между такими короткими передачами будут видны. 7 hours ago, jcxz said: И то что: как бы намекает на то что, по мнению разработчиков этого чипа, никто в здравом уме не станет так делать - стирать, а потом рисовать поверх. А ожидается, что нормальный путь - рисовать в отдельной памяти и засылать в ILI уже готовое изображение. Нет. Это как бы намекает, что если нужна скорость- то нужно использовать параллельный интерфейс (8- или 16- битный), а не последовательный. А уж если выбран последовательный- то нужно жертвовать ресурсами ведущего процессора,чтоб добится ускорения. Ну и еще разработчики как бы намекают, что эта команда не настолько востребована, чтобы снизить привлекательность этого контроллера на рынке- просто все покупают и выкручиваются как могут, имея то что есть. И я уже писал выше, что даже если не стирать а просто писать- то у меня выигрыш по количестве пересылаемых данных будет 25%, несерьезный профит на фоне увеличения объема нужных для этого ресурсов (полный экран в RAM ЦП, пусть и сжатый). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 5 марта, 2020 Опубликовано 5 марта, 2020 · Жалоба 57 минут назад, Ruslan1 сказал: Убить на такую"оптимизацию" дополнительно 10% процессорного времени- это непозволительная роскошь для меня. У меня сейчас там задач 30 крутится, некоторые из них уже довольно ресурсоемкие (DSP). Вспоминается поговорка про книгу и фигу... Странно - пишу одно, а понимаете совсем другое, такое ощущение, что читали мой пост через слово.... Во-первых: где я писал про 10%? Я писал "не более 10%". Точно сказать не могу, так как девайс далеко. Да и эти 10% - это не "эта оптимизация занимает", это общая загрузка процессора у меня в ПО, когда обновляется только экран, а других тяжёлых задач не выполняется. Т.е. - включает в себя рисование (немножко) и много других мелких задач, в том числе саму пересылку в SPI. Во-вторых: я писал у меня SCLK=40МГц, соответственно при ваших 20МГц загрузка CPU задачей конвертирования будет в 2 раза ниже. В-третьих: А сколько у вас сейчас %-ов времени занимает рисование? И это рисование во внешней ОЗУ. А у меня - во внутренней ОЗУ. Надеюсь не нужно говорить, что во внутренней ОЗУ рисование может происходить в разы быстрее (во сколько именно - зависит от процедур рисования). Так что общий суммарный результат рисование+конвертирование+пересылка при переходе на внутренюю память с конвертированием может оказаться не то что не медленнее, а даже быстрее чем рисование+пересылка во внешней памяти. Цитата "сомнительная"- потому что не на пустом месте. Нужно дополнительно буфер под DMA, и "почти в два раза" превращается во что? в "почти в полтора раза"? Или предлагается по 1 килобайту гонять и часто отвлекаться на создание буфера? в таком случае нужно будет очень часто в эту низкоприоритетную задачу переходить, тормоза при прорисовки на экране из-за задержек между такими короткими передачами будут видны. У меня - два DMA-буфера по 2 КБ каждый. Берём калькулятор и считаем: 2048*8/(40e+6)=0.4 мсек - это период активации задачи конвертирования. Это что - "часто"? Затраты процессорного времени на переключение задачи - доли процента. Вобщем - опять приводите надуманные мифические проблемы. И что за "тормоза при прорисовки на экране"? О чём речь? И что за "задержки между передачами"? У меня в алгоритме нет никаких задержек между передачами - перечитайте внимательнее мой пост, я там специально на этом акцентировал внимание. Артефакты на экране будут только при вашем подходе, когда стираете, а потом поверх рисуете по-новой, и вас почему-то совсем не смущает что при выводе динамической картинки, нужная картинка на экране будет присутствовать только половину времени, а другую половину - стёртый фон. А в реале - для пользователя будет вообще не смотрибельный результат. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 5 марта, 2020 Опубликовано 5 марта, 2020 · Жалоба 4 hours ago, jcxz said: Вспоминается поговорка про книгу и фигу... Странно - пишу одно, а понимаете совсем другое, такое ощущение, что читали мой пост через слово.... Вы правы. Разговор ни о чем. У каждого свои приоритеты и свое видение проблем и решений. На этой оптимистической ноте предлагаю закончить дискуссию о "книгах и фигах". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 243 6 марта, 2020 Опубликовано 6 марта, 2020 · Жалоба 19 часов назад, Ruslan1 сказал: Вы правы. Разговор ни о чем. У каждого свои приоритеты и свое видение проблем и решений. Вот именно. На вашем месте я первым делом задумался бы зачем: В 05.03.2020 в 12:31, Ruslan1 сказал: У меня сейчас там задач 30 крутится в embedded реалтайм системе на Cortex-M. Которые наверняка расходуют ОЗУ под стек несравнимо больше, чем требует мой метод конвертации дополнительной ОЗУ под промежуточные буфера. Тогда может оказаться что и полный видеобуфер легко влезет во внутреннюю ОЗУ. И вообще - нафига столько независимых задач? Оно реально нужно? Для чего??? Не представляю.... У Вас реально 30 независимых друг от друга процессов? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
