А разрешение экрана?

Щас всё скажу

480х320. 8бит шина 24 бита кодирование пикселя

Fmc частота 240мгц

А покажите настройки таймингов. Если не затруднит.

Выше скидывал фото

Я имел в виду в коде. Там где FSMC инициализируется.

Подскажите, кто с SPI работал, обязательно чтобы принять данные, надо сначала отправить что-то? По принципу сдвигового регистра. Просто насколько я знаю, есть режим Receive only, но по коду у меня получается извлекать данные только если я предварительно отправляю что-нибудь. Т.е. отправил байт, байт принял, причём этот отправленный байт никуда не уходит дальше мк, но если я убираю функцию отправки, то и приём перестаёт работать. Мк - Master. Ещё вопрос по DMA, имеет ли смыл его крепить к SPI если я извлечаю порции данных по 320 байт каждые 3 млсек, будет ли выигрыш в чем-нибудь от DMA?

Да, таков принцип SPI: master инициирует обмен и даёт тактирование для slave’а (во время того как отправляет «пустую посылку»). Поэтому если ждёте посылки от slave, то надо отправить «пустую» посылку и за время этой пустой посылки slave на линии MISO выставит данные, которые примет мастер. А ваши пустые данные на линии MOSI никто не прочитает

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

Здравствуйте!
STM32H723 , KEIL -> компилятор с++ 6.16
Проблема в том, что основной while(1) выполняется раз
Сделано тестовое мигание светодиодами по флагам полученным от периферии работающей по DMA
Флаги объявлены как volatile
так же в цикл добавлен известный костыль вида asm volatile("");
Все тщетно... третья сутка пошла - цикл выполняется раз и все
Оптимизация от -O0 до -Ofast влияния не оказывает
колбеки по ДМА работают исправно

Кто-то сталкивался?

Вопрос по FreeRTOS: что будет если время срабатывания шедулера наступит в момент обработки прерывания? Т.е. раз в одну млсек вызывается шедулер, который должен передать управление какой-то из задач, что будет если в этот момент будет выполняться прерывание с максимальным возможным приоритетом 5 (у шедулера, насколько я помню приоритет выше - 0), прервет ли он прерывание? Ну либо если прерывание наступит в момент работы шедулера, прервется его работа и перейдёт в обработку прерывания или прерывание будет ожидать?

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

шедулер кто такой мы не знаем. обычно вроде планировщику дается приоритет 3. если произойдет прерывание более приоритетное, чем планировщик (численно приоритет 0, 1, 2), то работа планировщика или вообще чего угодно прервется и будет обрабатываться это прерывание. если ниже - то планировщик будет в курсе этого прерывания и отдаст обработку обработчику уже когда сам это захочет.

отсюда кстати следует, что функции, заточеные на работу "из прерываний" а-ля QueueGiveFromISR или TaskNotifyFromISR можно вызывать только в обработчиках, чей приоритет ниже (в численном выражении больше), чем приоритет планировщика

потому что тогда планировщик "в курсе" произошедших деяний. всё, что происходит в обработчиках более приоритетных, происходит как бы вне ведома планировщика

это кстати моё понимание вопроса, может кто добавит или исправит

а, ну и любое "железячное" прерывание выше по приоритету, чем любая задача ОС.

ХАЛ сам меняет