Arduino.ru

Полезный проект, надо будет опробовать!

А ориентацию 90/180 градусов можно реализовать?

А я уже опробовал, библиотека просто бомба. Простенько и со вкусом. Огромное спасибо автору.

ПС. И автор забыл указать, что библиотека выводит как ангийский, так и русский, український и беларуский шрифты. Причем без бубнов, вот как написал в скетче LD.printString_6x8(F("Україна - ненька моя"), 0, 4) , вот так и на экране будет. )

На 180 - уже есть.

На 90 - для 1306, если мне не изменяет память, реализовать можно, но нужно гораздо глубже перепрограммировать дисплей (чтобы байт, 8 пикселей, располагался не вертикально, а горизонтально). Для 1106 - не смотрел.

Но, в любом случае, коль скоро беблиотека работает без буфера, то любые подобные манипуляции оказываются аппаратно зависимы.

Ну а самое главное - по мере обрастания "фичами" библиотека теряет свою компактность. Поэтому хочется, чтобы в библиотеке было только самое необходимое, а не все, что кому-то когда-то может понадобиться.

Разве забыл?

А мне казалось, что прямо в названии темы фигурирует слово "кириллица". А кириллица - это, помимо русского, украинского и беларусского, также болгарский, македонский, русинский, сербский и черногорский.

Правда, должен признаться, что если русский, украинский, белорусский, болгарский и русинский поддерживаются честно, то, скажем, в македонском можно добиться адекватного изображения надписей, но для этого нужно заменить македонские "S" или "J" на аналогичные по написанию латинские.

Нет ли у автора этой библиотеки со SPI?

Плюсанул и подписался на тему. Спасибо за библу ))

В названии темы, да, фигурирует. Но и многие другие библы выводят кирилицу, но с телодвижениями. А ваша -  сразу, как есть. Вот в том-то и вишенка.

Но, я как бы не настаиваю. Фигурирует, - значит фигурирует. ))

Были бы у меня дисплеи с SPI - появилсь бы и библиотека.

Да и самя сейчас, честно говоря, предпочел бы SPI, но основа этой библиотеки зародилась в первую неделю моего знакомства с Ардуино, поэтому какой дисплей мне первым попался, для такого интерфейса и написал.

Ну как раз на этот случай в том же названии есть уточнение "UTF-8", беда лишь в том, что далеко не все начинающие пользовалели Ардуино знают, что среда Arduino IDE работает именно в этой кодировке.

В общем, всен, что нужно, написано, но, увы, не совсем вразумительно.

Неплохо, но такое https://youtu.be/i6ZzAEG1vaE на этой либке не забацаеш ;)

Было бы желание.

Библиотека поддерживает вывод битмапа, а самому рисовать в битмап (который, кстати, не обязан занимать всю площадь экрана) никто не запрещал.

Т.е. промежуточный буфер. Прога пишет в него, передает его в либу, а та уже выводит на экран. А зачем? Это и ОЗУ нужно, и время на заполнение и вывод ;) Не понимаете на что намекаю?

Я вам намекну на одно обстоятельство - с либой от адафруит + трошки кода, мой скетч хавал 78% флеш и 76% ОЗУ, после перехода на эту - 48% и 42℅ соответственно. Намек понятен?
Нужны блекджек и женщины? Адафруит вам в помощь. Ну или другие либы с разной степенью доступности женщин.

Я Вам сострадаю с вашими проблемами, причем только здесь адафрукт. Что он дерьмо с буфером 1КБ прогрессивное человечество давно вкурсах и его избегают. Или Вы решили что то видео на адафрукте - так таки нет конечно, там буфера нет вобще, не считая нужных для работы БПФ.

я тоже

В чем проблема? Хотите рисовать на экране побайтно - рисуйте. Немножечно времени на заполнении, конечно, выиграете. Но но на выводе потеряете намного больше.

И еще одно замечение (простите за очевидность): Можно выводить на экран и без всякой библиотеки, только библиотека для этого не нужна. :)

А на что ВЫ намекаете, я не понял. Лично я, если бы мне потребовалось реализовать что-то подобное тому, что на видео, помимо библиотеки использовал бы и небиблиотечные функции. А расширять библиотеку для частного случая - не стал бы.

Разумеется расширять библиотеку под ту или иную картинку не стоит. Библиотеки универсальностю ценны. А намекаю  я на калбек. Возмем к примеру void ASOLED::drawBitmap(const byte *bitmaparray, byte X, byte Y, byte width, byte height) Все как обычно, указатель на буфер первым параметром, в данном случае буфер в PROGMEM (кстати неплохо бы это в типе буфера отразить). Аналогично можна разумеется как в адафрукте указатель на ОЗУ сделать. Но оба подхода слабоваты. А вот если вместо его указатель на функцию возвращающую очередной байт для отрисовки на экран сделат - то все становится намного интересней. Именно так и сделано то видео, функция возвращающая байт там такая.

А вот можно как-то SD-карту задействовать? Для шрифтов, или битмапов, например. Ни одной такой не видел. Опционально, конечно.

Признаю - мой косяк.

Основа либы делалась в первые две недели моего знакомства с Ардуино.

Ту есть два замечания:

1. А сколько времени уходит при этом на отрисовку одного экрана? По опыту работы на ПК такой подход крайне неэффективен.

2. Насколько я онял, такие функции неуниверсальны. Т.е. даже большой пачки на все случаи жизни не хватит.

Для дисплея - своя библиотека, для карты - своя. Это разные устройства. Связывать их между собой - задача основной программы, а не библиотечных функций.

1. С временем порядок. На видее без тормозов, а ведь там БПФ заодно считает, синусоиды генерит и выводит-вводит. Понятно что если в сравнивать с выводом фиксированой картинки из PROGMEM, то медленей получится, но фиксированая все хотелки совсем не покрывает. А если сравниват с использованием буфера в ОЗУ то надо учитывать и время на формирование буфера, и время мало отличается. При грамотном использовании аппаратного i2c  пока предыдущий байт выводится новый расчитывается. 

2. В каком смысле не универсальны? На все случаи жизни ничего не хватит;)

Это понятно, что для сдшки своя библиотека, а для экрана своя.
Я имел в виду - как это сделано в либе, которая к примеру звук выводит из файла wav. Она, при наличии карты и SD.h, воспроизводит файлы с карты, но может и с PROGMEM.
К примеру, LD.drawBitmapSD("proba.bmp");

То, что видно на видео, можно оценить в 4-5 fps. Моя библиотека обеспечивает порядка 20 fps при обновлении всего экрана. Конечно, понятно - FFT и все такое... там уже скорость вывода на экран имеет второстепенную роль.

Собсвенно я позиционирую библиотеку для проектов, в которых дисплей играет вспомогательную роль (для чего, собственно, и нужна минимальная ресурсоемкость даже за счет ограничения функциональности). Например, я использовал ее для колесного робота. В Вашем же проекте, судя по FFT, синусоиде и пр. экран - это то, ради чего проект и создавался. Это несколько разные цели и, соответственно, разумно достигать их разными средствами.

Вы забыли упомянуть, о какой именно библиотеке идет речь.

Лично мне встречались библиотеки как для Uno, так и для Due. Первые, как правило, предназначались для готовых аппаратных модулей - Shield'ов. На самом Shield'е располагались как слот для карты, так и звуковой модуль. Т.е. серийно выпускается и довольно распространен модуль, содержащий в себе два разных периферийных устройства. В расчете на этот единственный модуль и написана библиотека.

Для Due, который сам содержит все необходимое для воспроизведения звука - своя библиотека. В качестве периферии также используется единственный модуль - слот SD.

Если мы берем отдельно экран и отдельно слот SD - это два модуля.

Модулей (Shield'ов), в которых были бы совмещены экран и слот SD мне не попадалось, а следовательно, писать библиотеку для несуществующего модуля не имеет смысла.

Вот https://github.com/TMRh20/TMRpcm библиотека, которая, недурственно, надо сказать, воспроизводит wav (там вроде даже mp3 заявлено, не разобрался до конца).
Она не для шилда, она вообще. А СДшка, это просто SPI, даже шилда не нужен, для согласования уровней 6 резисторов вешается и все. Я, например, эти шесть резисторов прямо к переходнике SD - microSD припаять, и использую как шилд.
Просто, как оказалось, использовать СДшку как программную память - нет. Так хоть для битмапов пошло бы, а если сделать подгрузку надписей, для разных, языков, из файла на СД, - это было бы что-то. Но лучше отдельным модулем, не всем это надо.
Тут вообще, если фантазию включить, надписи можно прямо с СДшки, и сразу как битмассивы загружать, типа в виде витиеватых шрифтов. Вот только нужен будет какой-то редактор, чтобы их готовить.
Приблизительно так:
Функция - открыть файл на карте.
Функция вывода предварительно подготовленного битмассивы в строку.
Правда ещё нужно будет таки функцию дополнения вывода переменными из программы.
Надеюсь не очень сумбурно, и не слишком по нубски объясняю.
Тогда вместо текстовой надписи, которую нужно хранить в PROGMEM, придется хранить только адрес битмассива в файле на карте.

Кстати, вот вам экран с СДшкой на борту 1pcs 1.8 inch TFT LCD Module LCD Screen SPI serial 51 drivers 4 IO driver TFT Resolution 128*160 TFT interface 1.8 inch
http://s.aliexpress.com/M3eyEVZv?fromSns=Копировать
(from AliExpress Android)

kostyamat, а обсуждаемая библиотека то тут при чем?

Есть библиотека для карты, есть библиотека для дисплея, хотите использовать совместно - кто ж Вам запретит!

Другое дело, что данная библиотека заточена под минимальное использование памяти, а SD сама по себе прожорлива по памяти. Так что в проектах, где критично количество ОЗУ, SD вряд ли пригодится.

А что касается указанного Вами дисплея, то он явно цветной. Т.е. не меньше 16 бит на пиксель. При разрешении 128х160 - это более 40 кбайт один экран. Для такого имеет смысл хранить картинки на карте, т.к. на Uno даже одной картинки в PROGMEM не поместится.

Универсальных решений не бывает. Особенно для ограниченных в ресурсах микроконтроллеров. Что подходит для одного, совершенно не годится для другого.

Заинтересовался цифрами, упростил код вызова до 

Калбек все тот же, только он расчитан на часть экрана с графиком, а я его теперь на весь экран вызываю. Получил 86мс - 12fps, упростил калбек до return 0xc2; нарисовало полоски на весь экран 60мсек -15fps. На софтовом i2c.  ИМХО - более чем достаточно для любых применений, кроме качественной анимации и видео. Но она явно не для такого экрана. Либу свою я использую универсально, в всех указанных случаях. А чего бы и нет?! Выводить  битмапы из PROGMEM аналогично вашей тоже умеет. Шрифты тоже из PROGMEM напрямую. Линии, окружности и прочую лабудень используя временный буфер под требуемую часть экрана тоже (буфер извне передается, как данные выведены - память освобождается). И отдельное применение - отладка скрипта в готовом изделии без экрана. Цепляю на любые 2 свободных пина и софтовый i2c готов. Рассматриваемый пример с DTMF, FFT, алгоритмом Герцеля и пр. как раз пример применения для отладки, смотреть сигналы както надо было.

По дискусии про поддержку SD карты - тулить это в либу экрана плохая идея. Не нужно лепить монстров. Но невозможность вывести картинку из SD на экран без буферизации её - очевидно тоже недостаток. Кстати калбек тут тоже выручает ;) Я так делал на TFT 320*240*16bit. Перед вызовом вывода картинки файл с ней открывается, проверяется на соответствие формата, выделяется на стеке небольшой, по памяти 128 байт, буфер. В вызов передается калбек на функцию которая возвращает из буфера очередной байт, а если он пуст - вычитывает очередной блок данных из файла. Перерисовывало экран 1-2сек. Слабоват 328-й для графики 320*240, а либа поддержки SD - один из образчиков тормознутости.  Думаю если ей переписать то можно и до ограничения по скорости SPI дойти 2-3fps вытянуть, только нафига оно.

Привет, долго мучался с адафрутом и нехваткой места, пока ненаткнулся на SSD1306Ascii. Сравнил вашу либу и либу https://github.com/greiman/SSD1306Ascii , результат:

и либу, которой пользуюсь:

Надеюсь будет полезно тем, кому и с вашей либой памяти не хватает =)

А не смущает, что в одном случае шрифт 6х8, а в другом - 5х7? В одном случае - 48 бит на символ, в другом - 35 бит на символ, разница по шрифту - навскидку 27%. Сколько там в шрифте символов? Это я про то, что надо бы покорректней сравнивать ;) К тому же, на первый взгляд - в указанной вами либе нет поддержки UTF-8, стало быть - на русском там писать не судьба, по ходу.

Да видел, только шрифта 6х8 из доступных https://github.com/greiman/SSD1306Ascii/tree/master/SSD1306Ascii/src/fonts не нашёл =)

andriano, можно где нибудь почитать о формате битмапа в вашей библиотеке? В частности хочется понять, что означают

первые 4 байта в ваших примерах. Гуглёж ничего полезного не даёт.  И есть ли программа, что-бы на компе нарисовать нужное изображение попиксельно, и сразу получить массив в нужном формате.

dimax, формат я упер из первой попавшейся мне библиотеки для 0.96" OLED. Кажется, она называлсь OzOLED. Но, возможно, и другая, при написании своей (а это был мой первый опыт написать что-то для Arduino) я использовал для справки 3 библиотеки.

Первые две цифры, очевидно, размер изображения по горизонтали и вертикали в пикселях. Четвертая - количество изображений в файле. А третья, думаю, для совместимости с файлом шрифтов, где это поле обозначает номер первого символа в таблице (для полного алфавита обычно код пробела (0х20), а для цифрового - код нуля (0х30)). Собстренно, его можно использовать для выбора нужного изображения по коду, если в массиве помещено сразу несколько изображений (в указанном файле содержится единственное изображение с кодом 255). Вот как-то так. Но формат изобретал не я, так что могу лишь поделиться своими догадками.

Есть ли программа - не знаю, я пользовался обычным текстовым редактором (как известно, настоящий программист пишет так: "COPY CON PROGRAM.EXE").

а начинающий так: "copy con program.com" ??? ))) или debug program.com

Ну да, если начинающий, то начинать нужно с СP/M-80.

библиотека так себе. текс выводится только статичный, текст из переменной вывести так и не получилось. из переменной можно вывести только число, но только одним шрифтом, а текст можно вывести 2 шрифтами. 

1. Что такое нестатичный текст?

2. Из переменной какого типа не получилось вывести текст?

3. Вообще-то в библиотеке используется единственный шрифт. Но двух размеров. Любым из размеров можно вывести как строку, так и число.

PS. Библиотека и задумывалась как "так себе" - чтобы для экономии памяти ничего лишнего. Отличает ее от других компактных библиотек лишь поддержка кириллицы "из коробки".

Тут такое дело. Не могу погасить 1.3" OLED SH1106. :)

LD.setBrightness(0) дает просто небольшую яркость, но экран не гасит. :(

И не должно (по крайней мере, с точки зрения разработчиков дисплея). 

Яркость там изменяется в очень небольших пределах. Полностью погасить экран - только очищать его.

добавил в редактор поддержку шрифтов OLED_I2C на основе которых сделаны шрифты ASOLED. до определенной степени совместимость с ASOLED есть, идущий с библиотекой шрифт читается и запишется верно. но не знаю как насчет шрифтов высотой больше 8 и высотой не кратной 8. 

Плата за отказ от экранного буфера - практическая невозможность выводить что-то некратное 8 по высоте. (точнее, возможность, конечно, есть - но чтобы реализовать ее нужна квалификация, при которой уже не нужны библиотеки типа ASOLED).

В библиотеке сейчас, насколько помню, жестко зафиксирован размер 6х8. Точнее, 5х8 с прмежутком в один пиксел.

Еще раз повторюсь: все сделано для минимизации программной и оперативной памяти. Поэтому расширять возможности не планирую.

Хотя, с другой стороны, сейчас применяю эту библиотеку для Due. Так что - как знать, может и еще чего добавлю.

Сложновато разобраться, как сделать чтобы пока загружается ардуингка, пакман бежал по желтой полосе дисплея? я менял некоторые значения из примера но результаты пугают) объясните в двух словах за эту анимацию пожалуйста

так же не могу понять как реализовать вот такое?

Serial.println((versiondata>>24) & 0xFF, HEX); 

при том что  вот такое Serial.print((versiondata>>16) & 0xFF, DEC);  работает корректно

LD.printNumber((HEX)(versiondata>>24) & 0xFF, 108, 0); так не дает сделать

как выводить 0x значения?

Чтобы "пока загружается ардуинка" что-то выводить на дисплей, нужен еще один МК, кроме ардуинки. иначе никак

Можно минут пять гонять пэкмена вхолостую, чтобы было видно, что проект серьезный - долго грузится.

хихихи

имелось ввиду не в момент загрузки а в момент начала выполнения функции Setup,  для того чтобы в loop все успело инициализироваться и быть готово к корректной работе

ну и еше в двух словах как вообще анимация отрисоввывается в случае пакмана

Зря смеетесь, ответ совершенно серьезный. я не знаю, что у вас такое иннициализируется в Сетап, что можно успеть анимацию вызвать. В большинстве проектов Сетап выполняется за доли секунды.  Разве только имитировать бурную деятельность -см ответ Садмана на предыдущее сообщение

анимация - это последовательный показ статичных картинок в разных позициях дисплея. Отрисовывается в положеннии х, потом стирается и отрисовывается на позиции х+1, потом на позиции х+2 и тд

А вообще, ваши вопросы - явный оффтоп в этой ветке. Разместите свои вопросы в разделе Программирование

Serial.println позволяет работать с различными наборами параметров по одной единственной причине: этих "Serial.println" на самом деле несколько. Каждая отрабатывает свой набор. Хотите, чтобы "давала" - напишите сами. Ничего сложного в этом нет. С моей же точки зрения, HEX формат может понадобиться при работе с подобным дисплеем чрезвычайно редко. Настолько редко, что писать отдельную функцию для этого не имеет мсысла. Он ведь не предназначен, как консоль, для выдачи отладочной информации. 

В общем, у Вас два варианта:

1. Написать нужный Вам варинт printNumber самостоятельно и дополнить им библиотеку.

2. Самому преобразовывать число в HEX-строку и выводить ее обычной функцией вывода строки.

А возможно ли как-то вывести на экран длинную строку с автоматическим разбиением ее на строки?

Почему-то это умеет делать, по-моему, одна библиотека Adafruit, которая на платах типа Nano бесполезна, так как занимает всё место. :)