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

[Reflector]

[uquote="Мурик",url="/forum/viewtopic.php?p=3377672#p3377672"]Reflector, semihosting тоже выведет результат в консоль через отладчик.[/uquote]
Ага, только работает он так.


И с ограничениями:
Semihosting operations cause the CPU to drop into "debug state", which means that for the duration of the data transfer between the target and the host PC no code (including interrupts) will get executed on the target. Thus if you application uses interrupts, then it is normally advisable to avoid the use of semihosting while interrupts are active.

Кроме того RTT работает и на ввод. Можно ли сохранить вывод посредством semihosting в файл я как-то тоже не уверен...

[VladislavS]

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

[a5021]

[uquote="Reflector",url="/forum/viewtopic.php?p=3377646#p3377646"]Допустим хочу я проверить какая версия сортировки быстрее, тогда пишем следующий код[/uquote]
С тем, что это можно использовать сколь-нибудь осмысленно, никто и не спорил. Правда, чтобы выяснить, какая сортировка быстрее, проще посмотреть значения прямо в отладчике, чем принтфы выписывать. Да, бывает, что данных много и в процессе отладки хорошо бы видеть их полностью в отладочной консоли, но для таких случаев не напряжно и какой-нибудь USB-TO-UART подцепить. В сухом остатке от таких рассуждений остается, что st-link вроде и можно перешить в j-link, но так ли это нужно, не совсем понятно.

[Ярослав555]

В основном работаю с АВР, имею в распоряжении наверное самый жирный отладчик - Atmel-Ice. Но вот такую тему вроде "проверить скорость выполнения" предпочитаю реализовывать ножкодрыгом. На платах всегда имеется статусный светодиод - осцилом стал и видишь период переключения. Просто и надежно.

[Reflector]

[uquote="a5021",url="/forum/viewtopic.php?p=3377737#p3377737"]С тем, что это можно использовать сколь-нибудь осмысленно, никто и не спорил. Правда, чтобы выяснить, какая сортировка быстрее, проще посмотреть значения прямо в отладчике, чем принтфы выписывать. Да, бывает, что данных много и в процессе отладки хорошо бы видеть их полностью в отладочной консоли, но для таких случаев не напряжно и какой-нибудь USB-TO-UART подцепить. В сухом остатке от таких рассуждений остается, что st-link вроде и можно перешить в j-link, но так ли это нужно, не совсем понятно.[/uquote]
Ладно, давай сравним степень ненапряжности. RTT работает с любым STM32, для этого делать не нужно вообще ничего. Чтобы подцепить USB-TO-UART нужно иметь, помимо него самого, к чему цеплять, т.е. нужен свободный USART, при этом возможно придется подпаиваться, возможно даже предварительно отпаяв старые провода и потом все возвращать на место.

Касательно возможности посмотреть значения прямо в отладчике. Ставить брейкпоинты в релизе дело неблагодарное, даже если я помечу elapsed как volatile и поставлю сразу после этого __BKPT(), то хоть выполнение кода и прервется в нужной точке, но значение переменной я все равно не увижу. В дебаге проблем нет, но там сортировка выполняется в 3 раза медленнее, в любом случае это совсем не то, что мне нужно. Если же говорить о самих сортируемых данных, то опять же они не всегда представляют из себя просто линейный массив который можно просмотреть во время отладки. Например, как понять что находится после сортировки в связанном списке? Или, допустим, что делать если хочу нажимать кнопки на пульте/клаве и сразу видеть что пришло или выводить какую-то информацию периодически, каждую секунду...

[uquote="Ярослав555",url="/forum/viewtopic.php?p=3377799#p3377799"]В основном работаю с АВР, имею в распоряжении наверное самый жирный отладчик - Atmel-Ice. Но вот такую тему вроде "проверить скорость выполнения" предпочитаю реализовывать ножкодрыгом. На платах всегда имеется статусный светодиод - осцилом стал и видишь период переключения. Просто и надежно.[/uquote]
На AVR применяемые подходы во многом обусловлены бедностью его периферии, а у практически любого STM32 есть 24-х плюс 32-х битные таймеры, не считая множества 16-ти битных, потому там идея измерять скорость при помощи осцилла или частотомера уже не кажется настолько притягательной, хотя я сам несколько раз так делал.

[a5021]

[uquote="Reflector",url="/forum/viewtopic.php?p=3377917#p3377917"]Ладно, давай сравним степень ненапряжности. RTT работает с любым STM32, для этого делать не нужно вообще ничего.[/uquote]
Соглашусь здесь с тем, что ежели ни к чему кроме stm32, этот ст-линк цепляться не будет, то возможно и есть смысл его раз и навсегда обратить в j-link. В прочих же случаях, лично я бы не стал.

Касательно возможности посмотреть значения прямо в отладчике. Ставить брейкпоинты в релизе дело неблагодарное, даже если я помечу elapsed как volatile и поставлю сразу после этого __BKPT(), то хоть выполнение кода и прервется в нужной точке, но значение переменной я все равно не увижу.

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

В дебаге проблем нет, но там сортировка выполняется в 3 раза медленнее, в любом случае это совсем не то, что мне нужно.

А что за неведомые силы в отладке тормозят сортировку?

[Reflector]

[uquote="a5021",url="/forum/viewtopic.php?p=3377925#p3377925"]Соглашусь здесь с тем, что ежели ни к чему кроме stm32, этот ст-линк цепляться не будет, то возможно и есть смысл его раз и навсегда обратить в j-link. В прочих же случаях, лично я бы не стал.[/uquote]
Никто и не заставляет перешивать st-link если он один и нужно шить еще и те же STM8, хотя полноценный j-link поддерживает великое множество разных мк.

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

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

А что за неведомые силы в отладке тормозят сортировку?

Да хотя бы отключение инлайнинга. Это еще в 3 раза медленнее получилось при моих не самых стандартных ключах -Og -fno-inline, а у большинства будет стоять -O0, тогда медленнее в 7 раз.

[Мурик]

Ага, только работает он так.

Хотите сказать что RTT может передать 82 символа за микросекунду?

Не нравится semihosting, во многих IDE есть альтернативы, например EBmonitor в EmBitz, который работает с ST-Link.

Have interaction with your target with the EBmonitor plugin. Using circular buffers with EB's live target inspection, the target is not halted during transfers like semihosting. EBmonitor is bidirectional!

[VladislavS]

В режиме RTT программа не передаёт даннае, а складывает их в буфер в памяти. А отладчик их потом оттуда вынает. Поэтому, во-первых, приложение не тормозит, во-вторых, не зависнет, если отладчик не подключен. Ну и в-третьих, не надо переопределять стандартный ввод-вывод, он ведь и в программе может быть задействован.

[Мурик]

В режиме RTT программа не передаёт даннае, а складывает их в буфер в памяти.

Буфер кольцевой? Во первых на него тратится память. Во вторых, отладчик может не успеть прочитать данные что приведет к их потере. Короче это тот же EBmonitor что EmBitz. Но RTT требует J-Link, а EBmonitor работает с ST-Link.

[Reflector]

[uquote="Мурик",url="/forum/viewtopic.php?p=3377976#p3377976"]Хотите сказать что RTT может передать 82 символа за микросекунду?[/uquote]
Проверил на F429, при 180MHz получил 3.2us.

[uquote="Мурик",url="/forum/viewtopic.php?p=3378004#p3378004"]Буфер кольцевой? Во первых на него тратится память. Во вторых, отладчик может не успеть прочитать данные что приведет к их потере. Короче это тот же EBmonitor что EmBitz. Но RTT требует J-Link, а EBmonitor работает с ST-Link.[/uquote]
Ничего там не теряется, отправка обернута в критическую секцию, буфер может быть любой начиная от 2-х байт. Естественно скорость будет соответствующая

[VladislavS]

Мгновенная скорость ограничена скоростью копирования память-память. Средняя 500000 кбит.

[Мурик]

Проверил на F429, при 180MHz получил 3.2us.

А на M3 (F103 и подобные) при 72 МГц, будет какое время?
Я проверил semihosting на F103 и время передачи почти 100 символов составило 123 мкс что на два порядка меньше чем на вашей картинке.

Спойлер

Semihosting.png

(48.58 КБ) 35 скачиваний

Ничего там не теряется, отправка обернута в критическую секцию, буфер может быть любой начиная от 2-х байт. Естественно скорость будет соответствующая

Если отладчик ничего не читает, то программа зависнет...

Проверил на F429, при 180MHz получил 3.2us.

Это с условием передачи в комп через J-Link? Есть сомнения что через SWD можно передать 90 символов за такой промежуток времени.

[a5021]

[uquote="Reflector",url="/forum/viewtopic.php?p=3377958#p3377958"]Никто и не заставляет перешивать st-link если он один и нужно шить еще и те же STM8, хотя полноценный j-link поддерживает великое множество разных мк.[/uquote]
Полноценный j-link всем хорош, кроме цены.

В дорелизном состоянии выяснять скорость бессмысленно, она может отличаться от релиза на десятки процентов, а может и в десятки раз.

Разве кто-то запрещает временно выставлять уровни оптимизаций, как в релизе и на этих настройках тестировать?

[Мурик]

Можно сделать проще - запустить отладку на релизной конфигурации как на картинке в моем предыдущем сообщении.

[Reflector]

[uquote="Мурик",url="/forum/viewtopic.php?p=3378036#p3378036"]А на M3 (F103 и подобные) при 72 МГц, будет какое время?[/uquote]
Проверял на F0, при 48MHz получается 17us, на F1 должно быть около 8-10.

Я проверил semihosting на F103 и время передачи почти 100 символов составило 123 мкс что на два порядка меньше чем на вашей картинке.

Все вопросы к Segger

Если отладчик ничего не читает, то программа зависнет...

Зависнет, когда и если закончится место в буфере, но с семихостингом без отладчика зависнет еще до начала отправки

Это с условием передачи в комп через J-Link? Есть сомнения что через SWD можно передать 90 символов за такой промежуток времени.

Нет, это время через которое функция отправки возвращает управление. Грубо говоря разница между семихостингом и RTT такая же как между блокирующей отправкой буфера через USART, да еще и в режиме отладки, с запретом всех прерываний, и отправкой при помощи DMA. Если создать серьезную нагрузку когда буфер всегда занят, то разница будет не такая существенная, но если периодически отсылать объемы данных которые в буфер помещаются, то это можно сделать фактически со скоростью копирования данных в этот буфер.

[Мурик]

Все вопросы к Segger

Значит или реклама (нужно показать что их RTT намного лучше), или у J-Link с semihosting не все так как должно быть.

Зависнет, когда и если закончится место в буфере, но с семихостингом без отладчика зависнет еще до начала отправки

Получается тот же semihosting только с буферизацией.

[dosikus]

Мурик, хватит уже тупить. RTT в сто крат лучше недоделанной хрени от эмоблитс, надо всего лишь пересилить свои амбиции и попробовать...

[isx]

День добрый. Не поделится ли кто-нибудь куском кода инициализации i2c stmf103 на CMSIS в режиме мастера
Не работал раньше на этом камне с этой шиной, а как говорят в сети - модуль там жутко глючный.

[dosikus]

isx, http://mcu.goodboard.ru/viewtopic.php?id=14#p2261