sevenMod.data - это массив во флеше, так можно весь шрифт во время компиляции сконвертить, причем с дополнительными опциями, типа русские символы убрать, а английские оставить только заглавные и еще в начале таблицу со смещениями до символов добавить.
Можно и построчно, но я предпочитаю выводить символ столбцами слева направо. То тогда строка выводится последовательно столбцами. Если построчно, то вы как представляете? Вам нужно вывести строку символов, вы на каждый символ будете поле вывода переопределять?
Конечно, для каждого символа переопределяется окно по размеру символа, через RASET/CASET... Но тут я или криво читала даташиты на дисплеи, или оконный вывод построчный у TFT-дисплеев. Хотя, какая мне разница, у вас получилось - я рада за вас.
shonty писал(а):
а что там писать? вот только сейчас подключил дисплей и заранее написаный драйвер.
Я к тому, что написать на асме программу уровня тех устройств на 128 меге, что есть в статьях, особенно с вашим подходом оптимизации, экономии ОЗУ и максимального использования регистров - будет долго очень. И отлаживать ее - будет сложно...
Adrift, не, ну вы еще кресты притянули... Сейчас прибежит двадцать девятый и будет кричать, что это расточительно )))) Только современный ассемблер, только хардкор.
Но тут я или криво читала даташиты на дисплеи, или оконный вывод построчный у TFT-дисплеев.
Возможно и я криво читал даташит, а возможно производители не тем концом контроллер к матрице приклеивают.. но CASET я определяю как 0x2b, а RASET как 0x2a. Хотя с MADCTL как только не изгалялся
Just_Fluffy писал(а):
Я к тому, что написать на асме программу уровня тех устройств на 128 меге, что есть в статьях, особенно с вашим подходом оптимизации, экономии ОЗУ и максимального использования регистров - будет долго очень. И отлаживать ее - будет сложно...
Не знаю что за устройства, но однажды я написал драйвер под ST7735, и в последствии с небольшими изменениями он был доработан и под ILI9341 и под разные разрешения от 128*128 до 240*320. Если попадётся 320*480, то переделать не составит больших затрат И адаптировать драйвер под контроллер для меня тоже не особо затратно. например в LGT 32-х битный буфер spi, а имея базу, скорректировать не сложно))
Just_Fluffy писал(а):
или оконный вывод построчный у TFT-дисплеев.
Вывод можно настроить полюбому.. Но рациональнее задавать один раз поле, а потом лить в него последовательно символ, несколько столбцов бакгроунда (межсимвольный промежуток), потом опять символ и т.д.. Поэтому перезаливка полей, даже на очень крупных шрифтах, глазу не заметна..)) я просто не так часто трачу времени на смену координат)) Дисплеи на 8мгц SPi работают довольно шустро. Глаз чуть-чуть только подлавливает первичную полную заливку))
Just_Fluffy писал(а):
Но тут я или криво читала даташиты на дисплеи, или
или дисплеи, которые у нас традиционно принято считать ILI9341 и прочими, на самом деле идут с другими контроллерами, в частности могут попадаться SPFD5408A, R61520 и другие.. Ну это проявляется, если уж совсем досканально в настройках рзбираться.. Не помню.. там и 2 бита в MADCTL вроде разные.. ещё какие то редко используемые опции.. Но разница незначительна и заморачиваться не стоит..
И по поводу что на асме писать страшно)) В плане того же драйвера для ТФТ я вспотел только один раз) потом по накатаной.. Но, как говориться, лучше 100 раз вспотеть, чем один раз остыть
Добавлено after 35 minutes 45 seconds: Just_Fluffy, а как вы отрисовываете графики, если у вас горизонтальный вывод? График вроде выводится побарно))
Но тут я или криво читала даташиты на дисплеи, или оконный вывод построчный у TFT-дисплеев.
Какой угодно там вывод и на современных дисплеях часто достаточно один байт поменять при инициализации. Например, для ST7735 чтобы как его не поверни отрисовка шла слева направо и сверху вниз нужно в MADCTL записать одно из 4-х значений: 0xA0, 0x60, 0xC0, 0x00. Однако бывают контролеры на которых поменял ориентацию на альбомную и нужно флипить X и Y, а если совсем замороченные где каких-то битиков не хватает, там еще сложнее.
Just_Fluffy писал(а):
не, ну вы еще кресты притянули... Сейчас прибежит двадцать девятый и будет кричать, что это расточительно )))) Только современный ассемблер, только хардкор.
Пусть те кто кричат про расточительность попробуют сконвертить шрифт потратив 0 байт RAM и флеша и 0 тактов CPU, на чем угодно )
Пусть те кто кричат про расточительность попробуют сконвертить шрифт потратив 0 байт RAM и флеша и 0 тактов CPU, на чем угодно )
не кричать не пробовать не буду
Когда то я делал всякие шрифты. Делал индексированные переменной ширины. И, если речь идёт об экономии места, а шрифт очень крупный, то применял такой изврат: Например из буквы "Щ" через таблицу индекса можно было выбрать Щ, Ш и Ц. Из буквы "Ю" выбиралась О, причём и ру и ен. Так же буквы А, С, Р, К.. и т. д. дублировали друг друга ру и ен.. А в основной таблице последовательность была "Ъ(небольшой пробел)Щ" и выбиралось соответственно Ъ, Ь, Ы, Щ, Ш, Ц Английская заглавная "I" выбиралась в любом месте.. То есть для полной таблицы ascii высотой 24px экономия была существенная))
И в какой то момент я на всё это забил)) Мы же книги на дисплеях не пишем. И вполне хватает несколько каких то стационарных надписей. Поэтому мне проще сделать любую надпись одним блоком, пусть даже символы в надписях повторяются, но это всё равно будет экономичнее по многим параметрам, чем использование таблиц. А таблицы у меня на в основном 0123456789ABCDEFx и дополнительные символы если нужны типа % и т.п..)) При накопленном опыте и инструментах в принципе любую блочную надпись сделать не сложно. Нужды в таблицах нет
Добавлено after 8 minutes 2 seconds:
Adrift писал(а):
Кстати, попробуйте на своем ILI9341 осциллограмму вывести, а потом энкодером ее масштабировать, у многих на ARM тормозит )
масштабирование пока не осваивал и даже о алгоритме масштабирования пока не задумывался
Добавлено after 3 minutes 12 seconds: Хотя вру.. В последнем графике есть зачатки настройки масштабирования.. Но это чисто что бы график в нужное поле вогнать )) Всё равно стационарно)
Когда то я делал всякие шрифты. Делал индексированные переменной ширины. И, если речь идёт об экономии места, а шрифт очень крупный, то применял такой изврат: Например из буквы "Щ" через таблицу индекса можно было выбрать Щ, Ш и Ц. Из буквы "Ю" выбиралась О, причём и ру и ен. Так же буквы А, С, Р, К.. и т. д. дублировали друг друга ру и ен..
Не вы одним таким страдали ) Вопрос в том делалось ли это все вручную или какая-то утилита все проделывала автоматически... Моя старая прога для ПК генерила вот такие текстурки:
Тут 159 символов 8x12, где также обрезано пустое пространство по краям, потом символы поворачиваются или флипятся, cреди всего этого находятся дубликаты и т.д.. Заполнение текстуры 98% и упаковка в ней символов - это самая сложная часть. Потом я уже экспорт для мк добавлял...
shonty писал(а):
Мы же книги на дисплеях не пишем. И вполне хватает несколько каких то стационарных надписей. Поэтому мне проще сделать любую надпись одним блоком, пусть даже символы в надписях повторяются, но это всё равно будет экономичнее по многим параметрам, чем использование таблиц. А таблицы у меня на в основном 0123456789ABCDEFx и дополнительные символы если нужны типа % и т.п..)) При накопленном опыте и инструментах в принципе любую блочную надпись сделать не сложно. Нужды в таблицах нет
Суть в том, что у вас один шрифт, но перед использованием можно указать как именно его хочется использовать. Например, хотите вы все надписи делать одним шрифтов, а время выводить другим, тогда можно для этого другого передать строку ":0123456789" и будет создан новый массив во флеше где присутствуют только эти символы, с отрисовкой по горизонтали или диагонали, как вам угодно. И поскольку оригинальный массив не используется, то компилятор его выкинет, оставив только новый. Никаких утилит, работает с tiny13 )
shonty писал(а):
масштабирование пока не осваивал и даже о принцыпе масштабирования пока не задумывался
Не, не в том смысле масштабирование ) Было в одном делении 10us, крутанули энекодер и стало 20us, старую осциллограму нужно стереть не затрагивая всего остального и потом нарисовать новую, возможно еще какой-то текст поменяется.
Не знаю что за устройства, но однажды я написал драйвер под ST7735, и в последствии с небольшими изменениями он был доработан и под ILI9341 и под разные разрешения от 128*128 до 240*320. Если попадётся 320*480, то переделать не составит больших затрат И адаптировать драйвер под контроллер для меня тоже не особо затратно.
Да причем тут драйвер! Я к тому, что писать на асме весь функционал устройства при размерах кода более 4-8-16 кб долго и не всегда оптимально.
shonty писал(а):
а как вы отрисовываете графики, если у вас горизонтальный вывод? График вроде выводится побарно))
попиксельно, батенька, попиксельно. Точно так же, как не-горизонтальные, не-вертикальные линии, окружности... Для дисплеев с 8бит на пиксель и выше - непосредственный вывод пикселя (да, это накладно, через RASET/CASET задать только первую координату, потом заслать 1 пиксель. Для ОЛЕД1306 - драйвер в памяти держит видеобуфер, все рисование идет в этом буфере. Потом по команде идет апдейт в дисплей только тех областей, которые менялись после прошлого апдейта.
Adrift писал(а):
Кстати, попробуйте на своем ILI9341 осциллограмму вывести, а потом энкодером ее масштабировать, у многих на ARM тормозит )
Так тут надо разделять математику и вывод. Если пытаться отрисовать 10000 точек на дисплее шириной 320 точек (т.е. 30+ точек на один столбец дисплея) - это одно. Если пробегаемся по массиву 10000 точек и усредняем их во второй массив 320 точек - и выводим только эти 320 точек - это другое. В основном тормоза получаются в математике - обработать большой массив...
попиксельно, батенька, попиксельно. Точно так же, как не-горизонтальные, не-вертикальные линии, окружности...
нее.. у меня по выводу графика более примитивный сюжет)) В памяти массив из 320 переменных. Тупо считываю переменную и выожу столбец графика. Что бы разрывов сильных не было точка графика 3px. Поле один раз задаю. Столбцы сами инкрементируются..
Но я писал, я особо графиками не злоупотребляю)) Вот сейчас перед выбором стою: накатить график или просто в цифрах девиацию за определённое время выводить))
Кстати)) раз пошла такая пьянка) Как вы относитесь к тачскринам на этих дисплеях? я заказал 5 шт. дисплеев, а продавец перепутал, прислал с тачем.. Что то меня тач не впечатлил Да он ещё блёклость какую-то придаёт.. Хотя вам наверное пофиг) Вы же на заказ кодите, а я для себя) Так и не придумал как эти тачи оторвать боюсь сломать
Добавлено after 8 minutes 21 second:
Just_Fluffy писал(а):
попиксельно, батенька, попиксельно.
ну вот и разобрались)) Теперь мне понятно, почему вам с этими дисплеями работать грустно, а мне весело
Добавлено after 6 minutes 55 seconds: Попиксельно это вроде caset/raset/ramwrite + цвет пикселя.. 72 бита на пиксель?
Так тут надо разделять математику и вывод. Если пытаться отрисовать 10000 точек на дисплее шириной 320 точек (т.е. 30+ точек на один столбец дисплея) - это одно. Если пробегаемся по массиву 10000 точек и усредняем их во второй массив 320 точек - и выводим только эти 320 точек - это другое.
Речь про тормоза вызванные медленной отрисовкой. Скажем в одном случае берем из массива 320 байт подряд, потом крутим энкодер и берем 320 байт через один. Выводят не точки, а наклонные линии, которые, в свою очередь, состоят из вертикальных или горизонтальных линий поменьше. Вот ими все и рисуется, а тормозит у тех кто рисует по точкам, хотя на AVR по идее будет тормозить в любом случае )
Adrift, а как нарисовать не-вертикальную и не-горизонтальную линию можно? Только по точкам... Брезенхемом или другим алгоритмом (но брезенхем быстр и целочислен)... Другого пути нет. А графики я рисую почти всегда линиями, кстати. От одной точки к другой. Но с учетом того, что пределы графика редко когда совпадают с областью вывода - сначала все данные обрабатываются и укладываются в массив размерностью по ширине поля вывода. Далее ищется мин/макс для масштабирования. Далее масштабирование можно делать сразу при выводе, либо прогнать по массиву. Если точек данных меньше, нежели столбцов в области вывода - вывод растягивается. Ну и далее линии от первой точки ко второй, от второй к третьей и т.д. В случае TFT, если ОЗУ позволяет, проще "отрисовать" график в каком то буфере, а потом выплюнуть весь буфер в область графика. Но тут уже надо смотреть, что будет быстрее.
shonty писал(а):
Хотя вам наверное пофиг) Вы же на заказ кодите, а я для себя)
На заказ я консультирую тупых юзеров по работе в учетной системе, да правлю/пишу код на PLSQL. А радиолюбительство - это хобби. Если на заказ что то получится сделать - хорошо. Но это сейчас стало достаточно редко...
shonty писал(а):
Как вы относитесь к тачскринам на этих дисплеях?
Вполне нормально. Но после емкостных тачей на телефонах, когда там еще всякие покрытия олеофобные, резистивный пластмассовый тач возвращает меня в эпоху палмтопов со стилусами. Надо не прикасаться, а нажимать - не тач-скрин, а пуш-скрин))). И засирается он сильно. А в остальном - волне себе норм. Опрос тача делается на SPI с медленной скоростью (500кГц, например), его можно сделать на машине состояний и на прерывании от SPI. Минус тача в том, что его координаты никак не соответствуют координатам в дисплее. Нужно делать калибровку хотя бы по двум точкам диагональным, а лучше по 4м или по 9. А дальше все просто. На экран добавляются контролы - это могут быть метки, кнопки, чеккеры, радиобатоны... При добавлении контрола задается его реакция на нажатия, области нажатий... Далее рисовальшик рисует эти объекты на дисплее. Старт опроса тача идет по сигналу нажатия от него, дальше вычисляются координаты нажатия. После получения координат идет перебор экранных объектов - если нажатие попадает в область нажатия какого то из объектов - генерируется событие "нажатие" с номером объекта и номером его области нажатия. Либо сразу колбек на обработчик нажатия для конкретного контрола. Если никуда не попало - то нажатие игнорируется. Но вот честно, на асме я б это не рискнула делать. Асмовые вставки для оптимизации обмена с дисплеем - да, можно. Ибо обмен - бутылочное горлышко при выводе графики. А остальное все - ЯВУ. Это проще и быстрее. А с моим подходом к абстракции от железа - даже легко переносимо между разными МК. И достаточно легко - между разными семействами МК.
а как нарисовать не-вертикальную и не-горизонтальную линию можно? Только по точкам... Брезенхемом или другим алгоритмом (но брезенхем быстр и целочислен)... Другого пути нет.
Спойлер
Код:
drawLine(int x1, int y1, int x2, int y2, uint16_t color) { int dx = std::abs(x2 - x1); int dy = std::abs(y2 - y1);
if (!dx) { fillRect(x1, y1, 1, dy + 1, color); return; }
Минус тача в том, что его координаты никак не соответствуют координатам в дисплее. Нужно делать калибровку хотя бы по двум точкам диагональным, а лучше по 4м или по 9.
Да-да.. Середину вроде откалибровал, а края всё равно сбиваются
Just_Fluffy писал(а):
И засирается он сильно.
И чисто по тактильным ощущениям, да и по эстетическим не нравится ..
А с работой то я его разобрался. как раз на lgt8 и гонял.
shonty, в интернетах пишут, что тач нельзя опрашивать на высоких скоростях, как то скорость SPI влияет на точность позиционирования. Может там АЦП работает не сам по себе, а в момент чтения данных, не знаю. Но требование к низкой скорости заставило меня на АВРке делать конвеер на прерывании. Я калибровку делала по 4 точкам в углах экрана. В принципе, хватает. Под палец области надо большие делать, точности хватает.
Adrift, Ага )) Везде так. И потом из года в год таскаешь за собой готовые блоки по проектам... Единственное, я по нормальному кресты так и не освоила. В школе пичкали бейсиком, в ВУЗе - паскалем. Первый раз Си потрогала, когда автоматизацию управления установкой делали в одном НИИ в 1996 году.
И давайте, если хочется поговорить про графику и разные дисплеи - то уползем в отдельную тему? А то как бы тема про мегу 8 и олед....
shonty, в интернетах пишут, что тач нельзя опрашивать на высоких скоростях, как то скорость SPI влияет на точность позиционирования.
У меня в проекте на spi висел дисплей, тачскрин и ещё один датчик. У датчика spi вообще с обратным клоком был.. Так что при обращении к чему либо spi постоянно перенастраивался.
Аппаратный spi.
Добавлено after 39 seconds: Всё соблюдал) и полярность клока и скорости))
Добавлено after 2 minutes 35 seconds:
Just_Fluffy писал(а):
И давайте, если хочется поговорить про графику и разные дисплеи - то уползем в отдельную тему? А то как бы тема про мегу 8 и олед....
Давайте.. Но ведь начнём про одно, съедем на другое))
// Инициализация дисплея if(!display.begin(SSD1306_I2C_ADDRESS, OLED_RESET)) { Serial.println(F("Failed to initialize SSD1306!")); while(1); }else{ Serial.println(F("Success to initialize SSD1306!")); }
display.clearDisplay(); // Очистить экран display.setTextSize(1); // Установить размер текста display.setTextColor(SSD1306_WHITE); // Установить цвет текста display.setCursor(0,0); // Установить курсор в начало display.print(F("Hello, World!")); // Вывести текст display.display(); // Обновить экран }
void loop() { display.clearDisplay(); // Очистить экран display.setTextSize(1); // Установить размер текста display.setTextColor(SSD1306_WHITE); // Установить цвет текста display.setCursor(40, 25); // Установить курсор display.print(F("Круг:")); // Вывести текст display.drawCircle(64, 32, 20, SSD1306_WHITE); // Нарисовать круг display.display(); // Обновить экран delay(1000); // Задержка в 1 секунду }
Давайте вернемся в русло темы OLED1306. Дисплей имеет 1 бит на пиксель, организация - горизонтальными блоками высотой 8 пикселей (1 байт). Любой вывод, который не идет сразу в 8 пикселей одного блока - сразу становится интересным - задача комбинирования уже отрисованного изображения и выводимого без доступа к данным отрисованного - становится нетривиальной. Обычно для таких дисплеев выделяется буфер в ОЗУ. В нашем случае 64*128 = 8192 бита или 1 килобайт. И все рисование производится в этом буфере, который потом можно выплюнуть в дисплей. Можно уменьшить размер буфера, например, до 8 пикселей по вертикали, но это менее удобно.
Хотя, если писать на асме и стараться использовать только регистры, то, наверное, можно минимизировать использование ОЗУ. Но... зачем?
Так и не смог понять, зачем вам считывать пиксели с матрицы, так как пиксели там те, которые вы сами нарисовали.. Но вот всерьёз задумался над переходными эффектами смены изображения.. типа растворения или "стекания". Но мысль не использовать ОЗУ, а перед выводом делать AND или OR с маской. И программно это сделать не сложно. Тут основная сложность придумать нормальную маску.. Для "растворения"/"проявления" в идеале подошёл бы генератор случайных чисел, но это затратно для меги
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 21
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
это вроде caset/raset/ramwrite + цвет пикселя.. 
