ili9341 SPI

didim

Всем привет. Есть желание разобраться с кодом для дисплея ILI9341 для STM32 на HAL. Если использовать SPI 8 бит вроде бы как все работает, но очень медленно даже на прерываниях - заливка экрана около 1 секунды. Если слать данные через DMA ( HAL_SPI_Transmit_DMA вместо HAL_SPI_Transmit_IT), то результат такой же (все те же 8 бит) - медленное обновление.

Как для HAL организовать шуструю отправку данных на дисплей (заливка, рисование, текст, картинки)? С 16 битным режимом на HAL странность какая-то, в stm32f1xx_hal_spi.h все функции передачи данных только 8 бит.

Поделитесь, пожалуйста, примером для HAL для этого дисплея.

Реклама

dosikus

Без кала все делается, без кала...

Реклама

didim

акий остряк

BorisSPB

Что касается 16 бит, вот что мы видим в коде stm32f1xx_hal_spi.c:

Код: Выделить всё

HAL_StatusTypeDef HAL_SPI_TransmitReceive(SPI_HandleTypeDef *hspi, uint8_t *pTxData, uint8_t *pRxData, uint16_t Size, uint32_t Timeout)
{
...
    /* Transmit and Receive data in 16 Bit mode */
    if(hspi->Init.DataSize == SPI_DATASIZE_16BIT)
    {
      if((hspi->Init.Mode == SPI_MODE_SLAVE) || ((hspi->Init.Mode == SPI_MODE_MASTER) && (hspi->TxXferCount == 0x01)))
      {
        hspi->Instance->DR = *((uint16_t*)hspi->pTxBuffPtr);

Так что несмотря на указатели uint8_t *, в 16 битном режиме они приводятся к uint16_t*.

Реклама

didim

но для функций типа
HAL_SPI_Transmit_DMA и HAL_SPI_Transmit_IT
не прописано режимов в 8 или 16 бит, а по умолчанию только uint8_t *pData стоит и все

Реклама

gotik.edik

Моя реализация. Правда еще не долизанная.

Реклама

didim

gotik.edik писал(а):Моя реализация. Правда еще не долизанная.

как по скорости получилось?
через DMA получается хорошо, но не все можно вывести на экран целым буфером - линии, круги и т.п. они, конечно не очень быстро отрисовываются

Мурато Мяуконни

Если не хватает внутренней оперативки на полный кадр и нет внешней, тогда целесообразно делать двойную буферизацию. То есть, выделить два одинаковых буфера, стоящие друг за другом в адресном пространстве. И пока передается просчитанный первый буфер, считается второй буфер. Когда первый буфер передан, а второй уже просчитан, запускаем передачу второго буфера и считаем первый буфер. Неудобно, конечно, но зато быстрее, чем ждать сначала передачи, а потом просчета.

Мурато Мяуконни писал(а):Если не хватает внутренней оперативки на полный кадр и нет внешней, тогда целесообразно делать двойную буферизацию. То есть, выделить два одинаковых буфера, стоящие друг за другом в адресном пространстве.

Интересно, как можно выделить 2 буфера, при нехватке памяти даже для одного ?
И почему обязательно их расположение друг за другом ?

Мурато Мяуконни

Это же очень просто, предельно просто!
Два буфера размером меньше размера полного кадра. Например, 1/8 кадра или 1/16 кадра. Столько, сколько можно выделить оперативки под буфер.
А расположение друг за другом - потому, что DMA, когда передает, у него есть флаг передачи половины буфера и флаг передачи полного буфера. Эта возможность используется, чтобы не переключать адреса памяти DMA. То есть, для DMA буфер получается один, но разбитый на два. Потому что, чтобы изменить адрес, нужно остановить канал (или поток) DMA, изменить и снова его включить.
Так что, всё нормуль.
На практике, затраты времени на просчет буфера (с реальными данными) приблизительно равны времени передачи буфера.

Мурато Мяуконни писал(а):Например, 1/8 кадра или 1/16 кадра. Столько, сколько можно выделить оперативки под буфер.

А если выводим что-то, что выходит за рамки области этих двух буферов ? Например - линия во весь экран.

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

В любом случае, при возврате на первый буфер, придётся делать эти манипуляции.
ИМХО, тогда лучше их делать для каждого буфера, имея уже отработанный кусок программы, принимаемый начальный адрес буфера и (пере)запускающий DMA.

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

Не факт. Всё зависит от обработки данных (алгоритм, объёмы, ...). Время обработки может значительно превышать время вывода. И тут придётся делать синхронизацию вывода с окончанием обработки, что накладывает ещё лишние телодвижения.

Мурато Мяуконни

Это не проблема. Экранные координаты то не зависят от координат в буфере. Экранные координаты находятся в главной функции формирования кадра. Главная функция рисует картинку так, как будто буфер полноразмерный, но с одним исключением - отслеживается заполнение каждого из двух буферов. Как только буфер заполнен, просчет приостанавливается, запускается передача сформированного буфера, и запускается просчет следующего участка. Ну и так далее, пока не будет достигнут конец экранных координат в главной функции.
Да, это неудобно, да, лишние движения, но другого выбора нет. И всё равно, даже с такими движениями картинка отрисовывается быстрее.
При возврате в первый буфер DMA просто запускается заново. В принципе, это не так принципиально, как именно сделано. Но на практике приходишь как раз к такому варианту.
И даже если использовать одинарный буфер, то формирование кадра выглядит почти так же, только буфер по заполнении не переключается, а только останавливается его заполнение до окончания передачи буфера в дисплей. Размер буфера меньше размера кадра дисплея.
Такой дисплей можно полностью вписать только в F429, да и то лишь при 16-битном цвете.

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

Не хотим возиться с лишними телодвижениями - ставим внешнюю SRAM (SDRAM) побольше размером и получаем в качестве бонуса чудесные эффекты послойной компоновки, наложений с альфа-каналом, предварительного просчета графических элементов. Из минусов - дороговизна SRAM, издержки обмена SDRAM, два полных порта выводов отнимается на FSMC (FMC), усложняется программа. Хотя работа дисплея упрощается до уровня "включили и поехали".

gotik.edik

Аlex писал(а):
Мурато Мяуконни писал(а):Если не хватает внутренней оперативки на полный кадр и нет внешней, тогда целесообразно делать двойную буферизацию. То есть, выделить два одинаковых буфера, стоящие друг за другом в адресном пространстве.
Интересно, как можно выделить 2 буфера, при нехватке памяти даже для одного ?
И почему обязательно их расположение друг за другом ?

Согласен. А потом еще дать понять EmWinу как его пережевывать для Ili9341. И это все на RE чипе без FMС/FSMC.

Моей библиотеки вполне хватает работать с EmWin. А вот мультики, извините, на SPI экране не посмотришь, да и не для этого они, тут нужен 8080 + FSMC.

Сугубо мое имхо.

Мурато Мяуконни

Не, а в чем конкретно сложности то? Эмвин, это который плагин-генератор кнопочек чтоль? И вы не знаете, как его вписать?
А без него - всё, кратны, затык? Неужто не сумеете самостоятельно написать синенькую кнопчку и положить поверх нее текст, а рядом поставить окошечко квадратненькое для циферок? Да ну вы что, это даже процедурно (математическим алгоритмом) пишется в два счета. А вывод растрового массива можно вообще без оперативки делать. Компоновщик кадра - это ж двойной цикл с координатами XY. В него и встраивайте всё. Причем, можно вообще без выделенной оперативки, можно прям сразу, во время вывода, если ваша система имеет достаточное быстродействие.
Но если хотите получить серьезный результат, вам придется использовать нормальный чип и видеопамять.
А раз не хватает оперативки, то для более-менее нормальной работы с дисплеем у вас другого выбора то и нету. Либо шашечки, либо ехать.

И что такое RE-чип? Эт что еще за зверь? С буквами RE в названии я вам навскидку назову десяток штук сразу.
Нет FMC - так возьмите другой чип, че такого то. По тем или иным причинам не можете поставить другой чип - тогда пользуйтесь тем, что есть, у вас других путей нету. Или не хватает знаний? Тут уж ничего не поделать - свои мозги в чужую голову не вложишь. Хоть я и попытался это сделать, так на меня еще и обиделись некоторые тут.

Не посмотришь мультики? Странно. А что, разве 20-25 fps получить такая проблема чтоль? Да ну, вы что. И хотя кое-кто тут тряс китайскими бумажками, что типа невозможно, но нет, ошибаетесь, возможно. Но вопрос в другом - чтобы смотреть мультики, нужно иметь не только быстрый интерфейс дисплея, но и быстродействующую подсистему формирования этих мультиков.
Высокий fps нужен не только для видео, но даже и в обычных экранных менюшках. Кому понравится тормознутая графика то?

gotik.edik

Дорогой дружище МУРАТО !

!!!! Во первых, RE чипы во всех сериях STM32 имеют одинаковую флеш и память, а так - же наличие FMC/FSMC( в зависимости от сери, и это уже будет Vx 100 ногий)
ВЫВОД: Читайте доки, они иногда открывают глазенки !
!!!! Во вторых ! Если вам не подуше EM-WIN и вы хотите лепить свой кривой горшок, ложить кнопочки, квадратики, потом его оптимизировать, это сугубо ваше личное дело.
WMов много и это выбор каждого человека. Где требуется скорость, на маленьких объемах и на простых задачах с граф. интерфейсами я тоже иногда пишу все свое.
ВЫВОД: Считаете Emwin плагингенератором, ну я наверное тут просто промолчу, видимо вы его даже в руки не брали, а нявкать попусту, ну как минимум не красиво
!!! В третих. По поводу можно и или нельзя мультики, 25-кадров получить, то можно и хрен сломать и зубочисткой бетонную стену процарапать, вот только нужно - ли ? Для
динамической картинки есть масса других граф. подсистем, тот - же 8080, при желании перейти на LVDS можно, или на другой интерфейс, прицепить SDRAM либо если
это чип младе 4xx линейки, то SRAM, не суть в этом... Я не пойму смысл вашего поста ? В решили кому - то щелкнуть по носу величайшими навыками рисования на
коленке кнопочек и квадратиков ? Лично я это учил лет так 20 назад в Универе, меня вы нге удивили. А так - же я вам скажу, что готовая система WM заткнет вашу
самописную за пояс на 1,2,3 ! Если конечно вы ее не писали лет 5, а потом не оптимизировали и дорабатывали еще года три !

Еще раз повторю, для резиновых умников, типа "Мурато", SPI экрана вполне хватает для граф. интерфейса с использованием EmWin. Если вы собираетесь для пары окошек городить огород, который в итоге поднимет цену устройства в несколько раз, то Вас, господин Мурато, работодатель выставит на улицу вместе с вашими горшками !

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

Надеюсь здесь присутствующие меня поддержат.

Мурато Мяуконни

gotik.edik писал(а): Надеюсь здесь присутствующие меня поддержат.

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

А то я беспокоюсь за ваш рассудок.

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

20 лет назад в наших "универах" учили тому, чем гордиться нынче стыдно. Вот вам и результат - вы нынче даже не знаете, как же

gotik.edik писал(а):потом еще дать понять EmWinу как его пережевывать для Ili9341. .

Я ничего не придумал, вы сами написали это.

gotik.edik писал(а):Если вы собираетесь для пары окошек городить огород, который ...

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

gotik.edik писал(а):, я просто людям отдал оптимизированную библиотеку под экран...

Открыл, посмотрел... Уууууу... "Оптимизированную", говорите? уууууу..... Там всё переделывать надо. Это этом Х@#але (HAL) далеко не уедешь. И прочтите даташит на дисплей внимательно. Часть команд вашей инициализации в готовом дисплее не поддерживается. Лучше уж сами глазенки свои открывайте

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

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

gotik.edik

Корона не жметь голову ?

HAL не такой, команды не такие... У вас с психикой там все ок ?

А пользовать HAL или нет, я уже писал. Это сугубо ваше право. На простых задачах я его его использую, мне никапельки за это не стыдно. Крупные корпорации делают проекты не просто на HAL, а на Simulink, а это еще более МАКРО.

Ладно, больше вас трогать не буду. Выздоравливайте.....

Мурато Мяуконни

gotik.edik писал(а): HAL не такой, команды не такие.....

HAL_StatusTypeDef SPI_WaitFlag(SPI_HandleTypeDef *hspi

Да ну, неужели? правда чтоли?

и чем принципиально ваш кал (HAL) отличается от калокуба?
Херня всё это. Вы не доделали даже и этот кал (хал).
Я расписал, как положено грамотно делать. Но у вас кал в голове. Пишите на любом кале, но хотябы грамотно то. Если уж выкладываете свои творения, то хоть чтоб люди не плевались то...
"Крупные корпорации, крупные корпорации".. А что, в "крупных корпорациях" не бывает своих калоистов или наоборот, толковых челов?
Как думаете, вот чем отличается тот же Эппл от Микро-мягких?

Кароч, как голубь в шахматах - раскидал все фигуры и полетел рассказывать, как он соперника уделал.

gotik.edik

и чем принципиально ваш кал (HAL) отличается от калокуба?
Херня всё это. Вы не доделали даже и этот кал (хал).

Умат.... Вы сами поняли, что сказали ?

STM32Cube и написан, для генерации процедур инициализации периферии. Они не просто отличаются

, а они сделаны один для другого. Я плакаль )))).....

Вы не доделали даже и этот кал (хал)

Просто умиляет.... Чего, чего не доделал ?
HAL вообще - то компания ST разрабатывает. Я как - бы не в праве его доделывать, разве, что только для себя. И к чему цитата статуса была.... ну то ладно....

Если можно, напишите, что вы там такое убойное покуриваете.

P.S. Выздаравливайте...

Мурато Мяуконни

Ой, вы мне сейчас будете сказки рассказывать, ёлы-палы. Кал - он и в африке кал. Хоть "процедуры инициализации периферии", хоть функции. Функции кала - вообще бред сумасшедшего кролика.
Ой блин, лучше доприлижите свою библиотеку. Может, поймете, что она называется драйвером.