Т.е. я буду делать плату для STM32 и распаивать на ней процессор другого производителя? Статья о STM32. Перестаньте задавать вопросы не касающиеся темы. Сказано было для отладки.
Вы говорите про частный случай. В статье UART упоминается как необходимый интерфейс для отладки. Если вы пишите прошивку для МК и вам нужно как-то через терминал отлаживать взаимодействие по SPI, берете прослойку с UARTом и заменяете ее на RTT. Работать будет так же. Необходимости именно резервировать шину UART нет. Она может послужить для чего-нибудь более полезного.
Опять же, суть моего посыла в том, что для отладки прошивки МК необходимости использовать UART (а его использование влечет свои последствия) нет, так как есть RTT. Вот вам конкретный пример. Имеем МК, к нему подключаем 4 шаговика по SPI. Как через UART нам получить лог взаимодействия МК с шаговиками? добавлять метки данных конкретного шаговика метку (DR1, DR2..)? а потом к этому написать парсер?
С RTT делаем так: создаем 4 канала, открываем/подключаемся к 4 терминалам (портам) и шлем все данные независимо друг от друга (в порт 9090 обмен данными с шаговиком 1, в порт 9091 данные шаговика 2 и т.д.) ...
Мое сугубо личное мнение - вообще не должен такого знать. Я лишь просто попытался опровергнуть аргументы в пользу uarta при таких условиях. А так да, чем меньше тестировщик знает об устройстве (в плане понимании как оно изнутри работает), тем больше вероятность что он найдет различные баги.
Я как раз понимаю, это был риторический вопрос. Я бы разделил тестировщиков на:
"способных", т.е. у них есть опыт работы с электроникой и понимание что есть какая-нибудь периферия (uart. usb, spi, sdcard и т.п.). И даже если тестировщик чего-то не знает, сильно сомневаюсь что ему составит огромных усилий докачать некий софт с поддержкой telnet (хотя многие программы для мониторинга COM портов также имеют при себе возможность подключения и к TCP, UDP портам)...
"не способных"... ну тут уж разработчик на мой взгляд обязан для него подготовить все необходимое так, чтобы обучать не пришлось (еще лучше написать инструкцию, самому себе в будущем может пригодится).
Абсолютно неверное утверждение. Откуда тестировщик умеет пользоваться COM портом? откуда он вообще знает что это такое и как оно выглядит? Вам не нужно никого учить. Просто передаете ему папку с утилитами и скриптом и говорите на какую иконку нажать. Если прям очень ленивый тестировщик, можете все упихать в один исполняемый exe файл, это вообще не проблема тестировщика, а разработчика ПО, которому нужны логи.
1) Откуда такого пользователя uart? Если UART используется как основной протокол для передачи данных между МК и например ПК, вопросов нет. Это как бы совсем другое и уже касается диагностики вне разработки ПО
2) Если ваш пользователь на самом деле тестировщик ПО, то ничто не мешает вам вместо uart переходника дать ему китайский или любой другой stlink vx.. Какая разница пользователю что и куда он подключает.
3) Если же вы разработчик, то крайне рекомедную хотя бы пощупать работу с RTT, помимо типичного вывода в терминал отладочных сообщений, вы можете настроить несколько терминалов одновременно и использовать каждый из них для собственных нужд (это очень очень сильно зависит от самого проэкта). Например 1 терминал обычная отладка с shell интерфейсом. 2 терминал для вывода бинарных данных/логов (а можно и не бинарных а например в csv формате и сохранять сразу в файл csv, третий терминал можете использовать как интерфейс прослойку для связи с каким-нибудь GUI интерфейсом (симуляции на ПК софта, который потом будет на каком-нибудь устройстве). 4 терминал для максимально детализированной отладки какого-нибудь модуля ПО или его части (когда пошаговая отладка не возможна, да бывает и такое)...
Так вот если уж для отладки нам нужен вывод ввод, то глупо не использовать УЖЕ разведенный SWD для которого 100% будет под рукой stlink, иначе о какой отладке кода идет речь. Время идет, технологии развиваются. Когда-то отлаживали LED светодиодами, потом uart. Теперь есть и RTT под капотом и никаких танцев с бубном ему не требуется.
Всмысле никаких библиотек поддержки? 1) Настройка тактирования перефирии 2) Настройка DMA для разгрузки MCU 3) Выбрать пины (для разных проектов, плат вам это придется делать. 4) Конфигурация этих пинов 5) Пины кроме как для отладки использовать нельзя 6) Нельзя просто взять ваш код с конфигурацией "пары" регистров и перенести его с STM32F0 на например STM32H7
RTT от переферии не зависит. Купируются файлы в проект и все. Можно использовать.
Мда, в 2025 году все еще отлаживать через UART... При том что SWD разъем тоже будет выведен. Пора бы уже научиться использовать RTT + OpenOCD в связке и иметь несколько каналов ввода-ввывода через telnet. Скорость обмена которую я получал с stlink v2 была около 100 кбайт/с.
Т.е. я буду делать плату для STM32 и распаивать на ней процессор другого производителя? Статья о STM32. Перестаньте задавать вопросы не касающиеся темы. Сказано было для отладки.
Вы говорите про частный случай. В статье UART упоминается как необходимый интерфейс для отладки. Если вы пишите прошивку для МК и вам нужно как-то через терминал отлаживать взаимодействие по SPI, берете прослойку с UARTом и заменяете ее на RTT. Работать будет так же. Необходимости именно резервировать шину UART нет. Она может послужить для чего-нибудь более полезного.
Опять же, суть моего посыла в том, что для отладки прошивки МК необходимости использовать UART (а его использование влечет свои последствия) нет, так как есть RTT. Вот вам конкретный пример. Имеем МК, к нему подключаем 4 шаговика по SPI. Как через UART нам получить лог взаимодействия МК с шаговиками? добавлять метки данных конкретного шаговика метку (DR1, DR2..)? а потом к этому написать парсер?
С RTT делаем так: создаем 4 канала, открываем/подключаемся к 4 терминалам (портам) и шлем все данные независимо друг от друга (в порт 9090 обмен данными с шаговиком 1, в порт 9091 данные шаговика 2 и т.д.) ...
Интересно а как UARTом добраться до SPI, I2C? Можно поподробнее?
все что можно на UART, можно и через RTT.
Я не могу на данный момент знать. Либо свой блог заведу либо еще где.
Задумываюсь, но скорее всего это будет не на хабре.
Мое сугубо личное мнение - вообще не должен такого знать. Я лишь просто попытался опровергнуть аргументы в пользу uarta при таких условиях. А так да, чем меньше тестировщик знает об устройстве (в плане понимании как оно изнутри работает), тем больше вероятность что он найдет различные баги.
Я как раз понимаю, это был риторический вопрос. Я бы разделил тестировщиков на:
"способных", т.е. у них есть опыт работы с электроникой и понимание что есть какая-нибудь периферия (uart. usb, spi, sdcard и т.п.). И даже если тестировщик чего-то не знает, сильно сомневаюсь что ему составит огромных усилий докачать некий софт с поддержкой telnet (хотя многие программы для мониторинга COM портов также имеют при себе возможность подключения и к TCP, UDP портам)...
"не способных"... ну тут уж разработчик на мой взгляд обязан для него подготовить все необходимое так, чтобы обучать не пришлось (еще лучше написать инструкцию, самому себе в будущем может пригодится).
Абсолютно неверное утверждение. Откуда тестировщик умеет пользоваться COM портом? откуда он вообще знает что это такое и как оно выглядит? Вам не нужно никого учить. Просто передаете ему папку с утилитами и скриптом и говорите на какую иконку нажать. Если прям очень ленивый тестировщик, можете все упихать в один исполняемый exe файл, это вообще не проблема тестировщика, а разработчика ПО, которому нужны логи.
1) Откуда такого пользователя uart? Если UART используется как основной протокол для передачи данных между МК и например ПК, вопросов нет. Это как бы совсем другое и уже касается диагностики вне разработки ПО
2) Если ваш пользователь на самом деле тестировщик ПО, то ничто не мешает вам вместо uart переходника дать ему китайский или любой другой stlink vx.. Какая разница пользователю что и куда он подключает.
3) Если же вы разработчик, то крайне рекомедную хотя бы пощупать работу с RTT, помимо типичного вывода в терминал отладочных сообщений, вы можете настроить несколько терминалов одновременно и использовать каждый из них для собственных нужд (это очень очень сильно зависит от самого проэкта). Например 1 терминал обычная отладка с shell интерфейсом. 2 терминал для вывода бинарных данных/логов (а можно и не бинарных а например в csv формате и сохранять сразу в файл csv, третий терминал можете использовать как интерфейс прослойку для связи с каким-нибудь GUI интерфейсом (симуляции на ПК софта, который потом будет на каком-нибудь устройстве). 4 терминал для максимально детализированной отладки какого-нибудь модуля ПО или его части (когда пошаговая отладка не возможна, да бывает и такое)...
Аргумент по типу - пользователь не имеющий stlink бьется пользователем не имеющим uart переходник. В сегодняшнее время китайские и не только stlinkи стоят сопоставимо с uart переходниками. Но в статье цитирую:
UART очень нужен для printf-отладки.Еще на UART можно запустить Shell. Shell нужна для отладки, управления, тестирования софта и железа, просмотра логов, диагностики и многого другого.Так вот если уж для отладки нам нужен вывод ввод, то глупо не использовать УЖЕ разведенный SWD для которого 100% будет под рукой stlink, иначе о какой отладке кода идет речь. Время идет, технологии развиваются. Когда-то отлаживали LED светодиодами, потом uart. Теперь есть и RTT под капотом и никаких танцев с бубном ему не требуется.
Всмысле никаких библиотек поддержки?
1) Настройка тактирования перефирии
2) Настройка DMA для разгрузки MCU
3) Выбрать пины (для разных проектов, плат вам это придется делать.
4) Конфигурация этих пинов
5) Пины кроме как для отладки использовать нельзя
6) Нельзя просто взять ваш код с конфигурацией "пары" регистров и перенести его с STM32F0 на например STM32H7
RTT от переферии не зависит. Купируются файлы в проект и все. Можно использовать.
Мда, в 2025 году все еще отлаживать через UART... При том что SWD разъем тоже будет выведен. Пора бы уже научиться использовать RTT + OpenOCD в связке и иметь несколько каналов ввода-ввывода через telnet. Скорость обмена которую я получал с stlink v2 была около 100 кбайт/с.
и как вашим attiny через wifi управлять?
Если можно тетрагидропиранилциклопентилтетрагидропиридопиридиновыми, то я придумаю новую формулу и сделаю новый рекорд:
гентетраконтагидропиранилциклопентилтетрагидропиридопиридиновыми.
Ну, помянем их...
Кто посмел перекаверкать истинное название?? Правильно не SOSAL, а LASOS. Будьте как рыба в воде.
Автор, вы используете Extended Erase Memory Command, а не Erase Memory Command... внимательнее надо быть
Ну конечно, это "статья" ради саморекламы. В этом "step by step" гайде, много чего отсутсвует...
Поддерживаю.. Уже давно в OpenOCD внедрили. Можно настроить как угодно разное кол-во вводов/выводов.