STM32 новичку в ARM что к чему

[dosikus]

hosturik, в F0 у SPI есть FIFO , есть нюансы с обращением к буферу. Все это не расскажет вам калокуб...

[hosturik]

А как мне выйти с положения, может есть какое то решение?

hosturik писал(а):

Мне нужно добиться быстрое выполнение программы в главном цикле где вызываются все функции работы с дисплеем.
Сейчас главный цикл крутится всего 10 раз в секунду примерно, что очень мало.

[rai17]

dosikus писал(а):

Еще раз- счетчик таймера не останавливается при бряках...

Всё равно не ясно, в первом случае "останавливается" строго по плану, а во втором тож вроде "останавливается" (цифирьки перестают бежать).
В любом случае, спасибо за помощь.

[dosikus]

Вам jcxz уже отписался как надо смотреть подобные вещи. А ранее я писал о том как фризить таймер.
Но, подобные вещи отлаживать лучше лог.анализатором, выводя маркеры на пины

[Reflector]

hosturik писал(а):

А как мне выйти с положения, может есть какое то решение?

Для начала вынеси проверку вперед и добавь второй буфер... И что там вообще на дисплей выводится, раз такой фпс? Дисплей 320x240 можно за ~80ms полностью текстом забить при 48 тактовой, без DMA, но не делать же это каждый кадр...

[hosturik]

Выводится текст, картинки-пиктограммы и фигуры, типа прямоугольников и линий.
Ну у меня примерно так и есть, примерно ~100ms обновление экрана, SPI по даташиту в нем максимум 10 мегагерц, хотя я передаю на 12.
Хоть с DMA хоть без него, на скорость обновления это не влияет
Это теоретический предел обновления обновления для этой частоты.

[Reflector]

hosturik писал(а):

Выводится текст, картинки-пиктограммы и фигуры, типа прямоугольников и линий.
Ну у меня примерно так и есть, примерно ~100ms обновление экрана

Зачем это все выводить постоянно?

[dosikus]

hosturik, а DMA еще и в циркулярном режиме поди?

[hosturik]

dosikus Да нет, в обычном режиме, без кольцевого буфера

Reflector Как вариант, можно некоторые элементы вывести один раз и больше не выводить, а таких элементов половина от общего количества, это раза в два повысит скорость обновления,
Можно подробнее про второй буфер, как его нужно использовать?

[Reflector]

hosturik писал(а):

Reflector Как вариант, можно некоторые элементы вывести один раз и больше не выводить, а таких элементов половина от общего количества, это раза в два повысит скорость обновления

А что с оставшейся половиной? Неужели эти элементы меняются десятки раз в секунду? Это уже какая-то игра должна быть или демка...

[hosturik]

Мониторинг различных параметров: тока, напряжения, мощности и графики для отображения всего этого.
Выводить обновленные цифры только тогда, если данные изменились, по мере необходимости?
Хорошая идея, нужно будет попробовать, по идее это должно прилично увеличить скорость выполнения программы в главном цикле.

[Reflector]

hosturik писал(а):

Можно подробнее про второй буфер, как его нужно использовать?

Просто чередуешься два буфера, пока из одного идет отправка заполняется второй, потом отправляешь из него, а заполняешь первый. Если время заполнения достаточно велико, то и экономия может быть существенной.

hosturik писал(а):

Выводить обновленные цифры только тогда, если данные изменились, по мере необходимости?

Конечно, даже может реже, все равно бессмысленно обновлять данные 10 раз в секунду.

[jcxz]

rai17 писал(а):

Смотрю в View-System Viewer-TIM-TIM1-CNT (повторюсь, пользуюсь Keil).
Так вот (опять же повторяюсь), при установки breakpoint на вход в ISR TIM1 в симуляторе (Use Simulator) всё отлично - вижу 0х0000, а вот при подключении платы с прошитым камнем STM32F103С8Т6 по SWD через ST-Link V2 (Use: ST-Link Debugger) – получаются вообще случайные значения в View-System Viewer-TIM-TIM1-CNT.

Вот именно поэтому и не нужно использовать симулятор. Сами видите же - что толку от него ==0 при отладке работы с периферией.
Скопируйте нужный периферийный регистр в локальную переменную (static int volatile var) на входе в ISR до брекпоинта. И смотрите эту переменную.

Добавлено after 12 minutes 31 second:

hosturik писал(а):

А как мне выйти с положения, может есть какое то решение?

Вообще по уму DMA-транзакции с SPI-шиной завершают не по завершению передачи, а по завершению приёма. Если конечно знать - что такое SPI и что на ней передача идёт почти одновременно с приёмом. Тогда и FIFO любой глубины не страшно
Если только конечно не используете однопроводный (2-направленный по одному проводу SPI). В этом случае сложнее: тогда завершение TX-DMA без поллинга можно ждать зарядив таймер на некоторую выдержку после уведомления от TX-DMA-канала о завершении передачи блока. Выдержку посчитать исходя из размера FIFO. Ну или завести низкоприоритетную задачу и поллить в ней, не мешая работе полезных задач.

Добавлено after 5 minutes 56 seconds:

hosturik писал(а):

Ну у меня примерно так и есть, примерно ~100ms обновление экрана, SPI по даташиту в нем максимум 10 мегагерц, хотя я передаю на 12.

Не верь даташиту! У меня LCD на ILI9341 320x240 в проекте работает с SCLK <= 45МГц.

hosturik писал(а):

Это теоретический предел обновления обновления для этой частоты.

Нет конечно. На STM32F429 на 180МГц у меня обновляется хоть на полной скорости 45МГц. Хотя сейчас стоит 160МГц тактовая и соответственно - SCLK=40МГц.

Добавлено after 9 minutes 22 seconds:

Reflector писал(а):

Конечно, даже может реже, все равно бессмысленно обновлять данные 10 раз в секунду.

Если есть какая-то динамика и графические элементы её отображающие - то нормально. Например если график или какой-то линейный/круговой индикатор - выше частота - плавнее двигается.

[rai17]

jcxz писал(а):

Скопируйте нужный периферийный регистр в локальную переменную (static int volatile var) на входе в ISR до брекпоинта. И смотрите эту переменную.

Ок, буду пробовать.

[hosturik]

jcxz писал(а):

Вообще по уму DMA-транзакции с SPI-шиной завершают не по завершению передачи, а по завершению приёма.

Спасибо за советы, попробую поэкспериментировать


При просмотре памяти (Flash) на МК STM32F030C8 в отладчике заметил очень интересную особенность.
Смещение начала памяти в этом МК 0x8000000, память по даташиту 64 килобайта (0x10000)
То есть она должна заканчиваться по адресу 0x8000000 + 0x10000 = 0x8010000
Но память заканчивается по адресу 0x8020000 (когда она заканчиваются в окне просмотра памяти появляются знаки вопроса "?")
То есть получается памяти в нем 128 килобайт. Ради интереса попробовал загрузить во влеш картинку,
чтобы занимаемое место в памяти превысило 64 килобайт и на мое удивление все работает.

То есть получается что памяти в МК STM32F030C8 на самом деле 128 килобайт, а не 64, как заявлено.
Как такое возможно? Интересно, а в других сериях также, никто с этим не сталкивался? И ОЗУ тоже больше чем заявлено? Я не знаю как можно проверить ОЗУ.
И еще интересно в STM32F030C4 вместо 16 килобайт сколько на самом деле, неужели тоже 128.

[WiseLord]

В STM32F103C8, которые попадались мне, тоже 128кБ, хотя по даташиту 64кБ. "Лишняя" память вполне рабочая, могут быть лишь тонкости с загрузкой - нужно чтобы прошивальщик умел игнорировать значения, полученные из ID контроллера.

[ozzy]

STM32F030C4 сколько на самом деле

32 кб

[Reflector]

WiseLord писал(а):

В STM32F103C8, которые попадались мне, тоже 128кБ, хотя по даташиту 64кБ.

Там есть 103CB, а F030C8 как бы старший в линейке, кроме того для F0 камни у которых 128К идут уже с удвоенным размеров страниц флеша... Проверил на F051C8, а F030 - это и есть F051: в скрипте линкера увеличил размер флеша и уже для буфера размером 65КБ словил HardFault.
А не, в DS конкретно для F030C8 он наоборот младший, значит у него может быть и 256К флеша Тогда ситуация становится еще более запутанной, с одной стороны у F030 есть DAC и TIM2, как у F051, но флеша больше у первого, т.е. получается камни разные...

[jcxz]

hosturik писал(а):

Но память заканчивается по адресу 0x8020000 (когда она заканчиваются в окне просмотра памяти появляются знаки вопроса "?")
То есть получается памяти в нем 128 килобайт. Ради интереса попробовал загрузить во влеш картинку,
чтобы занимаемое место в памяти превысило 64 килобайт и на мое удивление все работает.

Возможно что МК с 64К флеша - отбраковка при производстве более ёмких МК.
Например: сделали МК с 128К, начали тестить - а часть флеша не прошла тест -> ремапнули сбойные страницы в верх адресного пространства, осталось >=64К - прогнали тест - работает -> промаркировали как 64К и продали. А сбойные страницы остались физически, но производитель не гарантирует их работу. Может они по климатике тест не прошли, или там есть биты, которые не программируются, или ещё по какой причине.

PS: Это как версия - не претендую на истину.

[hosturik]

jcxz Тоже так думаю. Для себя эту возможность использовать можно в единичных экземплярах, но вот в серию запускать я думаю не стоит