Во-первых, RAW - это не формат. Так принято обозначать “сырые” данные, не имеющие формата. Обычно - полученные с матрицы фотоаппарата. Но при работе с МК зачастую так называю данные, преобразованные специально для загрузки в дисплей.
Чего же тут странного?
PNG - формат со сжатием, BMP - без сжатия, а RAW тоже сжатия не подразумевает.
16-ричный код - способ представления чисел в виде текста. К изображению никакого отношения не имеет. Поэтому надо радоваться, что ничего не изменилось, значит, не насажали новых ошибок поверх старых.
Нет.
Сжатый файл будет загружаться дольше, так как требуется дополнительное время на распаковку.
Нет.
Устройства поочередно используют “одни и те же пины” при общении с МК.
Т.е. МК сначала считывает некоторую порцию информации себе в память, потом передает ее на экран.
Естественно, есть ряд особенностей:
Если у МК мало памяти, то изображение загружается в память и передается на дисплей по частям.
Если изображение хранится в виде отличающемся от того, какой нужен дисплею, то после считывания с карты и передачей на дисплей изображение преобразуется к нужному виду.
Если тзображение находится в сжатом формате, оно сначала распаковывается.
а вы не стали делать проект дополнительной памяти используя дисплей ? или не получилось ?
часть кода бы посмотреть(подрезать) как обращаться к таким регистрам памяти… читать записывать… желательно не 1но значение, а потоком…
а то psram даже 30 мб мало… а тут может скорость будет приемлема, и пригодится в будущем… например для подключения необычных мк с их памятью, по spi а то ии может выдать не понятно что…
По замыслу sd карта используется как Флеш память для хранения настроек/установок работы терморегулятора, и для хранения фонового изображения и двух индикаторов., таймер будет хранить время внутри себя. Сначала хотел использовать EPROM арлуинку для хранения установленных данных и не использовать sd карту, но потом перечитав кучу всяких примеров и мануалом понял что картинки фонового изображения и индикаторов в EPROM с таким объемом какой получался у меня не залить, и так же хранить изображение в виде пиксельного кода так же не вариант так как объема памяти у ардуины не хватает, переключился на работу с sd картой. Вроде как в разы проще, но все таки не догоняю в каком формате. Хранить изображения на карте. Были сомнения с параллельным подключением одноименных пинов дисплея и sd карты, но благодаря вам все встало на свои места. Осталось собрать тестовую модель и проверить функционал.
Что именно вас интересует в скетче? Какая его часть?
Сейчас корпус печатаю для этого барахла, передняя крышка распечаталась на 60% там где будет стоять дисплей, плата согласования уровней между дисплеем и ардуиной и энкодер для установки режимов работы и настройки режима работы.
Нет, дисплей как память я не думал даже об этом. Если на плате дисплея есть слот под sd решил применить его как стороннюю память для хранения настроек. Даже порывшись в барахла нашел sd карту на 128мб😄 которой должно хватить для хранения фонового изображения иконок и сохранения настроек.
С ESP вообще не работал никогда, по этому и не пытался сразу внедрить ее в проект.
Немножечко забросил. Пришел другой дисплей - у него свои проблемы. Пока с ними разбираюсь.
А по поводу использования свободной части видеопамяти, хоть в теме и есть намек, что это невозможно из-за того, как аппаратно сконфигурирован дисплей, но это не совсем так: можно заставить работать MOSI как MISO. Т.е. информацию можно прочитать с того же пина, который используется для записи. При этом, правда, вместо аппаратного SPI приходится делать его софтверный аналог, работающий в обе стороны через один пин. Информацию из регистров мне так уже удалось считать. А до чтения из памати - не дошел - отвлекся (см. выше).
Да, я тоже пришел к идее блочного устройства. Ориентировочно по 128 байт - как в CP/M-80.
Вообще-то видеопамяти там сотни кбайт, о Мбайтах даже речи не идет.
Чаще всего используется как раз RAW, совпадающий с устройством видеопамяти. Чтобы всю перекодировку возложить на ПК, а на МК этим не заниматься.
Чаще всего в цветных экранах для МК используется 16-разрядный цвет (R:5,G:6,B:5).
Но я как раз сейчас вожусь с дисплеем, который мне пока не удалось заставить работать в этом режиме.
Это может иметь смысл только в случае, когда SPI одновременно используется и из прерывания, и из основного потока.
Можно и так, и так.
На резисторах, вроде, проще, но есть ограничения по частоте. Теоретически. На практике, если Вы используете 5-вольтовый МК, там не те скорости, чтобы это могло сказаться.
это понятно, но я питаю надежду что мне попадется какой то готовый модуль, с объемом памяти несколько мегабайт, где попытаюсь применить часть вашего кода, а может и куплю внешний psram в итоге… но я лентяй просто))), не люблю паять…
Друзья, что то у меня ни чего не получается, установил библиотеки для дисплея UTFT но потом начитавшись всякой ереси поставил библиотеку utft_eSPI типа эта Библия легко переделывает jpg файлы
#include <TFT_eSPI.h> #include <SD.h> но возникли конфликты по подключению пинов.
Мучался целый день, лазил в библиотеках, менял настройки пинов подключения в библиотеке и так ни чего не получилось, все равно ошибка в скетче по назначению пинов.
Сейчас хочу все таки разделить SPI, оставить отдельно для SD card аппаратную SPI, для дисплея выделить программную SPI.
На экране есть слот SD и пины для подключения так что я ни чего там не скрещиваю. А с ESP просто не работал по этому вообще не знаю с какой стороны к ней подходить,
И если это можно реализовать на ардуинке то почему бы и да