ILI9488 3,95 дюйма, сенсорный экран

Проекты Проекты @lilik
22

IMG_20240630_193913
IMG_20240630_1939131024×572 289 KB

VID_20240630_192233
Хрен с ними, с массивами, нашёл другую функцию и она заработала. Медленно правда. А вариант с сенсорным перебором картинок ещё медленнее.

//вывод фотокартинок
#include <Adafruit_GFX.h>
#include <TFT_eSPI.h> 
#include <SPI.h>
#include "ris_.h"//файл хранения массивов фотокартинок
TFT_eSPI tft = TFT_eSPI();// 

void setup() {
 tft.init();
 tft.setRotation(4);
 tft.fillScreen(tft.color565(0,0,0));

  }
void loop() {
draw_Ris(0,0,ris_00,320,480);
draw_Ris(0,0,ris_11,320,480);
}
//
void draw_Ris(int x, int y, const uint8_t *bitmap, int w, int h) { //функция вывода фотокартинки
  if (x < 0 || x + w > 320 || y < 0 || y + h > 480) {
    return;
  }
  tft.setAddrWindow(x,y,w ,h );
  for (int j = 0; j < h; j++) {
    for (int i = 0; i < 2 * w; i = i + 2) {
      tft.pushColor(256 * bitmap[i + 1 + j * 2 * w] + bitmap[i + j * 2 * w]);
    }
  }
}
//

… Варианта типа

byte massiv_1[100]=int massiv_2[50];

не нашёл :slight_smile:

23

Хм…
Не знаю что и сказать если сразу не доходит, что из 100 8-битных точек не получится сделать 50 16-битных…

Попробую еще раз повторить вопрос - картинки у вас 8бит или 16?? Интересуют не массивы. а формат битмапа!

Подсказка - массив типа uint8_t может содержать как 8битные, так 16битные данные

24

Аааа… я в толк никак не возьму :slight_smile: Конечно 16 бит на пиксель, но в двух числах. А надо одно. 8 бит на пиксель это редкость, как и 3 :slight_smile: Но я делал.

25

Да и однобитные и двубитные, всё перепробовал, но здесь другой затык тип нужен в функцию уинт16, иначе ругается.

26

кто вам мешает сделать приведение указателя на массив к типу uint16_t* в момент передачи в функцию, если вы считаете, что только в этом дело?
Попробуйте, только картинку возьмите 16битную

27

Это как? Типа так:

char some_vals[] =  {3,11}; //some char/byte array
    
    short *pshort = (short*) some_vals;
28

типа так

29

Спасибо, до этого догадался только что:

//вывод фотокартинок
#include <Adafruit_GFX.h>
#include <TFT_eSPI.h> 
#include <SPI.h>
#include "ris_.h"//файл хранения массивов фотокартинок
TFT_eSPI tft = TFT_eSPI();// 

void setup() {
 tft.init();
 tft.setRotation(4);
 tft.fillScreen(tft.color565(0,0,0));
 }
void loop() {
draw_Ris(0,0,ris_00,320,480);
draw_Ris(0,0,ris_11,320,480);
//tft.pushImage(0, 0, 320, 480, (const uint16_t*) ris_00);
//tft.pushImage(0, 0, 320, 480, (const uint16_t*) ris_11);
}
//
void draw_Ris(int x, int y, const uint8_t *bitmap, int w, int h) { //функция вывода фотокартинки
  if (x < 0 || x + w > 320 || y < 0 || y + h > 480) {
    return;
  }
  tft.setAddrWindow(x,y,w ,h );
  for (int j = 0; j < h; j++) {
    for (int i = 0; i < 2 * w; i = i + 2) {
      tft.pushColor(256 * bitmap[i + 1 + j * 2 * w] + bitmap[i + j * 2 * w]);
    }
  }
}
//

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

30

Как у Intel, так и у AVR первый байт младший.

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

31

Если считать с права на лево, как и биты. Видно арабы всё же внесли свою лепту )))

32

В конвертере не нашёл как байты местами переставить. А как в приведении типов заставить брать вначале второй байт?

33

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

34

У компьютера нет “справа налево”, у компьютера есть только последовательность адресов. То есть либо от старшего к младшему, либо наоборот.

Отправь на помойку этот конвертер.
Меня вообще удивляет постановка вопроса: ты что, вообще программировать не умеешь, если вместо того, чтобы написать собственный конвертер пользуешься каким-то левым и неудобным?

35

Мне кажется он правильный и красивый :slight_smile:

сборка4
сборка4737×530 117 KB

И не так просто написать аналог. Проще не пользоваться функцией из библиотеки или её переделать. Тем более, что визуально скорость отрисовки картинок одинаковая (скетч из 29 поста). Хотя библиотека весьма богата функциями.

36

на картинке куча опций. например “MSB first” это случайно не то?

37

Честно говоря не знаю. Верхние понятны более, менее, а что эта значит не знаю.

38

MSB - Most Significant Byte - старший байт. MSB First - старший байт передается первым

39

Попробую переконвертировать картинку с галкой на опции.

40

слушайте, если я правильно понял, вы же сами конвертируете байты в uin16 вот этой строчкой:

так что вам мешает взять в ней байты в обратном порядке?

(хотя такой метод “конвертации” - бред редкостный…)

41

Зачем? Эта функция работает правильно в рамках данной библиотеки и цвета выводит верно. А вот штатная функция как теперь выяснилось требует постановки галки на опции MSB First в конвертере и писания при вызове

tft.pushImage(0, 0, 320, 480, (const uint16_t*) ris_33);

а не

tft.pushImage(0, 0, 320, 480, ris_33);

Спасибо за подсказки :slight_smile: