Comments 152
Зачем так сложно о простом? Конечно программно можно выявить некоторые косяки в платах, но далеко ни все и не всегда. Замыкание или непропай может быть в каком то таком месте что проц даже и не запустится, а может быть в каких то аналоговых сетях и МК не сможет это проверить. Пытаться софтом определить замыкания на плате бесполезное занятие.
Гораздо эффективней (и я всегда так делаю) написать тестовую прошивку которая проверяет всю переферию. Это может быть отдельная программа , а может быть модуль в основном софте запусаемый каким то хитрым образом. Он же может использоватся и при последующим ремонте.
Этот программный компонент реально работает и уже несколько раз помог найти КЗ в платах.
Гораздо эффективней (и я всегда так делаю) написать тестовую прошивку которая проверяет всю переферию.
Вот вам пример из жизни. При инициализации шины I2S микроконтроллер перезагружается. На другой плате этого не происходит. Как вы поймете какой из 5х проводов шины I2S коротит на UART TX?
а зачем определять? выглядит как брак
ремонтировать после EoL немного не корректно, нужно работать с отделом качества контрактников
кмк вещь полезная, чтобы браковать, но зачем понимать какой из проводов куда коротит?
проверил функционал - брак/не брак и достаточно
а зачем определять? Зачем понимать какой из проводов куда коротит?
Разработчику надо не только выявить факт брака, но также надо распознать причину брака.
Это нужно чтобы объяснить тётушкам на производстве, что надо отпаять и что надо заменить максимально понятно, чтобы они вас поняли и починили.
причина в некачественной пайке, этим должен заниматься тот, кто паял
как я уже сказал осуществлять ремонт после того, как он прошел контроль не корректно
разве что на единичных сборках/мелких сериях/прототипах, у меня вот лежит куча с браком, раньше процент был больше, со временем уменьшается, но стабильно пара процентов уходит: убивает что-то статикой, непропай, повышенное потребление, выходит за расчет аналоговых параметров - не важно
разбираться, а уж тем более менять что-то после автоматического монтажа - бред
долго, дорого и не качественно
причина в некачественной пайке, этим должен заниматься тот, кто паял
Ну вот включил программист-микроконтрллеров плату и плата не работает. Разработчик идет в цэх, подходит к монтажнице и говорит:
-плата которую ты собрала не работает
монтажница в ответ:
--Ок, что именно не работает и что мне надо поменять?
Разработчик прикидывается валенком и говорит:
--Да я особо не разбирался. Не знаю. Смотрю не работает и принес тебе.
Так что-ли надо работать по Вашему?
как я уже сказал осуществлять ремонт после того, как он прошел контроль не корректно
Вот нет никакого контроля. Плату спаяли тётушки бальзаковского возраста, визуально глазками посмотрели на PCB (ничего такого не заметили) и передали программисту-микроконтроллеров.
Программист-микроконтроллеров прошил плату релизной прошивкой и видит, что плата не работает.
Что делать?
отдавать на нормальный монтаж
Ошибки не только в монтаже бывают, но и в самом дизайне PCB тоже.
Вот Вам яркий пример.
Схемотехники для RS2058 взяли для Э3 распиновку от корпуса MSOP10, а на PCB поставили корпус QFN.
В результате мультиплексор не пропускает сигнал так как распиновка в MSOP10 и QFN не совпадает на 90%.
Никто на этаже не мог понять что не так.
Зато мой еще прошлый примитивный load-detect
https://habr.com/ru/articles/756572/
выявил место проблемы на первой же секунде своей работы.
ну тогда все не будет работать, их нужно до серии выявлять
я же говорю: в принципе штука полезная, но для выходного контроля достаточно выводов годная или нет конкретная плата
если нет - то в брак, если брака слишком много - на анализ, но вот тестировать и ремонтировать серийное изделие после сборки - неправильно
их нужно до серии выявлять
Для серии обязательно надо строить полноценные test jig(и). Типа таких
https://thirdpin.io/stendy_testirovaniya_elektroniki_i_pechatnyh_plat
Cross-detect хорош на стадии проверки первого, второго прототипа PCB. Когда еще нет ни одной test jig и окончательного решения о запуске массового производства.
неправильно это создавать электронный мусор, если есть возможность отремонтировать. другой вопрос что ремонтировать возможно некому.
Схемотехники для RS2058 взяли для Э3 распиновку от корпуса MSOP10, а на PCB поставили корпус QFN.
А это системная ошибка. При грамотно построенной разработке такого не должно быть в принципе. Если такое случается, то это означает, что процесс проектирования электроники построен неверно.
Никто на этаже не мог понять что не так.
Бегите из этого места как можно скорее. :)
Бегите из этого места как можно скорее. :)
Куда бежать? В РФ везде так.
Куда бежать? В РФ везде так.
Я вам уже писал, не стоит распространять свой опыт на всю индустрию целиком. Если вам по работе попадались только гнилые места, это не означает, что все места такие.
Карась плавает. Карась — рыба. Но это не означает, что все рыбы плавают. А вы продолжаете это упорно утверждать из раза в раз.
Плату спаяли тётушки бальзаковского возраста
Бальзак, "Тридцатилетняя женщина". Что за эйджизм ;)
Так то у вас получился аналог автотестов, но для железа. Если тесты прошли - это ничего не значит. Если упали - значит ошибки точно есть.
Как вы поймете какой из 5х проводов шины I2S коротит на UART TX?
Элементарно, Ватсон ;)
Тот который рядом.
Напряжометр с пищалкой в помощь ;)
Это потом выяснилось что I2S c UART коротит.
Cross-deteсt как раз показал.
Сначала вообще не ясно было что не так. Тем же DMM прозванивать - это бы целый день заняло а, то и неделю.
А сross-deteсt все нежелательные перемычки за минуту найдет
целый день заняло а, то и неделю
Нет смысла проверять КЗ любых 2 точек на плате. Имеет смысл проверять близко расположенные, и непосредственно связанные с МК. Вряд ли это займет весь день.
Хотя, конечно, автоматизированное тестирование найдет ошибку бесплатно (если ошибка действительно связана с КЗ ножек МК).
Тот который рядом.
У программистом MCU на компе нет топологии всех 4х внутренних слоев PCB, чтобы понять кто там рядом проложен, а кто нет.
Да и тест падов на PCB тоже нет, чтобы приложить электроды DMM для прозвонки.
Если закорочены внутренние слои, тут, пожалуй, какие вопросы к монтажникам?
Программисты тем более вообще имеют право ничего не знать о топологии.
Тогда плату надо тестировать еще до того как на нее компоненты будут припаяны. Нужно для каждой PCB test jig строить.
Пытаться софтом определить замыкания на плате бесполезное занятие.
Видимо Вы ещё очень мало времени занимаететь программированием микроконтроллеров.
Зачем так сложно о простом?
Где Вы тут сложность-то увидели? Конечный автомат на 9 состояний для Вас сложно?
Конечно программно можно выявить некоторые косяки в платах, но далеко ни все и не всегда. Замыкание или непропай может быть в каком то таком месте что проц даже и не запустится, а может быть в каких то аналоговых сетях и МК не сможет это проверить.
Что дешевле: строить для каждой платы тестировочный стенд с pogo pins
или залить прошивку IoBang с Cross-detect(ом)?
Test jig необходим в подавляющем большинстве случаев, если речь идет именно о промышленном производстве, а не локальном кустарном. Да даже для небольших партий чего бы то ни было все-равно нужен стенд с оснасткой для проверки.
Test jig необходим в подавляющем большинстве случаев, если речь идет именно о промышленном производстве, а не локальном кустарном. Да даже для небольших партий чего бы то ни было все-равно нужен стенд с оснасткой для проверки.
Как Вы собираетесь pogo pin(ами) от test jig подбираться пинам BGA микросхем , чтобы выявить короткое замыкание на соседних пинах?
Зависит от контекста. В случае производства закладывается процент брака, отбракованные платы откладываются и потом их проверяют вручную, и, скорее всего, при небольшом проценте брака такими платами никто не будет заниматься. Ну отправить на проверку стоит конечно для определения в чем был брак, но такую отремонтированную плату вряд ли будут пускать обратно в производственный процесс, если только это не что-то очень дорогое. В ручном тестировании, если определиться что где-то коротит — ну перепаяют подозрительные чипы. И зачем заводить какой-то софт, который сможет всего лишь частично определить проблемное место?
Давно изобретен автоматический визуальный и рентген контроль на производстве пп и монтаже. Если требования DFM выполнены, то все работает. После приемки нужен только функциональный контроль - работает или нет через тестовую прошивку или часть загрузчика. Брак в помойку или возврат на производство, когда накопится. А при отладке пары плат это делается ручками и глазами + рентген для бга.
По вашим описаниям прцесса - чую я гнилую НИИ шную организацию работы, когда люди не знакомы с мировыми практиками и стандартами и вынуждены изобретать костыли. Сам 20 лет там отработал и все это проходил.
от test jig подбираться пинам BGA микросхем, чтобы выявить короткое замыкание на соседних пинах?
Для этого есть JTAG.
собрать тестинг джиг стоит где-то 150$. Без него один хрен в серию ничего не запустить. На производстве же завернут и пошлют лесом
Зачем так сложно о простом?
Вот Вам механизм попроще Load-Detect для Проверки Качества Пайки
https://habr.com/ru/articles/756572/
но он не умеет определять короткие замыкания между дорожками PCB. Зато просто.
а почему не JTAG + boundary scan?
Есть где методичка как пользоваться этим JTAG + boundary scan ? Какое нужно оборудование, какой софтвер?
Ну поставит программатор в boundary scan на пине P0.04 3.3V, а дальше-то что?
boundary scan применим только тогда когда у тебя на плате 2+ микросхем с JTAG интерфейсом.
А в микроконтроллерных проектах только одна JTAG микросхема (микроконтроллер).
Можно что угодно ставить на GPIO через JTAG, а толу-то?
И вообще на большинстве электронных плат с MCU на разъёмы выводят не JTAG, а двухпроводной интерфейс SWD.
https://fiona.dmcs.pl/~rkielbik/nid/IEEE_1149_JTAG_and_Boundary_Scan_Tutorial.pdf
SWD это только провода, boundary-scan по ним тоже доступен: https://www.xjtag.com/company/newsroom/single/press-releases/xjtag-introduces-arm-swd-support-and-user-defined-libraries/
https://github.com/viveris/jtag-boundary-scanner --вот здесь уже софт какой-то есть...
Лучше бы господа Кауркин Максим Николаевич , Стариковский Алексей Юрьевич , Гурин Константин Львович написали бы пост на habr про свой уникальный опыт управления процессором по JTAG чем заполнять эти мнимые конторские свидетельства.
Тогда бы их труд хоть кто-то реально прочитал и прокомментировал.
Наверное еще текст своих исходников на миллиметровой бумаге печатали чтобы их рассмотрели.
Стариковский Алексей Юрьевич перед вами, спрашивайте, что вас интересует...
--Какое устройство выступало в роли переходника с USB-JTAG? Подойдет ST-Link V2 ISOL?
--Какой был программный API для управления отладчиком на стороне PC приложения?
--Как обрабатывались аппаратные прерывания по переполнению таймера на target?
FTDI FT232, собственная библиотека для MPSSE. ST-LINK -- не подойдет, он на stm32f1/stm32f7
еще был lua интерфейс для скриптов для DFT, но это уже в это свидетельсво не попало
Я открыл спеку на FT232 , но там нет даже слов таких как JTAG.
https://ftdichip.com/products/ft232hq/ не все ft232 одинаково полезны
https://aliexpress.ru/item/1005004864054361.html -- вот платка готовая
Вот еще один добротный текст,
https://habr.com/ru/articles/768460/
где сказано как можно на PC крутить код для микроконтроллера.
Почему нельзя было воспользоваться для этого не JTAG, а UART?
Можно же написать прошивку для процессора с UART-CLI, где будет всего 2 команды: чтение физического адреса и запись физического адреса.
Залить прошивку в ROM процессора.
Далее соединить PC и PCB переходником USB-UART и с тем же успехом утилитой на PC читать и писать регистры. Интерпретировать их по datasheet и отрисовывать красивую GUI.
Переходники USB-UART они же дешевле чем переходники USB-JTAG.
потому, что это "взрослый" чип, у него память -- это DDR3 снаружи, а через JTAG мы могли получить доступ ко всему, даже при полностью мертвом процессоре. FT232 стоит не сильно дороже FT230, а если вместе с платой, то разницы уже не видно. JTAG можно до 30+МГц разогнать, UART так не умеет.
Получается что если делать то же только для MCU, то можно на PC написать внешнюю прошивку размером с гигабайт в бинаре, которая никогда бы не поместилась бы во on-chip Flash память.
Вот только не ясно откуда микроконтроллер будет исполнять код прерываний (внешнее прерывание по нажатию кнопки) если прошивка внешняя и крутится на PC.
Из on-chip RAM памяти что-ли?
Тогда PC еще должен будет исполнять роль и компоновщика и интерпретатора одновременно.
вы зачем-то мешаете в одну кучу отладку переферии и проверку внешних соединений с отладкой программы на ядре контроллера. Первое можно делать внешней программой через прямой доступ к регистрам устройств и к ножкам по boundary-scan. отладку программы в ядре (прерывания) уже можно отлаживать с участием собственно ядра... И откуда берутся "гигабайты в бинаре", сколько функциональности хотите, столько и будет размера...
что это "взрослый" чип
Даже в CPU процессорах Cortex-A есть несколько десятков килобайт для on-chip BOOT ROM(а). Например 1892ВМ14Я
и? в Байкал-Т тоже был BOOT ROM MONITOR, доступный через консоль. Только вот что делать, если консоль не отвечает?
Значат что-то с проводами, либо прошивка на target зависла.
Мне в микроконтроллерах JTAG нужен только для пошаговой отладки, в случае если CLI не отвечает на команды из TeraTerm.
Беру очередной MCU, настраиваю на нем UART-Shell, а далее отладка идет только по UART-CLI
У меня есть отдельный текст про то, почему нужна консоль в UART
https://habr.com/ru/articles/694408/
настраиваю на нем UART-Shell
т.е. вам нужно в слепую подать питание на HSE, PLL, GPIO, UART, выставить частоту PLL, wait-states для FLASH, ну и бауд-рэйт UART... ошибка в одной операции -- и у вас пересборка-перезаливка. Альтернатива -- все это понастраивать снаружи и заливать уже только рабочий вариант...
Это надо преподавать в институтах.
все это понастраивать снаружи и заливать уже только рабочий вариант.
Вот только как отладить на PC программные компоненты MCU, которые вызывают внешние прерывания?
В микроконтроллерах у каждого блока (GPIO RCC Timer SysTick Flash UART DMA) есть целая куча всяческих прерываний на каждый чих.
И исполняться ISR прерывания должны либо из on-chip RAM либо из on-chip Flash.
Если говорить метафорами, то получается микроконтроллер-марионетка.
Вместо куклы микроконтроллер, вместо ниточек 4 провода JTAG. А кукловод это Host PC.
То есть у вас на PC работает одновременно GdbServer и ваша GUI утилита.
GdbServer общается по JTAG c Target, а ваша утилита по TCP сокету общается с GdbServer .
GUI утилита управляет GPIO через GdbServer сервер. Так?
Я так понял то, что Вы делаете объяснено в этом тексте
https://habr.com/ru/articles/433504/
JTAG/SWD дают прямой доступ к памяти МК, и, как следствие, ко всем его регистрам. Не очень быстрый, но доступ. Не только к GPIO, а вообще ко всей периферии. Хоть GPIO ставьте, хоть АЦП считывайте, хоть через I2C с остальной платой разговаривайте. Сам boundary scan (в своем изначальном смысле) - это исключительно JTAG, но тут он и не нужен.
Всё то же самое можно реализовать на хостовой стороне, получив в добавок кучу бонусов - например, (теоретическую) возможность использовать одну и ту же софтину для кучи плат, задавая конкретную конфигурацию хоть мышкой. Да и сама софтина может быть хоть десять гигабайт, уметь тестировать не только сам МК, но еще, например, периферийные микросхемы.
JTAG/SWD дают прямой доступ к памяти МК, и, как следствие, ко всем его регистрам. Не очень быстрый, но доступ. Не только к GPIO, а вообще ко всей периферии. Хоть GPIO ставьте, хоть АЦП считывайте, хоть через I2C с остальной платой разговаривайте.
Это что мне надо на PC писать отдельный симулятор прошивки под Win и весь MCAL, чтобы через JTAG GPIO считывать/прописывать?
Да это же жесть полнейшая. Cross-Detect в 100 крат проще получается.
Ну, приведенное вам по ссылке коммерческое ПО именно так и работает.
Учитывая, что в приведенном вами фрагменте "прошивки" 10% логики и 90% простыни из копипаста - уверен, на каком-нибудь python это получилось бы куда проще как минимум из-за замены C высокоуровневым языком, а так же доступности полноценной ОС. Для того, чтобы через SWD дергать ножками GPIO, усилий вообще не требуется (помимо поиска библиотеки для используемого отладчика).
уверен, на каком-нибудь python это получилось бы куда проще как минимум из-за замены C высокоуровневым языком, а так же доступности полноценной ОС. Для того, чтобы через SWD дергать ножками GPIO, усилий вообще не требуется (помимо поиска библиотеки для используемого отладчика).
В Роcсии никто так не делает!
Писать на Python симулятор прошивки который работает на Windows. При этом поддерживать Real-Time SWD link с target(ом) чтобы на реальной железке отражались изменения на PCB.
Вы попробуйте убедить Python разработчика чтобы он перешел из Back-end разработки на Python за 300kRUR заниматься таким мартышкиным трудом в embedded за 50 kRUR.
Это просто смешно!
Смешно то, что Вы считаете, что никто так не делает. Вам все правильно разъясняют, и python был приведен как пример, можете брать тот же C/C++.
Подразумеваю, что эти трое господ еще свои исходники на миллиметровой бумаге распечатали, чтобы получить это бессмысленное свидетельство.
Лучше бы они пост на habr написали про свой опыт управления процессором по JTAG.
Тогда бы их труд хотя бы один раз прочитали, оценили и прокомментировали.
В 2013 в военном НИИ меня тоже вовлекли в процесс получения государственной регистрации моей программы для ЭВМ. Я тогда обрадовался. Но зря.
Замучился распечатывать листы с исходниками. При этом приписался целый поезд из чинуш-соавторов у которых на столе даже компьютера никогда не стояло.
В результате никто текст так и не прочитал и обратной связи не было как и вознаграждения тоже.
В итоге я понял одну вещь.
Лучшее что можно сделать со своей хорошей программой - это написать по нее пост на habr.
не совсем понятно зачем симулятор прошивки. Можно читать по jtag регистр состояния ножек и писать в регистр выхода ножек. А дальше запускаем тот же алгоритм сканирования перебором, но уже на компе.
Нужно еще регистр установки подтяжек читать писать.
А вот выход ножек трогать нельзя. Это же push-pull.
В случае КЗ на GND push-pull (ом) можно нечаянно сжечь плату.
Можно читать по jtag регистр состояния ножек и писать в регистр выхода ножек.
Осталось только понять какой там API, чтобы из консольного windows приложения на Си читать регистры MCU по JTAG.
И нужеy ли параллельно работающий GDBServer (ST-LINK_gdbserver.exe) для этого?
JTAG/SWD дают прямой доступ к памяти МК, и, как следствие, ко всем его регистрам. Не очень быстрый, но доступ. Не только к GPIO, а вообще ко всей периферии. Хоть GPIO ставьте, хоть АЦП считывайте, хоть через I2C с остальной платой разговаривайте.
Всё то же самое можно реализовать на хостовой стороне, получив в добавок кучу бонусов - например, (теоретическую) возможность использовать одну и ту же софтину для кучи плат, задавая конкретную конфигурацию хоть мышкой. Да и сама софтина может быть хоть десять гигабайт, уметь тестировать не только сам МК, но еще, например, периферийные микросхемы.
А как тогда обрабатывать внешние прерывания (например по SysTick таймеру или GPIO, I2C, UART, DMA, SPI)? Тоже на Host(e)?
Вам нужно работоспособность SysTick таймера протестировать (вдруг чип бракованный подсунули?) или корректность сборки платы?
Если вдруг вам часто подсовывают чипы, где сломан SysTick таймер - можете залить тестовый код в RAM и оттуда выполнить. Но это мягко говоря нецелевое применение обсуждаемой технологии.
а почему не JTAG + boundary scan?
Обыкновенный инженер может проверить что-то только одним единственным способом, хороший - тремя способам.
Вы привели один способ и всячески отбиваетесь от других способов... Вы к какой категории себя после этого относите?
Я наблюдал за автором статьи и не рекомендую вам с ним спорить - затея абсолютно бесполезная. Он пропагандирует отладку через uart cli и других способов не приемлет от слова совсем. А кто этого не понимает - тот чернь неученая. Так же уже писали, что блок-схемы автора перегружены и в них без стакана не разберёшься, но это тоже все потому, что никто не понимает истины
Причём я не хочу очернять подходы автора данной статьи, но у него совершенно отсутствует критика к себе, что сильно снижает рейтинги /то есть одобрение читающих/
Я заметил одну тенденцию.
Те люди, которые трындят, что UART-консоль якобы не нужна банально не понимают про что идет речь. Эти CLI никогда в своей жизни не видели (GUI поколение) и они просто не в теме.
К таким людям просьба относиться с пониманием.
Хотите сказать, Eclipse-GUI отладчик менее эффективен, чем консольный? А код вы тоже в консоли пишете?
Eclipse-GUI отладчик , конечно, удобнее чем GDB CLI отладчик. И код писать в vim тоже крайне неприятно.
Но пошаговая отладка нужна очень редко. Главным образом только для отладки UART для CLI. Далее отладки через UART-CLI в 95% случаев хватает.
Эту тему лучше разобрать в этом тексте
https://habr.com/ru/articles/694408/
тут же мы говорим про то как делать контроль пайки.
Пошаговая нужна редко, но посмотреть значение регистров и памяти - уже почаще.
Ну и самое главное: каковы плюсы распыляться по нескольким тулзам, в сравнении с комбайнами всё-в-одном? (AtmelStudio+AtmelICE, STM32CubeIDE+STLink etc).
но посмотреть значение регистров и памяти - уже почаще.
Вот я через UART-CLI преспокойно просматриваю содержимое регистров GPIO. Никакого отладчика при этом не нужно.
А я вот через GUI спокойно просматриваю регистры GPIO, UART, I2C и вообще любой периферии, вижу разбивку регистров по битовым полям с осмысленными именами. И адреса запоминать не нужно. А еще вижу список RTOS задач, могу переключаться по ним, смотреть их состояния, текущий стек и точку, в которой они сейчас находятся. Могу посмотреть историю исполнения программы (запись примерно последней секунды её жизни), включая время исполнения каждой функции (с точностью до такта) и их вложенность. Могу увидеть, из какого места МК свалился в хардфолт и что этому предшествовало. Могу ткнуть отладчик носом в переменную и он мне построит её график в реальном времени. Могу без графиков, просто смотреть значения избранных переменных в реальном времени с автообновлением. Могу подключить отладчик к эзернету и унести на этаж ниже, где стоит устройство. О всяком пошаговом исполнениии, брейкпоинтах и вотчпоинтах молчу.
И это всё занимает в прошивке 0 байт и требует 0 секунд, чтобы оно появилось в новом проекте. Именно потому я на вашу UART-CLI смотрю с ощущением того, что людям реально делать нечего, кроме как рисовать таблички в прошивке МК и раскрашивать вывод последовательного порта. Я обычно то же самое время трачу на написание осмысленного кода, решающего непосредственную задачу.
И, к слову, это абсолютно никак не мешает собирать проект из CMake, обмазывать его тестами и настраивать CI/CD. Потому что отладчик - полностью отдельная штука, которая подключается к абсолютно любой IDE, хоть к блокноту.
Потому что отладчик - полностью отдельная штука, которая подключается к абсолютно любой IDE, хоть к блокноту.
Я был бы Вам очень признателен, если бы Вы показали методичку как это к NotePad++.exe отладчик Си-прошивки подключить.
По моим наблюдениям в России из-за больших расстояний и слабой коммуникации исторически сформировалось две различные школы программирования-микроконтроллеров.
Можно условно их назвать Питерская школа и Московская школа. Что, к слову, вполне соответствует географии.
Подходы к разработке разные.
Питерская школа это сборка из Make/CMake, отладка через UART-CLI, модульные тесты внутри прошивки, текстовые протоколы, DevOps в Jenkins, командная работа(парное программирование).
Московская школа это сборка из-под IDE, отладка через JTAG, внешние тесты на PC, бинарные протоколы, solo-разработка.
Вы @makkarpov явный представитель московской школы.
Я прошел через обе эти школы и могу сказать, что проблемы возникают, когда в одном коллективе оказываются представители двух разных школ, и тут надо искать компромисс.
Спасибо за заботу, но у меня работает колесико на мышке, и я успешно доскроллил до этого комментария самостоятельно. И специально для этого я указал, что сборка идет через CMake, и что IDE может быть любая. У меня, например, используется CLion, который просто C++ IDE общего назначения. Отвечает за подсветку синтаксиса, автодополнение и линтинг. Даже не подозревает, что результат будет исполняться на МК.
Потому я ожидал все же более предметных комментариев.
Именно потому я на вашу UART-CLI смотрю с ощущением того, что людям реально делать нечего, кроме как рисовать таблички в прошивке МК и раскрашивать вывод последовательного порта
CLI поднимается один раз и переходит из проекта в проект без особых накладных расходов. Вам исходники CLI могу прислать в подарок. Уже отправил один архив в Новосибирск и один во Владивосток.
Тем более, если начинает не хватать памяти, то из релиза CLI всегда можно выпилить одной строчкой в make/CMake.
Разные инструменты отладки не исключают, а дополняют друг-друга.
Это, конечно, плохо, что у вас на работе урезали локального админа и не хотят оплачивать лицензии (а в нынешних реалиях скорее всего и не могут), но обсуждение вроде идет о разработке embedded софта, а не о работе на должности XXX в фирме YYY.
Я принадлежу к той школе, которая говорит, что если инструмент экономит твоё время - его надо использовать, поскольку время - это самый ценный ресурс. А нормальный отладчик экономит просто вагон времени, и никакой UART-CLI по эффективности поиска багов с ним даже рядом не стоял. Настолько рядом не стоял, что я и говорю о его ненужности для меня - у него просто нет решаемых задач. Единичные высокоуровневые отладочные команды (например, выбрать устройство на шине, послать ему запрос, дождаться ответа, проверить CRC) - это просто команды основного протокола коммуникации с хостом. И в одном проекте они одни, в другом другие, в третьем отсутствуют - ибо это разные устройства и предметная область там разная. А часть вещей типа записи истории исполнения вообще дополнительных физических проводов требует, и никаким софтом на МК вы её не сделаете. Самая полезная фича, кстати - позволяет видеть, как накладывались друг на друга прерывания/задачи/etc.
Тем более, если начинает не хватать памяти, то из релиза CLI всегда можно выпилить одной строчкой в make/CMake.
Если начинает не хватать памяти - то значит, что отладка на этом месте прекращается, поскольку вы больше не можете залить прошивку на устройство. Толку-то от того, что в релизе этого не будет - для того, чтобы состоялся релиз, сначала нужно доделать проект до конца.
Иными словами - средства отладки действительно не исключают друг друга, и отлаживать схему можно светодиодами - но согласитесь, что логическим анализатором это делать намного приятнее.
Именно потому я на вашу UART-CLI смотрю с ощущением того, что людям реально делать нечего, кроме как рисовать таблички в прошивке МК и раскрашивать вывод последовательного порта.
Разработчики московской школы программирования MCU привыкли прекрасно обходиться без CLI. Это нормально.
Однако если Вы добавите сокращенный Shell в релизную сборку для какого-н прибора то, пользователи будут Вам очень благодарны за такой extra функционал.
Они смогут проделывать свои специфические операции с вашим прибором. Подключать его к большому компьютеру и писать для устройства скрипты.
Примером устройств, где CLI оставлен в релизе являются векторный антенный анализатор NanoVNA V2, трансивер Flipper Zero, отладочная плата U-Blox ODIN, Bluetooth модуль BC127, домофоны и прочее.
Поэтому можно сказать, что CLI нужна не сколько разработчику сколько продвинутому пользователю продукта.
Однако если Вы добавите сокращенный Shell в релизную сборку для какого-н прибора то, пользователи будут Вам очень благодарны за такой extra функционал.
Подскажите, пожалуйста, для какой целевой аудитории вы делаете приборы. Мои пользователи будут благодарны, если прибор будет работать по назначению. Ближайший USB UART адаптер от них находится на расстоянии компьютерного магазина, причем скорее всего не ближайшего магазина.
Примером устройств, где CLI оставлен в релизе являются векторный антенный анализатор NanoVNA V2, трансивер Flipper Zero, отладочная плата U-Blox ODIN, Bluetooth модуль BC127, домофоны и прочее.
Все, кроме домофонов - весьма специфичные продукты.
Разработчики московской школы программирования MCU привыкли прекрасно обходиться без CLI. Это нормально.
Прекрасно обходиться без CLI на микроконтроллерах. Еще немного удивляет, как вы разбили людей на две бинарные категории и упорно пытаетесь эти категории натянуть.
Ближайший USB UART адаптер от них находится на расстоянии компьютерного магазина, причем скорее всего не ближайшего магазина.
Переходник USB-UART можно и на PCB заложить. Микросхема CP2104 4x4 мм и на улицу USB-C смотрит.
Вот и получается, что ближайший USB UART адаптер у них на расстоянии вытянутой руки лежит.
Так и сделано в NanoVNA V2 , Flipper Zero ,U-Blox ODIN .
У Flipper Zero используется нативный USB микроконтроллера, никаких переходников там нет. И это как раз логично, раз USB разъем в устройстве есть - берешь два провода и соединяешь его с МК, ноль затрат. Однако факт остается фактом - Flipper Zero - это устройство от гиков и для гиков.
Устройство, к которому приложил руку я - это прибор, стоящий на заводе. У прибора есть основной SoC (nVidia Orin), который присоединяется к внешнему миру эзернетом. От основного SoC внутри корпуса идут кабели к частям с МК (которые крутят моторами и делают некоторые другие вещи). Юзер даже не знает о том, что там есть какой-то UART вообще. Он заходит браузером на основной модуль и тыкает там кнопочки. Кроме того, юзер - это рабочий на заводе, он вообще не знает, что такое UART. Он занимается своими прямыми обязанностями, а не изучает внутренности прошивки через CLI.
А у меня, кстати, еще один вопрос представителям питерской школы. Вот есть у меня в прошивке алгоритм. Рядом лежит версия этого алгоритма на высокоуровневом языке, служащая образцом. Мне надо протестировать то, что я корректно реализовал оптимизированную версию алгоритма на C и она совпадает с образцовой.
В случае с тестированием на хосте это тривиально - берем, генерим пару мегабайт тестовых данных и эталонных ответов, компилим, запускаем, проверяем. Как сие тестировать из прошивки и UART-CLI?
Слишком абстрактные условия. Не до конца понял постановку задачи.
Если на target(е) не хватает памяти, то пристегиваем SD-карту по SPI, поднимаем FatFs и далее все как на PC.
UART-CLI тут будет как CMD консоль в Win(дe).
Хорошо, конкретизирую. У меня есть оптимизированная версия curve25519, вещи чисто математической. Рядом есть богомерзкий питон, в котором есть референсная версия из стандарта. Кроме того, сам curve25519 легко влезает в два килобайта, это разных тестовых данных у меня два мегабайта. В готовом устройстве никаких SD-карт и SPI не будет, там будет контроллер с 128 кб флеша. FatFs ему для своих прямых обязанностей тоже не нужен, в силу отсутствия разъема для SD карт.
Богомерзкий питон генерирует файлы в стиле скриншота, где просто перечисляется куча случаев и корректные ответы для них
Надо соединить Target и Host PC по UART-CLI.
Написать на PC консольную утилиту, которая будет просить микроконтроллер вычислить формулу для значения Х.
Прошивка будет возвращать Fa(X). PC будет на своей стороне рассчитывать Fb(x).
Если Fa(X)=Fb(X) для всех X, то утилита на PC скажет, что тест пройден.
Спасибо за ответ! Примерно так и сделано, только вместо прошивки бинарник с одним тестом, слинкованный для загрузки в RAM, а вместо UART CLI - SWD интерфейс, через который бинарник сначала копируется в память, потом туда же копируются тестовые данные, потом PC ставится на адрес функции и контроллер запускается. И волки, как говорится, сыты, и прошивка девственна.
каковы плюсы распыляться по нескольким тулзам, в сравнении с комбайнами всё-в-одном? (AtmelStudio+AtmelICE, STM32CubeIDE+STLink etc).
На самом деле использование всяческих IDE - это признак Junior разработчиков.
В сущности достаточной лишь удобного текстового редактора, а управлять сборкой надо из скриптов (Make, Cmake, Ninja)
Пояснение тут
https://habr.com/ru/articles/723054/
На самом деле использование всяческих IDE - это признак Junior разработчиков.
Крайне спорное утверждение, как раз отдающее junior'скими холиварами "что лучше". Использовать IDE или использовать скрипты - вопрос лишь итоговой эффективности. Современные IDE включают в себя практически весь инструментарий для эффективной сборки без использования левых скриптов, а для совсем уж особых запросов позволяют писать дополнительные сборочные скрипты прямо в себе для разных этапов компиляции/сборки. Скрипты могут быть эффективны только в случае выбора неэффективной/неоптимальной для выбранной архитектуры и задачи IDE, в противном случае при равном фукнционале они всегда будут существенно проигрывать.
Скрипты могут быть эффективны только в случае выбора неэффективной/неоптимальной для выбранной архитектуры и задачи IDE
Кто-нибудь понял, что имеет в виду @mlnw?
блок-схемы автора перегружены и в них без стакана не разберёшься
тем не менее 94 закладки!
https://habr.com/ru/articles/667030/
Вовсе нет. Просто в России из-за больших расстояний и слабой коммуникации исторически сформировалось две различные школы программирования-микроконтроллеров.
Можно условно их назвать Питерская школа и Московская школа. Что, к слову, вполне соответствует географии.
Питерская школа это сборка из Make/CMake, отладка через UART-CLI, модульные тесты внутри прошивки, текстовые протоколы, DevOps в Jenkins, командная работа(парное программирование).
Московская школа это сборка из-под IDE, отладка через JTAG, внешние тесты на PC, бинарные протоколы, solo-разработка.
Я прошел через обе эти школы и могу сказать, что проблемы возникают, когда в одном коллективе оказываются представители двух разных школ, и тут надо искать компромисс.
Еще Вы забыли добавить, что я также выступаю за сборку кода из скриптов вместо сборки из под GUI-IDE.
Почему Важно Собирать Код из Скриптов
https://habr.com/ru/articles/723054/
Хех, результаты голосований по ссылке говорят сами за себя.
Да там перевес 6% всего.
А если добавить еще тех кто из CMake (47.56% ), то выяснится, что фанаты GUI-IDE это вообще маргинальное меньшинство.
Вот на это голосование смотреть надо:
Это которое с одним-то голосом, и то вашим?)))
Я собираю прошивки с помощью CMake из разных IDE, т.к. все они под капотом запускают gcc/CMake, вот так) Т.ч. ваше голосование довольно бестолково сформулировано. А вот в последнем вопросе, пользуетесь ли вы самописными скриптами при сборке, всё однозначно сформулировано, и там видно, что 90% народа этим не заморачивается.
Еще Вы забыли упомянуть, что я рекомендую собирать прототипы на подложках из оргстекла, вместо колобоко-образного художества из перемычек
Изготовление Макета для Прототипа https://habr.com/ru/articles/709932/
Я не против тестирования на пропай чисто через JTAG на MCU без прошивки. Однако чтобы это производить надо MCAL написать, который на pc будет эмитировать GPIO. А разработка такого MCAL может занять 2+ мес. Ибо регистров много и там много настроек.
Одновременно с этим MCAL для исполнения на MCU уже есть от вендора и дается бесплатно (STM NRF CC26 ESP32 MDR32 и проч).
Вот и получается, что в моменте дешевле и быстрее написать код, который будет делать тест на прокай работая прямо на target(е).
Чтобы делать то, что Вы пишите надо нанимать отдельного программиста, который только и будет заниматься тем, что будет писать MCAL для каждого микроконтроллера по бинарной детализации регистров чтобы отрабатывать на pc виртуальный драйвер gpio, spi, i2c , uart и прочее.
Я бы и сам с удовольствием этим занимался, если бы не надо было релизы прошивок выпускать каждые 3 недели.
Ваша основная проблема состоит в том, что вы делаете какую-то вещь под себя, после чего приходите на хабр и начинаете убеждать народ, что это правильный и универсальный подход, и весь мир завтра так должен делать. И на критику реагируете фразой "Это что мне надо ...". Нет, вам ничего не надо. Разговор вообще не идет о том, как оптимизировать ваши процессы. Разговор идет о том, как оптимальнее решить задачу целиком, причем для случайного мимокрокодила.
У меня, например, нет готового UART CLI (и никогда не появится, потому что он мне нафиг не нужен, это пустой расход как человеческих ресурсов, так и машинных). Думаю, что у большинства читателей тоже.
Специально для вас прикладываю скриптик в 40 строк, который читает и пишет любые регистры на реальном МК. Даже светодиодик загорается, лично проверил. Никаких проблем добавить туда хоть CLI, хоть HTML вообще нет - и для этого не надо писать никаких драйверов UART-а, достаточно простого println.
Душат змею без регистрации и SMS
import time
import swd
class GpioTest:
RCC_AHB2ENR1 = 0x46020C8C
RCC_AHB2ENR1_GPIOBEN = 1 << 1
GPIOB = 0x42020400
GPIO_MODER = 0x00
GPIO_ODR = 0x14
MODE_OUTPUT = 0x1
def __init__(self):
self.swd = swd.Swd()
self.cortex = swd.CortexM(self.swd)
def _modify_reg(self, addr: int, b_reset: int, b_set: int):
self.swd.set_mem32(addr, (self.swd.get_mem32(addr) & ~b_reset) | b_set)
def _set_mode(self, gpio: int, bit: int, mode: int):
self._modify_reg(gpio + GpioTest.GPIO_MODER, 3 << (2 * bit), mode << (2 * bit))
def _set_pin(self, gpio: int, bit: int, value: bool):
self._modify_reg(gpio + GpioTest.GPIO_ODR, 1 << bit, int(value) << bit)
def run(self):
self.cortex.reset_halt()
while not self.cortex.is_halted():
time.sleep(0.1)
self._modify_reg(GpioTest.RCC_AHB2ENR1, 0, GpioTest.RCC_AHB2ENR1_GPIOBEN)
self._set_mode(GpioTest.GPIOB, 7, GpioTest.MODE_OUTPUT)
self._set_pin(GpioTest.GPIOB, 7, True)
if __name__ == '__main__':
GpioTest().run()
У меня, например, нет готового UART CLI
Если кому-то еще нужен код UART-CLI пишете в личку свои email/TG и я пришлю свою версию UART-CLI сорцов. Уже пару человек обращались. Выслал без проблем.
del
Зачем вы пишите этот тестировочный код на Python?
Не лучше ли бы написать его на С или С++? Тогда бы код был переносимым.
Вы могли бы запускать тест GPIO так на target(е) так и на PC через переходник USB/JTAG, просто заменив CMSIS на драйвер переходника USB/JTAG одной строчкой в makefile.
Выглядит так, как будто исчерпывающий ответ на это был дан в моих прошлых комментариях. Код написан на Python из-за того, что на таргете его запускать априори не планируется по самой постановке задачи.
Код написан на Python из-за того, что на таргете его запускать априори не планируется по самой постановке задачи.
Писать код для JTAG адаптера на Python это мартышкин труд!
Такие вещи надо на C или C++ делать, чтобы и разработчики прошивки и тестировщики могли использовать одну общую протестированную пере используемую кодовую базу.
Тем более стандарт автомобильного ПО ISO26262 запрещает использовать в разработке языки без строгой типизации типов данных (таких как Python) для всех ASIL.
а почему не JTAG + boundary scan?
Разные методы тестирования и отладки не исключают друг друга, а дополняют.
Хорошая статья. Интересный подход, который имеет право на жизнь. Видно, что автор участвует и имеет опыт в разработке и производстве серийного оборудования, с подходом экономичного производство( не путать с бережливым (5s)), а не как 90% разработчиков, только прототипов, которые идут в ящик или производятся штучно.
В качестве учебной задачи очень неплохо. Для производства конечно не подходит. Огорчает, что автор не разобрался с Boundary-scan. Существуют серийные образцы jtag- сканеров, в ПО которых загружается схемотехника платы, что дает возможность учитывать поведение других компонентов платы.
Огорчает, что автор не разобрался с Boundary-scan. Существуют серийные образцы jtag- сканеров, в ПО которых загружается схемотехника платы, что дает возможность учитывать поведение других компонентов платы.
Огорчает то, что Вы @MagNitronik
не написали по это текст на habr, раз у Вас есть экспертиза в этой теме.
Это мало кому интересно. У тех, кто купил проф. Оборудование есть на него мануал.
Вас обижает, что вас не поняли?
Не всё упирается в статьи на Хабре: одним это нафиг не интересно писать, у других нет времени.
ИМХО, проблемы серийных плат это проблемы производства и отк. В штучных прототипах эти вопросы легко решаются вместе со схемотехниками.
Статья же переносит проблемы с больной головы на здоровую.
Не всё упирается в статьи на Хабре: одним это нафиг не интересно писать, у других нет времени.
Написание постов на habr это своего рода вариант для сохранения ценной документации по проекту для тех компаний у которых нет денег на Atlassian Confluence(а).
Мне часто приходилось самому читать свои же старые тексты на habr так как там была инструкция того что приходится делать снова и снова в разное время.
https://habr.com/ru/articles/709932/
https://habr.com/ru/articles/695978/
https://habr.com/ru/articles/694708/
https://habr.com/ru/articles/683762/
https://habr.com/ru/articles/735422/
https://habr.com/ru/articles/726352/
https://habr.com/ru/articles/682498/
https://habr.com/ru/articles/673522/
Плюс хорошие комменты позволяют улучшить инструкцию до более понятного вида.
I2C не работает нормально на внутренних подтяжках. А если поставить внешние резисторы 4.7к, как положено, то не сработает этот тест.
С 5В МК, работающим с 3.3В периферией в режиме открытого коллектора, такая эквилибристика с подтяжками просто пожжет периферию.
Нет, не пожжет. У всех м/с есть диоды на VCC на каждом входе как раз на этот случай. Т.е. пока вы не перегреете этот диод током через подтяжку, оно будет жить. Здесь может быть другая засада -- можно фантомно поднять 3.3в до этих самых 5в через эти забавы. Если схема в глубоком сне и потребления по 3.3в нет, можно пожечь по питанию.
Cross-Detect для Проверки Качества Пайки в Электронных Цепях