Кадровый буфер, или как сэкономить место в ОЗУ

**RIMUS1989i** · 4 мая, 2022

Доброго времени суток. Есть вопрос, использования кадрового буфера. Имеется дисплей с RGB пикселями размер X на Y. Есть буфер в виде массива "uint8_t DATA_DISPLAY[x][y][3];" , где x - высота, y - ширина, 3 - количество цветов. И вот тут получается что если дисплей размером например 20*100 то это 6000 байт, как это дело можно оптимизировать?

Сейчас это работает так, выполняется программа по отрисовке графики и запись в массив, затем из массива по SPI отправляется на дисплей. При отправке работает два цикла один на ось x, другой на ось y. Все работает быстро и красиво но жрет много озу.

Изменено 4 мая, 2022 пользователем RIMUS1989i

Реклама

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

Alex · 4 мая, 2022

1 час назад, RIMUS1989i сказал:

как это дело можно оптимизировать?

Никак.
Для таких вещей существуют внешние RAM.

Реклама

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

**COKPOWEHEU** · 5 мая, 2022

Отправлять в реальном времени без буферизации. Или формировать изображение на лету. Скорее всего, у вас картинка вполне поддается расчету.

Реклама

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

**BARS_** · 5 мая, 2022

18 часов назад, RIMUS1989i сказал:

как это дело можно оптимизировать?

Не формировать весь кадр в памяти. Нафига вообще там весь кадр хранить?
Взять другой МК, где 6 Кб занятого ОЗУ не будут являться проблемой.
Хранить массив не в ОЗУ, а во флеше.
Подключить внешнее ОЗУ (но для этого придется взять нормальный МК)

18 часов назад, RIMUS1989i сказал:

DATA_DISPLAY[x][y][3]

А нафига там аж трехмерный массив? И какой смысл использовать 3 байта цвета, когда у дисплеев есть режим RGB565? Не проще сделать одномерный массив uint16_t, вычислять нужное смещение простым перемножением координат, и выводить этот самый массив одним циклом, что в несколько раз быстрее, чем крутить два цикла?

18 часов назад, RIMUS1989i сказал:

x - высота, y - ширина,

Ну вообще-то, обычно, наоборот...

Изменено 5 мая, 2022 пользователем BARS_

**RIMUS1989i** · 5 мая, 2022

1 час назад, COKPOWEHEU сказал:

Отправлять в реальном времени без буферизации.

Спасибо. Нужно попробовать...

1 час назад, BARS_ сказал:

Нафига вообще там весь кадр хранить?

А каким образом хранить, но не весь?

1 час назад, BARS_ сказал:

Взять другой МК, где 6 Кб занятого ОЗУ не будут являться проблемой.

Пока только atmel серии atmega. Плату под STM32 развел но еще не заказал и их нужно изучать...

1 час назад, BARS_ сказал:

Хранить массив не в ОЗУ, а во флеше.

Каким образом? Картинка динамическая и обновляется в процессе выполнения программы.

1 час назад, BARS_ сказал:

Подключить внешнее ОЗУ (но для этого придется взять нормальный МК)

Не вариант...

1 час назад, BARS_ сказал:

А нафига там аж трехмерный массив?

Для удобства восприятия и в программе, указал xyn цвет и вывел.

1 час назад, BARS_ сказал:

И какой смысл использовать 3 байта цвета, когда у дисплеев есть режим RGB565?

Дисплей самодельный, светодиодный... И по умолчанию один цвет = 16бит, такие микросхемы... При отправке по spi посылаю данные только в старшие разряды. Младшие 8 бит нули.

**BARS_** · 6 мая, 2022

15 часов назад, RIMUS1989i сказал:

хранить, но не весь?

Можно хранить, допустим, 1/5 требуемого буфера, и формировать его частями.

15 часов назад, RIMUS1989i сказал:

Каким образом? Картинка динамическая и обновляется в процессе выполнения программы.

Ну так у Atmega есть же функция положить массив во флеш.

15 часов назад, RIMUS1989i сказал:

Не вариант

Как вариант - поставить два МК. Один чисто для обработки буфера, а другой для всего остального. Сейчас это скорее всего будет даже дешевле, чем ту же STM32 купить...

15 часов назад, RIMUS1989i сказал:

Для удобства восприятия и в программе, указал xyn цвет и вывел.

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

**ChePay** · 6 мая, 2022

Первым делом я бы ушёл от 24 бит на пиксель.

Использовать либо 16 стандартных цветов, либо палитру из 16 нужных цветов.

Это позволит в 6 раз уменьшить размер буфера.

**COKPOWEHEU** · 6 мая, 2022

В 05.05.2022 в 16:57, RIMUS1989i сказал:

А каким образом хранить, но не весь?

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

В 05.05.2022 в 16:57, RIMUS1989i сказал:

Каким образом? Картинка динамическая и обновляется в процессе выполнения программы.

Что, вообще вся? И даже закономерностей в ней выделить не получается? Быть не может. Если вы рисуете GUI, там может быть статичная фоновая картинка, поверх которой рисуются прямоугольники с текстом. Тогда хранить надо только координаты и, не обязательно, текст. А картинка генерируется в реальном времени.

В 04.05.2022 в 20:53, RIMUS1989i сказал:

дисплей размером например 20*100

В 05.05.2022 в 16:57, RIMUS1989i сказал:

Дисплей самодельный, светодиодный...

Вы запаивали 2000 светодиодов вручную?! Маньяк...

В 05.05.2022 в 16:57, RIMUS1989i сказал:

Младшие 8 бит нули.

Ну так зачем их хранить если все равно нули

**RIMUS1989i** · 9 мая, 2022

В 06.05.2022 в 08:04, BARS_ сказал:

Можно хранить, допустим, 1/5 требуемого буфера, и формировать его частями.

Нужно это переварить и осознать, как это организовать...

В 06.05.2022 в 08:04, BARS_ сказал:

Ну так у Atmega есть же функция положить массив во флеш.

Так массив во флеше можно хранить статический не динамический, или что-то я не понял???

В 06.05.2022 в 08:04, BARS_ сказал:

Как вариант - поставить два МК. Один чисто для обработки буфера, а другой для всего остального. Сейчас это скорее всего будет даже дешевле, чем ту же STM32 купить...

Не, мы же не ищем легких путей! И как то это не правильно и расточительно...

@ChePay

В 06.05.2022 в 08:41, ChePay сказал:

Это позволит в 6 раз уменьшить размер буфера.

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

@COKPOWEHEU

В 06.05.2022 в 19:27, COKPOWEHEU сказал:

я когда-то реализовывал трехмерку на stm32f103,

Я развел плату под stm32f103, но как писал выше , её нужно изучить...

В 06.05.2022 в 19:27, COKPOWEHEU сказал:

Что, вообще вся?

Есть вариант отправлять только по столбцу ( да не построчно...), Почему по столбцу? Да потому что это анализатор спектра... При работе FFT удобно, выбрал столбец нарисовал его и т.д. Есть еще нюанс, Я могу обновлять столбцы только по такой схеме: 1,16; 2,17; 3;18, 4;19, 5;20 и т.д. при разводке ПП сложились трудности.

Плюсы микросхем которые я использую, у них есть своя оперативка, но минус я могу её только разом обновлять... По принципу сдвигового регистра. Нет возможности перерисовать только определенные пиксели.

В 06.05.2022 в 19:27, COKPOWEHEU сказал:

Вы запаивали 2000 светодиодов вручную?!

Пока 480... в планах расширить...

В 06.05.2022 в 19:27, COKPOWEHEU сказал:

Ну так зачем их хранить если все равно нули

А никто их не хранит...

static void sendData(uint8_t data)
{
	/* Так, как нужны данные 16бит, то мы просто посылаем два раза по 8бит. Младшие 8бит отправляются пустыми.
		Данные отправляются старшим битом вперед. */
	SPDR = data;					// Отправляем старшит байт
	while(!(SPSR & (1<<SPIF)));	
	SPDR = 0;					// Отправляем младший байт
	while(!(SPSR & (1<<SPIF)));
return;
}

функция обновления дисплея:

Спойлер

#define SCAN_APP 16
#define UNUSED_PINS 4
void Disp_Refresh()
{
	Disp_initLatch();
	uint8_t y = 0;
	uint8_t i = 0;

	for(uint8_t x = 0; x < (SCAN_APP); x++) // Отправляем данные
	{
		for(i = 0; i < UNUSED_PINS; i++)	sendData(0); // Отправляем 0 на неиспользуемые каналы, 4 раза
		for(y = 0; y < DISPLAY_HEIGHT; y++) 
		{
			sendData(DATA_DISPLAY[x + SCAN_APP][y][0]); // Отправляем уровень R
			sendData(DATA_DISPLAY[x + SCAN_APP][y][1]); // Отправляем уровень G
			sendData(DATA_DISPLAY[x + SCAN_APP][y][2]); // Отправляем уровень B*/

		}
		for(i = 0; i < UNUSED_PINS; i++)	sendData(0); // Отправляем 0 на неиспользуемые каналы, 4 раза
		for(y = 0; y < DISPLAY_HEIGHT; y++)
		{
			sendData(DATA_DISPLAY[x][y][0]); // Отправляем уровень R
			sendData(DATA_DISPLAY[x][y][1]); // Отправляем уровень G
			sendData(DATA_DISPLAY[x][y][2]); // Отправляем уровень B
		}
		Latch();
	}
return;
}

Видео.

Спойлер

**ChePay** · 9 мая, 2022

Нет, именно в шесть раз.
Исходно три байта на один пиксель, а можно хранить в одном байте цвета для двух пикселей.

Старшие четыре бита – для одного, младшие четыре – для второго.

**COKPOWEHEU** · 9 мая, 2022

Если речь о самодельном дисплее с динамической индикацией, который используется для вывода преобразования Фурье, достаточно хранить значения для каждой частоты, а уж цвет вычислять на лету.

Поскольку описания работы и устройства у нас как не было, так и нет, начнем с предположений. Допустим, обновление идет построчно, а на каждый пиксель отведено по 32 бита. Допустим, что столбцов всего 3, с координатами (10,10 - 20,100), (30,10 - 40,100), (50,10 - 60,100), текущее значение хранится в массиве bar[3]. Цвет заполненной части будет BAR_FILLED_COL, цвет пустой BAR_EMPTY_COL. Все свободное пространство заполняется фоновой картинкой из флеша. Тогда самый дубовый вариант может выглядеть так:

uint32_t pos2col(int x, int y){
  if( (x>=10) && (x<=20) && (y>=10) && (y<=100) ){
    if( y < bar[0] )return BAR_COL_FILLED; else return BAR_COL_EMPTY;
  }else if( (x>=30) && (x<=40) && (y>=10) && (y<=100) ){
    if( y < bar[1] )return BAR_COL_FILLED; else return BAR_COL_EMPTY;
  }else if( (x>=50) && (x<=60) && (y>=10) && (y<=100) ){
    if( y < bar[2] )return BAR_COL_FILLED; else return BAR_COL_EMPTY;
  }else{
    return background_bitmap[x + y*disp_w];
  }
}

void disp_update(){
  disp_reset();
  for(int j=0; j<disp_h; j++){
    for(int i=0; i<disp_w; i++){
      uint32_t col = pos2col(i, j);
      disp_send(col);
    }
  }
}

**RIMUS1989i** · 10 мая, 2022

18 часов назад, ChePay сказал:

Нет, именно в шесть раз.
Исходно три байта на один пиксель, а можно хранить в одном байте цвета для двух пикселей.

Старшие четыре бита – для одного, младшие четыре – для второго.

Я больше склоняюсь к вашему варианту. Осталось подобрать палитру. Изначально я думал использовать цветовую модель HSV без "value". Но это также минимум 2 байта на пиксель.

В принципе можно использовать и один байт на пиксель. Но опять нужно порыться в цветовых моделях - палитрах и придти к какому то стандарту. :umnik2:

@COKPOWEHEU

Спасибо, я об этом думал. Но это усложняет использование для другой графики: текст, картинка и т.д.

12 часов назад, COKPOWEHEU сказал:

Допустим, обновление идет построчно,

В этом и проблема что обновление идет по парным столбцам писал об этом выше. Оно работает так, всего два провода SPI, sclk и mosi, микросхемы которые стоят на дисплее они по спец импульсу определяют начало приема нового пакета данных и это служит флагом для вывода предыдущих (от прошлого пакета). Но пакет один, а получилось так, что дисплей состоит из двух областей, левая и правая. И тут приходится данные отправлять в такой последовательности: 1 и 16 столбец, 2 и 17, 3 и 18 и т.д. Что усложнят прямую отправку данных для разного типа, картинка, буква, спектр. Если со спектром все просто то вот с буквами не очень. Вот для этого в первую очередь использую буфер, для упорядочивания пикселей чтобы другой человек, если захочет использовать мой проект то ему не нужно будет понимать как оно работает.

**ChePay** · 10 мая, 2022

34 минуты назад, RIMUS1989i сказал:

Осталось подобрать палитру.

Может, ничего не подбирать, а взять стандартные Яркость + RGB:

**RIMUS1989i** · 10 мая, 2022

@ChePay

Нашел стандартный цветовой круг на хабре. По факту это тот же HSV - HSB, и запихнуть его можно в 8 бит. 2 бита яркость, 2 бита оттенок - насыщенность и 4 бита цвета. И это сократит с трех бит на пиксель до одного, и этого достаточно. И работать с этим будет просто и понятно!

Всем спасибо за идеи и участие.

P.s. Возможно когда-то будет отдельный МК только на графику...

**COKPOWEHEU** · 11 мая, 2022

В 10.05.2022 в 10:32, RIMUS1989i сказал:

Спасибо, я об этом думал. Но это усложняет использование для другой графики: текст, картинка и т.д.

Если картинка статичная, то никакой проблемы нет: вы точно так же пересчитываете координаты экрана в координаты картинки.

С текстом могут быть проблемы только если его настолько много, что не помещается в память. Впрочем, хранить-то надо "черно-белый" битмап, что уже в 8-32 раза лучше по памяти. Биту 1 соответствует "цвет текста", биту 0 - либо цвет фона, либо фоновая картинка.

Спойлер

Кстати, я тут пару месяцев назад тоже придумывал как выводить кучу текста столбцами. Вроде получилось:

В 10.05.2022 в 10:32, RIMUS1989i сказал:

В этом и проблема что обновление идет по парным столбцам писал об этом выше.

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

В 10.05.2022 в 10:32, RIMUS1989i сказал:

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

Остановитесь и подумайте каков шанс что ваш проект хоть кто-то будет повторять.

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

Войти

Кадровый буфер, или как сэкономить место в ОЗУ

Рекомендуемые сообщения

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Ссылка на комментарий

Поделиться на другие сайты

Присоединяйтесь к обсуждению

Последние посетители 0 пользователей онлайн

Сообщения