Comments 106
С моей точки зрения большинство разрабатываемых электронных плат работают под управлением микроконтроллеров STM32.
Смелое утверждение.
В отличие от...
микроконтроллеров на ядре 8051, появившихся в 1980 году и имеющих коллосальный парк legacy-устройств
микроконтроллеров PADAUK со стоимостью меньше 1 цент/шт и, соответственно, обширнейшим рынком бытовой электроники
микроконтроллерлв NXP с сертефикацией AEC-Q, которые допустимо применять в автомобилестроении (тоже немалый рынок)
микроконтроллеров на ядре AVR, ставших де-факто стандартом DIY-электроники благодаря Ардуино
...STM32 не.
<вывести пины, добавить тест-пады>
...или купить себе набор SDK08, которым можно зацепляться за выводы в т.ч. различных LQFP.
SDK08
Вывести отдельный свободный аппаратный UART на какой-нибудь PLD разъём. Желательно вилку. UART очень нужен для printf-отладки.
На самом деле, для отладки нужен JTAG, о котором в статье ни слова. Но это - без обид - просто интересный баг инженеров, плотно занимающихся программированием микроконтроллеров: многие из них думают, что JTAG - это такой беспонтовый интерфейс для заливки прошивок в микроконтроллеры. Однако это не совсем так :)
Добавить на свободный ADC уникальное константное напряжение для каждой новой версии платы <...> Если жалко ADC, то можно и четыремя-пятью GPIO бинарно задавать версию платы. <...> Если есть место, то можно еще джамперами задавать прошивке какой-то код. Условно NVRAM на джемперах.
Лопни мои глазоньки! Может проще при первом заводском программировании устройств вносить ревизию устройства в OTP-память, которой снабжаются STM32, а при необходимости обновления на этапе эксплуатации версии прошивки вычитывать эту область?
GND для оссциллографа. GND всегда нужно для подключения мультиметра, для подключения осциллоскопа
В современной отраслевой русскоязычной терминологии слово "осциллоскоп" не используется. Используется только "осциллограф".
Чем вам таг коннект не угодил? В минимальной версии на шесть контактов очень классный разъем!
От себя добавлю:
Не ставить ничего ближе 2х диаметров к крепежному отверстию, то есть если отверстие 3мм, то еще вокруг ободок 3мм. Особенно актуально, если это дешевый товар, и собирается он китайско-подвальным способом. Иначе может быть очень большое веселье с крепежом, когда нужные болтики внезапно $150 упаковка, такие же, но на 0.5мм шире шляпкой - $10 за упаковку - но у вас они не влезают.
Не экономьте на usb разъемах. Коннекторы по центу - это брак, который после десяти подключений начинает глючить или совсем отламывается. Тоже касается и разъемов карт памяти.
Выводите на перемычки BOOTx пины. 0102 перемычка ничего не занимает почти, но иногда чертовски нужно.
Закладывайте схемотехнику для совместимости. STM32 и его китаские собратья часто полностью совместимы по пинам, но кое-что может отличатся. Вот эти мелочи лучше заложить в виде перемычек - и здорово сэкономить на тираже в будущем.
Синие светодиоды в качестве индикаторов - зло и признак дешевой поделки. Белые тоже. Ибо они чаще всего черезмерно яркие и раздражают, когда прибор используется в темном помещении, например, в спальне.
Производящий в 2025 году платы на гетинаксе будет проклят навеки. И не важно, что это немного дешевле - он мало того неремонтопригоден, так еще и имеет свойство к внезапоному отваливанию дорожек под нагрузкой (провода, тяжелые выводные компоненты типа реле и конденсаторов, нагревающиеся компоненты) с последующим КЗ у пользователя.
UART это просто, быстро, удобно, и чаще всего ему не надо вообще никаких библиотек поддержки - буквально пару регистров настройки и всё. UART не заменяет отладчик, но тоже очень важен, например, на тестировании или поддержке.
И кроме того -- это универсально. Это позволяет к этому UARTу подключиться пользователю, не имеющему ST-Linkа и получить диагностику, чтобы отправить ее в поддержку.
Например, зачем?
Затем, что тестировщик может взять любой софт для мониторинга COM-порта и забирать лог после процесса тестирования. Очень удобно для ловли плавающих багов, которые на лабе не воспроизводятся. Научить его использовать отладчик... Нет, не реально. И тем более нереально научить это делать инженера поддержки/сопровождения, который поддерживает парк устройств у заказчика.
Ммм. А какие библиотеки поддержки нужны при отладке через JTAG/SWD?
Со стороны контроллера надо завести этот JTAG/SWD, но это ладно, так как разработчик для того и нужен. Большее зло - необходимость специального софта на ББ и умение им пользоваться. Для разработчика фигня, для остальных в цепочке разработки продукта - боль и унижение.
Тестировщик сидит у себя в отделе, а не ездит. Но его все равно очень сложно научить даже использовать uart - в тестировании сейчас почти всегда те люди, которые не смогли в разработку или аналитику, но хотят в айти....
Потому что часто инженеры поддержки - сотрудники заказчика, или какой-нибудь аутсорс. Их можно заставить поставить нужный софт, но научить их пользоваться им квест 80лвла. А putty они знают почти все, так как всякие коммутаторы и атс именно через СОМ-порт настраиваются.
И дорогой разработчик вместо своих прямых задач занимается поддержкой вместо сотрудников поддержки, стоящих намного дешевле.
Холивор бесплоден по своей сути. Если у вас разработчик отлаживается через printf через уарт - штош, вопрос к нему, почему он не использует современные средства отладки. Но вот кидать в этот уарт логи - вполне себе хорошая идея, чтобы упростить поддержку.
Конвертер там должен быть двунаправленный 3-5в, потому как периферия на 5 всё еще в ходу
В догонку. Можно из оставшихся свободных пинов MK делать детекторы напряжений через делители на GPIO.
Детектор 5V, 3.2V, 12V и т.п.
Для 5 В периферии напряжение 3,3 В в 99% случаев отлично считывается как лог. 1, конвертер не нужен.
Если связь двунаправленная, то периферия может отдать 5 Вольт обратно на вход МК и тогда МК может огорчиться.
Хотя, я лично считаю, что конвертер не нужен, так как это редкий случай. Для таких случаев проще добавить эту часть на стороне периферии или найти вариант на 3,3 В.
С моей точки зрения большинство разрабатываемых электронных плат работают под управлением микроконтроллеров STM32.
Смелое утверждение.
В отличие от...
микроконтроллеров на ядре 8051, появившихся в 1980 году и имеющих коллосальный парк legacy-устройств
микроконтроллеров PADAUK со стоимостью меньше 1 цент/шт и, соответственно, обширнейшим рынком бытовой электроники
микроконтроллерлв NXP с сертефикацией AEC-Q, которые допустимо применять в автомобилестроении (тоже немалый рынок)
микроконтроллеров на ядре AVR, ставших де-факто стандартом DIY-электроники благодаря Ардуино
...STM32 не.
<вывести пины, добавить тест-пады>
...или купить себе набор SDK08, которым можно зацепляться за выводы в т.ч. различных LQFP.
SDK08
Вывести отдельный свободный аппаратный UART на какой-нибудь PLD разъём. Желательно вилку. UART очень нужен для printf-отладки.
На самом деле, для отладки нужен JTAG, о котором в статье ни слова. Но это - без обид - просто интересный баг инженеров, плотно занимающихся программированием микроконтроллеров: многие из них думают, что JTAG - это такой беспонтовый интерфейс для заливки прошивок в микроконтроллеры. Однако это не совсем так :)
Добавить на свободный ADC уникальное константное напряжение для каждой новой версии платы <...> Если жалко ADC, то можно и четыремя-пятью GPIO бинарно задавать версию платы. <...> Если есть место, то можно еще джамперами задавать прошивке какой-то код. Условно NVRAM на джемперах.
Лопни мои глазоньки! Может проще при первом заводском программировании устройств вносить ревизию устройства в OTP-память, которой снабжаются STM32, а при необходимости обновления на этапе эксплуатации версии прошивки вычитывать эту область?
GND для оссциллографа. GND всегда нужно для подключения мультиметра, для подключения осциллоскопа
В современной отраслевой русскоязычной терминологии слово "осциллоскоп" не используется. Используется только "осциллограф".
P.S.
Для LEDов надо стараться назначить такой пин на котором есть аппаратный PWM. <...> Бывает так, что из-за проблем с логистикой на PCB ставят не те LEDs или не те токо ограничивающие резисторы.
Если разработка устройства ведётся с пониманием того, что производству могут доставить комплектующие не по BOM-у, разумным будет зарезервировать место под дополнительный резистор, параллельный основному токоограничивающему резистору. Чтобы в случае чего набрать подходящий совокупный номинал из пары резисторов имеющихся в наличие.
Но вообще - это капец, конечно.
Токоограничивающий резистор к контрольному сд на плате - компонент номиналы которого можно менять в сотни раз без изменения функций цепочки.
Токоограничивающий резистор к контрольному сд на плате - компонент номиналы которого можно менять в сотни раз без изменения функций цепочки.
Тут не соглашусь. У светодиодов интенсивность свечения пропорциональна току.
При стократном изменении токоограничивающего резистора и интенсивность свечения изменится стократно.
Я бы даже сказал не землю делать, а кучу пар земля-сигнал для такой конфигурации щупа
Иначе можно ловить все что угодно, но только не то что нужно.
И даже не JTAG, а SWD.
Тут опять проблемы разделения на электронщиков и программистов.
Если программисты вообще не хотят что-то слышать об интерфейсах, то электронщики ничего не хотят знать об отладочной периферии.
У ST в чипах один из лучших отладочных модулей - ARM CoreSight
Segger чипы STM32 использует как эталон для своих трассировщиков.
А тут UART какой-то, светодиоды ...
И еще этот ужасный, бестолковый и неуклюжий PogoPins , это наверно чтоб SWD только в крайнем случае подключали.
Между тем даже на самых дешевых отладках сейчас ставят инструментальные чипы для работы через SWD.
Я бы даже сказал не землю делать, а кучу пар земля-сигнал для такой конфигурации щупа
Тут тоже важно не перестараться, чтобы серийное изделие не превратилось в буйство метрологии.
электронщики ничего не хотят знать об отладочной периферии.
Электронщики, кмк, будут поближе к технологам. Технологи же, при наличие на плате BGA, вполне любят JTAG :) А то заглядывать через микроскоп с боковой призмой между шариков увлекательно, но на больших партиях утомляет.
А тут UART какой-то, светодиоды ...
И еще этот ужасный, бестолковый и неуклюжий PogoPins
Вот да. Я читал и такой: "Штааа? Штаа?!"
Чем вам таг коннект не угодил? В минимальной версии на шесть контактов очень классный разъем!
Чем вам таг коннект не угодил? В минимальной версии на шесть контактов очень классный разъем!
Я допускаю, что на некоторых устройствах tag-connect вполне уместен.
Однако обоснования использования tag-connect в контексте статьи выглядят весьма противоречивыми.
Благодаря Tag-Connect также можно исключить из BOM платы расходы на пластмассовый разъём для программатора
Его и так можно исключить. Оставить только контактные площадки под PBD-6-1.27 поверхностного монтажа. Сам разъём не запаивать. Если вдруг потребуется отладка на готовом устройстве - только тогда его и припаять.
Что должно быть заложено в каждую электронную плату на основе МК STM32? Само собой надо добавить квадратные первые пины на вилках, шелкографию, тест пады, симметричные отверстия 3мм по краям
<...>
3) Добавить для программирования по SWD разъем Tag-Connect. Площадь на PCB зачастую очень ценный ресурс.
Из моего опыта, или у вас площадь настолько ценный ресурс, что нет места под отладочный разъём или у вас множественный крепёж 3мм.
вот да, UART для принтф-дебага при том, что там есть специально обученный вывод SWO...
(а SWD на погопинах не всегда хорошо работает на высоких скоростях. а прошивать мегабайтный чип по унылым десяткам килобит/с- ну такое.)
SDK08
Он не замыкает соседние выводы?
SDK08 не замыкает соседние выводы?
При толщине ленты из которой сделаны захваты в 0,13мм, чтобы не замыкаться, ему достаточен зазор между выводами микросхемы в 0,13х2=0,26мм.
С учётом геометрии и всяких неровностей производитель декларирует допустимость работы по корпусам с зазором между пинами в 0,30мм. У LQFP-64 номинальный зазор 0,32мм.
Так что нет. Ну, в рамках разумного. Шину на 16 бит обвешивать при помощи SDK08 - такая себе идея, конечно. А подключиться к GND и CLKOUT - самое то.
Я не пользовался, поэтому спрашиваю. А эти вот трубочки - они не металлические?
Я не пользовался, поэтому спрашиваю. А эти вот трубочки - они не металлические?
Они металлические. Но там где крючок, их разводят сами выводы микросхемы, за которые они зацеплены, а на противоположном конце их разводит пластиковый корпус. У трубочек толщина 1мм, у корпуса 3мм. Так что трубочки друг друга не касаются.
В современной отраслевой русскоязычной терминологии слово "осциллоскоп" не используется. Используется только "осциллограф".
Я когда с рекрутёршей по телефону общался, она и вовсе сказала, что "надо уметь пользоваться осцилогом."
или купить себе набор SDK08, которым можно зацепляться за выводы в т.ч. различных LQFP.
Благодарю Вас @Flammmable за рекомендацию SDK08! Не знал, что есть такое.
Тотчас же заказал себе три комплекта.
Тут тоже важно не перестараться, чтобы серийное изделие не превратилось в буйство метрологии.
Зато когда ремонтируешь это серийное изделие, всегда приятно обнаружить нужный сигнал на тестпаде, а не на шарике номер BZ18 100500-ногого BGA.
Для начала приятно бы обнаружить документацию на изделие... борду, чтоб знать куда этот тестпад идёт...
Зато когда ремонтируешь это серийное изделие, всегда приятно обнаружить нужный сигнал на тестпаде, а не на шарике номер BZ18 100500-ногого BGA.
Оно приятно, если есть документация на плату (что характерно для evaluation board и менее характерно для серийных рабосих устройств). И если из 100500 ног BGA на тестпад выведено именно то, что сломалось (100500 тестпадов я лично видел только на evaluation board, но не на серийных рабочих устройствах).
3) Добавить для программирования по SWD разъем Tag-Connect
Такой себе совет конечно.
Цены на оригинальные Tag-Connect очень большие, и в наших условиях подобрать что то подходящее из номенклатуры очень проблемно.
Так же, если вы не заметили, у кабеля нет фиксаторов к плате. Т.е. чтобы отлаживать - все равно надо паять проводки и дальше уже цепляться как придумаете. У Tag-Connect есть кабели с фиксаторами, но разъем под них уже съедает много места.
Китайские прищепки тоже не всегда выход. Они будут работать если у вас разъем программирования с краю платы. Если плата относительно большая и разъем в глубине, то прищепкой уже можно не дотянуться
У этих разъемов есть болячка - контактирующие штыри на пружинках. И со временем они теряют упругость, не дожимают или просто вылетают из разъема. А с учетом цен на оригинальные кабели, ну прям может быть грустно.
2. Задайте себе вопрос: для чего нужна пустая плата с тремя втулками слева от минимальной версии на фото.
4. Десяток тысяч устройств ежегодно. Полёт нормальный.
2. Задайте себе вопрос: для чего нужна пустая плата с тремя втулками слева от минимальной версии на фото.
Одно время на avito даже продавались за 200 руб многоразовые пластмассовые цанги-фиксаторы из резины для Tag-Connect.
https://www.avito.ru/user/5558df2b308b21689aeccd2c323b76c1/profile?
Tag Connect grip-6 grip-10
А еще по площади на плате они занимпют места больше чем просто pin header с малым шагом
8) Добавить фаски по углам PCB. Это чтобы не поцарапаться об углы PCB. Чтобы не порвать пакет при перевозке платы в рюкзаке и т п. Скругленные края даже выглядят приличнее нежели острые углы.
Острые углы, это и индекс и крепление. При вставке в слот корпуса скругленной плате будет просто нечем упереться. Царапаются если зажали на фрезеровку и платы разломаны, но не отшлифованы с торцов хотя бы даже ручками...
Со светодиодами на пины надо быть осторожнее. Особенно, если их ток больше 0,5...1 мА. Большая нагрузка на GPIO негативно влияет на работу встроенного АЦП. Бывают случаи, когда АЦП при стабильном напряжении на входе выдает разные (на 5...10 %) коды в зависимости от состояния светодиодов на GPIO. Возможно, это влияние не на сам АЦП, а на внутренний опорник. Но эффект есть и надо о нем помнить, мигая диагностическими светодиодами.
Звучит разумно, но тогда это проблема с любой нагрузкой, что же теперь, не дрыгать лапами (не всегда есть diff in ADC) ?
ps ледов много не бывает - всегда радуется глаз, что уж говорить - у меня значительная часть удовлетворения от проекта от весёлого мигания телеметрии :)
Для отладочных целей можно ставить 20-30-50КОм резистор и мелкий белый диод, который вполне заметно горит при самых мизерных токах. Оно не нагружает порты и не требует транзистора.
А на пользовательские индикаторы таки надо ставить транзистор, и вешать их на ШИМ.
Для отладочных целей можно ставить 20-30-50КОм резистор и мелкий белый диод
При напряжении 3В и токоограничивающем резисторе 30кОм, ток через светодиод будет составлять 0,1мА. Такой ток сам по себе просадит, например, батарейку CR2032 за 40...90 дней.
На такие устройства обычно россыпь отладочных светодиодов не ставят. Максимум - один индикаторный, который иногда мигает.
Светодиоды. Желательно, чтобы LEDов было как минимум три.
На такие устройства обычно россыпь отладочных светодиодов не ставят. Максимум - один
:)
От себя добавлю:
Не ставить ничего ближе 2х диаметров к крепежному отверстию, то есть если отверстие 3мм, то еще вокруг ободок 3мм. Особенно актуально, если это дешевый товар, и собирается он китайско-подвальным способом. Иначе может быть очень большое веселье с крепежом, когда нужные болтики внезапно $150 упаковка, такие же, но на 0.5мм шире шляпкой - $10 за упаковку - но у вас они не влезают.
Не экономьте на usb разъемах. Коннекторы по центу - это брак, который после десяти подключений начинает глючить или совсем отламывается. Тоже касается и разъемов карт памяти.
Выводите на перемычки BOOTx пины. 0102 перемычка ничего не занимает почти, но иногда чертовски нужно.
Закладывайте схемотехнику для совместимости. STM32 и его китаские собратья часто полностью совместимы по пинам, но кое-что может отличатся. Вот эти мелочи лучше заложить в виде перемычек - и здорово сэкономить на тираже в будущем.
Синие светодиоды в качестве индикаторов - зло и признак дешевой поделки. Белые тоже. Ибо они чаще всего черезмерно яркие и раздражают, когда прибор используется в темном помещении, например, в спальне.
Производящий в 2025 году платы на гетинаксе будет проклят навеки. И не важно, что это немного дешевле - он мало того неремонтопригоден, так еще и имеет свойство к внезапоному отваливанию дорожек под нагрузкой (провода, тяжелые выводные компоненты типа реле и конденсаторов, нагревающиеся компоненты) с последующим КЗ у пользователя.
Синие светодиоды в качестве индикаторов - зло и признак дешевой поделки.
А ещё из-за дисперсии в хрусталике глаза возникает матёрая хроматическая аберрация - синие светодиоды очень сильно двоятся.
Производящий в 2025 году платы на гетинаксе
Неужели они до сих пор существуют? Кажется, последний раз гетинакс видел в аппаратуре времен СССР. И да, это был ужас при ремонте - дорожки отваливались при пайке только так.
когда прибор используется в темном помещении, например, в спальне
В принципе невозможность отключить светодиоды в потребительской электронике - зло. Цвет тут уже абсолютно не важен.
Не ставить ничего ближе 2х диаметров к крепежному отверстию, то есть если отверстие 3мм, то еще вокруг ободок 3мм
Зона отчуждения.
Благодарю Вас, @kenomimi, что поделились опытом.
Мда, в 2025 году все еще отлаживать через UART... При том что SWD разъем тоже будет выведен. Пора бы уже научиться использовать RTT + OpenOCD в связке и иметь несколько каналов ввода-ввывода через telnet. Скорость обмена которую я получал с stlink v2 была около 100 кбайт/с.
UART это просто, быстро, удобно, и чаще всего ему не надо вообще никаких библиотек поддержки - буквально пару регистров настройки и всё. UART не заменяет отладчик, но тоже очень важен, например, на тестировании или поддержке.
Всмысле никаких библиотек поддержки?
1) Настройка тактирования перефирии
2) Настройка DMA для разгрузки MCU
3) Выбрать пины (для разных проектов, плат вам это придется делать.
4) Конфигурация этих пинов
5) Пины кроме как для отладки использовать нельзя
6) Нельзя просто взять ваш код с конфигурацией "пары" регистров и перенести его с STM32F0 на например STM32H7
RTT от переферии не зависит. Купируются файлы в проект и все. Можно использовать.
И кроме того -- это универсально. Это позволяет к этому UARTу подключиться пользователю, не имеющему ST-Linkа и получить диагностику, чтобы отправить ее в поддержку.
Это позволяет к этому UARTу подключиться пользователю, не имеющему ST-Linkа
Чем подключиться?
получить диагностику, чтобы отправить ее в поддержку.
...сорвав с устройства пломбы, развентив корпус и тыкнувшись заранее прикупленным tag-connect прямо в плату?
Аргумент по типу - пользователь не имеющий stlink бьется пользователем не имеющим uart переходник. В сегодняшнее время китайские и не только stlinkи стоят сопоставимо с uart переходниками. Но в статье цитирую:UART очень нужен для printf-отладки. Еще на UART можно запустить Shell. Shell нужна для отладки, управления, тестирования софта и железа, просмотра логов, диагностики и многого другого.
Так вот если уж для отладки нам нужен вывод ввод, то глупо не использовать УЖЕ разведенный SWD для которого 100% будет под рукой stlink, иначе о какой отладке кода идет речь. Время идет, технологии развиваются. Когда-то отлаживали LED светодиодами, потом uart. Теперь есть и RTT под капотом и никаких танцев с бубном ему не требуется.
В сегодняшнее время китайские и не только stlinkи стоят сопоставимо с uart переходниками
Чтоб два раза не вставать:
иначе о какой отладке кода идет речь
Ну например посмотреть через UART-shell содержимое файловой системы на FatFS SD карты.
А потом взять и запустить на исполнение модульные тесты.
И проанализировать разноцветный лог в UARTе.
Так вот если уж для отладки нам нужен вывод ввод, то глупо не использовать УЖЕ разведенный SWD для которого 100% будет под рукой stlink
SWD хорош для отладки самого микроконтроллера и того, что у него внутри: регистры, RAM память, Flash.
А как быть, если надо отлаживать внешние ASICи, которые подключены к MCU по SPI, I2C, MDIO и прочее.
До них SWD уже не доберется.
Интересно а как UARTом добраться до SPI, I2C? Можно поподробнее?
Всё очень просто.
В прошивке есть драйвер SPI.
У драйвера SPI есть CLI команды.
По UART в TeraTerm набирают текстовые токены этих команд. Нажимается Enter.
Запускается функция spi_write_read аргументы берет из UART результат своей работы печатает в UART.
Таким образом мы читаем через CLI регистры, например, акселерометра.
Абсолютно то же можно сделать через rtt.
Вы говорите про частный случай. В статье UART упоминается как необходимый интерфейс для отладки. Если вы пишите прошивку для МК и вам нужно как-то через терминал отлаживать взаимодействие по SPI, берете прослойку с UARTом и заменяете ее на RTT. Работать будет так же. Необходимости именно резервировать шину UART нет. Она может послужить для чего-нибудь более полезного.
Опять же, суть моего посыла в том, что для отладки прошивки МК необходимости использовать UART (а его использование влечет свои последствия) нет, так как есть RTT. Вот вам конкретный пример. Имеем МК, к нему подключаем 4 шаговика по SPI. Как через UART нам получить лог взаимодействия МК с шаговиками? добавлять метки данных конкретного шаговика метку (DR1, DR2..)? а потом к этому написать парсер?
С RTT делаем так: создаем 4 канала, открываем/подключаемся к 4 терминалам (портам) и шлем все данные независимо друг от друга (в порт 9090 обмен данными с шаговиком 1, в порт 9091 данные шаговика 2 и т.д.) ...
В прошивке есть драйвер SPI. У драйвера SPI есть CLI команды.
Вы внутри микроконтроллера гоняете между программными модулями текстовые команды?
Вы внутри микроконтроллера гоняете между программными модулями текстовые команды?
Нет. Программные модули вызывают другие программные модули просто как вызов си функции.
Тогда какой смысл вы вкладываете во фразы: "В прошивке есть драйвер SPI. У драйвера SPI есть CLI команды"?
Если у вас "Программные модули вызывают другие программные модули просто как вызов си функции", то причём здесь CLI и "драйвер SPI в прошивке"?
Драйвер SPI надо же как-то проверять.
Для этого у него есть CLI команды.
https://elixir.bootlin.com/zephyr/v4.3.0/source/drivers/spi/spi_shell.c#L34
Как в Zephyr Project.
У каждого модуля (GPIO, I2C, UART и т п) есть Shell команды. В том числе и у SPI.
Драйвер SPI надо же как-то проверять. Для этого у него есть CLI команды.
if(strcmp(name,spi_shell_devices[i].name)==0)Ах :) Посимвольное сравнение строк - это именно то, чего так не хватает в rt-embedded, когда "надо отлаживать внешние ASICи, которые подключены к MCU по SPI" :)
А какими красками, в контексте вашего примера, играет тезис другого собеседника про UART, что "это просто, быстро, удобно, и чаще всего ему не надо вообще никаких библиотек поддержки", мммм :)))
Параллельно другие люди начинают рассказывать, что им нехватает скорости у МК, тактирующегося примерно от 100 МГц для управления несколькими электромоторами - приходится отказываться от РТОС! :)
Один мой коллега облюбовал для создания испытательных стендов микроконтроллер RP2040, программируемый на Питоне.
По моему субъективному мнению это действительно настолько плохо, что уже хорошо.
А ваш strcmp с CLI - просто плохо.
Обработка CLI в прошивке это всегда работа со строчками.
Надо внутри прошивки распознавать базовые типы данных из строчек. Надо сравнивать введенную строчку со списком известных прошивке имен команд, чтобы вызвать нужную callback функцию обработчик.
Надо разбивать строчку на подсрочки (CSV).
Это нормально.
Обработка CLI в прошивке это всегда работа со строчками.
О том и речь, что это форменное сумасшествие. Но в отличие от вайбкодеров на RP2xxx, честных социопатов, CLI в прошивке STM32, совмещённое с отладкой по UART - это претензия на псевдо-сакральное знание.
СLI в прошивке STM32, совмещённое с отладкой по UART - это претензия на псевдо-сакральное знание.
Этих CLI для ARMов полно.
Сорцы с реализацией уже скоро на заборах писать будут
Вон хоть у embox реализацию shell-а можно канибаллизировать
https://github.com/embox/embox/tree/e0cd6279507e413916a0dce526da87f486bb144c/src/cmds/shell
Сакральность заключается в том, что когда используя очередной такой CLI (на драйвере, который "нужно проверять") начнёт выдавать чепуху, повиснет, выйдет за границы массива или не сможет реализовать элементарный функционал, вы пойдёте выяснять "а какого чёрта...", вам расскажут, что "это не баг, это фича и вообще, это на самом деле удобно, если разобраться, а если вы считаете иначе, то вам следует Изучать Рабочие Инструменты, а не кочевряжиться тут".
За Изучением Рабочих Инструментов придёт старость.
Теперь есть и RTT под капотом и никаких танцев с бубном ему не требуется.
Как Вы собираетесь запускать shell в rtt на экзотических микроконтроллерах? Таких как mik32, Миландр, esp32, AVR, 8051 ?
Вот uart есть всегда и везде.
Т.е. я буду делать плату для STM32 и распаивать на ней процессор другого производителя? Статья о STM32. Перестаньте задавать вопросы не касающиеся темы. Сказано было для отладки.
Бывает так, что из-за проблем с логистикой на PCB в конце концов ставят не те LEDs или не те токо ограничивающие резисторы.
Т.е. я буду делать плату для STM32 и распаивать на ней процессор другого производителя?
Именно :) Вдруг из-за проблем с логистикой вам привезут микроконтроллеры не того производителя? А сроки поджимают :)))
1) Откуда такого пользователя uart? Если UART используется как основной протокол для передачи данных между МК и например ПК, вопросов нет. Это как бы совсем другое и уже касается диагностики вне разработки ПО
2) Если ваш пользователь на самом деле тестировщик ПО, то ничто не мешает вам вместо uart переходника дать ему китайский или любой другой stlink vx.. Какая разница пользователю что и куда он подключает.
3) Если же вы разработчик, то крайне рекомедную хотя бы пощупать работу с RTT, помимо типичного вывода в терминал отладочных сообщений, вы можете настроить несколько терминалов одновременно и использовать каждый из них для собственных нужд (это очень очень сильно зависит от самого проэкта). Например 1 терминал обычная отладка с shell интерфейсом. 2 терминал для вывода бинарных данных/логов (а можно и не бинарных а например в csv формате и сохранять сразу в файл csv, третий терминал можете использовать как интерфейс прослойку для связи с каким-нибудь GUI интерфейсом (симуляции на ПК софта, который потом будет на каком-нибудь устройстве). 4 терминал для максимально детализированной отладки какого-нибудь модуля ПО или его части (когда пошаговая отладка не возможна, да бывает и такое)...
UART это просто, быстро, удобно, и чаще всего ему не надо вообще никаких библиотек поддержки
Ммм. А какие библиотеки поддержки нужны при отладке через JTAG/SWD?
UART не заменяет отладчик, но тоже очень важен, например, на тестировании или поддержке.
Например, зачем?
Например, зачем?
Затем, что тестировщик может взять любой софт для мониторинга COM-порта и забирать лог после процесса тестирования. Очень удобно для ловли плавающих багов, которые на лабе не воспроизводятся. Научить его использовать отладчик... Нет, не реально. И тем более нереально научить это делать инженера поддержки/сопровождения, который поддерживает парк устройств у заказчика.
Ммм. А какие библиотеки поддержки нужны при отладке через JTAG/SWD?
Со стороны контроллера надо завести этот JTAG/SWD, но это ладно, так как разработчик для того и нужен. Большее зло - необходимость специального софта на ББ и умение им пользоваться. Для разработчика фигня, для остальных в цепочке разработки продукта - боль и унижение.
Затем, что тестировщик может взять любой софт для мониторинга COM-порта и забирать лог после процесса тестирования. Очень удобно для ловли плавающих багов, которые на лабе не воспроизводятся. Научить его использовать отладчик... Нет, не реально. И тем более нереально научить это делать инженера поддержки/сопровождения, который поддерживает парк устройств у заказчика.
Почему на выезды к заказчику ездит тестировщик, а не инженер сопровождения?
Почему он берёт с собой "любой софт", а не предусмотренный внутренними протоколами компании-производителя?
Где в этой воображаемой ситуации RDP, при помощи которого разработчик (надеюсь, его-то реально научить использовать отладчик) начинает видеть рабочий стол ноутбука "тестировщика"?
Тестировщик сидит у себя в отделе, а не ездит. Но его все равно очень сложно научить даже использовать uart - в тестировании сейчас почти всегда те люди, которые не смогли в разработку или аналитику, но хотят в айти....
Потому что часто инженеры поддержки - сотрудники заказчика, или какой-нибудь аутсорс. Их можно заставить поставить нужный софт, но научить их пользоваться им квест 80лвла. А putty они знают почти все, так как всякие коммутаторы и атс именно через СОМ-порт настраиваются.
И дорогой разработчик вместо своих прямых задач занимается поддержкой вместо сотрудников поддержки, стоящих намного дешевле.
Холивор бесплоден по своей сути. Если у вас разработчик отлаживается через printf через уарт - штош, вопрос к нему, почему он не использует современные средства отладки. Но вот кидать в этот уарт логи - вполне себе хорошая идея, чтобы упростить поддержку.
Тестировщик сидит у себя в отделе, а не ездит.
Прекрасно. Подключает тестировщик к устройству сервисный разъём с JTAG/SWD, нажимает на ярлык скрипта. По скрипту лабораторный источник подаёт на устройство питание, запускает среду в режиме отладки и устройство начинает работать.
Тестировщик нажимает на кнопки устройства, пытаясь вызвать нештатное поведение.
Если программа доходит до предустановленного брекпойнта, срабатывает другой скрипт, сохраняющий значение всех переменных, за которыми велось наблюдение, затем скрипт отключает питание, а затем на монитор выводится сообщение:
"Ошибка обнаружена, вы - молодец, возьмите с полки пирожок".
Если программа работает, но тестировщик видит нештатную работу устройства, он запускает данный скрипт принудительно.
В каком месте здесь UART удобнее?
Потому что часто инженеры поддержки - сотрудники заказчика, или какой-нибудь аутсорс.
Вы описываете ситуацию с какой-то странной диффузией ответственности.
Кто кому продал оборудование?
Кто при продаже оборудования определяет, что будет являеться штатным поведением оборудования, а что сбоем?
У оборудования есть гарантия? Кто по этой гарантии отвечает?
Если ответы: "Производитель, производитель, производитель", то о какой поддержке сотрудниками заказчика может идти речь?
Повторюсь. Вот сорвут сотрудники заказчика пломбы, вскроют корпус, подключатся непонятно где добытым переходником USB-UART к каким-то контактам, потом при помощи неопределённого набора утилит как-то провзаимодеуствуют с оборудованием. И затем с неким набором данных придут к производителю, скажут "Оно короче чё то не заработало. Мы эцсамое... ну ,вот" и протянут ему флешку. Что с этой флешкой дальше делать?
И дорогой разработчик вместо своих прямых задач занимается поддержкой вместо сотрудников поддержки, стоящих намного дешевле.
Не совсем так. Если мы рассматриваем ситуацию "Очень удобно для ловли плавающих багов, которые на лабе не воспроизводятся", то исправление такого бага и есть прямая задача разработчика.
Абсолютно неверное утверждение. Откуда тестировщик умеет пользоваться COM портом? откуда он вообще знает что это такое и как оно выглядит? Вам не нужно никого учить. Просто передаете ему папку с утилитами и скриптом и говорите на какую иконку нажать. Если прям очень ленивый тестировщик, можете все упихать в один исполняемый exe файл, это вообще не проблема тестировщика, а разработчика ПО, которому нужны логи.
Откуда тестировщик умеет пользоваться COM портом?
Вы не понимаете, просто каждый, кто имеет хоть какое-то отношение к электронике носит на связке ключей проводок tag-connect, преобразователь USB-RS232 и загрузочную флешку с ОС, PuTTY и заготовленным скриптом, сохраняющим поток символов в файл. Разумеется, он также в совершенстве знает скриптовые языки, чтобы по месту дописать в скрипт парсер потока для сохранения только нужных сервисных данных.
Я как раз понимаю, это был риторический вопрос. Я бы разделил тестировщиков на:
"способных", т.е. у них есть опыт работы с электроникой и понимание что есть какая-нибудь периферия (uart. usb, spi, sdcard и т.п.). И даже если тестировщик чего-то не знает, сильно сомневаюсь что ему составит огромных усилий докачать некий софт с поддержкой telnet (хотя многие программы для мониторинга COM портов также имеют при себе возможность подключения и к TCP, UDP портам)...
"не способных"... ну тут уж разработчик на мой взгляд обязан для него подготовить все необходимое так, чтобы обучать не пришлось (еще лучше написать инструкцию, самому себе в будущем может пригодится).
Я как раз понимаю, это был риторический вопрос.
Это был сарказм.
Я бы разделил тестировщиков на: "способных", т.е. у них есть опыт работы с электроникой и понимание что есть какая-нибудь периферия (uart. usb, spi, sdcard и т.п.).
Я вот не пойму концепт вашего (и моего) оппонента: зачем тестировщику знать внутреннее устройство оборудование? Тестировщик должен имитировать работу типового пользователя. Нагружать тестировщика умственной деятельностью по решению вопроса "чем снять дамп, если нет отладчика" можно только если концептуально такая же задача предусматривается и для пользователя. Но мне сложно представить класс такого оборудования.
Способный тестировщик не тот, кто знает, как заставить работать оборудование,
а тот, кто может заставить его не работать.
Мое сугубо личное мнение - вообще не должен такого знать. Я лишь просто попытался опровергнуть аргументы в пользу uarta при таких условиях. А так да, чем меньше тестировщик знает об устройстве (в плане понимании как оно изнутри работает), тем больше вероятность что он найдет различные баги.
Кстати, хороший, наверное, был бы вопрос:
почему Windows при сбое не пытается скинуть сервисные данные через UART, чтобы пользователь там поймал бы их "свистком", упаковал и отправил бы разработчикам? Почему Windows сама отправляет сервисные данные через сеть в Microsoft (если пользователь разрешил)? Почему на материнских платах не предусмотрен вывод сервисных данных с процессора через UART, в случае его нештатной работы, если это так удобно и универсально?
Или оно не так уж удобно и не так уж универсально?
Я лишь просто попытался опровергнуть аргументы в пользу uarta при таких условиях.
UART хорош тем, что на нем можно shell запустить.
И что хош делай.
Вот https://habr.com/ru/companies/whoosh/articles/978192/
Как вы на SWD CLI забабахаете?
Мда, в 2025 году все еще отлаживать через UART... Пора бы уже научиться использовать RTT + OpenOCD в связке и иметь несколько каналов ввода-ввывода через telnet.
Почему бы Вам не взять и написать про это методичку?
Задумываюсь, но скорее всего это будет не на хабре.
Не увидел светодиода, показывающего наличие питания.
Статья затрагивает важную тему обмена опытом при проектировании несложных устройств на базе микроконтроллеров.
У ST на каждый микроконтроллер есть документ где указана минимальная обвязка требуемая для запуска и работы. Статья как по мне имеет пользу, но мало информации о действительно важных цепях, стоило бы указать про фильтра питания, цепи reset, разделение цифровых и аналоговых земель.
Имею опыт вывода из строя микроконтроллера частым подключением SWD "на горячую". Решается добавлением супрессоров на линии, диода на линию 3,3В порта SWD и дополнительного резистора на reset.
С tag-connect не согласен. На серийном да, есть смысл для ускорения прошивки. Но для прототипов и предсерийных версий лучше STDC-14, коннектор st-link v3. Там есть и UART в том числе, сам разъем это двухрядовый 14 пиновый штыревой с шагом 1.27, вещь распространенная
Что должно быть на каждой PCB с STM32