Есть 2 сложности: 1) далеко не из всех экранов можно читать. Писать можно во все, а вот линии чтения могут быть даже не разведены на плате. Обратите внимание на распиновки SPI экранов. Как правило там будет пин DI (Data In), он же MOSI (Master Out Slave In). При этом далеко не везде есть DO (Data Out) / MISO (Master In Slave Out). 2) Все было бы просто если бы буфер кадра в микроконтроллере был выведен наружу с помощью шин адреса и данных, тогда бы микроконтроллер мог обращаться к буферу кадра просто как к обычной памяти. На деле для экономии пинов это не так. Скорее всего придется посылать экрану команду на чтение определенной области видеопамяти, а это дополнительные задержки. Опять же, если памяти в микроконтроллере мало, то читать буфер кадра придется по частям, а это еще бОльшие задержки и геморрой. К тому же не у всех экранов вообще есть команды на чтение (например SSD1306, которых валом на али)
Каждая команда для экрана это дорого и долго. Нужно отправить запрос, выдержать тайминги, получить подтверждения. Поэтому обращаться к экрану попиксельно невыгодно, проще организовать процесс общения какими-то блоками, или работать сразу с небольшой частью экрана.
Сходу 2 примера:
1) Вам нужно нарисовать строку из нескольких символов. С буфером кадра внутри микроконтроллера это выглядело бы так: - Для каждого символа скопировать из ПЗУ знакогенератора нужные байты прямо в буфер кадра - Одной командой залить буфер кадра в экран. Поскольку литься он будет сравнительно долго можно организовать фоновую передачу и отправить микроконтроллер заниматься другими задачами или просто спать.
Без буфера кадра это будет выглядеть так: - Для каждого символа дать экрану команду выставить viewport - выделить в микроконтроллере маленький буфер кадра для одного символа, переложить данные из ПЗУ знакогенератора в этот буфер кадра - Залить буфер одного символа в экран. - Повторить
Посмотрите видосы по подключению экранов к ардуине. Там прямо видно как картинки рисуются посимвольно и по линиям.
Тут нужно учитывать, что символы (особенно если они большие) занимают много места в ПЗУ и выгодно применять какие нибудь простейшие алгоритмы сжатия. Поэтому часто не получится копировать пиксели символов напрямую из ПЗУ в экран. И даже если символы не запакованы, скорее всего они будут монохромные, тогда как в экран нужно будет заливать в цвете, а значит все равно нужна будет некая конвертация.
Можно, конечно, избежать перепаковки/перекодирования цвета, но это будет достигаться ценой увеличения размера прошивки. В случае АТМеги это может быть слишком жирно.
2) Вам нужно нарисовать текст поверх картинки, которая уже есть на экране. Чтобы в дырках букв просвечивался старый фон, придется либо рисовать попиксельно (что как я уже сказал слишком дорого/долго), либо сначала вычитать из экрана необходимую область в микроконтроллер, быстро нарисовать что нужно, и залить назад в экран.
С буфером кадра в микроконтроллере никаких проблем нет - можно рисовать как угодно и в каком угодно порядке. Можно накладывать изображения друг на друга с разными режимами наложения и смешивания цветов.
Впрочем для вашего информатора все эти оптимизации не обязательны. У Вас информация будет обновляться редко и хватит даже если кадр будет рисоваться полсекунды посимвольно.
Я не про масштабирование, а про распаковку символов. Масштабирование средствами микроконтроллера будет выглядеть некрасиво - проще заранее все отмасштабировать и положить в прошивку. А рисовать линиями... Я думаю ардуиновские библиотеки примерно так и делают
Давненько я не программировал. Лет 15 уже. Вот и интересуюсь, может, проще в Ардуинке не распаковывать символы, а просто рисовать линиями их? Надо ведь буквально несколько цифр изобразить
1) далеко не из всех экранов можно читать. Писать можно во все, а вот линии чтения могут быть даже не разведены на плате. Обратите внимание на распиновки SPI экранов. Как правило там будет пин DI (Data In), он же MOSI (Master Out Slave In). При этом далеко не везде есть DO (Data Out) / MISO (Master In Slave Out). 2) Все было бы просто если бы буфер кадра в микроконтроллере был выведен наружу с помощью шин адреса и данных, тогда бы микроконтроллер мог обращаться к буферу кадра просто как к обычной памяти. На деле для экономии пинов это не так. Скорее всего придется посылать экрану команду на чтение определенной области видеопамяти, а это дополнительные задержки. Опять же, если памяти в микроконтроллере мало, то читать буфер кадра придется по частям, а это еще бОльшие задержки и геморрой. К тому же не у всех экранов вообще есть команды на чтение (например SSD1306, которых валом на али)
Каждая команда для экрана это дорого и долго. Нужно отправить запрос, выдержать тайминги, получить подтверждения. Поэтому обращаться к экрану попиксельно невыгодно, проще организовать процесс общения какими-то блоками, или работать сразу с небольшой частью экрана.
Сходу 2 примера:
1) Вам нужно нарисовать строку из нескольких символов.
С буфером кадра внутри микроконтроллера это выглядело бы так:
- Для каждого символа скопировать из ПЗУ знакогенератора нужные байты прямо в буфер кадра
- Одной командой залить буфер кадра в экран. Поскольку литься он будет сравнительно долго можно организовать фоновую передачу и отправить микроконтроллер заниматься другими задачами или просто спать.
Без буфера кадра это будет выглядеть так:
- Для каждого символа дать экрану команду выставить viewport
- выделить в микроконтроллере маленький буфер кадра для одного символа, переложить данные из ПЗУ знакогенератора в этот буфер кадра
- Залить буфер одного символа в экран.
- Повторить
Посмотрите видосы по подключению экранов к ардуине. Там прямо видно как картинки рисуются посимвольно и по линиям.
Тут нужно учитывать, что символы (особенно если они большие) занимают много места в ПЗУ и выгодно применять какие нибудь простейшие алгоритмы сжатия. Поэтому часто не получится копировать пиксели символов напрямую из ПЗУ в экран. И даже если символы не запакованы, скорее всего они будут монохромные, тогда как в экран нужно будет заливать в цвете, а значит все равно нужна будет некая конвертация.
Можно, конечно, избежать перепаковки/перекодирования цвета, но это будет достигаться ценой увеличения размера прошивки. В случае АТМеги это может быть слишком жирно.
2) Вам нужно нарисовать текст поверх картинки, которая уже есть на экране. Чтобы в дырках букв просвечивался старый фон, придется либо рисовать попиксельно (что как я уже сказал слишком дорого/долго), либо сначала вычитать из экрана необходимую область в микроконтроллер, быстро нарисовать что нужно, и залить назад в экран.
С буфером кадра в микроконтроллере никаких проблем нет - можно рисовать как угодно и в каком угодно порядке. Можно накладывать изображения друг на друга с разными режимами наложения и смешивания цветов.
Впрочем для вашего информатора все эти оптимизации не обязательны. У Вас информация будет обновляться редко и хватит даже если кадр будет рисоваться полсекунды посимвольно.
Reply
Reply
Reply
Масштабирование средствами микроконтроллера будет выглядеть некрасиво - проще заранее все отмасштабировать и положить в прошивку.
А рисовать линиями... Я думаю ардуиновские библиотеки примерно так и делают
Reply
Вот и интересуюсь, может, проще в Ардуинке не распаковывать символы, а просто рисовать линиями их? Надо ведь буквально несколько цифр изобразить
Reply
Leave a comment