Pull to refresh

Comments 26

UFO just landed and posted this here
Ну вообще, MCU. А в чем именно мощнее? Откуда информация? Просто нигде не видел, а интересно :)
Как минимум в том, что памяти более чем в 140 раз больше. Да и рабочая частота выше где-нибудь на порядок, как мне кажется.

Конечно такое сравнение не совсем уместно, но тем не менее.)
Могу расписать =)
Получаем: 7-ми дюймовый дисплей — скорее всего, 640*480, либо 800*600. Перемножаем: 307200*3 (RGB) = 921600 байт памяти (640*480), либо 1440000 байт (800*600*3).
Теперь, эту картинку нужно разворачивать не медленнее 20-40FPS. Получаем: 921600 * 20~40 = 18432000 (20FPS) или 36864000 (40FPS). Для 800*600 будет ещё больше — 1440000* 20~40 = 28800000 ~ 57600000 байт/с.
А теперь сравним с мегой…
У Вас — ATMega2560 в примере, а это: Max. Operating Freq. (MHz):
16 MHz
Не дотягиваемся даже до минимальной тактовой дисплея. Нет, разогнать можно, но… не настолько :)
Плюс, в дисплее память имеет двойной интерфейс — она не блокируется на чтение при записи — можно писать в любую ячейку памяти во время регенерации картинки.
Примерно, так.

Хм… промахнулся… обидно.
Это был ответ на вопрос автора — «Ну вообще, MCU. А в чем именно мощнее? Откуда информация? Просто нигде не видел, а интересно :)»
Вы всерьез полагаете, что скорость работы контроллера дисплея определяется скоростью регенерации пикселов? Сильное утверждение.
Это минимальная частота работы при условии, что используется DMA, либо аппаратная логика. Например, если использовать оба фронта тактового сигнала, можно опустить частоту вдвое, но в любом случае, контроллер дисплея в узкоспециализированной области опережает любые MCU, умеющие всё, но по чуть-чуть.
Та же история, что между CPU и GPU при обработке графики — ЦП будет скурпулёзно вычислять значения, а GPU просто загонит входные данные в блок расчётов и получит выходные на его выходе. Либо CUDA с конвеерами… и так далее.
Вот насчет FPS я сомневаюсь. Не думаю, что он сможет рисовать 20, а то даже и 40 кадров. Ведь он экран полностью очищает примерно за 0,5 секунды. А разрешение у него — 800x480.
Извиняюсь, но я сравнивал напрямую только «производительность» шины данных и скоростей обмена. Не могу вспомнить ни одного кристалла AVR-8, который бы мог гонять данные с такой скоростью.
И, да, здесь был намёк на скорость регенерации картинки. ЦП захлебнётся. Да и не хватит памяти у него.
Применительно к матрице БЕЗ своего контроллера, AVR её не развернёт. Либо будет дрожание тактирования (и гулять контрастность из-за невыдержанных таймингов), либо картинка будет замирать на время выполнения друхиг операций.
Я просто постарался развить мысль OnYourLips
Развертка формируется аппаратной частью и к скорости контроллера не имеет прямого отношения. Были разработки с прямым синтезом изображения, в том числ для телевизионного сигнала, но для очень небольших разрешений и довольно таки давно.
А вы случайно не знаете — где можно найти сам контроллер для такого дисплея?
У меня завалялся сам дисплей, голый, давно чешутся руки его куда-нибудь пристроить :)
Контроллер, который будет управлять дисплеем, или заниматься регенерацией картинки?
Если первый — то любой программируемый контроллер: AVR-8, PIC, ARM, да что угодно.
Если вторые — то тут нужно искать информацию по дисплею и смотреть, какой контроллер встроен в него. Напрямую с матрицей дисплея трудно иметь дело. С этим справятся разве что специализированные контроллеры ЖКИ с памятью (тот же SSD1306 — простенький, 128*64px, monochrome, или что мощнее), либо встроенные в чип (например, отладочная плата STM32VL-Discovery содержит чип с контроллером ЖКИ, но очень маленького размера).
Я не очень разбираюсь в терминологии(
У меня есть дисплей, из него выходит шлейф, как на картинке, который широкий: i076.radikal.ru/1408/15/217deb61bb2c.png

А хочу я какой-то контроллер, куда я воткну этот шлейф, и к которому можно подключить источник сигнала(AV, VGA).
Неплохой дисплей.
Гугл говорит, что это: '7" inch TFT LCD module 800x480 SSD1963 w/touchpad PWM'
То есть, в нём встроен SSD1963. Datasheet нашёлся. Интерфейс расписан сзади, так что это тем более не проблема.
Думаю, можно даже найти готовые библиотеки.
Дерзайте!
Запустить можно всё!
У самого есть MF-PROTO-BOARD, запущенный на STM32. Где-то даже было фото — тестировал самописную библиотеку.
Скрытый текст

Извиняюсь за качество — фото с телефона. Да и графики были рандомными.
Русский шрифт не получился из-за припадков Kail. Последний сохранял текст как UTF-8, а преобразовывать его силами контроллера в русские символы достаточно неудобно. Потому только английский.


Опять же, если дисплей на плате — всё отлично. Если только сам дисплей со шлейфом… не получится. Ему нунеж готовый сигнал. Предположительно R[8] G[8] B[8], HSync, VSync.
Да, проблема именно в том, что есть только сам дисплей со шлейфом, где бы отдельно плату купить?
Тогда проблема.
Боюсь, что отдельно плата не продаётся. Она именно что в сборе.
А если делать самостоятельно… лично мне плата такого уровня не по зубам, плюс, нужен сам контроллер, который будет управлять дисплеем и управляться со стороны контроллера.
Не спорю, можно развести «кустарно»… но это не стоит того.
А сам дисплей без контроллера почти бесполезен.
Сожалею :(
Вопрос по теме — в библиотеке действительно нет функции записи в контроллер дисплея? Она замаскирована? Или просто не описана в документации?
Посмотрел тексты библиотеки. Правильный ответ — 3 — функция не описана, хотя лежит в паблик секции.
А что касается библиотеки как таковой — двойственное отношение.
С одной стороны автор неплохо продумал архитектуру и настройки, но с другой стороны «Эффективность? — нет, не слышал».
И еще маленькое замечание — использование в одной функции символического имени RS, а в соседней магической константы 38 — это такая фича, типа признак хакинга, или теперь ТАК принято?
Опс, спасибо, что заметили. Забыл совсем) Извините
for (byte i(1); i <= lvl; i++) //Возведение в степень
brightness *= 2;

Подобный код выдает ардуинщиков с головой.
Вы такты считать пробовали? Это же нецелесообразный код — для возведения в квадрат всегда используется сдвиг влево. Я, конечно, понимаю, что при включенных оптимизациях нормальный копилятор это превратит в цикл, но это редко — зачастую оптимизации на МК отключены (в AVRStudio — по умолчанию их нет вообще)…
Ну наверное имелось в виду возведение двойки в степень, если верить коду, тогда его действительно можно заменить сдвигом влево.
А вот что касается возведения в квадрат при помощи сдвига влево — что то новенькое, если вы не имеете в виду реализацию умножения сдвигом и сложением.
А что касается ардуинщиков — это не оскорбление и не диагноз, а всего лишь определенная ступень развития, с которой можно и дальше шагать.
Да, я слышал что-то об этом, даже специально искал в интернете побольше информации, но ничего лучше этого не нашёл, к сожалению. А так, в коде, я возвожу двойку в степень.
Если в ардуино применяется настоящий С, то Ваш фрагмент кода эквивалентен
brightness = 1 << (lvl-1);
и таки да, на НЕКОТОРЫХ архитектурах будет исполняться быстрее, хотя для регулировки яркости дисплея вряд ли критично быстродействие.
Не вижу смысла считать такты до возникновения проблем с производительностью. Говоря образно, нет смысла весь день ходить с напряжённым бицепсом, если тебе от силы пару раз в день нужно поднять рюкзак.
Sign up to leave a comment.

Articles