Этих конверторов как говна за баней. Когда мне понадобился - один запрос к гуглу всё решил. Там выбирать затрахаешься. Я, правда, не выбирал - взял из первого результата поиска Image2Lcd, он закрыл мою потребность а больше мне от него ничего не нужно. Можете попробовать.
(выделено мною)
Вот-вот. Поэтому я предпочитаю писать сам, чем сначала искать в Гугле, потом выбирать, а потом еще и проверять... IMHO быстрее выходит.
конвертер картинок в массивы к библиотекам не помешал бы). Авторам написал, но вряд ли ответят.
Этих конверторов как говна за баней. Когда мне понадобился - один запрос к гуглу всё решил. Там выбирать затрахаешься. Я, правда, не выбирал - взял из первого результата поиска Image2Lcd, он закрыл мою потребность а больше мне от него ничего не нужно. Можете попробовать.
Эту как раз мимо пропустил. Перепробовал несколько, вроде нашёл даже под данный тип экрана, но код генерит - одни 11111. Пользуюсь вот этим :
Да, ладно Вам. Я скачал первый, что попался. Запустил. Он мне картинку в массив перегнал, только запятую в конце лишнюю поставил. Меня вполне устроило.
Я не напишу. Что ЕвгенийП предложил работает, но пока краказябры-фарш (способа сканирования не подберу) из рисунка на экране. А тема о том, что к хорошо разжёванным библиотекам под экраны чуток добавить конкретных конвертеров. Такие варианты есть, но к другим библиотекам (нытьё в чистом виде-факт!).
После забавных попыток-краказябров я таки попал настройками (а их много) в правильное сканирование картинки под экранчик. Но вот фокус - на экранчике картинка в инверсных цветах. То есть либо автор конвертера, либо библиотеки что-то напутал (себя я исключаю :))
Что означает Antitone pixel in byte (переводчик ясности не внёс)?
Да, видимо порядок укладки бит в байт при сканировании (от 0b или к 0b).
32 варианта сканирования в конвертере по расположению "обрывков" картинки в массиве - это дань творчеству авторов библиотек или производителей экранов-дисплейчиков?
А всё таки в языке, применительно для Ардуино, нет возможности работать с битовыми строками-полями, минуя понятие байт? Вроде bit massiv []={011001100110010111010...} (но именно бит, а не байт) по типу:
А всё таки в языке, применительно для Ардуино, нет возможности работать с битовыми строками-полями, минуя понятие байт? Вроде bit massiv []={011001100110010111010...} (но именно бит, а не байт) по типу:
Почему нет? Есть. И описание с примерами есть на этом форуме.
Так нагляднее и проще писателю : понятный один способ сканирования-воспроизведения на экран, визуализация картинки в массиве. Ведь замена 0х00, на 00000000 раздувает массив не очень. Другой вопрос - скорость прорисовки на экране и одноцветность рисунка.
Простой вопрос. Зачем визаулизировать массив в программе? Есть же конвертор, который показывает картинку. Если уж очень хочется видить, сохраните картинку рядом с программой. И смотрите когда надо. Всё равно в скомпилированной прошивке картинка будет перекорёжена и её не возможно будет идентифицировать. А видеть картинку в программе это блажь. Она уходит с экрана, как только переходишь к тексту программы. Какая разница - всё равно крутить экран. А хекс вместо бин существенно сократит длину программного кода.
Ну, вроде разобрался - библиотек для текста и вывода картинок много, конвертеров тоже, в МК можно записать больше десятка изображений (хранить в соседнем ino - визуализация лишнее). Даже фотка давняя моя - узнаваема :)
Интересно, а как с 3д графикой для Ардуино? Искал готовые, разжёванные библиотеки - их нет. Наткнулся на интересный вариант:
3D-графика, Ардуино и быстро - вещи несовместимые.
ESP/STM по идее "каркасную" псевдо-3D должны потянуть. Помню, "каркасные" Т-72 и прочие БРДМ очень бодро на 286-й машине шпыняли Абрамса)) Да и Elite на Z80...
Разобрался. Рисуем модель как обычно. Авторский конвертер сам превратит её в каркасную и выдаст скетч.
Хочу чуть модернизировать вариант автора- добавить управление приближением-удалением к модели, осями вращения и его направлением, добавить массивов моделей - несколько вместо одной. Хватит ресурса УНО? Сейчас 42 процента памяти и 81 динамической использует. Есть ли конвертеры отдельные для преобразования obj или stl в массивы, используемые автором? Прилично у него спросить, почему не сделал библиотеку (товарищ из-за рубежа)?
Забавно: stl файлы тоже берёт конвертер его, но ругается и вместо скетча выдаёт тхт с его текстом.
Автор ответил-пока делать библиотеку желания не имеет. А жаль, мне кажется по наивности, он смог бы впихнуть и шрифты, и графику 2D, 3D. Библиотек таких хороших ведь нет :(
Была такая шальная мысль :) Но расценки за рубежом большие, наверное, + настоящего художника обидеть деньгами можно. А так, в складчину, ежели для всех библиотека - 500 р. могу без щекотки отдать.
Отложил пока 3D анимацию (до появления публичной библиотеки), пробую OLED_I2C для анимации картинок (она вроде визуально шустрее). Как двигать картинку вдоль, поперёк, наискосок понял. А как удалять-приближать к наблюдателю, поворачивать на угол хотя бы относительно оси Z?
Тогда ищите всех, кому ещё (кроме Вас), это нужно и складывайтесь.
Я вот не вижу смысла в такой библиотеке :-(
Нет, не отдельная библиотека, а как опция к текстовым и 2Д картиночным функциям "обычных" библиотек. Вот в этой, что я выше упомянул есть пример с 3D кубом, но это явно единичный случай. Хотя это наверное желание впихнуть невпихуемое в одно целое.
А так, я уже до 1000р созрел для коллективного разума )))
Просто вот, например, хочется жучка по экрану, что бы бегал под разными углами, а в функции myOLED.drawBitmap(0, 0,foto_A, 32, 32); нет аргумента - угол поворота картинки (((
Просто вот, например, хочется жучка по экрану, что бы бегал под разными углами, а в функции myOLED.drawBitmap(0, 0,foto_A, 32, 32); нет аргумента - угол поворота картинки (((
Просто вот, например, хочется жучка по экрану, что бы бегал под разными углами, а в функции myOLED.drawBitmap(0, 0,foto_A, 32, 32); нет аргумента - угол поворота картинки (((
Вы когда-нибудь слышали такой термин - спрайтовая анимация.
Да, так примерно и задумывал, но хотелось в рамках функций библиотеки спрайт не только поступательно двигать, а и вращать, уменьшать-увеличивать на экране.
Да, так примерно и задумывал, но хотелось в рамках функций библиотеки спрайт не только поступательно двигать, а и вращать, уменьшать-увеличивать на экране.
Спрайт не нужно вращать (на угол отличный от кратных 90), и увеличивать-уменьшать.
И потом, спрайтовая анимация - слишком специфичная область, чтобы ее включать в универсальную библиотеку.
Ну вот вставил я гифку жука в экранчик. Пробегает он мимо. Но в библиотеке не нашёл и вращение спрайта даже на 90 градусов (( А хотелось имитации жука в банке (сейчас дети начнут майских жуков насмерть рассматривать, как они копошатся)... Получается новый комплект картинок подгружать в скетч.
#include <Wire.h>//Подключаю библиотеку протокола I2C.
extern char glaza_A[];
extern char glaza_B[];
extern char glaza_C[];
extern char glaza_D[];
extern char glaza_F[];
//////////////////////////////////////////////////////////////////////
//Предварительно создам функции ввода команд и данных в дисплей.
void oledCommand(int comm) {
Wire.beginTransmission(0x3C);//Начинаем передачу команд устройству с адресом 0x3C.
Wire.write(0x00);//Сообщаем дисплею, что следующее передаваемое значение - команда.
Wire.write(comm);//Передаем команду.
Wire.endTransmission();//Завершаем передачу данных.
}
///////////////////////////////////////////////////////////////////////
void oledData(int data) {
Wire.beginTransmission(0x3C);//Начинаем передачу данных устройству с адресом 0x3C.
Wire.write(0x40);//Сообщаем дисплею, что следующее передаваемое значение - данные, которые необходимо вывести на дисплей.
Wire.write(data);//Передаем данные.
Wire.endTransmission();//Завершаем передачу данных.
}
/////////////////////////////////////////////////////////////////////
void setup() {
Wire.begin();
//процесс инициализации частично команды необязательны, т.к. имеют выбранное значение после RESET
oledCommand(0xAE);//выключение дисплея
oledCommand(0xD5);// Частота обновления экрана
oledCommand(0x80);
oledCommand(0xD3);// Смещение изображения на дисплее (Offset)
oledCommand(0x0);
oledCommand(0x40);
oledCommand(0x8D);//включение емкостного умножителя
oledCommand(0x14);
oledCommand(0x20);//настройка адресации
oledCommand(0x00);// 0х00 для горизонтальной, 0х01 для вертикальной, 0х02 для постраничной адресации
oledCommand(0xA1);//отражение по горизонтали, для отображения справа налево необходимо использовать команду 0xA0
oledCommand(0xC8);//отражение по вертикали, 0xC0 для переворота изображения по вертикали.
//Одновременное использование команд 0xC8 и 0xA1 или 0xA0 и 0xC0 позволяет повернуть изображение на 180 градусов.
oledCommand(0xDA);
oledCommand(0x12);
oledCommand(0x81);//установка контрастности дисплея
oledCommand(0xCF);
oledCommand(0xD9);
oledCommand(0xF1);
oledCommand(0xDB); // установка Vcomh(влияет на яркость)
// oledCommand (0x30); // 0x00 - 0,65Vcc; 0x20 - 0,77Vcc; 0x30 - 0,83Vcc
oledCommand(0x40);
oledCommand(0xA4);
oledCommand(0xA6);//инверсия дисплея, 0xA6 для отключения инверсии, 0xA7 для включения инверсии цвета.
oledCommand(0xAF);//включение дисплея
Wire.setClock( 400000L );
}
void loop() {
// сценарий анимации глаз
for (int i = 0; i < 1024; i++){oledData(pgm_read_byte(&glaza_A[i]));}delay(500);//ВПРАВО
for (int i = 0; i < 1024; i++){oledData(pgm_read_byte(&glaza_C[i]));}delay(2000);//ЦЕНТР
for (int i = 0; i < 1024; i++){oledData(pgm_read_byte(&glaza_B[i]));}delay(500);//ВЛЕВО
for (int i = 0; i < 1024; i++){oledData(pgm_read_byte(&glaza_C[i]));}delay(2000);//ЦЕНТР
for (int i = 0; i < 1024; i++){oledData(pgm_read_byte(&glaza_D[i]));}delay(500);//ВНИЗ
for (int i = 0; i < 1024; i++){oledData(pgm_read_byte(&glaza_C[i]));}delay(2000);//ЦЕНТР
for (int i = 0; i < 1024; i++){oledData(pgm_read_byte(&glaza_F[i]));}delay(500);//ЗАКРЫТЬ
for (int i = 0; i < 1024; i++){oledData(pgm_read_byte(&glaza_C[i]));}delay(2000);//ЦЕНТР
//
}
Пробую экран-мордашку без библиотек с буфером-дублем экрана в озу - чтобы в про мини 168 всё влезало. С анимацией понятно. Возникает вопрос с 33 строкой - как она работает? Как смещать спрайт-картинку вверх-вниз, влево-вправо? Все ссылаются на даташит, но процедуры работы команды не поясняют. Может кто это уже делал?
Этих конверторов как говна за баней. Когда мне понадобился - один запрос к гуглу всё решил. Там выбирать затрахаешься. Я, правда, не выбирал - взял из первого результата поиска Image2Lcd, он закрыл мою потребность а больше мне от него ничего не нужно. Можете попробовать.
(выделено мною)
Вот-вот. Поэтому я предпочитаю писать сам, чем сначала искать в Гугле, потом выбирать, а потом еще и проверять... IMHO быстрее выходит.
конвертер картинок в массивы к библиотекам не помешал бы). Авторам написал, но вряд ли ответят.
Этих конверторов как говна за баней. Когда мне понадобился - один запрос к гуглу всё решил. Там выбирать затрахаешься. Я, правда, не выбирал - взял из первого результата поиска Image2Lcd, он закрыл мою потребность а больше мне от него ничего не нужно. Можете попробовать.
Эту как раз мимо пропустил. Перепробовал несколько, вроде нашёл даже под данный тип экрана, но код генерит - одни 11111. Пользуюсь вот этим :
https://www.dcode.fr/binary-image
Да, соглашусь пожалуй, но конвертер картинок в массивы к библиотекам не помешал бы). Авторам написал, но вряд ли ответят.
так напишите сами...
А то не понятно, о чем тема, нытье одно - это не подходит, то не устраивает...
Я не напишу. Что ЕвгенийП предложил работает, но пока краказябры-фарш (способа сканирования не подберу) из рисунка на экране. А тема о том, что к хорошо разжёванным библиотекам под экраны чуток добавить конкретных конвертеров. Такие варианты есть, но к другим библиотекам (нытьё в чистом виде-факт!).
После забавных попыток-краказябров я таки попал настройками (а их много) в правильное сканирование картинки под экранчик. Но вот фокус - на экранчике картинка в инверсных цветах. То есть либо автор конвертера, либо библиотеки что-то напутал (себя я исключаю :))
Что означает Antitone pixel in byte (переводчик ясности не внёс)?
Галочку "Reverse color" попробуйте
"Anti tone", видимо "инверсия".
Там же есть галка "Reverse color". Это разве не инверсия цвета?
"Anti tone", видимо "инверсия".
Нет, если её снять картинка ломается, а цвет остаётся (судя по просматриваемым обрывкам фарша на экране)
Там же есть галка "Reverse color". Это разве не инверсия цвета?
Да, с галочкой цвет меняется - в конвертере на чёрный фон (рисунок справа), а на экране на белый.
"Anti tone", видимо "инверсия".
Да, видимо порядок укладки бит в байт при сканировании (от 0b или к 0b).
32 варианта сканирования в конвертере по расположению "обрывков" картинки в массиве - это дань творчеству авторов библиотек или производителей экранов-дисплейчиков?
А всё таки в языке, применительно для Ардуино, нет возможности работать с битовыми строками-полями, минуя понятие байт? Вроде bit massiv []={011001100110010111010...} (но именно бит, а не байт) по типу:
bool massiv []={0,1,1,0,0,0,1...}
А всё таки в языке, применительно для Ардуино, нет возможности работать с битовыми строками-полями, минуя понятие байт? Вроде bit massiv []={011001100110010111010...} (но именно бит, а не байт) по типу:
Почему нет? Есть. И описание с примерами есть на этом форуме.
Я одного не пойму - НАЮХА?
Так нагляднее и проще писателю : понятный один способ сканирования-воспроизведения на экран, визуализация картинки в массиве. Ведь замена 0х00, на 00000000 раздувает массив не очень. Другой вопрос - скорость прорисовки на экране и одноцветность рисунка.
По мне так вполне себе даже колхозный способ решает проблему примерной визуализации в массиве:
Простой вопрос. Зачем визаулизировать массив в программе? Есть же конвертор, который показывает картинку. Если уж очень хочется видить, сохраните картинку рядом с программой. И смотрите когда надо. Всё равно в скомпилированной прошивке картинка будет перекорёжена и её не возможно будет идентифицировать. А видеть картинку в программе это блажь. Она уходит с экрана, как только переходишь к тексту программы. Какая разница - всё равно крутить экран. А хекс вместо бин существенно сократит длину программного кода.
Ну, вроде разобрался - библиотек для текста и вывода картинок много, конвертеров тоже, в МК можно записать больше десятка изображений (хранить в соседнем ino - визуализация лишнее). Даже фотка давняя моя - узнаваема :)
Интересно, а как с 3д графикой для Ардуино? Искал готовые, разжёванные библиотеки - их нет. Наткнулся на интересный вариант:
https://drububu.com/miscellaneous/tiny_devices/index.html
Каким инструментом можно быстро нарисовать каркасную 3Д модель? Сам пользуюсь только "Опенскадом", мне хватает для печати и моделирования.
Интересно, а как с 3д графикой для Ардуино? Искал готовые, разжёванные библиотеки - их нет. Наткнулся на интересный вариант:
https://drububu.com/miscellaneous/tiny_devices/index.html
Каким инструментом можно быстро нарисовать каркасную 3Д модель? Сам пользуюсь только "Опенскадом", мне хватает для печати и моделирования.
3D-графика, Ардуино и быстро - вещи несовместимые.
3D-графика, Ардуино и быстро - вещи несовместимые.
ESP/STM по идее "каркасную" псевдо-3D должны потянуть. Помню, "каркасные" Т-72 и прочие БРДМ очень бодро на 286-й машине шпыняли Абрамса)) Да и Elite на Z80...
"Помню" - это хорошо. А помните, были ли в этих 286 еще и 287?
Разобрался. Рисуем модель как обычно. Авторский конвертер сам превратит её в каркасную и выдаст скетч.
Хочу чуть модернизировать вариант автора- добавить управление приближением-удалением к модели, осями вращения и его направлением, добавить массивов моделей - несколько вместо одной. Хватит ресурса УНО? Сейчас 42 процента памяти и 81 динамической использует. Есть ли конвертеры отдельные для преобразования obj или stl в массивы, используемые автором? Прилично у него спросить, почему не сделал библиотеку (товарищ из-за рубежа)?
Забавно: stl файлы тоже берёт конвертер его, но ругается и вместо скетча выдаёт тхт с его текстом.
Переделал код в части loop, для примера 5 моделек в скетче их просмотра заняли чуть более 60 процентов.
Автор ответил-пока делать библиотеку желания не имеет. А жаль, мне кажется по наивности, он смог бы впихнуть и шрифты, и графику 2D, 3D. Библиотек таких хороших ведь нет :(
Так Вы можете инвестировать в хорошую библиотеку, оплатив труд автора.
Была такая шальная мысль :) Но расценки за рубежом большие, наверное, + настоящего художника обидеть деньгами можно. А так, в складчину, ежели для всех библиотека - 500 р. могу без щекотки отдать.
Отложил пока 3D анимацию (до появления публичной библиотеки), пробую OLED_I2C для анимации картинок (она вроде визуально шустрее). Как двигать картинку вдоль, поперёк, наискосок понял. А как удалять-приближать к наблюдателю, поворачивать на угол хотя бы относительно оси Z?
Тогда ищите всех, кому ещё (кроме Вас), это нужно и складывайтесь.
Я вот не вижу смысла в такой библиотеке :-(
Я вот не вижу смысла в такой библиотеке :-(
библиотека хорошая... но денег не дам
библиотека хорошая... но денег не дам
Ну, да, как у Михаила Афанасьевича
Тогда ищите всех, кому ещё (кроме Вас), это нужно и складывайтесь.
Я вот не вижу смысла в такой библиотеке :-(
Нет, не отдельная библиотека, а как опция к текстовым и 2Д картиночным функциям "обычных" библиотек. Вот в этой, что я выше упомянул есть пример с 3D кубом, но это явно единичный случай. Хотя это наверное желание впихнуть невпихуемое в одно целое.
А так, я уже до 1000р созрел для коллективного разума )))
Просто вот, например, хочется жучка по экрану, что бы бегал под разными углами, а в функции myOLED.drawBitmap(0, 0,foto_A, 32, 32); нет аргумента - угол поворота картинки (((
И как жить-то? :-(
Ну или блажь пройдёт, или по картиночно придётся изгаляться :)
Ну, да, как у Михаила Афанасьевича
Профессор, вас стоило бы расстрелять!
Просто вот, например, хочется жучка по экрану, что бы бегал под разными углами, а в функции myOLED.drawBitmap(0, 0,foto_A, 32, 32); нет аргумента - угол поворота картинки (((
Вы когда-нибудь слышали такой термин - спрайтовая анимация.
Да, так примерно и задумывал, но хотелось в рамках функций библиотеки спрайт не только поступательно двигать, а и вращать, уменьшать-увеличивать на экране.
Да, так примерно и задумывал, но хотелось в рамках функций библиотеки спрайт не только поступательно двигать, а и вращать, уменьшать-увеличивать на экране.
Спрайт не нужно вращать (на угол отличный от кратных 90), и увеличивать-уменьшать.
И потом, спрайтовая анимация - слишком специфичная область, чтобы ее включать в универсальную библиотеку.
Ну вот вставил я гифку жука в экранчик. Пробегает он мимо. Но в библиотеке не нашёл и вращение спрайта даже на 90 градусов (( А хотелось имитации жука в банке (сейчас дети начнут майских жуков насмерть рассматривать, как они копошатся)... Получается новый комплект картинок подгружать в скетч.
в библиотеке не нашёл и вращение спрайта даже на 90 градусов (( А хотелось
вращение на 90 делается заменой координаты х на у и наоборот. И иногда инвертированием значений.
Где менять? В координатах вывода спрайта?
Реализовал, правда за счёт поворотов изображений всего экрана.
Пробую экран-мордашку без библиотек с буфером-дублем экрана в озу - чтобы в про мини 168 всё влезало. С анимацией понятно. Возникает вопрос с 33 строкой - как она работает? Как смещать спрайт-картинку вверх-вниз, влево-вправо? Все ссылаются на даташит, но процедуры работы команды не поясняют. Может кто это уже делал?
Оказалось просто. После (0*D3) пишем, например, (-16) - смещаем вниз на 16 строчек.
А оттенки серого никто не пробовал на варианте с I2C? Идея сама интересна.
Фокус не удался - частота мала.