Альтернатива USART, Как насчет SWO? Опции

[NeDoEng]

В настоящее время (впрочем как и многие начинающие) использую для вывода отладочных сообщений USART. Т.е. помимо программатора к плате подключен еще и преобразователь USB-USART - неудобно же.
Знаю, что есть такой интерфейс SWD, который поддерживает вывод отладочной информации через вывод SWO. Т.е. имея 1 программатор с интерфейсом SWD такой как ST-link/V2 можно и шить и получать отладочные сообщения.
Например при использовании USART на скорости 921600 бод 1 байт можно передать примерно за 11 мкс. Достаточно быстро и погрешность установки скорости 0,16%. Быстрее пробовал, но не пашет почему-то. Использую преобразователь на ft2232.

SWO может так же или быстрее? Нигде не найду конкретных значений.

[jcxz]

SWO может так же или быстрее? Нигде не найду конкретных значений.

Лучше так не делать (не убирать отладочный UART). Вылезет потом у Вас проблема, что с подключенным SWD работает, а без - нет, как искать будете?
Включения/выключения питания, технологическое тестирование в течение длительного времени (когда какая-то инфа пишется в лог) с десятком устройств - как это всё делать?
Испытания на устойчивость к помехам и на помехоэмиссию с контролем работоспосбности, тоже - как?
Да и как-то пробовал я выводить отладку через J-Link, имхо: при этом нарушается реалтайм работы устройства, такое ощущение, что вывод через отладочный JTAG подтормаживает работу устройства,
по сравнению с обычной работой без лога или с логом в UART. Правда пробовал это не через SWD, а через JTAG. И может что-то не так сделал.
Но, имхо, работа с подключенным эмулятором и без оного - бывает несколько разной и нужно иметь возможность отладки и без подключенного эмулятора.

[esaulenka]

Да и как-то пробовал я выводить отладку через J-Link, имхо: при этом нарушается реалтайм работы устройства, такое ощущение, что вывод через отладочный JTAG подтормаживает работу устройства,
по сравнению с обычной работой без лога или с логом в UART. Правда пробовал это не через SWD, а через JTAG. И может что-то не так сделал.

Ну ещё бы. Semihosting - это старый механизм. Довольно гибкий, но крайне медленный:
- софт в контроллере на каждый putchar() выставляет брекпоинт.
- отладчик "ловит" этот брекпоинт, считывает переданный байтик (по определённой комбинации регистров, насколько я помню), отправляет в консоль.
Помимо двунаправленной консоли, можно ещё кучу "плюшек" организовать, но, вроде б, это так никто и не поддержал. Подробности есть на arm.com в разделе "ARM Compiler Software Development Guide" -> "Semihosting".
Но постоянные остановки ядра на пользу реалтайму не идут, конечно же.

SWO - это совсем другая штука. Ядро кладёт байтик в специальный регистр, а дальше "оно само". Но тут канал однонаправленный (впрочем, в 99% случаев отладочный канал такой и нужен).

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

Это если только энергосбережение какое-то отлаживать. Но там и внешний уарт мешать будет.
А так - SWD и SWO штуки независимые, можно использовать только что-то одно.

[jcxz]

SWO - это совсем другая штука. Ядро кладёт байтик в специальный регистр, а дальше "оно само". Но тут канал однонаправленный (впрочем, в 99% случаев отладочный канал такой и нужен).

Если так, имхо - это сводит его полезность почти к нулю.

esaulenka, верно в 99% случаев достаточно одностороннего обмена.

Может быть Вам. А мне в 100% случаев нужен двусторонний канал отладки.

Я использую HS USB если нужен действительно быстрый канал для чего-то типа J-Scope.

USB для обычного лога не очень хороший выбор, так как для отладки: чем проще периферия, чем меньше требует ресурсов и чем раньше она запускается от момента старта ПО, тем лучше.