Търси "ChibiStudio" и си оркестъра направо. Няма нужда да се мъчиш.

Ако това ми беше попаднало преди 2 седмици щеше да ми спести доста лутане ...

Но в него не се използва АРМ плъгина и проектите са мейк-фаил базирани.
В моя вариант успях да направя проект с АРМ плъгина и с 4.7 компилатора.

Май ще продължа да си бачкам с моя вариант.

Нищо не ти пречи да сложиш gnu arm plugin-а в студиото. Щом вече имаш проект, какво ти коства да го импортираш в студиото и да пробваш. Не виждам причина дебъг-а да е зависим по някакъв начин от това дали е managed или не.
Ако си успял, пусни някой картинка като спреш на брейкпоинт например какво се вижда в Debug прозореца. Интересно ми е дали показва всички тредове и call stack-овете вътре към момента на спиране. Както каза Миро, за това по-голямо значение има openocd-то и gdb-то. Ама то в студиото openocd-то е на поляка и май е актуално. Иначе може да се наложи да билваш openocd.

хе-хе, ако показва половината ще е много интересно

Общо взето ИДЕ-тата показват това, което им връща дебъгера. В случая gdb взема информацията от емилатора, а той откъде я взема зависи... При PEEDI си имам конфигурационен файл, в който описвам що за животни са тасковете и къде трябва да се търсят. Ако искам мога да опиша списъка само на активните таскове или всички таскове. Абе каквото задам, това си излиза... При оцд също трябва да има начин да се конфигурира списъка на тасковете, на даден таск как се взема има, състояние и контекст и т.н.

Иначе моят съвет е да не се жените за ИДЕ. Разбира се колкото по-удобно толкоз по-добре, но задължително всичко което ви показва ИДЕ-то вие трябва да можете да си го вземате през gdb конзолата. Това е задължително, иначе просто слагайте IAR, Кейл или друго и не се занимавайте с GNU.
Просто ако се уливате в иде-та рискувате да не научите възможностите на gdb. А те наистина са необятни защото не става въпрос просто за команди, а за език. Все едно да се сравнява разговор по телефон с пращане на факс. Колкото и да е нагледен факса, друго си е живия разговор... най-малкото винаги може да питаш.
Примерно нещо тривиално - командата print или просто p. С нея може да си видите всяка променлива, но не всички знаят, че освен променливи може да се принтват функции. Примерно "p foo( 46)" където фоо е някаква функция от вашия код... На всичкото освен че се изпълнява може и да я дебъгвате, да й слагате брейкпоинти и т.н.

Да де, има смисъл ако показва всичките, ако показва по-малко (0 или не всичките), не е добре.
Това с женитбата за иде-то има резон, но то важи за всичко в този свят. Ако се ожениш (буквално), е същото - може да се наложи да се разделяте/сменяте, ама това не значи да не се жениш въобще. Същото е и със езика за програмиране, и с всеки друг инструмент. И с колата - като свършат запасите от петрол, ще ти се наложи да смениш транспорта. Ама засега сигурно се възползват от това удобство.
Аз не мога да приема че конзолния интерфейс е по-удобен (разбирай - по-ефективен) от графичния. Най-малкото имам още едно входно устройство - мишката, с 2-3 (понякога и 10) допълнителни бутона. Ако примерно решиш да смениш shell-а и те се наложи да учиш нови команди и опции ще си дори в по-неизгодна позиция от нас, с GUI-тата. Щото то при нас иконката билд или run е все една, често клавишните комбинации са едни и същи (или могат да се настройват), имаме контекстни действия върху различните ресурси - все работи дето искат писане ако си в конзолата.

Не става въпрос GUI vs конзола... двете не се изключват, напратив те са си различни неща и могат само да се допълват взаимно. За целта обаче *трябва* да се познават и двете. Хайде с ГУИ-тата се бачка по интуиция и няма нужда да четеш документация, ако GUI-то е наистина добро.
В случая ГНУ-сарските неща отдолу са конзолно ориентирани, а пък идеята на Еклипс е да бъде нещо като "обвивка" точно на такива истории. Затова и повечето дето не са свикнали с конзоли като видят Еклипс и се изприщват... Сума си народ си мисли, че Еклипс е "компилатор" или че трябва да прави еди какво си.
Силата на ГУИ-то е фронт енд-а. Да "цъкнеш" с мишка, да го видиш в "човешки вид" и т.н. Но всяко GUI има един огромен недостатък - не подлежи на автоматизация и на модификация. Просто не става. Често давам примера с "чукчето", т.е. като правиш релийз нормално трябва да компилираш, но ако работите повече хора преди да релийзнеш е добре да видиш преди това дали наистина компилираш последните сорсове. След като компилираш пък често се налага да криптираш или компресираш фърмуера. После да го разпратиш или качиш където трябва. Различно е, но всяка фирма си има някаква организация и ако се прави само с GUI трябва да цъкаш с мишката на 100 места. Като риска да пропуснеш някоя стъпка е голям. Особено за проект от преди 5 години. Ето тук идва силата на конзолата - там няма проблем да извикваш компилатори, да синхронизираш с репозиторита, да пращаш файлове, абе каквото там си трябва.
Правиш си го на скрипт и го закачаш на бутона с чукчето. От тук нататък няма какво да се обърка. Или натискаш чукчето или не го натискаш. Релийза или става или не става, ако има проблем.
Същото е и с дебъга - има много неща дето се автоматизират. И могат да се автоматизират само чрез скриптове, защото си трябва логика "ако е това направи еди какво, ако не е това направи друго..". За съжаление все още не е измислен добър визуален начин за изразяване на логика. Затова ГУИ-тата или идват с някаква фиксирана логика или с много ограничени възможности за модификация. Ако ти пасва - ОК, ама като не ти пасва на твойта логика удряш на камък..

? Явно съм голям оптимист (оптимист е човек на който му липсва информация), щото си мислех, че Еклипса позволява лесна къстъмизация и добавяне на функционалност с плъгини. За това се насочих към него - с дългосрочен план да се науча да си дописвам плъгини, с които да си облекча живота. Примерно терминалната програма (от съседната тема) на който ми се ще да мога да му добавя и протоколна поддръжка със съответно парсиране. Мислех това да стане на базата на RxTx плъгина за еклипса със съответното дописване ...



+1
Надявам се да стигна и до там, но като за начало започнах с по-интуитивния и лесен начин с ГУИ-то.


Прикачам два екрана на еклипса:

Е то си е така... има към 100000 плъгина. Аз примерно го ползвам и за VHDL и за XML и PHP и какво ли не. Изобщо може да редактираш всевъзможен сорс, включително и с подръжка на енкодинги (задължително ако имаш веб истории), умна синхронизация с репозитарита, всякакви компилатори и т.н.

Въпросът беше, че често има нужда от нещо нестандартно. Последователност от операции дето само вашата фирма я прави и т.н. Ако вашата фирма е голяма интернационална компания вероятно може да си позволи да си поръча плъгин или направо къстъм ГУИ. Но има и такива като нас, дето не можем или не искаме чак такива глезотии... С две думи автоматизациите си ги скриптосваме

Миро, аз те питах и преди ама не ми отговори. Докъде стигна с твоята ОС и под какъв лиценз планираш да я пускаш. И въобще планираш ли да го правиш или ще остане за вътрешно фирмена имплементация.

ако не съм отговрил, значи не съм видял въпроса... нямам какво да крия

Доколкото си спомням дадох линк към публичната част - code.google.com/p/tmos/
Сорсове и всичко е качено, даже писах някакви обяснения

Лиценз, засега формално е GPL, ако искаш нещо друго нямаш проблем, пари не искаме... Писал съм го GPL защото все пак работодателя ми има конкуренция, не че някой ще тръгне да ни ползва ОС-а. Но не сме в медицинския бизнес и не сме конкуренция

Иначи докъде съм стигнал - поддръжка за Атмел, ST и Luminary. Долу горе стандартните драйвери са направени. Тия дни ще кача и usb host... Има и непубликувани неща като gprs стекове и т.н. ама за тях без резрешение на шеф нищо повече не мога да кажа

Абе пак съм във филм... Тоя път проекта е сериозен, натаманиха ме за лидер, с главата съм в торбата
Ще пиша в другата тема, че тая е за Чибито.