Има ли такова чудо, което да има читаво IDE за PC с Linux, което да поддържа хардуерен дебъгер подобно на ST, Keil, IAR, ставащо за работа и с което може да се свърши нещо реално?

(Въпроса ми е към някой, които има реален опит с това)

С руст нямам опит но го държа под око и доколкото знам има вече няколко РТОС-а писани на него т.е. яма проблем за всичко което търсиш да намериш нещо писано по темата. За ИДЕ и дебъгер предполагам, че най лесно ще е с VSCode защото в него интеграцията на всякакви езици е направена и тя не зависи от платформата т.е. syntax highlighting, autocomplete и т.н. а дебъгера обикновено не се интересува кой знае колко от езика на който е писано стига да може от мета дебъг информацията да ти покаже текущата инструкция на коя линия от сорса отговаря.

възниква въпроса: Защо Rust ?

По стриктен е по време на компилация относно използване на ресурси в различни нишки и предупреждава за потенциални заключвания т.е. теоретично по стабилен код. Отделно разни големи имена го харесаха - Линус го разреши в ядрото, fish (алтернативен shell) го пренаписаха на rust. Аз съм скептичен, че в следващите 10-15 години докато се пенционирам ще е заменил доброто старо Ц така, че нямам намерение да инвестирам време за учене. Младите да го мислят. Може и да има смисъл ако хоризонта ти в бранша е още 30-на години.

Предполагам звучи малко тъпо, но понеже имам ограничен времеви ресурс (а и не е да не ме понамързява) ми се ще да намеря "панацеята" за моите нужди и тя да е един език за програмиране за всичко.
За сега с микроконтролерите (почти всякакъв вид от 8 до 32 битови) от десетиления си върша работа на С/С++ с най-разни платени и фри IDE-та и компилатори за Боза и Линукс, но виждам голям зор да си сетна и подкарам за Linux PC IDE + среда за крос компилация и крос дебъгинг за Расбери Пи на С/С++ ...

Разни познати (предимно PC програмисти) ми разпрявят как RUST-a бил мулти платформен и поддържал всичко като платформи "с един клик" и реших да проверя до колко това отговаря на истината. Твърдят, че специално за Расберито нямало абсолютно никакъв проблем, но мен ме интересува и девелопмънта за микроконтролерите.

Чата рязправя, че има разни варианти, даже дава и акъл какво и как да си сетна като развойни средства, но реших да питам "ЖИВИ ХОРА" за това.

Змие и гущеро-жабо подобните езици специално за Разберито се твърди че имат поддръжка и всичко необходимо, но някак си ми "обръщат червата" като започна да ги уча и все ги зарязван в даден момент. Сдобих се с всякакви книги и литература за тях, но явно съм доста изкривен като мислене от С/С++ и за сега не ми пасват на светоусещането.
(Като гледам синтаксиса на RUST-a мяЗа доста повече на С/С++ срямо тях)

е па имаш си я панацеята и си е плюс всякакви други експерименти

за С/С++ GDB си е стандартно, за Rust е нещо подобно, едва ли са излезнали от "шаблона"
ся до колко са интегрирани в IDE е друг въпрос

Имаше идея преди години за VSCode(IDE) / PlatformIO(builder) за всички продукти на малинките ( тотален крос )
но не се получи "сглобката" ... ПИ ОРГ казаха: нямаме човек който разбира от Python за да поддържа проекта

Емо, зарежи го ръст и научи добре шел за линукс. Ще имаш повече полза във времето. После ако имаш нужда инвестирай в ръст. Малинката няма проблем да я ползваш като хост за разработка. Е, бавна е ако решиш да компилираш на нея линукс ядро ама за ембедед проекти с РТОС няма никакви проблеми. На теб проблема ти е, че искаш всичко да е с ГУИ а то е направено за конзола и шел. От шел ми отнема около час да накича всичко на празна малинка или х86 и да продължа работа. Разликата е, че не ползвам ГУИ ами сериен кабел за шел.

И за да не се чудиш да ти обясня защо е хубаво да предпочиташ шел - основно защото така можеш да работиш с минимални усилия било то ремоте през ssh до машина която е на майната си или пък през сериен кабел до платка на бюрото - усилията и уменията които трябва да имаш са едни и същи. А и ти сам си се сблъскал вече с болезненото и бавно подкарване на неща през ГУИ та би трябвало да ти светне, че нещо не е в ред. Ама се отплесваш в търсене на решение в грешна посока защото тоя ръст ще ти добави още едно ниво на омотване. А на теб проблема ти е, че не ръчкаш през терминал.

Малинката успях да я ползвам като хост през терминал за компилиране на С/С++, но цял живот съм дебъгвал човешки през IDE-та разни и някак си ми идва в повече слагането на брейк поинтове, дебъгване и гледане на променливи през конзолата... В ИДЕ-то това го правя с няколко клика на мишката, а и визуализацията е на друго ниво спрямо конзолната.

Аз за момента не успявам да си сглобя това, което описах за малинка като крос тулове на Линукс ПЦ, но при първа удобна възможност опитите ми ще продължат... Не съм се отказал.
(на ПЦ с Боз не съм се и опитвал, а и не мисля и да опитвам)... Опитвам се да избягам от Боз-а и за сега само на служебния комп го имам.
(Е, и на линукс лаптопите на децата съм им качил виртуали машини с Боз, за да го имат като опция, защото в училище работят с Боз, но основно гледам да ги "свикна" с линукс-а.)

(Като си реша проблема с Малинката - определено ще забравя за РЪСТ-а )

ОТ:
До днес не бях пипал rust. След днес се съмнявам, че ще повторя. Два еднакви примера - hello world. На rust изпълнимият файл около 500kB, на C почти 16kB...

За съжалени много често се налага да се дебъгва новия фирмуер на платка от продукцията а не на тази от девелопмънта просто защото не е ясно дали ще можеш да повториш проблема заради различията в хардуера. Ако имаш специална платка на която има удобно изкарани житаг и сериен порт е лесно. Ама като няма? Да не говорим за платки които са специално скопени да не могат да се дебъгват като част от защитата им - например платежни терминали. Тогава си принуден да дебъгваш с клатене на пинове и гледане в сорса. Да отвориш дебъгер и да гледаш променливи си е лукс. Т.е. като няма как да избегнеш трудното дебъгване по добре да му свикнеш и то да ти е основния начин а не това с ГУИ дебъгера и гледането на променливите в него. Свикнеш ли на лесното после всяка трудност ти излиза през носа - затова не се разглезвай, че после боли. Да не говорим, че като си дълбоко в един проект и всичко ти е в главата само като видиш кое не работи и ти е ясно защо може да се получи т.е. много проблеми се решават почти без дебъгване.

Ти искаш да си решиш проблемите с по добри инструменти а не с умения. Истината е, че уменията са по ценни. А умения с правят с кофти инструменти, не със хубави. Един път като натрупаш достатъчно умения тогава вече с хубавите инструменти можеш да правиш чудеса за нула време. Но преди това трябва да си минеш по трънливия път с трупането на опит. Това е основната разлика между един синьор с 5 години стаж и друг с 30.

И аз да се включа с "компетентно мнение"
Ако си на С/С++ не ти трябва главоболие с Rust и тем подобни. Тия са езици-еднодневки дето стават модерни за няколко години и после загиват заменени от други еднодневки. Идеално за индианци ИТ-та да има постоянно какво да учат, ама за хора дето вършат реална работа си е просто заигравка.
Аз тук ще добавя силно противоречиво мнение - С е достатъчно за всичко, но когато човек почне да го домързява, бейсик е мързеливото решение за проблеми дето не искат капацитета на С

Нещо не разбирам каква е драмата с дебъгването на Малинката?
1. Пускаш на Малинката с gdbserver приложението което искаш да дебъгваш.
2. На ПЦто на което си направил кроскомпилацията или дебъгваш конзолно с gdb или графично с eclipse с подходящ плъгин който поддържа gdb remote протокола. И всичко е безплатно...
Имаше и някакви платени алтернативи от сорта на VisualGDB ама не съм ги тествал.
Другия вариант е да ръгнеш клавиатура, мишка и монитор на пайката и да билдиш и дебъгваш директно на нея...

Проблемите са две основни групи:
1. Как да се сетне крос компилатор (GCC) на PC с Линукс, който да е с правилните библиотеки за съответната версиа на Лунукса на малинката, така че да може да се билдне и линкне файл, който да може да върви на малинката след като се прехвърли на нея. (Добре ще е това да става с някакво IDE, за да не ми се налага да машинописвам много в конзолата)

2. След като файла е прехвърлен на малинката - да може да се дебъгва пак с някакво или същото IDE на PC-то, за да може лесно и пак без "машинописване в конзолата" да може да се слагат брейк пойнтове, да се спира и тръгва, да се гледат лесно голям брой променливи, паметта, стекове и т.н.

И всичкото това - за дебъгване на приложна програма, а не да драйвери за ядрото на ОС-а на малинката - без HW дебъгер.

3. Да може с HW дебъгер да се дебъгват драйвери на ниско ниво от ОС-а на малинката - пак крос с човешка визуализация.

Иначе да използвам малинката като комп с дисплей и клавиатура (или през конзолата) и да билдвам програми на него - това е ясно, но е тегаво.

Ако си наясно как се прави това - бирите са от мен без значение марката и количеството им.

Малинката няма житак т.е. нея самата не можеш да я дебъгваш на ниско ниво с хардуерен дебъгер. Можеш да я ползваш като хост от който да дебъгваш друга платка която си има житаг и хардуерния дебъгер е закачен към малинката т.е. като обикновено пц.

дебъгваш узер APP, не кернела по житаг