Приветствую.
Отладочная плата STM32F746 Disco, с 32-битной SDRAM MT48LC4M32B2, которая подключена по 16-битной шине данных.
И вот такая засада выясняется - при выполнении записи в SDRAM в размерности uint16_t или uint32_t по НЕЧЕТНОМУ адресу вываливается с ошибкой "невыровненный доступ". (чтение выполняется нормально). И ладно бы, было бы понятно, но на отладочной плате STM32F469 с такой же SDRAM, но подключенной по 32-битной шине данных этой проблемы нет ни в каком виде. Так же этой проблемы нет и на STM32F429 с 16-битоной SDRAM.

Начал разбираться че да как, в пошаговой отладке выяснил, что виновата инструкция 16-битного сохранения strh. Причем, при включении оптимизации -03 эта инструкция не используется, вместо нее - strb (побайтное сохранение). Однако, пошаговая отладка на -03, мягко говоря, некомфортна, если не сказать больше.
Вроде бы, по описанию из мануала, FMC в режиме SDRAM должен обеспечивать выбор любого байта сигналами DQM.
И поэтому у меня родилась догадка, что из-за подключения только части шины - 16 бит из 32 возможных, возникла такая проблема. Хотя я и не уверен, что именно в этом дело. По идее, в 32-битной SDRAM при 16-битном подключении вторая половина 32-битной ячейки просто не используется.

А вопрос вот в связи с чем - в проекте буду использовать STM32H743 с 32-битной SDRAM MT48LC4M32B2 на 32-битной шине. И поэтому вопрос - будет ли такая же проблема с невыровненным доступом там?
Проверить сейчас не могу - печатная плата не изготовлена, а отладочная с H743XI имеет только 16-битную SDRAM.

PS. Варианты решения "не используй невыровненный доступ" - не подходят, потому как массив переменных типа RGB888 не имеет выравнивания элементов по четным адресам.
PS2. Инит FMC - строго по мануалу, проверял раз на -дцать, в том числе и пошагово.
PS3. При заполнении через DMA2D работает без проблем в любых вариантах.
PS4. Если пиксельный буфер разместить во внутренней SRAM, то так же проблем не возникает ни в каком варианте. То есть, проблема чисто на стыке "FMC - микросхема SDRAM"

Какие получаются инструкции - исключительно прерогатива написанного вами же кода. И его интерпретации компилятором. При желании можно написать так, что записи разобьются на 8-битные. Только код получится тормозной.

Идея ложная. "Вторая половина" находится по адресу на +2 выше первой. Убедиться в этом просто.
По причинам неработы невыровненного доступа не подскажу, но возможно что-то не так или с конфигурированием FMC, или кеша данных, или MPU.

Не очень понятно - почему именно "не подходят"?
Что такое "переменные типа RGB888"? 24-битные пиксели или...?
Если пиксели, то почему их нельзя хранить неупакованными - как 32-битные (не используя старшие 8 бит)?
Если нужно хранить именно упакованными, то почему нельзя писать в SDRAM по 2 пикселя? Тогда не будет невыровненных записей в принципе.

а. используйте (uint16*)RGB565, либо (uint32*)RGB888, как предложили выше.
б.
Соберите конфигурацию только с SDRAM (х32) и проверьте инструкцию невыровненной записи. Наличие/отсутствие самих микросхем контроллеру перпендикулярно, он просто вернет дурь (при чтении). Напомню, вопрос не в данных, а в получении GP от невыровненного доступа. (могу заблуждаться в возможности, но это легко проверяется _практически_)

Хм, да это то делал, просто думал, что несоответсвие конфигурации как-то влияет.
Подключил Nucleo-H743 вообще без микросхемы, сконфигил FMC. Запускаю - та же фигня:

Вылетает на инструкции 16-битного сохранения strh, при этом r3 содержит 0xD0000001. Видимо, хоть модуль FMC во всех линейках внешне и одинаков, но в F7/H7 ведет себя иначе.
Ладно, фик с ним, дальше не буду разбираться, приму как есть, будем считать, что не критично. Главное, что через DMA2D всё-таки работает, а при прямом обращении надо делать побайтную запись.


Ааа, видимо, вы не имели дел с графикой и SDRAM Иначе бы непонимания и не возникло.
При аппаратном считывании модулем LTDC никаких зазоров на выравнивание не допускается. А если перейти в режим ARGB8888, то будет лишний оверхед по объему памяти и по битрейту на шине FMC - микросхема SDRAM. При больших размерах дисплея эти параметры становятся весьма важными.
И по два пикселя сразу писать тоже некомильфо, потому что при записи нужного пикселя будет затираться соседний. А операция "прочитать - изменить - записать" сожрет доталова скорости на шине.


Опять не угадали Если FMC настроен на 16-битную шину данных, то адреса он располагает непрерывно - DQM_2 и DQM_3 не используются, а на шине адреса формируется следующий адрес. Поэтому, получить доступ ко второй половине 32-битной ячейки микросхемы SDRAM невозможно - верхние DQM не управляются, а адрес переключает сразу на следующую 32-битную ячейку SDRAM.

MPU и кэш выключены. Конфигурация FMC - строго по мануалу, раз на -дцать перепроверенная и испытанная в разных вариантах. Да она и простая в принципе то - задаются размеры шин данных, задаются тайминги, взятые из даташита SDRAM, подаются команды запуска, предзарядки, загрузки регистра конфигурации и выставляется таймер рефреша. Там запутаться то негде.

В общем, я решил, что хрен с ним, буду учитывать этот факт, и все функции непосредственной записи пикселя в DRAM будут покомпонентными, размером в 1 байт

Значицца, сижу, читаю эррату на H743. Там сказано:


То есть, для ЧТЕНИЯ. А про ЗАПИСЬ - ни слова. А в эррате на F746 вообще нет упоминаний о невыровненном доступе.
Походу, надо писать эррату на эррату - список ошибок в списке ошибок.

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

С другой стороны, сижу и грустно смотрю на эрраты H7-серии. FMC везде, во всех моделях H7 косячный, с проблемой невыровненного доступа. Так же доталова косяков и в остальных модулях, причем, довольно чувствительных косяков, с пометкой No workaround, то есть, без решения.
Мдя. Мож, хрен на эти 480 МГц (которые только для ядра, любая периферия, включая флеш и общую SRAM, вдвое медленнее), и делать на старом F746, который хоть и имеет косяк с SDRAM, но в общем остальных косяков поменьше.

Мимо. Имел дело и с тем и с другим. Потому и непониманию - на кой писать поточечно??? Имхо - в нормально написанном графическом ПО практически не должно быть поточечных манипуляций с картинкой.

Т.е. - увеличение объёма потока по чтению на какую то всего лишь 1/3 вас напрягает. В то время как увеличение объёма потока по записи аж в 3 раза! - совсем не напрягает?

Так напишите своё графическое ПО так, чтобы операций "прочитать - изменить - записать" требовалось по минимуму. Чтобы ПО старалось писать пиксели пачками, по многу за раз.

Т.е. - вы взяли микросхему с 32-битной шиной, но подключили к МК только младшие 16 бит? Ну ладно - потеряли половину ёмкости чипа. Ну и что? Работать то оно должно нормально. Какая разница - сколько бит ячейки используется?

Да уж.... "решение"... вместо одной 32-битной записи на пиксель, выполняемой одной командой CPU, будет аж ~5 команд! для записи одной единственной точки. Программа будет ползать еле-еле....

Если бы реально имели дело, то не спрашивали бы, что такое RGB888 и знали бы, что такое отрисовка линий и окружностей по алгоритму Брезенхема. Они попиксельно рисуются. Другого не придумано пока что.


Меня не напрягает. Напрягает подсистему памяти на участке SDRAM - LTDC, а так же DMA2D - SDRAM. Если бы вы с этим имели дело, то понимали бы.
В мануале четко написано, какие форматы с какой скоростью на какой размер дисплея могут идти. И это вам не 320х240, а 1280х800.


У меня графический движок уже давно написан и использует как прямое построение, так и граф.ускоритель.


Это не я взял, а производитель ST Microelectronics на своей отладочной плате Discovery так поставил. Не знаю почему. Спросите у них, если кажется, что они ошиблись.
В предыдущем сообщении вы не знали, как SDRAM адресуется, а тут вдруг заявляете обратное. Быстро ж переобулись. Я б на вашем месте промолчал....


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

Для тех, кто в танке, поясняю - далеко не всё можно отрисовать во встроенной SRAM по причине размеров. И рисовать кусок в SRAM, потом кидать его через DMA2D в SDRAM, потом повторять для след.куска и так далее - не всегда хорошее решение.
Но по-видимому, придется вернуться к такому решениею из-за косячного контроллера FMC.
И еще раз - 32 бита на пиксель - это непозволительный оверхед при двух слоях и 1280х800 пикс.
Если бы читали мануалы, то видели бы ограничения.
Так что не кричите, а спокойно разберитесь в теме вопроса.

Напомню - тема вопроса была про косяк работы FMC с невыровненным доступом. И я нашел ответ - косячный модуль FMC во всей линейке. Об этом говорит эррата.

Если бы вы реально имели дело с графикой, то знали бы, что только чайники рисуют что-то (тем более - линии) попиксельно.
И потому их код не выполняется, а скорее ползает.
Когда научитесь программировать (а не только своё ЧСВ прокачивать), то сможете и линии и даже круги/окружности рисовать быстро. И проблем с невыровненным доступом не будет. И ахинею про STRB/STRH не будете нести.

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

"Движок" рисующий попиксельно , годится только в мусорку.

Т.е. - вы не сумели правильно запрограммировать чип, из-за чего используется только половина SDRAM. Да и то запрограммировали криво. Но конечно виноваты все вокруг (и производтель платы в том числе), но конечно только не вы.
Что производитель поставил на свою плату что-то неправильно - не надо рассказывать сказок. Снимите корону и скажите правду, что не справились с инициализацией FMC/SDRAM.

Пока наезжаете и несёте ерунду здесь только вы. Если бы вы сняли корону, умерили своё ЧСВ и хоть немного подумали бы, то поняли бы как писать 32-битными словами.
Если что: моя графическая библиотека в одном из проектов рисует линии и другие фигуры максимально используя 32-битные записи. При том что точки там занимают вообще по 4 бита. И никакой Брезенхем мне не мешает почему-то.

Плохому танцору всегда кто-то мешает: производитель платы, чип, еррата... Всегда кто угодно виноват, но только не он сам.


PS: Заходим на сайт "ARM" читаем:
https://developer.arm.com/documentation/ka002886/latest/
Совет "задействовать MPU" был дан мною ещё в самом первом сообщении. Но ТС его проигнорировал, вместо этого начав наезжать и прокачивать своё ЧСВ.

PPS: К сведению чайников, не знающих что такое STRH/STRB - даже если невыровненный доступ работает, то невыровненные операции доступа к памяти, всё равно выполняются медленнее. Не говоря уже о том, что запись пикселя в два приёма STRH+STRB (даже с выровненной STRH) будет гораздо медленнее одной 32-битной записи. И писать что-то графическое попиксельно, да ещё - записывая каждый пиксель в несколько приёмов - это просто днище. Это не программирование, а говнокодинг.

Ну и к чему этот поток самосознания от вас? Еще три дня назад вы не знали, что такое RGB888 и какая адресация у SDRAM, а сейчас вы хвастаетесь тем, чего за пару дней прочли. Еще и хамите. Тьфу на вас, необразованное хамло и хвастун Вам еще подрасти до моего уровня, потом получите разрешение хамить. Хотя лично я никому не хамлю, несмотря на немалый свой опыт. Хамят те, у кого опыта и знаний по-минималке, это давно известный факт.

А то, что вы процитировали, я уже нашел до вас, О ЧЕМ И НАПИСАЛ В ПРЕДЫДУЩЕМ СООБЩЕНИИ. Это всего лишь констатация факта косяка контроллера FMC/SDRAM.

Так понятно? Так что не стоило истерить.
Вы, сударь, хамло Тьфу на вас еще раз. Чем меньше опыта, тем больше истерик. Поскольку вы сами сказали:

Так что вы об этом точно так же не знали и узнали буквально сегодня Не надо врать, сударь!

Ладно, можете истерить дальше - чем больше истерик, тем меньше практического опыта у истерекующего.
И к следующему разу -

- к следующему вашему потоку самосознания прочтите, как работает SDRAM. Адресуемые в конкретно этой микросхеме SDRAM ячейки - 32-битные. На линиях адреса A[0...] выставляется не адрес байта, а адрес ЯЧЕЙКИ, которая в этой микросхеме является 4-байтной (32 бита).
И конкретный байт выбирается сигналами DQM[3:0]. И если DQM2 и DQM3 не подключены, то старшее полуслово DQ[31:16] не используется. Отсюда - и половина от заявленной ёмкости микросхемы. Это НЕ зависит от конфигурации FMC. Можно выставить ширину шины данных в 32 бита, но если DQM[3:2] и DQ[31:16] не подключены, то старшее полуслово потеряется. Как вы его собрались извлекать то?
Вот сидите теперь и читайте мануалы. А то врёте про то, чего не нюхали. Меня то не обманешь этим фуфлом



Ну нарисуйте наклонную линию под 45° не попиксельно Глупый хвастун! Тьфу на вас еще раз.

Да ладно! Вы об этом узнали только из моего поста.
Как известно: Плохому танцору даже яйца мешают. Это про вас.
И кто после этого неблагодарное хамло?
Остальной ваш бред комментировать лень. Чешите своё ЧСВ и дальше.

PS: Каждый чайник, только научившийся тыкать в кнопки, почему-то мнит себя великим кодером. Ещё и других поучает....

Ну, на этом и закончим. Видимо, в адресации ячеек SDRAM разбираться вам лень, и линию под 45° тоже ниасилили. И когда поняли, что не вывозите по знаниям, от вас начался сплошной поток хамства и личных оскорблений - обычная практика у таких как вы. Это в инете безопасно оскорблять других, а при разговоре тет-а-тет вам давно бы уже в рыло насовали за это.

Ну и слава богу, вы хоть не будете лезть туда, где не разбираетесь. Слава aллaxу, хамливый дилетант самослился. Тьфу на него еще раз