Абе то не е само до акробатиките... ей на и в CMSIS кода ми намери нови забележки, а уж е стандартен код, би трябвало да е читаво написан, ама... Но явно и "големите" драскачи ако не им прави някой забележки пишат както дойде

Иначе за Еклипс зависи какво правиш. Ако го ползваш само като текстов редактор може и да не ти хареса.... Но истината е, че това е страшно гъвкава среда. Може да си настройваш всичко. Казвам го щото много хора като си го сложат и почват с оплаквания от типа "абе аз съм свикнал така, пък под еклипс не е така...". После отиват в настройките (а те са хиляди) и се загубват и се опетлават.
А то е много просто. Като отидеш в опциите си има поле и пишеш какво ти трябва. Примерно искаш преди компилация или дебъг да ти записва всички отворени файлове. Ами пишеш "save" и веднага ти излизат нужните опции. Иначе верно не може да ги намериш тия опции без търсене. Та мисълта ми е, че що се отнася до поведение, клавиши и т.н. всичко може да се настрои според както си свикнал. Поне аз си ги настройвам нещата. А защо по подразбиране настройките не са толкова интуитивни е друг въпроса

Но най-важното е, че Еклипс не е просто редактор. Това е среда и то отворена среда, която се интегрира с какво ли не. А като почнеш да работиш сериозно си трябват много неща. Примерно в екип като се работи не може без CVS , SVN или друг репозитар. Като почнеш да си документираш сорс-а си трябва doxygen или друг подобно. Като почнеш по-сложни проектчета тип клиент сървър си трябва я малко PHP, я джаба. Или пък ако имаш фпга ти трябва VHDL/verylog... Всичко това го има в Еклипс. И то не просто го има, но го има по ПЕРФЕКТЕН начин. Имаш контрол върху ВСИЧКО, включително и най-дребните детайли като енкдоинга на файловете дали да е 1251, UTF-8 или нещо друго.

Просто имаш всякакви опции за всичко. И всяко нещо си пасва с останалите. Невероятно е. Сега някой ще каже, да ама еди кой си тул е по-удобен за еди какво си.... Сигурно! Има много специализирани тулове. И текстови редактори и репозиторита и за веб и за какво ли не. Но колкото и да е добър един тул той има само даден брой функции, а почнеш ли да смесваш различни тулове неминуемо почват ядове.
Докато Еклипса е нещо като шаси, върху което всичко тулове си пасват един с друг. И като започнеш от спелинг (английски/български), енкодинг, после според езика синтаксис (ц/ц++/джаба/php/vhdl..), документации, работа в екип и т.н. и т.н.. Абе имаш всичко!

Но ако на теб ти трябва просто текстов редактор няма голяма файда че има всичко

Вдъхновен инсталирах еклипса и yagarto-то, след жабата разбира се (ей, не можах да се опазя от тая жаба). После също толкова вдъхновен реших, че ако бях направил дупка в лаптопа щеше да има същия ефект.
Тъй, сега когато нервите ми се поуспокоиха - някой написал ли е що-годе смислен туториал как се работи с това нещо? Защото срещам елементарни затруднения дори с готов екзампъл за Cortex-M3 от сайта на yagarto. Желанията ми се към него и ARM7, доколкото разбирам за М0 не мога да се надявам в момента (ако може ще е чудесно)?
И ... това с дебъга ще ми изяде главата, та ако може някое линкче да се зачета - гуглето като чуе еклипс и ме залива, та се давя. За момента се чувствам като цък-ач с мишката, дето вси ми било дадено на готово, та зор, зор ... На първо време това GDB - от къде, кое, как се настройва дебъгера?! Примера даден на сайта на yagarto има нещо смислено по темата, ама ... имам под ръка CrossConnect - с него как става номера под еклипс?
Въобще торба въпроси имам, та за да не ви тормозя за щяло и нещяло малко помощ с документация ще е добре. Като за начало?

абе има туториали за много работи, ама какво точно ще ти трябва не знам...

Давай проблемите един по един, че така трудно ще ти помогне някой

Първо ако ползваш ягарто може да компилираш за всякакви таргети, включая последните куртекс А-15... Нали затова го похвалих че най-накрая ягарто настигна по версия ГЦЦ, демек имаш всичко дето го поддържа ГЦЦ и не виждам какво те притеснява М0.

За Crossconnect не съм го ползвал най-добре някой с опит да ти каже как се настройва...

GDB е дебъгера. Може да го ползваш директно от команд промпта - стартираш и после командориш.... А под Еклипс се слага плъгин, за повечето емулатори се препоръчва Zylin-a, ама айде първо някой да помогне за кросконекта че тогава...

за да закачиш crossconnect към GDB ще ти трябва някакъв междинен сървър. Първо провери дали това е налично.

миро, на първо време ми е безкрайно любопитно как да направя простичка симулация на екзампълите - всега всеки опит за дебъг (логично) гърни с грешка за GDB-то, ама то логично - где го? Отивам да видя що е то Zylin. Ама наистина като все едно се уча да ходя на ръце - възможно е, полезно е, ама ...

цецо, следобеда търсих такова чудо, но за сега нямам тоя късмет - а явно може, защото на сайта на yagarto има сравнения между разни jtag-и и crossconnect-a присъства в таблиците, дори и Lite & Pro вариантите. Та значи може, чудно защо из нета не срещнах нещо смислено по темата...

В какъв смисъл где го?

Като инсталираш ягарто, то трябва да ти е в пътя... BTW особеност е че по традиция пред GCC туловете се слага префикс, за последното ягорто той е arm-none-eabi-*

т.е. GDB-то ти е arm-none-eabi-gdb.exe

той хубаво ще пусне gdb то. Ама GDB то някак си трябва да се конектне към хардуера. Т.е трябва ти gdb server за конкретното дебъгващо желязо. Не съм чул да има такова нещо за crossconnect.

Първо това проучи, защото ако нямаш тази брънка, не можеш да сглобиш веригата. И ще трябва да се откажеш или от crossconnect или от цялата gcc концепция.

Една "особеност" на последното ягарто т.е. GCC 4.6...

Старото GCC (arm-elf- версиите) правеха табличка със статичните конструктори в секция ".ctors" а сега тая секция се казва ".init_array". Така че всички, които ползват Ц++ да го имат предвид и да си фикснат линкерските скриптове (а ако се налага и стартъп кода)....

Като изключим горните "особености" остана ми само един проблем с новото GCC 4.6 и GDB 7...

Проблемът е, че за определени функции GDB не намира дебъг информация. По-точно губи май само част информацията като връзката с номерата на редовете в сорса. В крайна сметка дебъгването става неприятно.
Ето малко примерчета... спирам на омазана функция:



обаче:


това показва, че все пак има някаква информация за тоя адрес и тая функция... както и това:



Сега, това което успях да открия е, че проблемът е свързан с оптимизацията на секциите. Значи като махна -Wl,--gc-sections няма проблеми! Дебъгва като слънце!
Само че тая опция ми трябва понеже тя разкарва неизползваните променливи/код. А пък аз имам доста мъртъв код и съм на ръба на флаша, така че особено за дебъг версия не желая да линква мъртъв код...

Най-вероятно --gc-sections оптимизира някоя дебъг секция. Не мога да хвана коя точно щото дори и --print-gc-sections не показва нищо съмнително. Сравнявах символи, мап-ве, листинги... всичко за което се сетих - нищо не откривам. В смисъл аз знам за кои функции си губи информацията и за кои не, но и в двата случая символите и всичко останало изглежда еднакво.

В крайна сметка стигнах до извода, че единственото което се губи е части от някоя шибана дебъг секция. И много вероятно да е бъг понеже се дъни на следните типове функции:
1) Такива, дето "заместват" weak. Примерно горния LowLevelInit е такава. Имам weak (стандартен) вариант в ОС-а, но в приложението я подменям тая функция...
2) Функции дето се викат индиректно. Примерно всяка нишка е функция, която не се вика директно от никъде. Но тъй като указателя към функцията все пак се ползва то съвсем логично не я "оптимизира". Но пък оптимизира дебъг информацията мамка му...

Някакви идеи кво да го правя?

Ще ми се да хвана точно секциите, ама не съм много в час с дебъг секциите, ELF, DWARF и т.н.... А и то да го хвана коя секция чисти не знам как бих могъл да го оправя...

Това го забелязах на MIPS версията при CodeSourcery 4.4.x , защото при Microchip 3.4.4 с --gc-sections си работи и цялата debug информация е налична. Аз го хванах случайно преди време, но при мен не само, че липсваше инфо за някои функции, ами от примерен код от към 3000 байта ми правеше hex файла от 13-байта без никакъв код вътре. Накрая започнах да махам опция по опция и накрая хванах, че garbage collector-а се дъни. Ама не си спомням дали имаше код в elf файла, или само в hex файла липсваше.

Но аз съм много далеч още от работещ код под CodeSourcery, успях само да накарам да ми компилира и свърже проект с 30-тина C файла до изпълним файл от 32kb , та не знам какво има по кода ( пробвах на желязо, естествено не тръгна ).

Имам още работа по линкерския скрипт, първо ползвах готов, накрая започнах на чисто и сега поне знам какво правя. Отделно ползвам една смесица от startup код и libxxx библиотеки на Microchip с такива от CodeSourcery, които трябва да ги разделя и да използвам като общ код само периферните библиотеки на Microchip. Header файловете на Microchip за PIC32 са омешени на диска с тези на GCC, трябва и те да се редактират, така че да са в отделна папка, за да мога да използвам header файловете на CodeSourcery. А бе има работа доста

При теб е ясно, нямаш KEEP за входните точки и боклучията се държи нормално... При мен линкерския скрипт е наред и нямам проблем със самия код. Чисти се само излишния код.

Проблемът ми е *само* с дебъг секциите, там ми маха информацията за определени функции. Два дена го борих без успех, даже си пренаписах изцяло линкерския скрипт според последните версии на DWARF и т.н.

Тъпото е че дебъг секциите са голяма мъгла. Не ги показва в листингите, символите от тях ги няма в маповете. Изобщо не мога да видя какво има вътре и какво липсва

edit:

лек напредък.... това се оказа вярно, т.е. ако изключа -ffunction-sections -fdata-sections мога да включа боклучията (--gc-sections). Така е малко по-добре...