Комментарии 32
У вас всё так основательно - GCC, Makefile, а тут раз и какая-то проприетарная виндовая тулза для прошивки. Почему не OpenOCD или st-util/st-flash ?
Я пока выбрал rdimon.
А почему ? Я догадываюсь, что Вы хотите чтобы вывод printf() уходил в дебагер, но на сколько это удобно ? На мой взгляд слать вывод в UART0 - более основательное решение, позволяющее вести отладку дедовским методом без лишних устройств. :)
Почему не st-util/st-flash ?
Почему проприетарныя? Это же утилиты из состава всеми признанного Segger J-link: Ozone, jflash, jflashLight.
Всё, что связано с STM тут вообще работать не будет. Это же абсолютно другой MCU YTM32.
Для OpenOCD у нас просто нет cfg файла под YTM32B1ME05G0MLQ. А так можно было бы отлаживаться и OpenOCD, как в случае с Artery (AT32F4x).
Если не ошибаюсь Segger J-link это проприетарная фиговина, все тулы у них проприетарные и поддержки опенсорса у них нет. У меня лежит где-то в шкафчике этот Segger, но я ни разу им не пользовался именно потому, что он закрыт. Есть более человечные решения на базе FTDI.
Это же абсолютно другой MCU YTM32
Но протокол то Вы используете - SWD от STmicro ? Значит st-flash должен работать. Ну чисто гипотетически. :)
Конфиг для OpenOCD можно составить самому если знать на каких пинах какие сигналы JTAG разведены.
Segger J-link это проприетарная фиговина
Эм, ну и что? Эта "фиговина" работает быстро и надежно.
Эта "фиговина" работает быстро и надежно.
sEGGER это, пожалуй, одна из немногих печально известных компаний у которых каждая новая версия клиентского софта J-link хуже предыдущей...
Да это так...
Все мои коллеги сидят на J-link версии не превышающей 6.20, хотя сейчас уже есть 7.66. В новых версиях GUI даже окно на весь экран сделать невозможно. Хотя раньше эта возможность была. И лог прошивки раньше был информативнее, чем сейчас.
А самые стабильные прошивки для J-link датируются аж 2014 годом! 11 летняя давность! Остальное просто не работает и постоянно сваливается в Hard Fault. Это как?
Утилита J-Flash просто блочит неоригинальные китайские отладчики J-link V9 за 3к RUR и превращает их в кирпичи. Происходит это обновлением прошивки без предупреждения. У нас на этаже уже три таких кирпичика лежит.
В результате ничего не остается как покупать оригинальный sEGGER V12 отладчик за 120kRUR.
Это как?
Не замечал особой разницы, возможно потому что не так часто пользовался именно их GUI. Например, работа с segger embedded studio всегда была шустрой и отладка была без каких-либо проблем на всех версиях драйверов. Работа через утилиты nordic semiconductor (через nrfutils) тоже была всегда безпроблемной.
При этой Segger ПО не видит J-link программаторов от того же nordic .
Поэтому nordic выпустил свою консольную утилиту для обновления.
C:\Program Files (x86)\Nordic Semiconductor\nrf-command-line-tools\bin\nrfjprog.exe
Это как?
sEGGER это пример цинничного Vendor Locking-га.
При этой Segger ПО не видит J-link программаторов от того же nordic
Можно тут подробнее?
Поэтому nordic выпустил свою консольную утилиту для обновления.C:\Program Files (x86)\Nordic Semiconductor\nrf-command-line-tools\bin\nrfjprog.exe
Она имеет заточенный под nrf интерфейс, в чем вопрос? Она всё также работает на JLink.
Утилита J-Flash просто блочит неоригинальные китайские отладчики J-link V9 за 3к RUR и превращает их в кирпичи. Происходит это обновлением прошивки без предупреждения. У нас на этаже уже три таких кирпичика лежит.
В результате ничего не остается как покупать оригинальный sEGGER V12 отладчик за 120kRUR.
Это как?
Эм, а что Вы хотели от неоригинальных копий? Вы же понимаете все риски с этим связанные. Вы говорите о покупке оригинального отладчика так, как будто это что-то плохое. Если у Вас работа связана с железом, и Вы его используете в своей работе постоянно, то покупка оригинального отладчика не выглядит дикой.
Вы говорите о покупке оригинального отладчика так, как будто это что-то плохое. Если у Вас работа связана с железом, и Вы его используете в своей работе постоянно, то покупка оригинального отладчика не выглядит дикой.
Да, но надо ещё и для учёбы себе купить один отдельный программатор. А 120k это дорого.
Зависит конечно от учёбы, но на почти всех отладочных платах (например, от nordic и от stm) стоят встроенные отладчики, ничего дополнительно покупать не нужно.
Забудьте про stm и nordic.
На дворе санкции!
Теперь надо работать только с китайскими микроконтроллерами: Artery, YunTu, GigaDev, Esp32, Nuvoton.
На отладке YTM32 отсутствует встроенный отладчик.
del
Забудьте про stm и nordic.
Зачем про них забывать? Их новые чипы огонь, особенно у nordic.
На дворе санкции!
Новые китайские друзья не могут сделать свой отладчик? =)
STM - да, огонь, но у Nordic сами чипы, может, и огонь, но SDK сваливается в УГ. За 2 года 2 раза мигрировали на более новые версии, т.к. выявляли серьёзные баги в из SDK. К слову, техподдержка их в основном всегда на все найденные баги предлагает мигрировать на новые версии SDK с новыми багами. В итоге остановились на 2.6.0 с парочкой грязных воркэраундов, и молимся, чтобы заказчик не потребовал новых фич, которые бы потребовали миграции на другую версию SDK.
"Нормальные" китайские подделки мимикрируют под урезанную EDU-версию J-Link и не огребают таких проблем с подлинностью, как более навороченные. Пиратство, к слову осуждаю, и китайские J-Link не использую, благо есть легальные решения для Nordic и ST, но считаю, что segger как-то слишком уж жадные.
Как увидел, что речь пошла про отдельный J-Link сильно удивился и аж пролистал назад, чтобы увидеть, что китайцы на свою отладку встроенный дебаггер зажопили.
но SDK сваливается в УГ
Да, согласен. Я использовал их softdevice, и отладка в нем была боль. После того как они перешли на zephyr, который собирает прошивку через миллион скриптов, генераций (и еще очень долго) — перестал пользоваться их SDK, разве что смотрел их SDK просто как референс в некоторых моментах. На голое железо простой софт ложится очень хорошо, так как сам чип учитывает некоторые особенности разработки ПО. И когда я говорил про "огонь" — я имел ввиду только чипы, не SDK.
но SDK сваливается в УГ
Что значит акроним УГ?
Забудьте про stm и nordic.
Зачем про них забывать? Их новые чипы огонь...
Вот смотрю я на это все и слегка недоумеваю. Чтоб не сказать больше и нецензурно. Да за тот переполох и коллапс, который STM устроили в нашей промышленности несколько лет назад, когда никакой STM ни за какие деньги купить было просто нельзя, когда производство встало, когда проекты экстренно перепроектировались на другие чипы, продолжать использовать их в реальных проектах и нахваливать...
Да, блин, память как у золотых рыбок.
Для учебы есть JLink-EDU. 7к - вполне достаточно за полноценный отладчик и чистую совесть.
J-link V9 это просто подарок для эмбеддеров. Легко ремонтируется. Легко восстанавливается прошивка. Поддерживает кучу популярных ядер. Клон доступный и недорогой. Для гурманов в интернете есть несколько открытых проектов клонов, в том числе под USB Type C и с гальванической развязкой. Есть J-Link Server для линукса, лёгким движением руки при помощи недорогого одноплатника получаем отладчик с гальванической развязкой и подключением через Ethernet. Единственный недостаток - не поддерживается производителем с 2021 года, новых ядер там уже не будет
libc rdimon мне нужен только лишь для того, чтобы работала функция snprintf() для float чисел.
Это надо для UART-CLI. Для сериализации структур.
Если найду более компактную реализацию libc охотно перейду на нее.
Используя J-Link под Ozon-ом вы ничего конкурентного не получаете в отладке по сравнению с другими адаптерами.
Преимущество J-Link хорошо проявляется на мой взгляд только в C-Spy от IAR.
Да тут не до преимуществ. Лишь бы хоть как-то работать с новым чипом.
Чтобы в случае Hard Fault был способ понять в чем дело.
Всё равно основная отладка идет по UART-CLI.
А пошаговая отладка нужна редко, только когда прошивка намертво зависает по непонятным причинам.
Мы ж про отладку говорим. В ней преимущество и проявляется в легкости подъема голых платформ с нуля.
Ozon - это когда нужно чужой бинарник прореверсить. На большее он слабо годится.
Неудобство Ozon лишь в том, что его надо тоже патчить как и Jflash. Чтобы он узнал новый тип MCU.
Вот тут только что вышел обзор по использованию Ozone - https://www.linkedin.com/video/live/urn:li:ugcPost:7291108344533012480/
Как видно timeline там очень примитивный. Коментатор даже видно полохо понимает зачем timeline нужен.
На самом деле без J-Link Ultra timeline практически бесполезен.
Этот текст в очередной раз подтверждает тот факт, что все микроконтроллеры программируются абсолютно одинаково, если собирать код из самостоятельно написанных GNU make файлов.
Этот текст подтверждает лишь тот факт, что вы пока не работали с микроконтроллерами, которые программируются иначе. Простой пример - семейство DA1469X и подобные от Dialog Semiconductor (ныне Renesas). Так как там нет встроенной флэш-памяти и процесс прошивки конфигурируется в зависимости от NOR-flash, которую выбрали для проекта. И это мы говорим не про экзотику, такой же M-33. А ведь можно вспомнить, что есть еще RISC-V и для него процесс и инструментарий могут несколько отличаться.
Про то, что можно использовать OpenOCD уже говорили выше. Я в целом понимаю нежелание писать конфиги для него, но зачем использовать тулы с GUI для прошивки и клацать мышкой? Нереально, если в день прошивается несколько тысяч устройств на каждом джиге и бессмысленно, если это все можно заскриптовать. Наверное это возможно только для околокустарного производства во всяких НИИ и КБ, где собирается пара-тройка экземпляров и разработчика можно припрячь к потоковой прошивке и сборке.
Не могу не отметить также догматичность заявлений про единственно верный® способ отладки через UART-CLI. Тратить ресурсы (интерфейс, пины, прерывания, время) пожалуй можно, если нет требований к реалтайму и есть возможность заложить контроллер побольше, но зачем? И что делать, если свободных ресурсов нет, как и желания раздувать BoM партии на +100k$? Все то же самое можно провернуть через RTT абсолютно бесплатно. А для взаимодействия с МК после прошивки релизным бинарём и отключения SWD можно использовать mcumgr и любой из транспортов, который он поддерживает. BLE, UART, USB-CDC, сеть - что угодно, а при желании можно и своё завелосипедить.
Не могу не отметить также догматичность заявлений про единственно верный® способ отладки через UART-CLI. Тратить ресурсы (интерфейс, пины, прерывания, время) пожалуй можно, если нет требований к реалтайму и есть возможность заложить контроллер побольше, но зачем? И что делать, если свободных ресурсов нет, как и желания раздувать BoM партии на +100k$? Все то же самое можно провернуть через RTT абсолютно бесплатно. А для взаимодействия с МК после прошивки релизным бинарём и отключения SWD можно использовать mcumgr и любой из транспортов, который он поддерживает. BLE, UART, USB-CDC, сеть - что угодно, а при желании можно и своё завелосипедить.
Ответ тут
Почему Нам Нужен UART-Shell?
https://habr.com/ru/articles/694408/
Настройка ToolChain-нa для Разработки на Микроконтроллерах YTM32x