И еще одно замечание: судя по myOLED.upgate(), используется библиотека с буферизацией. Во многих проектах это недопустимо ресурсоемко. Ну и, кроме того, не позволяет подключить к одному контроллеру типа Atmega328 более одного дисплея.
Отсюда пожелание: переделать все примеры на библиотеку без экранного буфера. К сожалению, это вопрос не чисто механического переноса, т.к. нужно будет адаптировать сами "картинки" под аппаратные возможности дисплея.
Думал над этим. Нет хороших графических библиотек без буфера у меня на примете, а так да, сразу можно на про мини 168 замахнуться :-)
Отсюда пожелание: переделать все примеры на библиотеку без экранного буфера. К сожалению, это вопрос не чисто механического переноса, т.к. нужно будет адаптировать сами "картинки" под аппаратные возможности дисплея.
drawCircle без экранного буфера ?
Что Вы хотели сказать этим вопросом?
Переделывать, очевидно, нужно не drawCircle, а процедуру вывода изображения на дисплей. Если непонятно, скажу проще: нужно отказываться от drawCircle и других функций, которые не могут работать без экранного буфера.
lilik пишет:
Думал над этим. Нет хороших графических библиотек без буфера у меня на примете, а так да, сразу можно на про мини 168 замахнуться :-)
А их и не может быть. По определению - многие графические операции не могут быть выполнены аппаратно на этом дисплее.
Собственно, именно в этом и заключается "изюминка" - при невозможности реализации универсальных функций отрисовки придумать и реализовать способы обхода этого ограничения в каждом конкретном случае. И задача из чисто механической сразу переходит в разряд творческих.
andriano я прекрасно умею общаться с SSD1306 без буфера, без библиотеки - напрямую. Просто у ТС есть вызовы функций, которые реализовать без буфера достаточно проблематично.
andriano я прекрасно умею общаться с SSD1306 без буфера, без библиотеки - напрямую. Просто у ТС есть вызовы функций, которые реализовать без буфера достаточно проблематично.
Их не нужно реализовывать. Нужно придумать им замену для конкретного случая.
Как в принципе можно обойтись без буфера? Предположим есть функция математическая как строить фигуру по точкам. "Одну точку" не передать в экран, а только 8 "одного байта" по конкретному адресу. Если точек 200 - это 200 передач по адресам. Они быстрее чем 1 по всем адресам?
Как в принципе можно обойтись без буфера? Предположим есть функция математическая как строить фигуру по точкам. "Одну точку" не передать в экран, а только 8 "одного байта" по конкретному адресу. Если точек 200 - это 200 передач по адресам. Они быстрее чем 1 по всем адресам?
Другая логика работы используется. Для фигур все сложно, но возможно ...
Как в принципе можно обойтись без буфера? Предположим есть функция математическая как строить фигуру по точкам. "Одну точку" не передать в экран, а только 8 "одного байта" по конкретному адресу. Если точек 200 - это 200 передач по адресам. Они быстрее чем 1 по всем адресам?
Другая логика работы используется. Для фигур все сложно, но возможно ...
Как в принципе можно обойтись без буфера? Предположим есть функция математическая как строить фигуру по точкам. "Одну точку" не передать в экран...
Правильно рассуждаешь.
Но медленно. На каждый маленький шажочек нужен очередной толчок.
Раз "одну точку не передать на экран", значит, следует принципиально избавляться от попиксельной графики. Т.е. рассматривать экран не как набор пикселей, а как набор более крупных примитивов. Хотя бы 8-пиксельных. А желательно - больше. Скажем N*M, где N - кратно 8, а M - больше 1.
А желательно - больше. Скажем N*M, где N - кратно 8, а M - больше 1.
Так можно реализовывать вывод текста, имея в постоянной памяти картинки букв размером N*M, но в графике как , например, вывести отрезок заданной длины, под заданным углом? Мне кажется, в общем случае без буфера, хоть и скромного размера, не обойтись. Кстати если бы в используемой мной библиотеке буфер сократили в 2 раза, а вывод разделили на 2 части - про мини 168 справилась бы уже. "Вообщем" тема "безбуферных графических библиотек" для ssd1306 не мой уровень творчества :-(
Пришёл таки второй экранчик. От радости захотелось узоров.
////////////// генератор узоров для ковра
#include <OLED_I2C.h>
OLED myOLED(SDA, SCL);
int t = 1000; // пауза между сменой рисунка ковра
int uz = 1000; // плотность узора ковра
void setup()
{
myOLED.begin();
myOLED.invert(0);//инверсия цвета
}
void loop()
{
myOLED.clrScr(); // очищаем дисплей
int p = map(analogRead(A0), 0, 1023, 0, 100); //размер ковра
/////
for (int i = 0; i < uz; i++) {
int x = random(0, 128);
int y = random(0, 64);
if (x * x + y * y < p * p) {//вышиваем, выплетаем узоры
myOLED.setPixel(x + 63, y + 32);
myOLED.setPixel(x + 63, -y + 32);
myOLED.setPixel(-x + 63, -y + 32);
myOLED.setPixel(-x + 63, y + 32);
}
}
///
myOLED.update(); delay(t);
}
Так можно реализовывать вывод текста, имея в постоянной памяти картинки букв размером N*M, но в графике как , например, вывести отрезок заданной длины, под заданным углом?
Другими словами, Вы согласны решать исключительно тривиальные задачи?
Цитата:
Мне кажется, в общем случае без буфера, хоть и скромного размера, не обойтись.
В общем случае - да.
Но речь идет не об общем, а о частном конкретном случае: для каждого из вариантов "шкал" придумать такой алгоритм, который позволит обойтись без буфера.
Берем OLED128х64, Цепляем к нему Нанку, общаемся по I2C, на Нанке - драйвер со всеми примитивами графики, анимации, 3Д элементов. И уже это "бутерброд" используем как экран для своей поделки, в которой уже не нужен будет буфер.
Вот тока не надо говорить, что я изобрел Некстион! ;))) Моя идея дешевше будет!
Берем OLED128х64, Цепляем к нему Нанку, общаемся по I2C, на Нанке - драйвер со всеми примитивами графики, анимации, 3Д элементов. И уже это "бутерброд" используем как экран для своей поделки, в которой уже не нужен будет буфер.
Вот тока не надо говорить, что я изобрел Некстион! ;))) Моя идея дешевше будет!
Я вроде писал уже, что (чисто ИМХО, не настаиваю! ...ну кроме как на перце и зубровке ;)) ) что кнопки и индикацию отмел для себя полностью. Если забыть про 8ми битный "ужОс" в виде АВР, то ESP дает возможность сделать веб-морду, а тилипон всегда в кармане. ;))) Да и памяти там побольше и частота повыше. АВР-ки в автомобиль оставляю - 5В немного более устойчивы к помехам и интерфейс мне там не нужен никакой.
/////////////////// индикатор наполнения ёмкости жидкостью
#include <OLED_I2C.h>
OLED myOLED(SDA, SCL);
extern const unsigned char schkala_A[];
int t = 30; // пауза между считываниями потенциометра
int pp = 0; // переменная для хранения предыдущего значения уровня
void setup()
{
myOLED.begin();
myOLED.invert(0);//инверсия цвета
}
void loop()
{
myOLED.drawBitmap(0, 0, schkala_A, 128, 64); // рисование картинки ёмкости
int p = map(analogRead(A0), 0, 1023, 15, 122); // считывание потенциометра и определение высоты уровня жидкости
if (abs(p - pp) > 1) { //если значение уровня поменялось выше порогового в 1 единицу
myOLED.drawRect(p, 8, 122, 54); // прорисовка контура столба жидкости
for (int i = 0; i < 2000 - p * 15; i++) { // прорисовка столба жидкости
int x = random(p, 122);
int y = random(8, 54);
myOLED.setPixel(x , y );
}
myOLED.update(); delay(t);
pp = p; //запоминание "нового предыдущего" значения
}
}
Но речь идет не об общем, а о частном конкретном случае: для каждого из вариантов "шкал" придумать такой алгоритм, который позволит обойтись без буфера.
Я придумал общий алгоритм для графической библиотеки совсем без буфера экрана. Но реализовать его сам едва ли смогу. Да и Ардуино тоже :-) Попробую изложить его простым языком, если получится, может сведущие разберутся.
Это индикация дозы (в каплях). А еще же нужен контроль остатков. И еще можно добавить расчетное количество промилле в крови (степень готовости), с учетом типа напитка и массы тушки поциЭнта
Итак любую картинку можно представить как множество отрезков, а поле экрана как декартову систему координат. Отрезки описываются уравнением вида:
где x,y координаты подходящих отрезку точек.
Заполнение экрана светящимися (не светящимися) пикселями происходит сначала по столбцам, потом по страницам. Проблема в том, что столбец из 8 точек надо заполнить один раз, зная какие точки в нём принадлежат хотя бы одному из отрезков и потом отправить в экран. То есть каждый текущий бит-точку с координатами x,y надо проверять на принадлежность всем отрезкам картинки. Например, картинка состоит из 100 отрезков, значит Ардуино должна пересчитать 100 условий. А всего около 800000 на картинку прежде чем весь экран отрисуется. Вот и получается, что вместо буфера МК нужен быстро считающий МК.
тема из полезной медленно дрейфует в фарс. Перенесли в "Проекты", скоро придется в "Отвлеченные" переносить :)
ИМХО. тема раскрыта почти полностью - происходит обсуждение по применению... и ТС не виноват, что народ на больную тему понесло. Если чего и переносить, то отдельные посты :)))))
lilik пишет:
...значит Ардуино должна пересчитать 100 условий. А всего около 800000 на картинку прежде чем весь экран отрисуется. Вот и получается, что вместо буфера МК нужен быстро считающий МК.
как-то даже и не удивительно... может видеокарту для ардуино пора придумать? :))))
Итак любую картинку можно представить как множество отрезков...
НизачОт!
Повторяю, наверное, уже в третий или четвертый раз: не нужно пытаться искать универсальное решение (рисование отрезка - это именно элемент универсального решения), нужно рисовать конкретную картинку. Без буфера. И без универсальных примитивов.
А прогресс ли это? Все шрифты набиты картинками в библиотеках под экранчики. Буквы-цифры не повернуть и не масштабировать. И тем не менее по другому не делают.
В коде я конечно не понял ничего, но подход ясен - буфер размером с символ, символ это отрезки-кривые, масштабирование, повороты. Вот мне и интересно, почему авторы библиотеки OLED_I2C не делали векторные шрифты в довесок к "картиночным"?
Примитивов могли добавить - эллипсов, звёзд,многоугольников, дуг, спиралей и т.д.
Там почитай. С начала автор темы хотел много разных примитивов. По ходу отказались. Отрезков для шрифтов с головой хватает. На таких разрешениях, как экран этот, дуги легко аппроксимируются.
//Вот мне и интересно, почему авторы библиотеки OLED_I2C не делали векторные шрифты в довесок к "картиночным"?
В векторном шрифте вся загвоздка в формате хранения. Нужно хранить очень сжато и распаковывать быстро. А растровый напрягов не требует.
Ждём тетриса!
Мне кажется, слишком контрастно.
Я бы попробовал вместо сплошной заливки использовать полутона, реализуемые чем-то вроде шахматного поля (квадратик - 1 пиксель).
Подправил.
И еще одно замечание: судя по myOLED.upgate(), используется библиотека с буферизацией. Во многих проектах это недопустимо ресурсоемко. Ну и, кроме того, не позволяет подключить к одному контроллеру типа Atmega328 более одного дисплея.
Отсюда пожелание: переделать все примеры на библиотеку без экранного буфера. К сожалению, это вопрос не чисто механического переноса, т.к. нужно будет адаптировать сами "картинки" под аппаратные возможности дисплея.
Думал над этим. Нет хороших графических библиотек без буфера у меня на примете, а так да, сразу можно на про мини 168 замахнуться :-)
Отсюда пожелание: переделать все примеры на библиотеку без экранного буфера. К сожалению, это вопрос не чисто механического переноса, т.к. нужно будет адаптировать сами "картинки" под аппаратные возможности дисплея.
drawCircle без экранного буфера ?
Что Вы хотели сказать этим вопросом?
Переделывать, очевидно, нужно не drawCircle, а процедуру вывода изображения на дисплей. Если непонятно, скажу проще: нужно отказываться от drawCircle и других функций, которые не могут работать без экранного буфера.
Думал над этим. Нет хороших графических библиотек без буфера у меня на примете, а так да, сразу можно на про мини 168 замахнуться :-)
А их и не может быть. По определению - многие графические операции не могут быть выполнены аппаратно на этом дисплее.
Собственно, именно в этом и заключается "изюминка" - при невозможности реализации универсальных функций отрисовки придумать и реализовать способы обхода этого ограничения в каждом конкретном случае. И задача из чисто механической сразу переходит в разряд творческих.
andriano я прекрасно умею общаться с SSD1306 без буфера, без библиотеки - напрямую. Просто у ТС есть вызовы функций, которые реализовать без буфера достаточно проблематично.
andriano я прекрасно умею общаться с SSD1306 без буфера, без библиотеки - напрямую. Просто у ТС есть вызовы функций, которые реализовать без буфера достаточно проблематично.
Их не нужно реализовывать. Нужно придумать им замену для конкретного случая.
Заготовка под вывод ошибок OBD:
Квадратики внизу - количество ошибок
Квадратик с точкой - отображаемая
Тёмный лес. Нашёл в файлах библиотеки используемой вот этот фрагмент. Строка для изменений 11 ?
Это не Wire, это прямое обращение к железу через порты ! С Wire было бы совсем все плохо - пришлось бы делить посылки на размер буфера Wire.
Да можно пробовать записывать в TWBR 0, 1, 2, ... Или найти где определяется TWI_FREQ и менять частоту.
Или найти где определяется TWI_FREQ и менять частоту.
Попробую в библиотеке OLED_I2C.
Как в принципе можно обойтись без буфера? Предположим есть функция математическая как строить фигуру по точкам. "Одну точку" не передать в экран, а только 8 "одного байта" по конкретному адресу. Если точек 200 - это 200 передач по адресам. Они быстрее чем 1 по всем адресам?
Ну, еще не забуть, прежде чем рисовать новую фигуру, надо старую стереть, т.е + еще 200 передач
Как в принципе можно обойтись без буфера? Предположим есть функция математическая как строить фигуру по точкам. "Одну точку" не передать в экран, а только 8 "одного байта" по конкретному адресу. Если точек 200 - это 200 передач по адресам. Они быстрее чем 1 по всем адресам?
Другая логика работы используется. Для фигур все сложно, но возможно ...
Как в принципе можно обойтись без буфера? Предположим есть функция математическая как строить фигуру по точкам. "Одну точку" не передать в экран, а только 8 "одного байта" по конкретному адресу. Если точек 200 - это 200 передач по адресам. Они быстрее чем 1 по всем адресам?
Другая логика работы используется. Для фигур все сложно, но возможно ...
Для спрайтов кратных 8 должно быть легко.
Как в принципе можно обойтись без буфера? Предположим есть функция математическая как строить фигуру по точкам. "Одну точку" не передать в экран...
Правильно рассуждаешь.
Но медленно. На каждый маленький шажочек нужен очередной толчок.
Раз "одну точку не передать на экран", значит, следует принципиально избавляться от попиксельной графики. Т.е. рассматривать экран не как набор пикселей, а как набор более крупных примитивов. Хотя бы 8-пиксельных. А желательно - больше. Скажем N*M, где N - кратно 8, а M - больше 1.
А желательно - больше. Скажем N*M, где N - кратно 8, а M - больше 1.
Так можно реализовывать вывод текста, имея в постоянной памяти картинки букв размером N*M, но в графике как , например, вывести отрезок заданной длины, под заданным углом? Мне кажется, в общем случае без буфера, хоть и скромного размера, не обойтись. Кстати если бы в используемой мной библиотеке буфер сократили в 2 раза, а вывод разделили на 2 части - про мини 168 справилась бы уже. "Вообщем" тема "безбуферных графических библиотек" для ssd1306 не мой уровень творчества :-(
Пришёл таки второй экранчик. От радости захотелось узоров.
Ползунок прогресса. Управлять кнопкой конечно будет ловчее.
Так можно реализовывать вывод текста, имея в постоянной памяти картинки букв размером N*M, но в графике как , например, вывести отрезок заданной длины, под заданным углом?
Другими словами, Вы согласны решать исключительно тривиальные задачи?
Мне кажется, в общем случае без буфера, хоть и скромного размера, не обойтись.
В общем случае - да.
Но речь идет не об общем, а о частном конкретном случае: для каждого из вариантов "шкал" придумать такой алгоритм, который позволит обойтись без буфера.
Господа! Я решил вашу задачку! ;))))))
Берем OLED128х64, Цепляем к нему Нанку, общаемся по I2C, на Нанке - драйвер со всеми примитивами графики, анимации, 3Д элементов. И уже это "бутерброд" используем как экран для своей поделки, в которой уже не нужен будет буфер.
Вот тока не надо говорить, что я изобрел Некстион! ;))) Моя идея дешевше будет!
Другими словами, Вы согласны решать исключительно тривиальные задачи?
:-)
Природа не сильно интересовалась моим мнением.
Господа! Я решил вашу задачку! ;))))))
Берем OLED128х64, Цепляем к нему Нанку, общаемся по I2C, на Нанке - драйвер со всеми примитивами графики, анимации, 3Д элементов. И уже это "бутерброд" используем как экран для своей поделки, в которой уже не нужен будет буфер.
Вот тока не надо говорить, что я изобрел Некстион! ;))) Моя идея дешевше будет!
С практической точки зрения это вариант.
Индикация это ~5-10% от задач.
Индикация это ~5-10% от задач.
Я вроде писал уже, что (чисто ИМХО, не настаиваю! ...ну кроме как на перце и зубровке ;)) ) что кнопки и индикацию отмел для себя полностью. Если забыть про 8ми битный "ужОс" в виде АВР, то ESP дает возможность сделать веб-морду, а тилипон всегда в кармане. ;))) Да и памяти там побольше и частота повыше. АВР-ки в автомобиль оставляю - 5В немного более устойчивы к помехам и интерфейс мне там не нужен никакой.
Индикатор уровня жидкости. С библиотекой, как и с индикаторами-шкалами в принципе ясно, можно добавить ещё функций построения графических примитивов.
Потестил схему двумя экранами, вроде всё работает.
В общем случае - да.
Но речь идет не об общем, а о частном конкретном случае: для каждого из вариантов "шкал" придумать такой алгоритм, который позволит обойтись без буфера.
Я придумал общий алгоритм для графической библиотеки совсем без буфера экрана. Но реализовать его сам едва ли смогу. Да и Ардуино тоже :-) Попробую изложить его простым языком, если получится, может сведущие разберутся.
Бочка в разрезе жаркого лета будет весьма актуальна
Бутылка. В проект наливатора. Тамошние алкаши будут рады
Для "наливатора нужен струемер-каплемер" :-)
Этот вариант сразу на три экрана (в наличии правда только два).
Это индикация дозы (в каплях). А еще же нужен контроль остатков. И еще можно добавить расчетное количество промилле в крови (степень готовости), с учетом типа напитка и массы тушки поциЭнта
(степень готовости), с учетом типа напитка и массы тушки поциЭнта
Типа как с бочкой, но с фигуркой человека?
(степень готовости), с учетом типа напитка и массы тушки поциЭнта
Можно и так. А можно угол наклона
тема из полезной медленно дрейфует в фарс. Перенесли в "Проекты", скоро придется в "Отвлеченные" переносить :)
Подправил - к изменению скорости капели добавляется изменение высоты стакана :-)
тема из полезной медленно дрейфует в фарс. Перенесли в "Проекты", скоро придется в "Отвлеченные" переносить :)
Я сейчас добавлю грусти про универсальную безбуферную графическую библиотеку.
Итак любую картинку можно представить как множество отрезков, а поле экрана как декартову систему координат. Отрезки описываются уравнением вида:
где x,y координаты подходящих отрезку точек.
Заполнение экрана светящимися (не светящимися) пикселями происходит сначала по столбцам, потом по страницам. Проблема в том, что столбец из 8 точек надо заполнить один раз, зная какие точки в нём принадлежат хотя бы одному из отрезков и потом отправить в экран. То есть каждый текущий бит-точку с координатами x,y надо проверять на принадлежность всем отрезкам картинки. Например, картинка состоит из 100 отрезков, значит Ардуино должна пересчитать 100 условий. А всего около 800000 на картинку прежде чем весь экран отрисуется. Вот и получается, что вместо буфера МК нужен быстро считающий МК.
Поэтому люди буфер и придумали ;)
тема из полезной медленно дрейфует в фарс. Перенесли в "Проекты", скоро придется в "Отвлеченные" переносить :)
ИМХО. тема раскрыта почти полностью - происходит обсуждение по применению... и ТС не виноват, что народ на больную тему понесло. Если чего и переносить, то отдельные посты :)))))
...значит Ардуино должна пересчитать 100 условий. А всего около 800000 на картинку прежде чем весь экран отрисуется. Вот и получается, что вместо буфера МК нужен быстро считающий МК.
как-то даже и не удивительно... может видеокарту для ардуино пора придумать? :))))
lilik, библиотека OLED вот эта используется?
https://github.com/jlegas/OLED_I2C
http://www.rinkydinkelectronics.com/library.php?id=79
Вот отсюда качал по моему.
Итак любую картинку можно представить как множество отрезков...
НизачОт!
Повторяю, наверное, уже в третий или четвертый раз: не нужно пытаться искать универсальное решение (рисование отрезка - это именно элемент универсального решения), нужно рисовать конкретную картинку. Без буфера. И без универсальных примитивов.
нужно рисовать конкретную картинку. Без буфера. И без универсальных примитивов.
Картинка это множество хаотично расположенных точек, координаты которых где то должны храниться?
Какой промежуточный вариант между крайностями?
А прогресс ли это? Все шрифты набиты картинками в библиотеках под экранчики. Буквы-цифры не повернуть и не масштабировать. И тем не менее по другому не делают.
та конечно! ))))
Уже столько лет как решено. А начало http://arduino.ru/forum/programmirovanie/krivye-beze?page=1 там и про безбуферную работу с экраном есть маленько.
В коде я конечно не понял ничего, но подход ясен - буфер размером с символ, символ это отрезки-кривые, масштабирование, повороты. Вот мне и интересно, почему авторы библиотеки OLED_I2C не делали векторные шрифты в довесок к "картиночным"?
Примитивов могли добавить - эллипсов, звёзд,многоугольников, дуг, спиралей и т.д.
Там почитай. С начала автор темы хотел много разных примитивов. По ходу отказались. Отрезков для шрифтов с головой хватает. На таких разрешениях, как экран этот, дуги легко аппроксимируются.
//Вот мне и интересно, почему авторы библиотеки OLED_I2C не делали векторные шрифты в довесок к "картиночным"?
В векторном шрифте вся загвоздка в формате хранения. Нужно хранить очень сжато и распаковывать быстро. А растровый напрягов не требует.
Вот мне и интересно, почему авторы библиотеки OLED_I2C не делали векторные шрифты в довесок к "картиночным"?
сложность кода на порядок выше
Мне кажется, что "математическое" хранение символа предпочтительнее "картиночного". А вот такой вариант не
облегчает кодирование?
Вот мне и интересно, почему авторы библиотеки OLED_I2C не делали векторные шрифты в довесок к "картиночным"?
Они задали себе вопрос "наюха?" и совершенно правильно на него ответили - "нахнесдалось!".
А вот такой вариант не
облегчает кодирование?
попробуйте вписать в него "Д" или "Й", я уж не говорю про буквы арабского алфавита.
Или даже проще - изобразите своим вариантом фонты bold и italic, так чтобы они четко отличались от plain
не думаю что символ '@' сюда влезет ))) Использую для символа 9*17