- monobogdan
- Постоялец
=A=L=X=
> Во вторых у него разрешение 240x240, но на самом деле VRAM больше по моему на 240x320, просто отображается кусочек 240x240.
Контроллер 240x320, ни больше, ни меньше, буфер кадра тоже под 240x320. Можно включить Partial mode и заюзать аппаратный скроллинг, эта фишка использовалась на некоторых телефонах.
=A=L=X=
> труколора
Это 24-х битный цвет ;) Контроллер держит только 262к, что всё же лучше чем 65к.
=A=L=X=
> Adafruit_GFX это вроде бы изначальная унифицированная библиотека по работе с разными дисплеями, но в итоге получается иногда существенная разница.
Для твоих целей это хрень полная, говнокод. Пиши свою граф. либу и драйвер дисплея, это не сложно.
=A=L=X=
> Надеюсь шина SPI справится с 20-30 кадрами в секунду...
Легко. Смотри:
https://i.imgur.com/RLyUkJ6.mp4
Но на видео RP2040, а для заливки фб в дисплей используется DMA, то есть процессор разгружен для блиттинга и формирования нового кадра.
Поскольку у ATMega328p не хватит ОЗУ для хранения ФБ, реализуй концепцию PPU - она не только сэкономит раму, но возможно поможет оптимизировать рисование на дисплей.
Подели дисплейную поверхность на два слоя: фон и спрайты. Для фонов используй классику - один супер-селектор, который выбирает страницу с фоновыми тайлами в памяти (т.е tiles[TileSelector * 16 + tileNumber] плюс линейная 4х-битная сетка. Если тайлы размером в 32x32, то на дисплей поместится 8 * 10 тайлов. Умножаем это значение на два, дабы зарезервировать немного ячеек для скроллинга и получаем дескриптор фона, помещающийся всего в 80 байт.
Как сделать спрайты - более чем очевидно, достаточно лишь линейного списка с массивом индексов в дескрипторе этих самых спрайтов. Можно сделать так:
4-5 битов на номер спрайта
1 флаг коллизий (как в NES)
1 флаг отражения по вертикали
1 флаг отражения по горизонтали.
Сколько будет жор памяти - зависит уже от тебя, но думаю буквально 20 байт для скролл-шутера ;)
Можно ещё дополнительный слой для текста сделать, шрифты экономнее хранить в 1-битном формате.
Если спрайты около-произвольного размера, не храни "боковые" прозрачные пиксели вообще. Ограничься массивом начальной и конечной позиции для каждого сканлайна, которую затем будешь прибавлять к координате X при блиттинге. Теоретически позволяет сэкономить и такты микроконтроллера, если SetWriteRect быстрее, чем заполнение одного сканлайна спрайта. Сэкономишь прям нормально оперативки. Кроме того, с таким способом можно вообще не реализовывать PPU и рисовать спрайты и фон на дисплей on-demand: то есть ты рисуешь сначала фон, затем спрайт. Поскольку у тебя нет возможности узнать цвет текущего пикселя на дисплее, ты сразу пропускаешь прозрачные пиксели, а для промежуточных просто делаешь перескок с помощью SetWriteRect на один X вперед.
Короче оптимизаций масса. Можем покумекать над этой темой ещё, если тебе интересно, я то давно хотел сделать свою консоль :)
monobogdan
Я эти прикалдески на базе ESP32 делаю, поэтому там нет проблем с ОЗУ:
Снизу как раз вот это "второе поколение" с хайколором экраном.
Смысл изначально был на самом деле как тестовая платформа чтобы подключать к ней разное и на неё же навешивать.
Но сейчас просто увлёкся таким побочным ответвлением что можно выводить игру на первый дисплей монохромную - и вот уже не заметил как второй полноцветный собираю.
Но реально писать игры конечно же не буду.
Ну ты конечно напугал меня. Я то думал реально игры писать будет. Я для своей написал, целых две - змейку и шутер))
Если посмотреть внимательно на фото обеих BrokenICE, то можно заметить проблему.
Когда я для нижней BrokenICE 2 спаял батарейный отсек, то провод оказался слишком короток чтобы расположить микроконтроллер вертикально как у BrokenICE 1. Пришлось поэтому МК прижать к батарейному отсеку и расположить горизонтально.
И вот уже видна заминка на с BrokenICE 2 - как пустить провода от стика? Они непременно залезут под руки и будут мешаться.
А если добавить две кнопки как у BrokenICE 1, то и вовсе получится полный бардак.
Поэтому пришлось провести мозговой штурм и признать неизбежное - этот дизайн зафейлился.
На самом деле он зафейлился еще до того - я планировал на BrokenICE 2 сделать "универсальную платформу" настрочив мелких дырок которые по необходимости можно расширять рассверливанием, но если присмотреться, то видно что в итоге я кусачками выдирал целые блоки чтобы пропускать провода и выглядит, да и пусконалаживается это стрёмно.
Поэтому со всей осознанностью назрела необходимость полного редизайна. И я принял этот вызов.
А что если сделать уже полноценный корпус - с верхней и нижней крышками и заранее наделать нужных дырок там где надо?
И таки да - тут FreeCAD не подкачал - тут я впервые ощутил, за всё это время, что FreeCAD крут - делать пластины с дырками в нём одно удовольствие - просто и элегантно накидываешь 2D примитивы и расставляешь между ними ограничения - т.е. например что центр одной дырки отстоит по горизонтали на 11 мм от центра другой дырки и т.п. - легко, элегантно и практично.
Итак, BrokenICE 2 родился во всём своём величии:
Гранд-беллисимо, кирпичный перфекционизм, изысканность в деталях и совершенство дизайна - вот что это!
=A=L=X=
> изысканность в деталях и совершенство дизайна
=A=L=X=
> Ну как видео... получив поток кадров с камеры я прикинул, что несжатые мегабайты 1920x1024 в сеть просто не пролезут, поэтому надо жать.
> Сжал категорично - сперва снизил разрешение самого preview mode до 640x480 и потом сжал его в JPEG с качеством 85% и сбрасываю кадры сии по сокету в управляющий ноутбук.
Лол, оказывается я переизобрёл https://ru.wikipedia.org/wiki/MJPEG
Сейчас когда консультировался у Deepseek как всё-таки какой нибудь H264 замутить он открыл мне глаза на это.
Купил я себе, для экспериментов, плату OrangePi One 3... ну это прям другой уровень, в сравнении с Arduino и ESP32. Ставим на SD карточку нормальный Linux/Android и можно писать программы нормальным С/С++ компилятором с нормальными библиотеками,... причём, при некоторой упоротости, прямо на самом девайсе и компилировать, подключившись по SSH. Гребёнка с GPIO присутствует. Аналоговых пинов нет, но это компенсируется внешним модулем АЦП по типу ADS1115 Один только недостаток, беспроводных интерфейсов нет, нужна другая модификация платы, либо воткнуть в usb свисток с BT/WiFi
0iStalker
У меня то как раз мысль шла с противоположного пути - зачем мне всяческие пи, если сам то девайс уже есть - устаревший смартфон. Это сразу фарш из всего и по сравнению с пи высочайшего качества обвешенный абсолютно всем кроме собственно пинов.
Поэтому в качестве мозгов использовать его, а в качестве пинов - тупейший Uno с 2 Кб оперативной памяти как раз интересно.
0iStalker
И че, как, балдеешь уже с spidev и экспортами GPIO в sysfs?
В соседней теме уже отписался, что уже пришёл и заработал намного более размерный физически дисплей с контроллером SSD1309:
Т.е. это всё такой же монохром 128x64 с такой же раскладкой видеопамяти, но больше физически плюс немного более навороченный контроллер чем был первый мой дисплей SSD1306 в этой теме.
Что прикольно - он уже работает по протоколу SPI.
А точнее вот как - он может работать ажно в четырёх существенно разных режимах передачи данных:
- параллельный 6800
- параллельный 8080
- серийный I2C
- серийный SPI
при этом параллельные интерфейсы отягощены разной битностью шины (хотя вроде как физически представлена только 8-битная), но серийный SPI еще может работать в двух вариантах - 3 провода и 4 провода (с сигналом DC) и по умолчанию чип распаян именно в последнем режиме.
Чтобы сменить режимы надо перепаивать управляющие резисторы на плате.
Так вот SPI интерфейс это изначально 4-проводной интерфейс - в нём (помимо земли!) четыре провода:
- MOSI (master out, slave in)
- MISO (master in, slave out) - физически в SSD1309 отсутствует, т.к. дисплей ничего в МК не передаёт, однако на МК аппаратный SPI получается что просто не может использовать свой контакт для других целей
- CLCK - синхронизирующий импульс
- CS - chip select - если устройство единственное и соблюдает некоторые принципы, то может отсутствовать.
И вот глядя на эту схему вы могли бы предположить, что раз MISO физически нет, то SPI в SSD1309 он же как бы изначально 3-проводной. А про какие 4 провода тогда шла выше речь?
Так вот оказывается тут действительно помимо протокола SPI на самом деле вводится еще один управляющий провод - DC (Data/Command) - и де факто протокол обмена между МК и SSD1309 это не SPI, а SPI с блекджеком - SPI+DC.
А нахрена это нужно? А потому что какой бы физический интерфейс не использовался, но де факто контроллер дисплея принимает на входе 9-битные порции ввода в которых 9-ый бит означает команду или данные мы в этой порции отправили в контроллер.
Байты данных просто сразу по оговоренным правилам заливаются в видеопамять, а байты команд (их может быть несколько подряд по протоколу) исполняют какие то настройки контроллера.
Вот так вот - и по умолчанию схема распаяна под SPI+DC - в конце каждой серийной передачи 8 бит через SPI с контакта DC снимается верхний 9-ый бит для внутренного формата.
Собственно режим "SPI - 3 провода" это когда передаются через SPI в порции именно все 9 бит и тогда пин DC становится не нужен.
Неожиданно. Получается что если аппаратный SPI и использовать, то его надо использовать аккуратно - если бит DC между длинными передачами меняется, то надо приостанавливаться, ждать пока выходной буфер опустошится, менять значение на DC и продолжать следующие передачи где он должен быть таким.
Хм. Интересный компромисс.
У ESP32 вот что что, но есть неприятная черта - контактов вроде и много, как у классических ардуин с AVR, но добрая треть "с особенностями".
Например пины 2 и 4 которые я заюзал в видео выше вроде и можно использовать, но при загрузке девайса они как то зачем то анализируются загрузчиком и если на них не тот уровень сигнала с загрузкой что-то может пойти не так.
И действительно с этим дисплеем идёт не так - прошивка не может войти в режим перепрошивки. Только отсоединив пин 4 от дисплея получается перепрошить МК.
При этом, ЧСХ на другом цветном дисплее (но микроскопического размера) по теме выше я использовал именно такое же подключение и там проблемы не было - тот контроллер дисплея почему то не выставляет на этих ножках чего то не того.
Надо будет ножки переставлять чтобы перепрошивка не сбивалась - и вот да, с ESP32 надо быть к подобному готовым и кидать такие контакты только на какие то пассивные штуки типа кнопок и вот в соответствии с тем что там допустимо а что не допустимо при загрузке иметь на входе.
И есть точно то же самое с выходами - опять таки за каким то хреном загрузчик при загрузке зачем то на некоторые ножки выводит шимованный сигнал непонятного мне в данный момент назначения - опять таки надо иметь ввиду и не подключать к таким ножкам что-то что может сойти с ума от этой особенности.
=A=L=X=
Может их стоит подтянуть к массе или плюсу?
Вроде как через код даже это можно на esp делать.
master-sheff
Да просто перекинуть на другие роги, а эти использовать надо чем то что по умолчанию подтяуто к нулю.
=A=L=X=
Загугли как работают подтяжки на выходах GPIO, вопросов не останется.