Update: Пока будете писать/экспериментировать, для тестирования рекомендую отправлять экрану не исходную картинку, а тупо массив, заполненный одним цветом, построчно. Посмотрите в библиотеке функцию заполнения прямоугольника (если она там есть конечно), думаю там найдете образец/направление движения к правильному коду.
Проверил крайнюю версию Adafruit библиотеки с github - по умолчанию она стартует на скорости SPI = FCPU/2 - 8 МГц для плат с кварцем на 16 МГц
fillScreen выводит байты парами и заполняет экран 132х162 за ~69-70 мс
Написано не оптимально. Грузит байт и висит пока он не отправится. Если проверять свободен ли SPI перед отправкой байта и не ждать окончания - накладных расходов будет меньше !
Komandir, а вы попробуйте работать с дисплеем не ожидая отправки байта и написать логику чтоб в этот момент что то делать) сложность кода усложняется в разы!
Не...проще просто отправлять партиями построчно, ускориться минимум в три раза за счёт отказа отправки команд по spi
И fillscreen заполняет одним цветом, т е упирается в скорость шины, а если картинку из eeprom тащить то замедляем сразу в несколько раз.
Не будет там в несколько раз.
Оптимально написанное перекодирование, думаю, не вылезет за время ожидания передачи. Т.е. отрисовка картинки будет выполняться практически столько же, сколько и заливка одним цветом.
А зачем цвет/пиксель перекодировать?
Если из 24 в 16 битный цвет то это надо делать заранее и всю картинку хранить уже в правильном расположении цветов.
И fillscreen заполняет одним цветом, т е упирается в скорость шины, а если картинку из eeprom тащить то замедляем сразу в несколько раз.
Не будет там в несколько раз.
Оптимально написанное перекодирование, думаю, не вылезет за время ожидания передачи. Т.е. отрисовка картинки будет выполняться практически столько же, сколько и заливка одним цветом.
Только картинку не из EEPROM, а из Flash.
А вы попробуйте а не думайте)
Я это уже прошёл на stm32, любая online обработка цветов замедляет работу, при spi 48 МГц у меня получалось 29 кадров 320х240 в секунду, МК между отрисовкой кадров не успевает кадр обработать ь
Пока такой вариант раскраски картинки тремя фонами. Пока не очень представляю как от попиксельной передачи перейти к построчной. Нужен доп. буфер на строку? Идея чтоб разноцветные "картиночные шкалы влазили в про мини 168" и указатель-стрелка быстро реагировал на изменение величины.
А вы попробуйте а не думайте) Я это уже прошёл на stm32, любая online обработка цветов замедляет работу, при spi 48 МГц у меня получалось 29 кадров 320х240 в секунду, МК между отрисовкой кадров не успевает кадр обработать ь
Не хочу пробовать.
Для всего, что имеет больше 8 кБайт видеопамяти, я использую исключительно параллельный интерфейс. Ну и, соответственно, для 320*240 - за сотню fps при одноцветной заливке. Это для f103. А для f407 - там радикально быстрее за счет аппаратного интерфейса внешней памяти. Но цифр для этого режима у меня сейчас нет.
Пока такой вариант раскраски картинки тремя фонами. Пока не очень представляю как от попиксельной передачи перейти к построчной. Нужен доп. буфер на строку? Идея чтоб разноцветные "картиночные шкалы влазили в про мини 168" и указатель-стрелка быстро реагировал на изменение величины.
Второй цикл с 21 по 25 строку в идеале заменить на одну команду - отправка в spi шину массив байт, только посмотреть есть ли она...
Про цвет да, массив заполнения заранее предварительно прописать нужным цветом, но вы пока сплошной цвет добейтесь, потом уже картинку рисовать.
И fillscreen заполняет одним цветом, т е упирается в скорость шины, а если картинку из eeprom тащить то замедляем сразу в несколько раз.
В #52 видно что даже одним цветом заполнение идет на 2/3 скорости шины SPI. Это можно/нужно поправить.
Вывод однобитных картинок на цветной дисплей вижу так:
на основании значения очередного бита берем нужный байт цвета и
начало цикла
отправляем его в железо
у нас 16 тактов что бы перейти к следующему биту и если байт картинки кончился - взять следующий
на 16-17 такте отправляем в железо второй байт для пикселя и у нас ещё 16 тактов что бы проверить не кончилась ли картинка, подготовить след байт цвета и перейти на начало цикла
подгоняем NOP ами длительность полуциклов и в бой ...
Перед попыткой выводить моноцвет по другому попробовал на экране тест, :) ожидал серый цвет, но нет, как поломатый телевизор из детства - "белочёрное мельтешенье".
... явно должно быть не как у вас при выводе картинки ...
Нет, конечно быстрее, но не как ssd1306 :)
Я не перепишу функцию tft.fillRect(0, 0, 128, 160,tft.Color565(255,255,255)); вне библиотеки (жабры коротки :) под массив из progmem и уж тем более в её рамках. Не ясно почему её авторы выбрали попиксельный вывод монохромной картинки как оптимальный.
наткнулся на косяк при использовании псевдографики )))
Взял библиотеку с этого форума, тут...посмотрел, в твоей библиотеке отсутствует буква я маленькая
Я конечно дико извиняюсь, но это опять я с этим файлом glcdfont.c в библиотеке <Adafruit_GFX.h> использую совместно с #include <Adafruit_ST7735.h> шрифты встают на свои места, если после первой половины таблицы, в начало второй половины таблицы (>127 символа) вставляю еще один (по сути 257 символ), в таблице это отражено двумя 127 символами.
В какой библиотеке править этот косяк (в каком файле)???
Я наверное че то не понимаю, но вывести пиксельный рисунок на растр ничего не стОит, нафига библиотеки. Есть растр в инете кодировки win1251, а вывести её в экран просто
Я наверное че то не понимаю, но вывести пиксельный рисунок на растр ничего не стОит, нафига библиотеки. Есть растр в инете кодировки win1251, а вывести её в экран просто
в адафрутовской библиотеке есть косяк, хочется найти и исправить, так как я лично её пользую...
да и не должна, я о том и говорю, что в таблице с русской кодировкой 257 символов...
по моему эта тема уже была на форуме, но не нашёл...
В оригинальной с умляутами чётко 256...
Я что этой темой озадачился, не пошла кодировка (отображение псевдографикой) при переносе кода сканера 2.4 на другой камень и другой монитор, ST7735 ... плюнул, переделал на вывод отображения сигнала через графику...и быстрее и точнее получилось...но раз непонятки остались надо эту тему добить
Пытаясь увеличить скорость вывода картинки, напоролся на встроенную в "иде" библиотеку TFT. Думаю, счас скорость другой библиотекой наращу... Полез.
А она по сути и есть адафрутовская из двух. В ней как раз исходник этого файла-буквахрана. Так там 254 символа, если я правильно пересчитал.
PS Буква "я маленькая" и вправду не выводится.
Недооценил я себя. Методом тыка и глубоких диванных раздумий увеличил существенно скорость вывода картинки во весь экран. Но сделать с границами областей и координатами вывода не могу... и мельтишат картинки, всё равно глаз видит смену. Слабый экран в сравнении с SSD1306. Я уже молчу если светодиод(ы?) подсветки перегорит или понадобиться гирлянда экранов на про мини 168? или грамотно ставить резисторы - в делители (10 штук).
неправильные пчёлы и неправильный мёд )))
Даже с оригинальной, что в поставке проблема, там 256 символов, от 0 до 255, исправляешь 255, а выводить его надо как 254 )))
О чём и речь )))
неправильные пчёлы и неправильный мёд )))
Даже с оригинальной, что в поставке проблема, там 256 символов, от 0 до 255, исправляешь 255, а выводить его надо как 254 )))
О чём и речь )))
эт как? может код символа из раблицы кривой берете? есть таблица win1251 например - там все заполнено и нет никакх "исправляешь 255, а выводить его надо как 254"
Кстати померил отношение скоростей вывода в исходном варианте и в крайнем с помощью секундомера. Около 1 к 12 раз.
progmem медленная хрень, в любом случае чуда не случится, глобального улучшения не получите!
Да, я понял, но всё же связываю это с самим экраном. Делал на ssd1306 (4 вывода) мимику глазами роботу-игрушке, 5 картинок-позиций глаз из progmem - смена картинок не видна была.
эт как? может код символа из раблицы кривой берете? есть таблица win1251 например - там все заполнено и нет никакх "исправляешь 255, а выводить его надо как 254"
ua6em пишет:
неправильные пчёлы и неправильный мёд )))
Даже с оригинальной, что в поставке проблема, там 256 символов, от 0 до 255, исправляешь 255, а выводить его надо как 254 )))
О чём и речь )))
в таблице шрифты 5х8, правлю один символ - 255, далее выводить его надо не как 255, а как 254, tft.print(char(254)); тогда всё пучком
Всё разобрался, когда нашёл, что пропускается 176 символ нашёл и отчего это и как решить )))
Исправленный код секундомера под RP2040:
// СЕКУНДОМЕР
#include <Adafruit_GFX.h> // Core graphics library
#include <Adafruit_ST7735.h> // Hardware-specific library for ST7735
#include <Adafruit_ST7789.h> // Hardware-specific library for ST7789
#include <SPI.h>
#define SPI01 // Дисплей на SPI1, NRF24L01 на SPI0
#if defined(SPI01) // для RP2040 SPI1
#define TFT_CS 13 // GP13 - CS
#define TFT_RST 14 // GP14 - RESET
#define TFT_DC 15 // GP15 - A0
#define TFT_MISO 12 // GP12 - MISO (MISO, RX)
#define TFT_MOSI 11 // GP11 - SDA (MOSI, TX)
#define TFT_SCLK 10 // GP10 - SCK
#else // для RP2040 SPI0
#define TFT_CS 5 // GP5 - CS
#define TFT_RST 6 // GP6 - RESET
#define TFT_DC 7 // GP7 - A0
#define TFT_MISO 4 // GP4 - MISO (MISO, RX)
#define TFT_MOSI 3 // GP3 - SDA (MOSI, TX)
#define TFT_SCLK 2 // GP2 - SCK
#endif
// For ST7735-based displays, we will use this call
Adafruit_ST7735 tft = Adafruit_ST7735(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);
float a = 0.00; // переменная для угла поворота стрелки
float aa = 0.00; // переменная для угла поворота стрелки (предыдущее значение)
int str = 55; //длина стрелки в пикселях
byte sek = 16; //
void setup(void) {
// Используйте этот инициализатор, если вы используете 1,8-дюймовый TFT
tft.initR(INITR_BLACKTAB); // initialize a ST7735S chip, black tab
tft.cp437(true); // не пропускаем 176 символ
tft.fillScreen(ST7735_BLACK);
tft.setRotation(1);//ориентация экрана
tft.setSPISpeed(50000000);
tft.drawCircle(80, 64, 63, ST7735_WHITE ); //обод секундомера
tft.drawCircle(80, 64, 62, ST7735_WHITE );
tft.drawCircle(80, 64, 61, ST7735_WHITE );
}
void loop() {
//
aa = a;
// tft.drawLine(80, 64, 80 + cos(aa)*str, 64 + sin(aa)*str,ST7735_BLACK ); // стирание старой стрелки-отрезка
tft.drawLine(80 + cos(aa + 1.5)*str * 0.1, 64 + sin(aa + 1.5)*str * 0.1, 80 + cos(aa)*str, 64 + sin(aa)*str, ST7735_BLACK ); // стирание старой стрелки
tft.drawLine(80 + cos(aa - 1.5)*str * 0.1, 64 + sin(aa - 1.5)*str * 0.1, 80 + cos(aa)*str, 64 + sin(aa)*str, ST7735_BLACK ); // стирание старой стрелки
a = a + PI / 30;
for (float i = 0.01; i < 2 * PI; i = i + PI / 30) {
tft.drawLine(80 + cos(i)*str * 0.9, 64 + sin(i)*str * 0.9, 80 + cos(i)*str, 64 + sin(i)*str, ST7735_GREEN ); // риски-метки шкалы через 1 сек
}
for (float i = 0.01; i < 2 * PI; i = i + PI / 6) {
tft.drawLine(80 + cos(i)*str * 0.75, 64 + sin(i)*str * 0.75, 80 + cos(i)*str, 64 + sin(i)*str, ST7735_WHITE ); // риски-метки шкалы через 5 сек
}
// tft.drawLine(80, 64, 80 + cos(a)*str, 64 + sin(a)*str,ST7735_WHITE ); // рисование новой стрелки-отрезка
tft.drawLine(80 + cos(a + 1.5)*str * 0.1, 64 + sin(a + 1.5)*str * 0.1, 80 + cos(a)*str, 64 + sin(a)*str, ST7735_WHITE ); // рисование новой стрелки
tft.drawLine(80 + cos(a - 1.5)*str * 0.1, 64 + sin(a - 1.5)*str * 0.1, 80 + cos(a)*str, 64 + sin(a)*str, ST7735_WHITE ); // рисование новой стрелки
//
tft.drawCircle(80, 64, 5, ST7735_WHITE );
tft.drawCircle(80, 64, 4, ST7735_WHITE );
tft.setCursor(50, 45);
tft.setTextSize(1);
tft.setTextColor(ST7735_GREEN);
tft.println(utf8rus("СЕКУНДОМЕР"));
tft.setCursor(70, 80);
tft.setTextSize(2);
tft.setTextColor(ST7735_GREEN);
if (sek < 10) {
tft.print("0");
} tft.println(sek);
sek++; if (sek > 59) {
sek = 0;
}
//
delay(835);//подбираем опытным путём
tft.fillRect(70, 80, 30, 20, ST7735_BLACK);
}
////////////////////////////////////////////////////////////////////////
/* Функция перекодировки русских букв из UTF-8 в Win-1251 */
String utf8rus(String source)
{
int i, k;
String target;
unsigned char n;
char m[2] = { '0', '\0' };
k = source.length(); i = 0;
while (i < k) {
n = source[i]; i++;
if (n >= 0xC0) {
switch (n) {
case 0xD0: {
n = source[i]; i++;
if (n == 0x81) {
n = 0xA8;
break;
}
if (n >= 0x90 && n <= 0xBF) n = n + 0x30;
break;
}
case 0xD1: {
n = source[i]; i++;
if (n == 0x91) {
n = 0xB8;
break;
}
if (n >= 0x80 && n <= 0x8F) n = n + 0x70;
break;
}
}
}
m[0] = n; target = target + String(m);
}
return target;
}
///////////////////////////////////////////////////////////////////////////
Правильная версия файла русифицированных фонтов - glcdfont.c
(находится в библиотеке <Adafruit_GFX.h> (заменить или старую переименовать и скопировать новую)
Отвлёкся я на скорость вывода картинки от вариаций раскрашивания. Пока в голову пришло три варианта - сектора цвета, градиент цвета и пиксель-ассорти. Какие ещё варианты могут быть?
Update:
только соотвественно вместо отправки двух байт
14
spiwrite(color >> 8);
15
spiwrite(color);
вам необходимо отправлять массив (буфер)
Update: Пока будете писать/экспериментировать, для тестирования рекомендую отправлять экрану не исходную картинку, а тупо массив, заполненный одним цветом, построчно. Посмотрите в библиотеке функцию заполнения прямоугольника (если она там есть конечно), думаю там найдете образец/направление движения к правильному коду.
Проверил крайнюю версию Adafruit библиотеки с github - по умолчанию она стартует на скорости SPI = FCPU/2 - 8 МГц для плат с кварцем на 16 МГц
fillScreen выводит байты парами и заполняет экран 132х162 за ~69-70 мс
Написано не оптимально. Грузит байт и висит пока он не отправится. Если проверять свободен ли SPI перед отправкой байта и не ждать окончания - накладных расходов будет меньше !
Komandir, а вы попробуйте работать с дисплеем не ожидая отправки байта и написать логику чтоб в этот момент что то делать) сложность кода усложняется в разы!
Не...проще просто отправлять партиями построчно, ускориться минимум в три раза за счёт отказа отправки команд по spi
Ну да.
Сначала setAddrWindow(0,y,_width,y+1);
Затем вместо строк 14-15 - цикл. Даже вложенный цикл: внешний по байтам строки монохромной картинки, а внутренний - по битам внутри байта.
Ну и, как верно заметил Kommandir, вместо ожидания - перекодирование следующего пикселя.
И fillscreen заполняет одним цветом, т е упирается в скорость шины, а если картинку из eeprom тащить то замедляем сразу в несколько раз.
Оптимально написанное перекодирование, думаю, не вылезет за время ожидания передачи. Т.е. отрисовка картинки будет выполняться практически столько же, сколько и заливка одним цветом.
Только картинку не из EEPROM, а из Flash.
А зачем цвет/пиксель перекодировать?
Если из 24 в 16 битный цвет то это надо делать заранее и всю картинку хранить уже в правильном расположении цветов.
Так у него картинка с однобитным цветом. На каждый бит экрану нужно отправить два байта.
Оптимально написанное перекодирование, думаю, не вылезет за время ожидания передачи. Т.е. отрисовка картинки будет выполняться практически столько же, сколько и заливка одним цветом.
Только картинку не из EEPROM, а из Flash.
А вы попробуйте а не думайте)
Я это уже прошёл на stm32, любая online обработка цветов замедляет работу, при spi 48 МГц у меня получалось 29 кадров 320х240 в секунду, МК между отрисовкой кадров не успевает кадр обработать ь
Так у него картинка с однобитным цветом. На каждый бит экрану нужно отправить два байта.
Тогда да, это проще и быстрее.
Пока такой вариант раскраски картинки тремя фонами. Пока не очень представляю как от попиксельной передачи перейти к построчной. Нужен доп. буфер на строку? Идея чтоб разноцветные "картиночные шкалы влазили в про мини 168" и указатель-стрелка быстро реагировал на изменение величины.
Картинка подобно трафарету накладывается на цветной фон.
Для всего, что имеет больше 8 кБайт видеопамяти, я использую исключительно параллельный интерфейс. Ну и, соответственно, для 320*240 - за сотню fps при одноцветной заливке. Это для f103. А для f407 - там радикально быстрее за счет аппаратного интерфейса внешней памяти. Но цифр для этого режима у меня сейчас нет.
Файл - картинка.
Пока такой вариант раскраски картинки тремя фонами. Пока не очень представляю как от попиксельной передачи перейти к построчной.
Нужен доп. буфер на строку?
Пока такой вариант раскраски картинки тремя фонами. Пока не очень представляю как от попиксельной передачи перейти к построчной. Нужен доп. буфер на строку? Идея чтоб разноцветные "картиночные шкалы влазили в про мини 168" и указатель-стрелка быстро реагировал на изменение величины.
Картинка подобно трафарету накладывается на цветной фон.
Нет, все плохо, вам в принципе необходимо избавиться от drawpixel и написать свою замену.
Это вариант где на скорость вывода я не гляжу.
Пока нашёл базовую функцию в библиотеке.
Вместо color в аргументах массив из PROGMEM? 1-бит превращать в один цвет, 0-бит в другой внутри функции?
Второй цикл с 21 по 25 строку в идеале заменить на одну команду - отправка в spi шину массив байт, только посмотреть есть ли она...
Про цвет да, массив заполнения заранее предварительно прописать нужным цветом, но вы пока сплошной цвет добейтесь, потом уже картинку рисовать.
В #52 видно что даже одним цветом заполнение идет на 2/3 скорости шины SPI. Это можно/нужно поправить.
Вывод однобитных картинок на цветной дисплей вижу так:
на основании значения очередного бита берем нужный байт цвета и
начало цикла
отправляем его в железо
у нас 16 тактов что бы перейти к следующему биту и если байт картинки кончился - взять следующий
на 16-17 такте отправляем в железо второй байт для пикселя и у нас ещё 16 тактов что бы проверить не кончилась ли картинка, подготовить след байт цвета и перейти на начало цикла
подгоняем NOP ами длительность полуциклов и в бой ...
так можно выйти на максимум шины SPI
По похожему принципу я сделал вывод на адресную ленту за 14 тактов на бит - https://wokwi.com/projects/328014892704465492
Я по ходу забыл, в файлы библиотеки "...GFX" надо добавить
я тебя не сильно расстрою, если скажу, что один символ в таблице лишний? сходу не нашёл какой именно...
Я по ходу забыл, в файлы библиотеки "...GFX" надо добавить
я тебя не сильно расстрою, если скажу, что один символ в таблице лишний? сходу не нашёл какой именно...
Нет, я брал отсюда, вроде работает без глюков.
http://arduino-kid.ru/blog/adresnaya-lenta-ws2812b-beguschaya-stroka-upravlenie-shriftami
Перед попыткой выводить моноцвет по другому попробовал на экране тест, :) ожидал серый цвет, но нет, как поломатый телевизор из детства - "белочёрное мельтешенье".
выводите через строку черный/белый
какая в итоге частота мерцания ? явно должно быть не как у вас при выводе картинки ...
... явно должно быть не как у вас при выводе картинки ...
Нет, конечно быстрее, но не как ssd1306 :)
Я не перепишу функцию tft.fillRect(0, 0, 128, 160,tft.Color565(255,255,255)); вне библиотеки (жабры коротки :) под массив из progmem и уж тем более в её рамках. Не ясно почему её авторы выбрали попиксельный вывод монохромной картинки как оптимальный.
Ленивые индусы
ssd1306 это 1024 байта, а тут их в 40+ раз больше - плата за цвет. Но есть выигрыш в скорости передачи - 8МГц SPI против 400 КГц (без разгона) I2C
20+ - это на самом деле 40.
Точно ...
Нет, я брал отсюда, вроде работает без глюков.
http://arduino-kid.ru/blog/adresnaya-lenta-ws2812b-beguschaya-stroka-upravlenie-shriftami
наткнулся на косяк при использовании псевдографики )))
Взял библиотеку с этого форума, тут...посмотрел, в твоей библиотеке отсутствует буква я маленькая
Я конечно дико извиняюсь, но это опять я с этим файлом glcdfont.c в библиотеке <Adafruit_GFX.h> использую совместно с #include <Adafruit_ST7735.h> шрифты встают на свои места, если после первой половины таблицы, в начало второй половины таблицы (>127 символа) вставляю еще один (по сути 257 символ), в таблице это отражено двумя 127 символами.
В какой библиотеке править этот косяк (в каком файле)???
Я наверное че то не понимаю, но вывести пиксельный рисунок на растр ничего не стОит, нафига библиотеки. Есть растр в инете кодировки win1251, а вывести её в экран просто
в адафрутовской библиотеке есть косяк, хочется найти и исправить, так как я лично её пользую...
ua6em а есть уверенность что она может больше 256 символов ???
void Adafruit_GFX::drawChar(int16_t x, int16_t y, unsigned char c, uint16_t color, uint16_t bg, uint8_t size) { drawChar(x, y, c, color, bg, size, size);
Что мешает пройти вывод символа по шагам ???
ua6em а есть уверенность что она может больше 256 символов ???
void Adafruit_GFX::drawChar(int16_t x, int16_t y, unsigned char c, uint16_t color, uint16_t bg, uint8_t size) { drawChar(x, y, c, color, bg, size, size);
Что мешает пройти вывод символа по шагам ???
да и не должна, я о том и говорю, что в таблице с русской кодировкой 257 символов...
по моему эта тема уже была на форуме, но не нашёл...
В оригинальной с умляутами чётко 256...
Я что этой темой озадачился, не пошла кодировка (отображение псевдографикой) при переносе кода сканера 2.4 на другой камень и другой монитор, ST7735 ... плюнул, переделал на вывод отображения сигнала через графику...и быстрее и точнее получилось...но раз непонятки остались надо эту тему добить
в таблице с русской кодировкой 257 символов...
:)
Пытаясь увеличить скорость вывода картинки, напоролся на встроенную в "иде" библиотеку TFT. Думаю, счас скорость другой библиотекой наращу... Полез.
А она по сути и есть адафрутовская из двух. В ней как раз исходник этого файла-буквахрана. Так там 254 символа, если я правильно пересчитал.
PS Буква "я маленькая" и вправду не выводится.
Недооценил я себя. Методом тыка и глубоких диванных раздумий увеличил существенно скорость вывода картинки во весь экран. Но сделать с границами областей и координатами вывода не могу... и мельтишат картинки, всё равно глаз видит смену. Слабый экран в сравнении с SSD1306. Я уже молчу если светодиод(ы?) подсветки перегорит или понадобиться гирлянда экранов на про мини 168? или грамотно ставить резисторы - в делители (10 штук).
есть функция в SPI
уже выше неоднократно писалось, сделайте буфер для одной строки и тупо построчно заполняйте экран.
update: наверное как то так, проверить не на чем.
в таблице с русской кодировкой 257 символов...
Даже с оригинальной, что в поставке проблема, там 256 символов, от 0 до 255, исправляешь 255, а выводить его надо как 254 )))
О чём и речь )))
update: наверное как то так, проверить не на чем.
Нет, экран чёрный, сначала не компилировалось, по наитию подправил строку 48 , но не помогло.
в таблице с русской кодировкой 257 символов...
Даже с оригинальной, что в поставке проблема, там 256 символов, от 0 до 255, исправляешь 255, а выводить его надо как 254 )))
О чём и речь )))
эт как? может код символа из раблицы кривой берете? есть таблица win1251 например - там все заполнено и нет никакх "исправляешь 255, а выводить его надо как 254"
update: наверное как то так, проверить не на чем.
Нет, экран чёрный, сначала не компилировалось, по наитию подправил строку 48 , но не помогло.
не подскажу :(
нет такого дисплея, но чую функцию вывода не в 48 строке менять надо, а добавить внутрь библиотеки
Тогда SPI.transfer(&lineBuf, dispW); останется и должна заработать?, а в tft.setAddrWindow(0, j, dispW-1, j); убрать хвост tft.
Кстати померил отношение скоростей вывода в исходном варианте и в крайнем с помощью секундомера. Около 1 к 12 раз.
Тогда SPI.transfer(&lineBuf, dispW); останется и должна заработать?, а в tft.setAddrWindow(0, j, dispW-1, j); убрать хвост tft.
никаких хвостов убирать не надо
по хорошему добавить в библиотеку Адафрута новую функцию которая выводит не пиксель, я именно строку.
Завтра может время найду поставлю эти библиотеки. посмотрю.
Кстати померил отношение скоростей вывода в исходном варианте и в крайнем с помощью секундомера. Около 1 к 12 раз.
progmem медленная хрень, в любом случае чуда не случится, глобального улучшения не получите!
Кстати померил отношение скоростей вывода в исходном варианте и в крайнем с помощью секундомера. Около 1 к 12 раз.
progmem медленная хрень, в любом случае чуда не случится, глобального улучшения не получите!
Да, я понял, но всё же связываю это с самим экраном. Делал на ssd1306 (4 вывода) мимику глазами роботу-игрушке, 5 картинок-позиций глаз из progmem - смена картинок не видна была.
эт как? может код символа из раблицы кривой берете? есть таблица win1251 например - там все заполнено и нет никакх "исправляешь 255, а выводить его надо как 254"
Даже с оригинальной, что в поставке проблема, там 256 символов, от 0 до 255, исправляешь 255, а выводить его надо как 254 )))
О чём и речь )))
в таблице шрифты 5х8, правлю один символ - 255, далее выводить его надо не как 255, а как 254, tft.print(char(254)); тогда всё пучком
Всё разобрался, когда нашёл, что пропускается 176 символ нашёл и отчего это и как решить )))
Исправленный код секундомера под RP2040:
Правильная версия файла русифицированных фонтов - glcdfont.c
(находится в библиотеке <Adafruit_GFX.h> (заменить или старую переименовать и скопировать новую)
Попробовал переставить массив новый вместо старого - буквы сбились, буквы "я" не появилось. В старой версии ещё "ё" неправильно рисуется, как N.
Попробовал переставить массив новый вместо старого - буквы сбились, буквы "я" не появилось. В старой версии ещё "ё" неправильно рисуется, как N.
после 11 строки добавь -
tft.cp437(
true
);
// не пропускаем 176 символ
Получилось, блин теперь во всех скетчах добавлять эту строчку :)
Получилось, блин теперь во всех скетчах добавлять эту строчку :)
да, тогда все 256 символов становятся доступны, в том числе символ градуса - 176 )))
Отвлёкся я на скорость вывода картинки от вариаций раскрашивания. Пока в голову пришло три варианта - сектора цвета, градиент цвета и пиксель-ассорти. Какие ещё варианты могут быть?