jcxz 172 28 июня, 2018 Опубликовано 28 июня, 2018 · Жалоба приведённый выше код скомпилирован очень эффективно. А зачем LDRH/STRH? Разве 32 бита из STR не будут автоматом распилены на две 16-битные записи контроллером шины? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VladislavS 29 29 июня, 2018 Опубликовано 29 июня, 2018 · Жалоба А зачем LDRH/STRH? Потому что в С-коде написаны 16-битные пересылки. Компилятор не имел права ослушаться. Разве 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 лет кто-то без меня будет делать? :biggrin: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 172 29 июня, 2018 Опубликовано 29 июня, 2018 · Жалоба Но мне это категорически не нравится, так как структуру теперь менять ни-ни. А если собирать из двух LDRH один STR, то это ещё и проиграешь в результате. Я в таких случаях обычно использую union: union { struct { u16 r0, r1, ..., rx; } r16; struct { u32 r0, r1, ..., ry; } r32; }; Первый член (r16) - логическое представление данных внутри; второй (r32) - для 32-битных обращений при пересылке. Если не нравятся лишние элементы в длинном конечном пути к членам, то можно и без имён r16, r32, просто задав разные имена внутренним членам - современные компиляторы уже нормально понимают безымянные структуры. Имхо - получается наглядно. Хотя конечно - на вкус и цвет.... Что потом с этим через N лет кто-то без меня будет делать? :biggrin: Всё перепишут на Cortex-Mxxx? :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 1 июля, 2018 Опубликовано 1 июля, 2018 (изменено) · Жалоба Разобрался с быстрым копированием по 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 байта? (какими ассемблерными инструкциями?) Изменено 1 июля, 2018 пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 2 июля, 2018 Опубликовано 2 июля, 2018 · Жалоба Дисплей активно работает по FSMC, сбоев не замечено. Накидал программу с 3D графикой. На разогнанном STM32F407 до 252 МГц вышло 24 FPS. Использовал софтварный текстурный мэппер, в SIMD не влазил, только VFP. Вот что вышло: http://www.youtube.com/watch?v=mIBVAke6A80 Исходники приложил ниже: Tunnel.rar В проекте применено копирование в память дисплея с помощью блоков по 128 байт (s0..s31 VFP) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 3 июля, 2018 Опубликовано 3 июля, 2018 (изменено) · Жалоба Подключил дисплей к Nucleo-144 STM32H743. Перестал показывать. Чтением регистра возвращается правильный ID, но не инитится. Кеширование кода/данных выключено. Вернул дисплей назад к STM32F4Discovery - всё работает. Обнаружил, что касание ножки ~CS дисплея пинцетом во время работы сносит крышу дисплею. Касание к остальным выводам не ведёт к сбоям. Если притянуть вывод ~CS к минусу через резистор 2 кОм, то касание пинцетом не влияет. Но на STM32H743 дисплей не хочет включаться (нет развёртки, но ID читается верно). Ставил растактовки такиеже при частоте 168 МГц и потом пересчитывал для 400 МГц. Один фиг - дисплей не инитится. Питание на дискавери 2.8V, на нуклее 3.2V. Может из-за этого? Куда копать? Изменено 3 июля, 2018 пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 3 июля, 2018 Опубликовано 3 июля, 2018 · Жалоба Поосторожнее с "касанием пинцетом". Сменили одежду или обувь - и "все пропало". :) То что при помехе на ~CS происходит "слет" - вполне естественно. --- Из-за более высокого уровня напряжения на другой плате - вопрос. Если бы оно уменьшилось, А оно увеличено до 3.2 В. Надо выяснить из док., какие требования у дисплея к его питанию и уровням входных линий интерфейса. (например, уровень 1 выше допустимого). Может с этим как-то связано. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 4 июля, 2018 Опубликовано 4 июля, 2018 (изменено) · Жалоба Поосторожнее с "касанием пинцетом". Сменили одежду или обувь - и "все пропало". :) То что при помехе на ~CS происходит "слет" - вполне естественно. --- Из-за более высокого уровня напряжения на другой плате - вопрос. Если бы оно уменьшилось, А оно увеличено до 3.2 В. Надо выяснить из док., какие требования у дисплея к его питанию и уровням входных линий интерфейса. (например, уровень 1 выше допустимого). Может с этим как-то связано. Обнаружил более глобальную проблему. FMC на отладочной плате Nucleo-H743ZI не работает как надо. Не читаются правильные значения регистров. Вместо дисплея подсоединял другую периферию - тоже не работает. Использую Кало-КУБ + Хал для генерации инит-кода. Вижу в нём настройку GPIO, FSMC и разрешение тактирования на FMC и GPIO. Этого достаточно? Есть ли подводные камни ? Лампочки мигают, кнопки тоже считываются, миллисекундные задержки работают. А FMC с инитом куба -не хочет. Вызванивал все сигналы (зацикливал в программе чтение-запись по адресам, по отдельным битам данных): D0..D7, A16, WR, RD, CS - всё на месте. Изменено 4 июля, 2018 пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 5 июля, 2018 Опубликовано 5 июля, 2018 · Жалоба Я не полагался бы так стопроцентно на HAL куба. Скорее 50 на 50. Если Вы исключили вопрос по уровням сигналов. Проверьте все ли корректно по софту при миграции на H743 (файлы включения, установка типа процессора может где-то "завалялась"). Возможно где-то "недоинициализация" узла(ов) периферии или тактовой в H743 по сравнению с F407. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 5 июля, 2018 Опубликовано 5 июля, 2018 · Жалоба Я не полагался бы так стопроцентно на 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 ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 5 июля, 2018 Опубликовано 5 июля, 2018 · Жалоба Обнаружил, что я не одинок, глюк присутствует ещё у одного товарища: 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. Вот первый блин комом как говорится. :santa2: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 172 5 июля, 2018 Опубликовано 5 июля, 2018 · Жалоба Обнаружил, что я не одинок, глюк присутствует ещё у одного товарища: https://community.st.com/thread/49249-stm32...spurious-writes И что характерно - тот товарищ тоже поклонник калокуба. О чём-то это говорит... :rolleyes: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 5 июля, 2018 Опубликовано 5 июля, 2018 (изменено) · Жалоба И что характерно - тот товарищ тоже поклонник калокуба. О чём-то это говорит... :rolleyes: В данном случае калокуб тут не причем. Подосрала сама 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 и разбавлять с даташитами :) И почему тогда в сети куча примеров под кало-куб, а на регистрах нет нигде примеров? Изменено 5 июля, 2018 пользователем repstosw Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 172 5 июля, 2018 Опубликовано 5 июля, 2018 · Жалоба Нужно ли включать кеширование кода и данных, если программа выполняется во встроенной Flash контроллера? Так собственно кеш в МК он для того и создаётся - чтобы кешировать FLASH. Или я не понял вопроса.... :wacko: Как запретить кешировать регион памяти для LCD, но оставить буферизацию? В AT91RM9200 делал это с помощью MMU, а тут как? А зачем его запрещать? Можно посмотреть на MPU. Возможности конечно не те что у MMU, но что-то там было. P.S. Я - не сторонник кало-куба, пока его использую, так как только начал знакомиться с STM32H743. Такое впечатление, что там над Вами кто-то стоит с большим дрыном и принуждает калокубить... :maniac: В чём проблема открыть юзер-мануал, прописать необходимый периферийный блок в виде структуры, описывающей регистры IO и писать код смотря только в мануал? И почему тогда в сети куча примеров под кало-куб, а на регистрах нет нигде примеров? Примеры для кого? Правильно - для чайников. И пишутся так, чтобы им понятнее было. Так 90% процентов этих читателей примеров дальше чайника и не уходят. Да и постят эти примеры такие же чайники. И примеры пользуются теми, кто не умеет/не хочет читать даташиты: воткнул готовый пример, заработало - ура! не заработало - идём гуглим следующий пример. В таком стиле "программирование". Вот таким хламомпримерами и наполнен инет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
repstosw 18 5 июля, 2018 Опубликовано 5 июля, 2018 · Жалоба Вопрос по поводу кеша возник не случайно. Так как раньше было отображение регистров периферии в адресное пространство типа "память", то при включенном кеше данных устройство работало некорректно. Сейчас же при отображении регистров устройства в адресное пространство типа "Device" кеш данных не мешает. Вот инфа, которая расставляет все точки над "I": http://microsin.net/programming/arm/an4838...unit-stm32.html http://microsin.net/programming/arm/an4839...he-stm32f7.html И всё-же я помню, что в AT91RM9200 аттрибут в MMU "Buferable" ускорял работу с периферией. А "Cacheable" приводил к артефактам. Есть ли подобное в H743 ? И почему ж никто не подсказал, что для внешних устройств надо было ремэпнуть банки, так как дефолтные установки ставят тип "память", а не "device"? Про адреса явно же писал. не верю, что с FMC никто не работал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться