Comments 20
Я помню еще хитрее делал: у меня к stm32 цеплялся ethernet и я просто подключался telnet'ом к плате и уже отправлял весь лог туда.
Спасибо, пригодилось. До сих пор использовал вот такую вставку:
Ну а переопределение _write не видел, хотя и искал
void vprint(const char *fmt, va_list argp)
{
char string[MAX_PRINT_LINE];
if(0 < vsprintf(string,fmt,argp)) // build string
{
HAL_UART_Transmit(&huart2, (uint8_t*)string, strlen(string), 0xffffff); // send message via UART
//CDC_Transmit_FS((uint8_t*)string, strlen(string));
}
}
void mprintf(const char *fmt, ...) // custom printf() function
{
va_list argp;
va_start(argp, fmt);
vprint(fmt, argp);
va_end(argp);
}
Ну а переопределение _write не видел, хотя и искал
Если это NRZ, можно ли SWO как то к UART подцепить и в консоль вывод делать?
Можно.
В этом случае с помощью itmdump нужно будет уже подключаться к COM-порту, а не к файлу/пайпу. В мануале на OpenOCD, собственно, такой способ и описывают в подразделе где идет речь о «tpiu config».
В принципе, можно даже и itmdump не использовать, а включить обычный эмулятор терминала — выводимые символы будет видно, но они будут разбавлены мусором.
Наиболее удобным способом использования ITM является вывод через SWO с иcпользованием NRZ кодирования — таким образом, нужна всего одна линия, и принимать данные можно будет не только с помощью отладчика со специальным входом, но и обычным USB-UART переходником, пусть и с меньшей скоростью.
В этом случае с помощью itmdump нужно будет уже подключаться к COM-порту, а не к файлу/пайпу. В мануале на OpenOCD, собственно, такой способ и описывают в подразделе где идет речь о «tpiu config».
В принципе, можно даже и itmdump не использовать, а включить обычный эмулятор терминала — выводимые символы будет видно, но они будут разбавлены мусором.
Ой! Всей фразы не заметил…
Параметры SWO не известны? Она зависит от частоты контроллера?
нашёл
8N1,скорость задаётся SWCLKэто для манчестерского. Хрен знает, какая тут скорость… Переходником цеплять не лучший вариант. Не подобрать стандартную скорость…
нашёл
8N1,
Баудрейт для SWO настраивается путем деления TRACECLKIN (Asynchronous_Reference_Clock далее; частота обычно равна частоте ядра) c помощью делителя SWOSCALER, задаваемым в регистре TPIU->ACPR
Приведенные в статье вызовы команды «tpiu config» происходят без последнего аргумента, который как раз и определит желаемую скорость SWO. Делал я это для того, чтобы openocd сам считал максимально возможную скорость для текущего отладчика.
Но если бы я хотел использовать USB-UART, скажем на 115200, я бы писал:
Ну и в общем то, на 115200 я как раз и тестил такой режим.
SWO output clock = Asynchronous_Reference_Clock/(SWOSCALAR +1)
Приведенные в статье вызовы команды «tpiu config» происходят без последнего аргумента, который как раз и определит желаемую скорость SWO. Делал я это для того, чтобы openocd сам считал максимально возможную скорость для текущего отладчика.
Но если бы я хотел использовать USB-UART, скажем на 115200, я бы писал:
tpiu config external uart off 168000000 115200
Ну и в общем то, на 115200 я как раз и тестил такой режим.
Можете для начала изучить консоль ITM в CubeIDE https://community.st.com/s/question/0D53W00000oVtxzSAC/swv-not-working-with-stm32f469idisco
По поводу RTT — не правда, что завязано на железе от SEGGER. Поищите такую цепочку: OpenOCD repository -> RTT patch.
Спасибо за наводку, посмотрю.
Там даже Jlink в результате не нужен?
Upd. Действительно не нужен. Обновлю статью.
Там даже Jlink в результате не нужен?
Upd. Действительно не нужен. Обновлю статью.
Semihosting — довольно медленный, RTT — завязан на программно-аппаратные решения Segger, USB — есть не в каждом микроконтроллере. Поэтому обычно, я отдаю предпочтение последним двум — использование UART и ITM.
SWO к сожалению тоже есть далеко не в каждом STM32. Ну а использование UART — это уже нагрузка на МК и использование периферии, т.е. уже не похоже на нормальный режим отладки. Так что на мой взгляд единственным универсальным и при этом эффективным способом логирования является технология типа Segger (там же на самом деле нет ничего такого секретного и проприетарного — просто периодическое чтения блока памяти через отладчик, можно самому легко написать, если есть желание).
Ну и кстати говоря, если уж говорить про непосредственно Segger, то их ПО (j-link, которое на мой взгляд на голову лучше openocd) спокойно работает с обычными st-link. Так что никакой привязки к их недешёвому железу нет.
Из всего семейства Сortex-M вывода SWO нет лишь у M0/M0+ — поэтому решение прокатывает в большинстве случаев. Однако, соглашусь с тем, что решение Segger наиболее универсально. Раньше вот даже не знал, что RTT уже c openocd скрестили, а теперь руки чешутся всё это дело проверить.
Из всего семейства Сortex-M вывода SWO нет лишь у M0/M0+ — поэтому решение прокатывает в большинстве случаев.
Ну вот например у нас из МК используются исключительно STM32F0, так что для нас это «лишь» является наоборот «всем». )))
Раньше вот даже не знал, что RTT уже c openocd скрестили, а теперь руки чешутся всё это дело проверить.
А зачем обязательно openocd использовать? Почему не попробовать более мощный j-link? Оно же даже без логирования и отладки намного удобнее, например хотя бы временем прошивки…
Насколько софт JLink быстрее? Полагаю, что главным фактором, определяющим время прошивки, является всё же скорость соединения дебагера.
Ну а в целом: Qt Creator поддерживает только openocd и st-util — это раз, работа под линуксом — это два (хотя мб софт jlink тут тоже работает), openocd это универсальный комбайн, поддерживающий хоть stm32, stm8, отечественные кортексы — это три, целый зоопарк отладчиков помимо jlink и stlink — это четыре, ну и возможность лазить в сходники и делать любые фиксы — это пять.
Насколько софт JLink быстрее? Полагаю, что главным фактором, определяющим время прошивки, является всё же скорость соединения дебагера.
В десятки раз. На том же железе (но с другой прошивкой программатора).
Qt Creator поддерживает только openocd и st-util
Это не так. Qt Creator изначально поддерживает ровно один универсальный режим отладки — удалённый gdb. Плюс к этому там есть две дополнительные предустановки для st-link и openocd. Однако это всего лишь для удобства — можно без проблем настроить тот же openocd (который естественно реализуют gdb сервер) через общий универсальный режим (он в настройках Qt Creator называется «по умолчанию»).
Так что отладка через j-link (ПО, а в качестве железа служит обычный st-link, перепрошитый под j-link их официальной утилитой) у меня отлично работает из Qt Creator.
работа под линуксом — это два (хотя мб софт jlink тут тоже работает)
Есть и под винду и под линух и под мак.
openocd это универсальный комбайн, поддерживающий хоть stm32, stm8, отечественные кортексы — это три
Так j-link аналогично. И более того, там получается одно универсальное решение не только со стороны ПО, но и одно аппаратное решение для всех МК.
целый зоопарк отладчиков помимо jlink и stlink — это четыре
В данном сравнение это получается уже скорее минус, чем плюс. )))
ну и возможность лазить в сходники и делать любые фиксы — это пять.
А вот это да, я бы тоже предпочёл иметь открытые исходники ПО от Segger. Но боюсь в таком случае у них не вышло бы нормально зарабатывать… ))) Так что уж лучше качественное закрытoe ПО.
Ну всё, почти все пункты биты =)
Однако, довольно сильное преувеличение. Для интереса взял STM32F4-DISCO c набортным ST-LinkV2 — сначала пробовал заливать бинарники через openocd, затем перепрошил отладчик в Jlink OB официальной тулзой и повторял через софт SEGGER на той же скорости SWD. На бинарнике в 1МБ — разница почти в 2 раза получилась (22 против 38 секунд). На бинарнике 100кБ — 3 против 4 секунд. На меньших размерах — разница, полагаю, будет еще менее заметна.
В десятки раз. На том же железе (но с другой прошивкой программатора).
Однако, довольно сильное преувеличение. Для интереса взял STM32F4-DISCO c набортным ST-LinkV2 — сначала пробовал заливать бинарники через openocd, затем перепрошил отладчик в Jlink OB официальной тулзой и повторял через софт SEGGER на той же скорости SWD. На бинарнике в 1МБ — разница почти в 2 раза получилась (22 против 38 секунд). На бинарнике 100кБ — 3 против 4 секунд. На меньших размерах — разница, полагаю, будет еще менее заметна.
Да, я вспомнил что в десятки раз — это касалось не openocd, а родной утилиты от STМ (называется ST-LINK Utility), которой я пользовался для прошивки до j-link.
если всё-же интересно только ускорение прошивки любой ценой, то я добивался 9 секунд для 400к прошивки через обычный USB-UART мост
habr.com/ru/post/305800/#Results
habr.com/ru/post/305800/#Results
Sign up to leave a comment.
Перенаправляем printf() из STM32 в консоль Qt Creator