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

rai17

Этого просто не может быть...
Контроллеры такого уровня и без симулятора? Смысл тогда?
Раскладывать на столе всё железо с осциллографами, да не с простыми, а золотыми (отматывать десяток другой экранов вперед-назад). Подключать различные генераторы и др. источники сигналов.
Например, отладить разгон - торможение асинхронной машины на максимальное ускорение (замедление) не допуская условий срыва синхронизма... Даже такая задача будет нерешаема.
НЕ МОЖЕТ БЫТЬ!
С симуляторами для avr вообще проблема отсутствует...

Реклама

dosikus

Смысл вашего перехода с авр ?

Реклама

jcxz

[uquote="rai17",url="/forum/viewtopic.php?p=3663169#p3663169"]С симуляторами для avr вообще проблема отсутствует...[/uquote]
Так может вам на avr и остаться тогда? Раз тут так сложно....

rai17

[uquote="dosikus",url="/forum/viewtopic.php?p=3663174#p3663174"]Смысл вашего перехода с авр ?[/uquote]

Смысл очевиден) Перестало хватать производительности.

Добавлено after 4 minutes 35 seconds:
[uquote="jcxz",url="/forum/viewtopic.php?p=3663269#p3663269"]Так может вам на avr и остаться тогда? Раз тут так сложно....

[/uquote]

Расцениваю этот вопрос как попытку "закарнавалить" тему.

Реклама

jcxz

[uquote="rai17",url="/forum/viewtopic.php?p=3663518#p3663518"]Расцениваю этот вопрос как попытку "закарнавалить" тему.[/uquote]
Вам уже всё сказали. Какой смысл в симуляторах если на реальном железе (с эмулятором) всё можно отладить? И это будет намного качественнее, так как симулятор - это одно, а реальное железо - совсем другое. И если в реальном железе такого уровня как современные ARM-ы производители делают кучу багов (почитайте errata) + баги симулятора - и какой смысл в такой отладке??? Отладите в симуляторе, а в реальном железе оно работать не будет с вероятностью 90%.
ARM - это не примитивный AVR - написать качественно на него симулятор на порядки сложнее. И также на порядке - менее нужно, так как ARM имеет развитые встроенные аппаратные средства отладки. В отличие от AVR.
Среди реальных разработчиков на ARM никто не пользует симуляторы - никому оно не нужно. В крайнем случае что-то сложное алгоритмически (и не привязанное к железу) можно отладить на компе под VS или билдером. А потом просто перетащить как есть на ARM.

Реклама

rai17

Fgt_dg23.jpg: (78.58 КБ) 304 скачивания

Дело в том, что почти всегда "сложное алгоритмически"...
На симуляторах (да в том же протеусе) мне приходилось сотни раз "катать" алгоритм взад-вперёд, добиваясь точной работы.
Не знаю как у других (статистику не собирал), а у меня проекты, после отладки в симуляторе запускаются (тьфу, тьфу, тьфу) всегда.
Для примера мааааленький фрагментик алгоритма управления двигателями геостационарной платформы.
Вобщем буду искать...
Для начала такая тактика:
Отладка в симуляторе Keil отдельных фрагментов программы камень stm32f103c8 (доступен для отладки)
Далее, при необходимости, проверить в железе осциллом.
Потом подзаливать в F4xx и смотреть что получилось....

Добавлено after 6 minutes 24 seconds:
Вот картинка, не ту вставил

Реклама

ПростоНуб

rai17, проблема в том, что для симуляции 32-х битной архитектуры на 480МГц требуется, как минимум, на два порядка больше вычислительных ресурсов, чем для симуляции 8-ми битной архитектуры на 16МГц. А с учетом сложности симуляции асинхронных процессов в контроллерах Chrom-ART, CAN, USB и т.п. - вычислительных ресурсов требуется уже на три(!) порядка больше. Условно говоря, если для симуляции AVR достаточно одного ядра на 1ГГц, то для симуляции STM32H7 потребуется 300 ядер по 3.3ГГц.
Как следствие вышеизложенного, полноценая симуляция всей линейки STM32 потенциально возможна только суперкомпьютерах, что сводит ценность этой симуляции к нулю.
Что касается отладки алгоритмов, то лично я предпочитаю их отлаживать совершенно отдельно компьютере. Во-первых, алгоритм по определению не зависит от архитектуры, во-вторых, используя тот же R я получаю возможность сформировать действительно любую возможную последовательность входных данных, которую получить не то что в симуляторе, даже в железе очень проблематично.

jcxz

[uquote="rai17",url="/forum/viewtopic.php?p=3663585#p3663585"]Для начала такая тактика:
Отладка в симуляторе Keil отдельных фрагментов программы камень stm32f103c8 (доступен для отладки)
Далее, при необходимости, проверить в железе осциллом.
Потом подзаливать в F4xx и смотреть что получилось....[/uquote]
Странная тактика: сперва отладить на некоем симуляторе (неизвестно какого качества) причём для совершенно постороннего процессора, потом залить совсем в другой МК (с другим ядром к тому же) и думать что всё отлажено. Просто какой-то мазохизм. Специально себе же проблемы придумываете на ровном месте.

Это ещё с учётом того, что у вас, как у начинающего на этом МК, главные проблемы будут скорей всего с периферией. А тут никакой симулятор не поможет.
По уму: покупают JTAG-эмулятор (или SWD), подключаются к целевому МК и отлаживают на нём. Если очень уж что-то очень сложное алгоритмически нужно отладить, то можно на ПК под VS например. По-крайней мере это точно и надёжнее и удобнее будет.
Впрочем - хозяин - барин. Каждый сходит с ума по-своему....

rai17

Я очень благодарен любым советам, для этого самого вопрос и задавал.
Подключаюсь по SWD (два провода), вроде нормально работает. Сейчас использую Кейловский отладчик. НО! например, tim1 в момент прерывания по переполнению кажет ерунду.

Я бы и рад по-простому (или правильному) пути идти (без мазохизма), поэтому и прошу помощи.
Можно поподробней, что есть "на ПК под VS"?

Добавлено after 5 minutes 9 seconds:
[uquote="ПростоНуб",url="/forum/viewtopic.php?p=3663613#p3663613"]rai17 используя тот же R я получаю возможность...[/uquote]
Спасибо за ответ.
О каком "R" идёт речь?

dosikus

[uquote="rai17",url="/forum/viewtopic.php?p=3663680#p3663680"]НО! например, tim1 в момент прерывания по переполнению кажет ерунду.[/uquote]

Какую именно "ерунду" , вы прочли мой пост?

jcxz

[uquote="rai17",url="/forum/viewtopic.php?p=3663680#p3663680"]НО! например, tim1 в момент прерывания по переполнению кажет ерунду.[/uquote]
Где смотрите? Поди в окне "Watch" отладчика?

Если у вас такой большой опыт в отладке девайсов на МК как писали

, то должны знать, что смотреть изменяющиеся регистры периферии (например - текущее значение таймера) через окно "Watch" отладчика - нельзя.
Надо на входе в ISR скопировать нужный регистр в переменную и смотреть её.
(Если что: ISR - это "обработчик прерывания"

)

[uquote="rai17",url="/forum/viewtopic.php?p=3663680#p3663680"]Можно поподробней, что есть "на ПК под VS"?[/uquote]
ПК - компьютер, VS - "Visual Studio". Ну или любая другая среда разработки для ПК. В 32-битном режиме позволяет отлаживать код, который потом легко перенести на ARM. Так как он тоже - 32-битный.

PS: Да - некоторые МК умеют останавливать тактирование указанной периферии во время останова отладчиком. И тогда счётчики таймеров не будут бежать пока стоите на бряке. Где это включается - смотреть мануал на свой МК.

ПростоНуб

[uquote="rai17",url="/forum/viewtopic.php?p=3663680#p3663680"]О каком "R" идёт речь?[/uquote]
Имеется в виду язык прогаммирования R. Он прост для изучения и позволяет легко генерировать заданные последовательности с управляемым распределением ошибок (искажений, шумов и т.п.). Несмотря на то, что он, преимущественно, направлен на статистический анализ данных, R предоставляет отличные возможности для генерации тестовых данных. Чем я и пользуюсь )

rai17

dosikus, Конечно прочел, притом внимательно...
-таймер фризился надо конфигурировать Debug MCU configuration register-
Это видимо имеется ввиду. Читал, сравнивал, работаю над этим.
Кажет ерунду, это когда ожидаешь увидеть в счетчике 0x0000, а видишь совершенно различные варианты, чередующиеся по непредсказуемому порядку...

Добавлено after 2 minutes 8 seconds:
ПростоНуб, Спасибо, познакомлюсь.

Добавлено after 39 minutes 6 seconds:
jcxz, Спасибо.
Опыт отладки девайсов на МК у меня небольшой (только avr).
Отлично получалось отлаживать устройства в Proteus.
В "Watch" не смотрю.
Смотрю в 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.
Буду разбираться...

hosturik

Подскажите по передаче через SPI с помощью DMA,
а точнее как избавиться от флага ожидания и чтобы при этом все работало
Каждый раз после отправки пакета данных через DMA, не важно 1 байт или 100 байт я передаю,
нужно ждать опустошение буфера передачи с помощью

while( SPI1->SR & SPI_I2S_FLAG_BSY )

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

Reflector

[uquote="hosturik",url="/forum/viewtopic.php?p=3663997#p3663997"]Мне нужно добиться быстрое выполнение программы в главном цикле где вызываются все функции работы с дисплеем.[/uquote]
Это дисплей к SPI подключен?

hosturik

Да, дисплей ILI9341 подключен по SPI1.
И еще тачскрин к нему подключен по другому SPI2.
И поскольку функции для работы тачскрина, в которых происходит обработка нажатия и рассчет коородинат нажатия тоже вызываются в главном цикле, время отклика на нажатие
не такое быстрое как хотелось, поскольку как я писал частота главного цикла где то 10 герц, которая ограничена скоростью обновления дисплея,
вернее скоростью передачи данных по SPI1 и ожиданием сброса флага BSY

Reflector

[uquote="hosturik",url="/forum/viewtopic.php?p=3664029#p3664029"]Да, дисплей ILI9341 подключен по SPI.[/uquote]
Какой дисплей? Какой мк? Нигде при передаче случайно HAL не используется? Никакие шрифты по точкам не отрисовываются? Когда отправляешь 100 байт по DMA что делаешь? Некоторые сразу флаг проверяют

hosturik

HAL не использую использую библиотеку LL. Это те же регистры только обернутые в удобочитаемые названия.
На регистрах тоже пробовал, разницы не заметил.
МК STM32F030C8T6, дисплей ILI9341
мне наверное нужно не ждать сброса флага в бесконечном цикле, а делать проверку установки пользовательского флага через if,
который я буду устанавливать в прерывании передачи DMA (transfer complete) и только после этого делать повторную отправку.

Код: Выделить всё

// Функция отправки данных по SPI
void Spi_Write_Data(uint8_t *data, uint16_t size){
  spi_send_dma(data, size);
  while(LL_SPI_IsActiveFlag_BSY(SPI1)){}
}


// Функция для отправки DMA запроса
void spi_send_dma(uint8_t *spi, uint16_t len){
  LL_DMA_DisableChannel(DMA1, LL_DMA_CHANNEL_3);
  LL_DMA_SetPeriphAddress(DMA1, LL_DMA_CHANNEL_3, (uint32_t)&SPI1->DR);
  LL_DMA_SetMemoryAddress(DMA1, LL_DMA_CHANNEL_3, (uint32_t)spi);
  LL_DMA_SetDataLength(DMA1, LL_DMA_CHANNEL_3, (uint32_t)len);
  LL_DMA_EnableChannel(DMA1, LL_DMA_CHANNEL_3);
}

Reflector

[uquote="hosturik",url="/forum/viewtopic.php?p=3664038#p3664038"]

Код: Выделить всё

// Функция отправки данных по SPI
void Spi_Write_Data(uint8_t *data, uint16_t size){
  spi_send_dma(data, size);
  while(LL_SPI_IsActiveFlag_BSY(SPI1)){}
}

[/uquote]
Я про это и спрашивал

Чем эта отправка отличается от отправки без DMA, если ты ждешь ее окончания ничего больше не делая?

WiseLord

Я особо с DMA не работал, но простая логика подсказывает, что ждать (цикл while) нужно не после spi_send_dma(), а до её вызова. Тем самым, данные по DMA будут себе в фоне отправляться, и уже только когда понадобится отправить новую порцию данных, мы снова вернёмся в Spi_Write_Data(), где и будем ждать окончания предыдущей передачи. Или не будем, если она успеет к тому времени завершиться.

Разве что ещё проследить, чтобы никто в буфер не писал (подготовка новой передачи), пока он по DMA занят.