| |
|
  |
 STM342F4 и FSMC, эксплуатация |
|
|
|
|
 Jun 29 2018, 01:58
|
Местный
Группа: Свой
Сообщений: 475
Регистрация: 14-04-05
Из: Москва
Пользователь №: 4 140
|
Цитата(jcxz @ Jun 29 2018, 01:27)  А зачем LDRH/STRH? Потому что в С-коде написаны 16-битные пересылки. Компилятор не имел права ослушаться. Цитата(jcxz @ Jun 29 2018, 01:27) Разве 32 бита из STR не будут автоматом распилены на две 16-битные записи контроллером шины? Будут, конечно. Только в скорости в моём случае уже не выиграть, я упёрся в скорость устройства в которое пишу, а вот читаемость кода пострадает. Режимы работы шины я настраивал с осциллографом под отладчиком. Отсюда и магические числа вылезли - после отладки просто скопировал значение регистров в код. PS: Да, можно немного сэкономить. Код *(uint32_t *)&cpld_regs[0] = *(uint32_t *)&ppm8s.state.rx.chanel[0];
*(uint32_t *)&cpld_regs[2] = *(uint32_t *)&ppm8s.state.rx.chanel[1];
*(uint32_t *)&cpld_regs[4] = *(uint32_t *)&ppm8s.state.rx.chanel[2];
*(uint32_t *)&cpld_regs[6] = *(uint32_t *)&ppm8s.state.rx.chanel[3];
cpld_regs[8] = (uint16_t)ppm8s.state.rx.dt_hp; //Эти поля uint8_t
cpld_regs[9] = (uint16_t)ppm8s.state.rx.dt_vp; И получить LDR/STR на части структуры, которая случайно совпала по расположению в памяти с внешними регистрами. Но мне это категорически не нравится, так как структуру теперь менять ни-ни. А если собирать из двух LDRH один STR, то это ещё и проиграешь в результате. Что потом с этим через N лет кто-то без меня будет делать? 
|
|
|
|
|
|
|
|
Jun 29 2018, 04:41
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(VladislavS @ Jun 29 2018, 04:58) Но мне это категорически не нравится, так как структуру теперь менять ни-ни. А если собирать из двух LDRH один STR, то это ещё и проиграешь в результате. Я в таких случаях обычно использую union: Код union {
struct {
u16 r0, r1, ..., rx;
} r16;
struct {
u32 r0, r1, ..., ry;
} r32;
}; Первый член (r16) - логическое представление данных внутри; второй (r32) - для 32-битных обращений при пересылке. Если не нравятся лишние элементы в длинном конечном пути к членам, то можно и без имён r16, r32, просто задав разные имена внутренним членам - современные компиляторы уже нормально понимают безымянные структуры. Имхо - получается наглядно. Хотя конечно - на вкус и цвет.... Цитата(VladislavS @ Jun 29 2018, 04:58) Что потом с этим через N лет кто-то без меня будет делать? Всё перепишут на Cortex-Mxxx? 
|
|
|
|
|
|
|
|
Jul 1 2018, 14:07
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 5-09-17
Пользователь №: 99 126
|
Разобрался с быстрым копированием по 128 байт за раз: ASM: Код memcpy128 PROC
EXPORT memcpy128
vpush {s16 - s31} ; 17
z vldm.32 r1!, {s0 - s31} ; 33
vstm.32 r0!, {s0 - s31} ; 33
subs.n r2, #1 ; 1
bne.n z ; ~3 (taken)
vpop {s16 - s31} ; 17
bx lr ; 1-3??
ENDP C: Код void memcpy128(void *destination,const void *source,int num); А как подобным образом реализовать заливку константой (memset) блоками выше, чем 4 байта? (какими ассемблерными инструкциями?)
Сообщение отредактировал __inline__ - Jul 1 2018, 14:08
|
|
|
|
|
|
|
|
Jul 2 2018, 09:59
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 5-09-17
Пользователь №: 99 126
|
Дисплей активно работает по FSMC, сбоев не замечено. Накидал программу с 3D графикой. На разогнанном STM32F407 до 252 МГц вышло 24 FPS. Использовал софтварный текстурный мэппер, в SIMD не влазил, только VFP. Вот что вышло: http://www.youtube.com/watch?v=mIBVAke6A80Исходники приложил ниже: 
Tunnel.rar ( 1.16 мегабайт )
Кол-во скачиваний: 18
В проекте применено копирование в память дисплея с помощью блоков по 128 байт (s0..s31 VFP)
|
|
|
|
|
|
|
|
Jul 3 2018, 15:28
|
Профессионал
Группа: Свой
Сообщений: 1 123
Регистрация: 8-03-09
Из: Днепр
Пользователь №: 45 848
|
Поосторожнее с "касанием пинцетом". Сменили одежду или обувь - и "все пропало".  То что при помехе на ~CS происходит "слет" - вполне естественно. --- Из-за более высокого уровня напряжения на другой плате - вопрос. Если бы оно уменьшилось, А оно увеличено до 3.2 В. Надо выяснить из док., какие требования у дисплея к его питанию и уровням входных линий интерфейса. (например, уровень 1 выше допустимого). Может с этим как-то связано.
|
|
|
|
|
|
|
|
Jul 4 2018, 07:30
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 5-09-17
Пользователь №: 99 126
|
Цитата(k155la3 @ Jul 3 2018, 15:28) Поосторожнее с "касанием пинцетом". Сменили одежду или обувь - и "все пропало". То что при помехе на ~CS происходит "слет" - вполне естественно. --- Из-за более высокого уровня напряжения на другой плате - вопрос. Если бы оно уменьшилось, А оно увеличено до 3.2 В. Надо выяснить из док., какие требования у дисплея к его питанию и уровням входных линий интерфейса. (например, уровень 1 выше допустимого). Может с этим как-то связано. Обнаружил более глобальную проблему. FMC на отладочной плате Nucleo-H743ZI не работает как надо. Не читаются правильные значения регистров. Вместо дисплея подсоединял другую периферию - тоже не работает. Использую Кало-КУБ + Хал для генерации инит-кода. Вижу в нём настройку GPIO, FSMC и разрешение тактирования на FMC и GPIO. Этого достаточно? Есть ли подводные камни ? Лампочки мигают, кнопки тоже считываются, миллисекундные задержки работают. А FMC с инитом куба -не хочет. Вызванивал все сигналы (зацикливал в программе чтение-запись по адресам, по отдельным битам данных): D0..D7, A16, WR, RD, CS - всё на месте.
Сообщение отредактировал __inline__ - Jul 4 2018, 07:33
|
|
|
|
|
|
|
|
Jul 5 2018, 07:12
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 5-09-17
Пользователь №: 99 126
|
Цитата(k155la3 @ Jul 5 2018, 04:05) Я не полагался бы так стопроцентно на HAL куба. Скорее 50 на 50.
Если Вы исключили вопрос по уровням сигналов.
Проверьте все ли корректно по софту при миграции на H743 (файлы включения, установка типа процессора может где-то "завалялась").
Возможно где-то "недоинициализация" узла(ов) периферии или тактовой в H743 по сравнению с F407. Что удалось обнаружить. Напряжение логической "1" на линиях D[0..7] = 0.38V. Логический "0" =0V. На линиях A[0], !RD, !WR, !CS напряжения логической "1" и "0" соответственно 2.8V и 0V -что норма. Теперь стало понятно, почему ID дисплея читался верно - потому что нулевой регистр. Был бы ненулевым, не прочлось бы. На чтение FMC работает. Уровни на линиях D[0..7] распознаются. Теперь осталось понять, почему же уровень напряжения логической "1" на линиях D[0..7] 0.38V, вместо 2...3.2V ...
|
|
|
|
|
|
|
|
Jul 5 2018, 11:04
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 5-09-17
Пользователь №: 99 126
|
Обнаружил, что я не одинок, глюк присутствует ещё у одного товарища: https://community.st.com/thread/49249-stm32...spurious-writesЦитата A single uint16_t write under 0x68000000 address results in 4 writes to memory, out of which first write is valid data, and rest are 0, as seen on logic analyser snapshot.
Вот первый блин комом как говорится. 
|
|
|
|
|
|
|
|
Jul 5 2018, 12:55
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 5-09-17
Пользователь №: 99 126
|
Цитата(jcxz @ Jul 5 2018, 11:18) И что характерно - тот товарищ тоже поклонник калокуба. О чём-то это говорит...  В данном случае калокуб тут не причем. Подосрала сама STM electronix. Ошибка кривая и аппаратная. Проблему решил, работает по крайней мере на внешней SRAM: https://electronix.ru/forum/index.php?s=&am...t&p=1571320Сейчас осталось вернуться LCD и раскочегарить 3D-туннель на 400 МГц при включенных кешах. Нужно ли включать кеширование кода и данных, если программа выполняется во встроенной Flash контроллера? Как запретить кешировать регион памяти для LCD, но оставить буферизацию? В AT91RM9200 делал это с помощью MMU, а тут как? P.S. Я - не сторонник кало-куба, пока его использую, так как только начал знакомиться с STM32H743. И очень жаль, что SPL нет, как это было в F407  Прийдется распиливать HAL и разбавлять с даташитами И почему тогда в сети куча примеров под кало-куб, а на регистрах нет нигде примеров?
Сообщение отредактировал __inline__ - Jul 5 2018, 12:59
|
|
|
|
|
|
|
|
Jul 5 2018, 14:50
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(__inline__ @ Jul 5 2018, 15:55) Нужно ли включать кеширование кода и данных, если программа выполняется во встроенной Flash контроллера? Так собственно кеш в МК он для того и создаётся - чтобы кешировать FLASH. Или я не понял вопроса....  Цитата(__inline__ @ Jul 5 2018, 15:55) Как запретить кешировать регион памяти для LCD, но оставить буферизацию? В AT91RM9200 делал это с помощью MMU, а тут как? А зачем его запрещать? Можно посмотреть на MPU. Возможности конечно не те что у MMU, но что-то там было. Цитата(__inline__ @ Jul 5 2018, 15:55) P.S. Я - не сторонник кало-куба, пока его использую, так как только начал знакомиться с STM32H743. Такое впечатление, что там над Вами кто-то стоит с большим дрыном и принуждает калокубить...  В чём проблема открыть юзер-мануал, прописать необходимый периферийный блок в виде структуры, описывающей регистры IO и писать код смотря только в мануал? Цитата(__inline__ @ Jul 5 2018, 15:55) И почему тогда в сети куча примеров под кало-куб, а на регистрах нет нигде примеров? Примеры для кого? Правильно - для чайников. И пишутся так, чтобы им понятнее было. Так 90% процентов этих читателей примеров дальше чайника и не уходят. Да и постят эти примеры такие же чайники. И примеры пользуются теми, кто не умеет/не хочет читать даташиты: воткнул готовый пример, заработало - ура! не заработало - идём гуглим следующий пример. В таком стиле "программирование". Вот таким хламомпримерами и наполнен инет.
|
|
|
|
|
|
|
|
Jul 5 2018, 16:50
|
Местный
Группа: Участник
Сообщений: 257
Регистрация: 5-09-17
Пользователь №: 99 126
|
Вопрос по поводу кеша возник не случайно. Так как раньше было отображение регистров периферии в адресное пространство типа "память", то при включенном кеше данных устройство работало некорректно. Сейчас же при отображении регистров устройства в адресное пространство типа "Device" кеш данных не мешает. Вот инфа, которая расставляет все точки над "I": http://microsin.net/programming/arm/an4838...unit-stm32.htmlhttp://microsin.net/programming/arm/an4839...he-stm32f7.htmlИ всё-же я помню, что в AT91RM9200 аттрибут в MMU "Buferable" ускорял работу с периферией. А "Cacheable" приводил к артефактам. Есть ли подобное в H743 ? И почему ж никто не подсказал, что для внешних устройств надо было ремэпнуть банки, так как дефолтные установки ставят тип "память", а не "device"? Про адреса явно же писал. не верю, что с FMC никто не работал.
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
