ESP32 против STM32F4. Xtensa LX6 против Cortex-M4F. Наглядная демонстрация силы двух ядер

[@VadRov]

ESP32 против STM32F4. Xtensa LX6 против Cortex-M4F. Наглядная демонстрация силы двух ядер Сравниваем на наглядном примере производительность двух микроконтроллеров. Программы для обоих микроконтроллеров в целом абсолютно идентичные. Разница определяется только спецификой конкретного м/к (работа с периферией). Условия плюс/минус одинаковые: 1. Микроконтроллер STM32F407VET6. Его ядро Cortex-M4F работает на частоте 168 МГц. Подключен дисплей на контроллере ILI9341 по FSMC без использования DMA. Скорость заливки дисплея 320х240 сплошным цветом - 469 кадров/с. 2. Микроконтроллер ESP32-wroom-32. Имеет два ядра Xtensa LX6, работающих на максимальной частоте 80, 160, 240 МГц. Естественно, сравнивать будем производительность по 1 ядру на частоте 160 МГц, но в качестве интереса проверим, на что способен этот м/к при двух ядрах на частотах 160 и 240 МГц. Подключен дисплей на контроллере ST7789 по SPI c использования DMA. Скорость заливки дисплея 240х240 сплошным цветом - 87 кадров/с (c DMA), 74 кадра/с (без DMA).

[@avr_stm_pro2955]

Спасибо 👍👍👍👍

[@kokotmkokot4926]

для графики и GUI выпустили специальную серию STM32U5F/G, с аппаратной поддержкой декодирования, 4 МБ ОЗУ и ПЗУ под видеобуфер и хранение картинок. Активно продвигают для работы с TGFX

[@silentage6310]

и цена наверное за тысячу?

[@kokotmkokot4926]

@@silentage6310 наверное дешевле.. есть альтернативы?

[@SIRepin]

Вы очень грамотно объясняете! Сплю и вижу, когда вы сделаете какие-либо детальные обзоры на микроконтроллеры серии STM32F4... Еще бы и видео по CubeIDE от вашего лица послушать! Очень нравится то, чем вы занимаетесь! У вас научился программы прошивать в микроконтроллер на STM32F411CEU6. Может какие-то проекты еще реализуете на этих железках (STM)?

[@VadRov]

Будут проекты для F4 серии. И про периферию будет кое-что (например, в этом видео намек). А по CubeIDE, что конкретно интересует? Вроде, все стандартно: создал проект, определился с тактированием, настроил периферию, вводы/выводы и вперед программу писать. 😉

[@SevenNightdreemVeryPavlovny]

Красиво, исходники бы увидеть

[@VadRov]

@@SevenNightdreemVeryPavlovny , исходник mGL (на нем эта демка сделана) в проекте видеоплеера на моем гитхабе в папке MicroGL2D. А для esp будет видео о низкоуровневом драйвере дисплея + mGL на два ядра. Конечно, все с кодом будет.

[@SevenNightdreemVeryPavlovny]

@@VadRov благодарю 🤝

[@SIRepin]

@@VadRov , спасибо за ответ! В целом, по каждой настройке Ваш комментарий. Просто, в первых видео Вы говорите, что пока не стоит этим голову забивать, а мне очень-очень интересно, что и за что отвечает!!! Я понимаю, что всё это есть на просторах интернета, вероятнее всего, но лично мне интересно Ваше мнение! Кстати, а вы по специальности кто? У вас есть какие-то курсы? Очень хотел бы у вас научиться ремеслу программирования микроконтроллеров, а также осуществлять какие-то проекты в общем формате (например, на макетной плате собрать схему с подключением тактового двигателя, либо подключение реле, либо семисегментных индикаторов...).

[@silentage6310]

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

[@VadRov]

Каждое из ядер независимо друг от друга выполняет рендеринг заданных ("своих") строк текущего кадра (в ОЗУ есть буфер на несколько строк, а не на весь кадр). Затем, пока готовые строки через DMA выводятся на дисплей, ядра в это время рендерят уже другие строки кадра. Upd. И так последовательно весь кадр. Отдельно друг от друга ничего не "крутится". Объекты определяются свойствами: координатами, цветом, текстурой, углом поворота и т.п., которые можно менять. Рендеринг объектов основан на простой математике.

[@silentage6310]

@@VadRov понял, интересная техника. таким способом конечно можно рисовать даже не имея памяти на полный кадр. но рисовать сложнее.

[@ДмитрийМамичев-к2б]

Присмотрелся к видео :) Жаль, что Ардуино не пользуетесь. Библиотеки с такими функциями-возможностями сообществу пригодились бы.

[@silentage6310]

esp это и так ардуино

[@VadRov]

Ардуино - это кроссплатформенная среда разработки. esp - это прежде всего микроконтроллер, который может быть запрограммирован (если можно так выразится), в т.ч., в этой среде. Для любого м/к мы можем писать программы в любой поддерживаемой среде либо вообще без среды, но при наличии компилятора, который поддерживает наш м/к (текстовый редактор, командная строка и т.п.). В программировании принято говорить об уровнях: низкий, средний, высокий (условно). Ардуино подразумевает высокий уровень. Библиотеки этой среды для м/к не требуют (как правило) от пользователя знания м/к на уровне "железа". Библиотеки для различных м/к унифицированы (например, по именам функций и т.п.) и представляют для пользователя некий "черный ящик", производящий действия по команде/функции. При этом, контроль со стороны пользователя за действиями этой команды отсутствует. Он (пользователь) принимает все как есть (конечно, если его любознательность не распространяется на изучение исходного кода библиотек). НО есть категория пользователей/программистов, которые хотят знать, как работать с м/к на уровне "железа" (низкий уровень). Это продвинутые пользователи, которые хотят писать собственные библиотеки работы с различными встроенными контроллерами и интерфейсами в м/к. Это возможно, если изучить спецификации на м/к от изготовителя. Грубо говоря, это своего рода "высший пилотаж", особенно, если программист использует все возможности м/к, которые заложил изготовитель (например, прерывания, прямой доступ к памяти и т.п.). Такие специалисты, которые понимают, как все работает на уровне "железа", особенно ценятся. Ардуино - это базис, начальный уровень, которого достаточно для большинства самодельщиков, реализующих простые устройства на м/к. Основное преимущество Ардуино - легкость написания ПО для м/к и доступность в этой связи широкого круга пользователей, которых пугают профессиональные средства разработки.

[@Seriyv0lk]

Красавчик!

[@openFrimeTv]

не понимаю что в этом контексте означает рендеринг? взять изображение и рандомно вывести его на экран или что?)

[@VadRov]

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

[@openFrimeTv]

@@VadRov и получается что оно выводит только саму картинку? Как png, без заливки других областей. И ещё и масштабирует. Это капец как сложно на самом деле.

[@VadRov]

​@@openFrimeTv , несложно. Обычная математика на уровне школьной программы. Все правильно. На экране построчно формируется кадр с учетом всех свойств объектов и их взаимного расположения. Да, тут предусмотрены специальные форматы текстур, которые позволяют учитывать не только компоненты цвета точки, но и ее прозрачность - A. Т.е. текстура, наряду с простыми форматами без прозрачности, может быть и в формате RGBA, как в том же png.

[@VasyaPupkinus]

Отличная работа, впрочем как всегда. Я сейчас играюсь с ESP32-S3 , вывожу картинки через библиотеку TFT_eSPI , тоже хорошо работает , скорость 80 Мбит . Услышал в вашем видео про атрибуты для хранения данных в оперативке, у меня на модуле есть 8 мегабайт PSRAM , если я туда все картинки сброшу то есть ли смысл потом их копировать в обычный RAM еспшки ? PSRAM быстро работает, но RAM всёже быстрее , но с PSRAM не нужно возиться с маллоками , каллоками , мемсипию, буферы делать тоже наверное не нужно. Как думаете ?

[@VadRov]

Тут надо смотреть, какая задача стоит и что за картинки (размер). Если Вы, например, игру пишите или "тяжелый" интерфейс, то разумно некоторые объемы текстур (текстуры персонажей, например) держать во временном буфере DRAM и обновлять по мере необходимости. А вообще надо исходить из того, что все данные, как Вы понимаете, изначально хранятся во флэш. А атрибут типа DRAM_ATTR просто указывает начальному загрузчику куда развернуть переменную при инициализации из флэш и по какому адресу к ней обращаться. Кстати, память PSRAM управляется аналогичными образом, через аналоги malloc, calloc и т.п. PSRAM здорово подойдет под буфер кадров. Можно нарисовать несколько кадров, а потом поочередно их выводить на дисплей (если c DMA, то используя промежуточный буфер DRAM).

[@VasyaPupkinus]

​@@VadRov Здравствуйте. На сайте еспрессиф указано "Обратите внимание: хотя ESP32-S3 имеет аппаратную поддержку DMA в/из внешней оперативной памяти, она еще не поддерживается в ESP-IDF." не понятно, если в их среде разработки нет поддержки, то где она есть ? )))) За вчера и сегодня провёл много "лабораторных работ" , с DMA без DMA , задача пока у меня бесполезный вывод картинок по очереди, типа анимация. Атрибут указывал так __attribute__((section(".psram.data"))) . Получилось у меня что вывод картинки из PSRAM работает быстрее всего без DMA. Что бы выводилось с DMA , не достаточно просто указать атрибут, нужно или создать буфер в том же PSRAM и копировать туда по одной, или выделить место под все картинки ( у меня их 33) и тогда можно через DMA работать со смещением адреса ( кривенько работает, артефакты всякие , но работает). ​ @VadRov ваша библиотека, для ESP32 , будет работать на Xtensa LX7 ? не знаю чем они отличаются , но вы в который раз обращаете внимание на LX6

[@VadRov]

@@VasyaPupkinus , писал библиотеку, не основываясь на esp-idf. Библиотека работает со spi и dma на уровне "железа" - регистров (по документации из reference manual). Но она пока для esp32. У esp32-s3 контроллер DMA и SPI иные. Там другая структура регистров и т.п. Xtensa LX7 - это просто ядро (микропроцессор) для встраиваемых систем. Набор периферии и ее архитектуру выбирает производитель м/к. Поэтому работа с периферией зависит только от того, что использовал изготовитель в конкретной серии м/к. Вот у stm32, например, ядра могут быть разными Cortex-M0 - Cortex-M7, а базовая периферия (GPIO, SPI и т.п.) плюс/минус одинаковые, что весьма удобно при переходе от одного семейства к другому (это делается легко). Но здесь китайцы от серии к серии зачастую меняют принципы работы с периферией, наворачивая программный ком в своем фреймворке. Это мне не нравится и это очень неудобно. А еще мне не нравится, когда юзеру не дают шансов управлять железом напрямую. 😉

[@ДмитрийМамичев-к2б]

Добрый день, подскажите, если нетрудно, как читать данные пикселей из ILI9341 на UNO с использованием SPI.h

[@VadRov]

Здравствуйте. Не пользуюсь Ардуино и готовыми библиотеками для работы с дисплеями. Если интересен алгоритм чтения на уровне "железа", то на моём гитхабе есть демка чтения gram памяти дисплеев на контроллерах ST7789 и ILI9341.

[@ДмитрийМамичев-к2б]

Смотрел для STM, и внутри файла display.c функцию чтения пикселя, но сам не адаптирую. Спасибо.

[@xxxx9320]

А потребление тока сравнивали? Имеется в виду при одинаковой производительности, с выключенным wifi и пр.

[@VadRov]

Для esp с выключенными wifi и bt около 50 мА (160 MHz), а для stm32f407vet6 около 59 мА. (168 MHz).

[@xxxx9320]

@@VadRov хм интересно, обычно esp много жрет, особенно в пике бывают скачки, но это вероятно только при включенном wifi...

[@microsource8781]

Спасибо за видео, а не могли бы вы дать прошивку для STM32F407VET6 хочу повторить ваш тест. За ранее спасибо!

[@VadRov]

У Вас такая же плата с дисплеем (комплект) ? Могу прошивку сделать для 320x240, не обрезая до 240х240.

[@VadRov]

drive.google.com/file/d/10jN-5sxuEKR-I27D3jn791NxZOFrhR9x/view?usp=sharing

[@microsource8781]

@@VadRov да комплект. Спасибо если сделаете под 320x240 Отлично все запустилось. При разрешении 320x240 FPS = 11 Спасибо ещё раз!

[@microsource8781]

Под STM писали в Keil или Cube?

[@VadRov]

@@microsource8781 , Cube (без HAL). Upd.: Да, все правильно 11 FPS. Картинка отнимает много процессорного времени при расчете вращения. Надо покопаться в алгоритмах (хотя, это не приоритет для меня). А заливка 469 кадров в секунду?

[@solarrvlab2484]

подскажите пожалуйста в какой среде вы программируете ESP32?

[@VadRov]

Я привык к Eclipse. Поэтому выбрал Espressif-IDE. Но пробовал VSC с PlatformIO (отказался из-за тормозов и нереально долгой сборки проекта).

[@TechnoDuke]

Ну ты автор нашел с чем сравнивать) Старье 10 летней давности от СТ и два ядра 240 МГц. Ну-ка сравни эту негодную ЕСП с STM32H7xx пусть даже одноядерным для начала. Глядишь оптимизма поубавится. Не говоря уже об аппаратном декодере JPEG, DMA2D (глядишь не придется на ассемблере писать процедуры копирования блоков памяти), LTDC или даже DSI контроллере который может дать такой поток данных на экран, что эти хиленькие спайные дисплейчики ножки пооткидывают от такой полосы пропускания. Так что предвзятое у тебя сравнение. Камни от СТ рулят, как бы кому не хотелось ЕСП рекламировать. А вот за видео проигрывателя лайк, так как достойное дело сделал. Однако F4 ну очень старая лошадка. Переходи на H7 ядро. Там куда все пошустрее, много аппаратных примочек тот же декодер джейпега. Дури у ядра на полгигаерца, да еще и две инструкции за такт если с кэшем. Ну а если уже речь об ассемблере, то куда интереснее было бы глянуть на пример использования DSP инструкций кортексов. Обычный асм это банальность. Понятно что это интересно как вид спорта, сделать быстрее чем компилятор. Но этот фокус присущ любой архитектуре и уже не интересен. Все же интереснее использовать специфические инструкции, для ЦОС например, которые и делают камни вкусными для потоковой обработки данных.

[@VadRov]

"Портянкой" отвечать не буду. Читайте описание и слушайте закадровый голос: сравниваем работу м/к по 1 ядру: 1 ядро Cortex-M4 на частоте 168 МГц и 1 ядро Xtensa LX6 на частоте 160 МГц. Остальное, в, т. ч., работа esp32 на двух ядрах к сравнению не имеют отношения, а даны для информации. Ядро и архитектура Cortex-M4 представлены в 2010 году, а ядро и архитектура Xtensa LX - в 2004 году. ESP32-wroom-32 - это "винегрет" из "древних" и местами угловатых "технологий" с порой "невнятным" reference manual. Так что, апеллирование к "старью 10-летней давности" неуместно. stm32H7x, к которому Вы меня отсылаете, знаю давно, т.е. близко с ним знаком. esp32 - отличный и производительный м/к за небольшие деньги, который подойдет для большинства "поделок". Ассемблер, DSP и банальность. Ну, банально применяйте DSP там, где код можно оптимизировать под DSP-инструкции. Естественно, ЦОС для это подходит как нельзя кстати. А кому что интересно и каким "спортом" каждому заниматься - это больше вкусовщина. Блин, "портянка" получилась. 🙂

[@TechnoDuke]

@@VadRov Без портянок не получается сказать аргументированно. Ну дык, раз нравится спорт на поле ЕСП, ну тогда понятна ангажированность виедо)) Кому-то вообще негодный TMS320 нравится. Извращенцы)

[@royroyson165]

Magic....