Тоже делал подобные часы =) Очень долго играл в шарады, чтобы можно было составить читаемую надпись для любой минуты. Часы сами себе являются корпусом - стек из 4 плат и рамки из акрила.
Я тоже реализовывал всё описанное на баше, и не в одном проекте.
Субъективное имхо:
баш намного менее читабелен;
в баше гораздо труднее добавлять новые фичи и фиксить старые;
в баше код сложнее поддерживать человеку, отличному от автора;
в баше очень много надо велосипедировать, когда в пайтоне это можно достать из коробки;
скрипты на пайтоне лучше сопрягаются с другими скриптами на пайтоне, существующими в проекте (как минимум препроцессинг, кодогенерация, постпроцессинг);
пайтон гораздо интуитивнее и приятнее в написании кода.
Мне этого уже более чем достаточно, чтобы начать с удовольствием применять описанное в статье. Поэтому и решил поделиться, т.к. возможно кто-нибудь тоже искал подобное.
В десятки раз. На том же железе (но с другой прошивкой программатора).
Однако, довольно сильное преувеличение. Для интереса взял STM32F4-DISCO c набортным ST-LinkV2 — сначала пробовал заливать бинарники через openocd, затем перепрошил отладчик в Jlink OB официальной тулзой и повторял через софт SEGGER на той же скорости SWD. На бинарнике в 1МБ — разница почти в 2 раза получилась (22 против 38 секунд). На бинарнике 100кБ — 3 против 4 секунд. На меньших размерах — разница, полагаю, будет еще менее заметна.
Насколько софт JLink быстрее? Полагаю, что главным фактором, определяющим время прошивки, является всё же скорость соединения дебагера.
Ну а в целом: Qt Creator поддерживает только openocd и st-util — это раз, работа под линуксом — это два (хотя мб софт jlink тут тоже работает), openocd это универсальный комбайн, поддерживающий хоть stm32, stm8, отечественные кортексы — это три, целый зоопарк отладчиков помимо jlink и stlink — это четыре, ну и возможность лазить в сходники и делать любые фиксы — это пять.
Из всего семейства Сortex-M вывода SWO нет лишь у M0/M0+ — поэтому решение прокатывает в большинстве случаев. Однако, соглашусь с тем, что решение Segger наиболее универсально. Раньше вот даже не знал, что RTT уже c openocd скрестили, а теперь руки чешутся всё это дело проверить.
Баудрейт для SWO настраивается путем деления TRACECLKIN (Asynchronous_Reference_Clock далее; частота обычно равна частоте ядра) c помощью делителя SWOSCALER, задаваемым в регистре TPIU->ACPR
Приведенные в статье вызовы команды «tpiu config» происходят без последнего аргумента, который как раз и определит желаемую скорость SWO. Делал я это для того, чтобы openocd сам считал максимально возможную скорость для текущего отладчика.
Но если бы я хотел использовать USB-UART, скажем на 115200, я бы писал:
tpiu config external uart off 168000000 115200
Ну и в общем то, на 115200 я как раз и тестил такой режим.
Наиболее удобным способом использования ITM является вывод через SWO с иcпользованием NRZ кодирования — таким образом, нужна всего одна линия, и принимать данные можно будет не только с помощью отладчика со специальным входом, но и обычным USB-UART переходником, пусть и с меньшей скоростью.
В этом случае с помощью itmdump нужно будет уже подключаться к COM-порту, а не к файлу/пайпу. В мануале на OpenOCD, собственно, такой способ и описывают в подразделе где идет речь о «tpiu config».
В принципе, можно даже и itmdump не использовать, а включить обычный эмулятор терминала — выводимые символы будет видно, но они будут разбавлены мусором.
Рад помочь!
Ну, использование sprintf() это можно сказать "естественная реакция организма" на задачу вывода строки в UART. Собственно, сам так и делал, пока не узнал о ключевом слове "retarget". А дальше все довольно быстро нагуглилось =)
При этом, у НИИЭТ тоже есть МК на ядре ARM Cortex (К1921ВК01Т), и в тамошнем UART'e тоже нет такого прерывания. Совпадение? Или по Зеленограду кочует один и тот же UART?
Достаточно одного взгляда на карту регистров, чтобы понять, что это один и тот же IP :)
Однако, в последних камнях НИИЭТ прерывание «передача завершена» появилось.
Тоже делал подобные часы =) Очень долго играл в шарады, чтобы можно было составить читаемую надпись для любой минуты. Часы сами себе являются корпусом - стек из 4 плат и рамки из акрила.
Я тоже реализовывал всё описанное на баше, и не в одном проекте.
Субъективное имхо:
Мне этого уже более чем достаточно, чтобы начать с удовольствием применять описанное в статье. Поэтому и решил поделиться, т.к. возможно кто-нибудь тоже искал подобное.
Бинарники там не выложены, но все необходимые процедуры описаны неплохо.
Однако, довольно сильное преувеличение. Для интереса взял STM32F4-DISCO c набортным ST-LinkV2 — сначала пробовал заливать бинарники через openocd, затем перепрошил отладчик в Jlink OB официальной тулзой и повторял через софт SEGGER на той же скорости SWD. На бинарнике в 1МБ — разница почти в 2 раза получилась (22 против 38 секунд). На бинарнике 100кБ — 3 против 4 секунд. На меньших размерах — разница, полагаю, будет еще менее заметна.
Насколько софт JLink быстрее? Полагаю, что главным фактором, определяющим время прошивки, является всё же скорость соединения дебагера.
Ну а в целом: Qt Creator поддерживает только openocd и st-util — это раз, работа под линуксом — это два (хотя мб софт jlink тут тоже работает), openocd это универсальный комбайн, поддерживающий хоть stm32, stm8, отечественные кортексы — это три, целый зоопарк отладчиков помимо jlink и stlink — это четыре, ну и возможность лазить в сходники и делать любые фиксы — это пять.
Там даже Jlink в результате не нужен?
Upd. Действительно не нужен. Обновлю статью.
Не отвалится. Настроить скорость можно хоть в самой прошивке, хоть через отладчик.
Приведенные в статье вызовы команды «tpiu config» происходят без последнего аргумента, который как раз и определит желаемую скорость SWO. Делал я это для того, чтобы openocd сам считал максимально возможную скорость для текущего отладчика.
Но если бы я хотел использовать USB-UART, скажем на 115200, я бы писал:
Ну и в общем то, на 115200 я как раз и тестил такой режим.
В этом случае с помощью itmdump нужно будет уже подключаться к COM-порту, а не к файлу/пайпу. В мануале на OpenOCD, собственно, такой способ и описывают в подразделе где идет речь о «tpiu config».
В принципе, можно даже и itmdump не использовать, а включить обычный эмулятор терминала — выводимые символы будет видно, но они будут разбавлены мусором.
Рад помочь!
Ну, использование sprintf() это можно сказать "естественная реакция организма" на задачу вывода строки в UART. Собственно, сам так и делал, пока не узнал о ключевом слове "retarget". А дальше все довольно быстро нагуглилось =)
Эррата? На них же кроме описания нету ничего.
Достаточно одного взгляда на карту регистров, чтобы понять, что это один и тот же IP :)
Однако, в последних камнях НИИЭТ прерывание «передача завершена» появилось.