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

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

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


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

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

Спасибо за ответ.
О каком "R" идёт речь?

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

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


ПК - компьютер, VS - "Visual Studio". Ну или любая другая среда разработки для ПК. В 32-битном режиме позволяет отлаживать код, который потом легко перенести на ARM. Так как он тоже - 32-битный.

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

Имеется в виду язык прогаммирования R. Он прост для изучения и позволяет легко генерировать заданные последовательности с управляемым распределением ошибок (искажений, шумов и т.п.). Несмотря на то, что он, преимущественно, направлен на статистический анализ данных, R предоставляет отличные возможности для генерации тестовых данных. Чем я и пользуюсь )

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.
Буду разбираться...

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

while( SPI1->SR & SPI_I2S_FLAG_BSY )

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

Это дисплей к SPI подключен?

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

Какой дисплей? Какой мк? Нигде при передаче случайно HAL не используется? Никакие шрифты по точкам не отрисовываются? Когда отправляешь 100 байт по DMA что делаешь? Некоторые сразу флаг проверяют

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

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

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

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

Естественно.


Если хочется быстро, то лучше сразу сделать два буфера.

Да я понимаю что так делать не правильно, но по другому у меня не получилось заставить заработать.

Вы имеете ввиду вот так?Так не работает

Мне наверное нужно не ждать сброса флага в бесконечном цикле, а делать проверку установки пользовательского флага через if,
который я буду устанавливать в прерывании передачи DMA (transfer complete) и только после этого делать повторную отправку. Но
у меня такой вариант почему то не заработал.
Или мне не прерывание DMA нужно ждать в прерывании SPI? Что то я запутался

Вот так я делал. Но не заработало. И я догадываюся почему. Данные для инициализации дисплея к напримеру пытаются отправиться, но я их попросту игнорирую,
если флаг не установился, из за чего не проходит даже инициализация.

Как минимум нужен volatile для flag. Только зачем так делать, если можно проверять флаг и без прерывания...

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

Так тоже пробовалНо как я выше написал, такой вариант не работает, потому что я просто пропускаю необходимые данные, например для инициализации дисплея

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