Някой да има идея за читав GNU toolchain за Cortex M3. Ще трябва да се прави комерсиално проектче и няма как да се копа на IAR.

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

Значи не съм бачкал с Cortex и нямам конкретен отговор.... Но според мен въпросът е какво ще правиш с JTAG-a (или SWD-то)..

Иначе си мисля че тулчейна ти е най-малкият проблем. Ако трябва ще ти спретнем един, но аз си мисля че не трябва. Аз ползвам Yagarto и той е долу-горе с последните версии на GCC и GDB. И доколкото виждам не протестира изобщо като му дам "-mcu=cortex-m3", почва да компилира само дето аз използвам ARM моде и естествено няма как да го компилира.

При всички случаи горещо ти препоръчвам GCC+Eclipse, доколкото те познавам няма да издържиш на други дървета. Желателно е да са native.... Най-добре ако може да си спретнеш една отделна лайнукс машинка, да сложиш GNU-то, да сложиш Eclipse и ако не ти се бачка на теб в линукс, просто един графичен терминал към нея и си бачкаш през бозата... Но пак казвам, че съм почти 99% сигурен че yagarto за бозата ще поддържа и кортекс (въпреки че на сайта пише друго). Жалко че нямам тук при мен никакъв кортекс да се пробвам.

Сега се сещам че ти трябва да имаш JLINK, те по принцип май в последните си версии поддържат Cortex.... (не знам доколко ти е оригинален JLINK-a обаче). Така де ако стане, пусни един GDB сервър за JLINK и после ще помагаме със съвети как да настроиш и да си организираш всичко...

като железа за дебъгване имам относително голям набор - самоделен wriggler, тапата на Balkana (която тръгва като Wriggler или Raven), Олимекския FT3232, и клонинга на Jlink. Последния се разпознава като стандартен Jlink от IAR без никакви фокуси. Гледам че на сайта на segger има GDB сървър за Jlink, но досега не съм го пробвал. Та откъм желязо се надявам да имам достатъчно ресурс.

Принципно имам една свободна линукска машина, но тя е P3, не е върха на сладоледа. Обаче проекта няма да е супер голям, мисля че в команден ред ще компилира сносно като скорост. Обаче eclipse върху нея ще я мъчи. Та по ми се ще графиката да ми е на работната машина. А то графиката си отива на eclipse, щото Insight ми е много дървен, а gdb в команден ред..... абе разглезен съм вярно е.

Честно казано не съм любител на Cygwin решенията. Но ако не намеря друг вариант и това ще правя.

Yagarto наистина пише, че не подържа Cortex. Според мен проблема е в дебъгването а не в компилатора.

http://www.codesourcery.com/

Това например. Но за изпитано, все още не е кой знае колко изпитано ....

Да видях ги и тях. Безплатно може да се дръпне Lite версията, която на практика би трябвало да е функциониращ toolchain. Само дето в безплатната версия не влиза Eclipse и човек ще трябва сам да го закачи. Което не ми изглежда особенно елементарно. Особенно ако искам графичния интерфейс да е на друга машина.

Aз съм го пробвал навремето. Работи поне с ARM7, но не бих казал че е много удобно. GDB сървърът имплементира само стандартния ГДБ ремоте протокол, който е само за дебъгване. А преди това се иска все пак да заредиш кода, който ще дебъгваш. Демек трябва ти и JFLASH (не е безплатен). Няма и никаква трейс функционалност.
Изобщо JLINK-a никак не е толкова удобен както с IAR (за съжаление). Колкото и смешно да звучи тъпото OCD е по-удобно (там проблемът е смотаното конфигуриране, но за щастие това е еднократна процедура). Само дето пък не знам дали OCD-то поддържа Кортекс (май не?)


Ако питаш мен и в самото дебъгване не би трябвало да има проблем. В смисъл Eclipse плъгини-те си ползват gdb и то версия която мисля поддържа кортекс. Най-вероятно не работят правилно джамовете за регистрите... Но те при читав емулатор изобщо не ти трябват. Важното е да не гърмят. И ако питаш мен струва си да пробваш... щото плъгините на Еклипс са най-близкото нещо до представите за "дебъгер"...

Уф тоя еклипс ще ме побърка.

Значи дръпнал съм "Eclipse IDE for C/C++ Developers (68 MB) ". Качил съм отгоре CDT-то на Zylin.

Като опитам да направя нов проект отивам на File->New->C Project. От там избирам MakeFile Project->Empty Project и отдясно селектирам Other Toolchain (освен това има и Cygwin).

И то ми прави нов проект. Хубаво ама вътре ми прави папка "includes" където им прави референси към хедърите на Cygwin. Нещо такова:

И няма разкарване, нищо не е активно по нея с десен бутон. Изчетох всякакви примерни страници из нета - оставам с впечатлението, че празен проект трябва да е празен проект. А при мен не е празен.

Преди 2 години имах същия проблем като се опитвах да подкарам Eclipse за MSP430. И пак загубих сума ти време... и не помня какво направих тогава

с десния върху проекта -> properties -> C/C++ General -> Path and symbols

в дясно се появяват едни include directories... търкаш всичко което не те кефи.
И го търкаш за всички languges (assembly, C, C++ квото имаш)


едит: Внимателно си настрой списъка на include файловете в Eclipse да отговаря на този който използваш при компилиране...
По принцип Eclipse няма откъде да знае какво и как и от къде компилираш и затова се опитва да отгатне... както прави при теб. Не че е фатално ако не отгатне, но редактора няма да оцветява правилно кой #ifdef ще се изпълни, и с мишката като задържиш върху някой символ няма да му намира #define-a както е в долната картинка...

и още нещо в случай че ползваш стандартни библиотеки не ги махай от горното

Уф разгеле. Мерси.

Какво имаш предвид под "стандартни"? При мен по дефоулт накачва Gygwin-ските. Ама те за ARM не са интересни, или бъркам?

Друг въпрос. Кой make да ползвам? Качил съм toolchain-а на yagarto. Ама той вътре make си няма.


П.С. yagarto-то си имало make (3.81). Ама неизвестно защо е завряно в OpenOCD раздела.

"стандартни" са библитеките за деление, за стрингове (strcmp, strcpy...)
Но е много относително понятие, щото който е компилирал тулчейна е вкарал някакви библиотеки. Aз от цигвина бягам като дявол от тамян и не ме питай кво са сложили... За ягорто мога да ти кажа че са сложили newlib или някаква окастрена версия.

Всъщност въпросът е ти какви библиотеки искаш да ползваш. Ако не искаш никакви става най-лесно с една опция на компилатора да му кажеш да разкара всякакви библиотеки по подразбиране... Тогава си на чисто и почваш с един гол компилатор. Но не знам дали ще имаш нерви сам да си пишеш код за всички функции или да търсиш сорсове... Ако беше за ARM7 можех да ти дам "лично производство" за абсолютно всичко... Ма няма да тръгне щото всичко ми е на асемблер. Оптимизирал съм го в пъти по размер и производителност спрямо стандартните решения.

Не знам какво да те посъветвам.... Ако искаш почвай да бачкаш с тва дето са ти го сложили и като компилираш някаква версия си погледни листинга и виж какво ти е наблъскало. Ако те устройва - ОК..
Може и да не ти хареса, просто повечето библиотеки идват едва ли не от лайнукс. И слагаш някъде един sprintf а пък то може да ти наблъска код за файлове и за сокети, нищо че ти printf-а ще го ползваш само за стрингове. Всичко зависи от това какво и как са ти го турнали... Да не говорим, че големите библиотеки идват на С и то универсално С и изобщо не са съобразени с уникалните възможности или невъзможности на АРМ. Примерно sprintf("%d") първо е една грамаданска функция дето яде много стек, второ за преобразуване на числото в десетично вика деление по два пъти за всяка цифра от резултата. А пък АРМ няма инструкция за деление (май и кортекса няма) и е страшно тромаво... Но пък деление на константа се прави супер лесно с 6-7 асемблерски инструкции.

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

Друго нещо, понеже нямаш много опит с GNU-та интересно ми е как ще си менажираш проектите... Че това също е цяла наука. Не е като new->project и айде в джаза... Верно може и с managed проекти да караш, ама ако не искаш свиркай...

За библиотеките - ми Newlib като за начало, а като приритам за ресурси.... ще плюнча молива то е ясно....

Иначе за менажирането на проектите... какво имаш предвид?

как ще си организираш проекта... директории ала-бала.
На IAR лесно - даваш new workspace/project и там опции простотии. При GNU нямаш такова нещо, имаш 1000 инструмента и само от теб зависи как ще ги ползваш... разбирай трябва да пишеш make файлове. Значи проблемите от една страна са писането на мейкове, но от друга страна повече става дума са организацията на нещата. Като мейковете трябва да съответстват на организацията ти...

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

Друг пример... как компилираш различните езици. Повечето дървари викат AS за асемблер, LD за линкване и т.н. Не че е грешка, ама аз не правя така... всичко го правя по един и същ начин, независимо дали става дума за асемблерине, компилиране или линкване... Примерно предпроцесора го викам за абсолютно всеки сорс файл. Така първо имам макроси, #define и в асемблера, а не само в С/С++. Второ мога да имам общи хедър файлове, а не за С-то да правя h-файлове пък за асм inc-файлове. Примерно като си дефинирам че ще правя DEBUG_XXX нещо и С-то и Асемблера си го ползват.
Отделно както казах избягвам да викам AS, LD и т.н. директно. Предпочитам да извикам GCC със съответната опция за асемблиране или линване. Проблемът е че един проект има много и различни опции и по-добре само веднъж да ги задаваш тези опции. Затова използвам GCC и го подавам на него, а то си знае в повечето случаи как да ги транслира до съответния линкве или асемблер. Ех, винаги се налага да дам и специфични опции, но колкото по-малко специфични неща има толкова по-добре. Иначе форматите са различни и като дадеш на асемблера една опция, на компилатора втора, а на линкера трета - противоречаща на другите две стават едни бози...


Та с две думи говоря за тва кво е "добра практика" или "добър стил" при работа с GNU... Аз съм се опитвал да събирам идеи на тая тема. Примерно ето тук съм описал как си правя мейковете http://www.informa-dev.com/res/tmos/TMO ... 2_MAKE.pdf
Далеч съм от мисълта че правя нещата по перфектен начин, но поне съм се постарал да разуча множество варианти и да подбера някакъв разумен. Целият проблем е, че в GNU всяко нещо може да се направи по безброй начини. А повечето хора преписват при това обикновено преписват възможно най-тъпото и най-неудачно решение. При комерсиалните среди е къде къде по-лесно... няма хиляди варианти, има няколко или само един. Съответно или го знаеш тоя вариант или не го знаеш. Просто и ясно...
За съжаление не е точно така с GNU, затова е важно повечко хора да си обменят идеите и да се отделят по-добрите решения... Поне аз съм винаги готов да открабна хубава идея

едит, сори бях копирал кофти линк...

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

Та сигурно вече ти е ясно що повече ми харесва IAR идеологията, а не GNU пройзводните Много по близо е до железарската ми душа Да ама не. То ако ставаше както ми е приятно.... както и да е.

Относно организацията на проектите. То сега ще е първия за пари който е на GNU. Даже вече почвам да се замислям, защото времето ме притиска, а пусто GNU яде времето като топъл хляб. Поне при мен. Та мисля проекта да си е по възможно най-опростената структура. Той така или иначе не е кой знае колко обемен, няма OS, няма много външен код, абе типичен микрконтролерен проект. Всъщност няма да е типичен, щото мисля да мине без нито един ред асемблер Директория със сорсове. Директория с мои хедъри. Директория с външни хедъри и директория с външни сорсове. Абе колкото по просто толкова по добре. Пък и при по проста организация по лесно ще се оправя с шантавия make.

Относно обектните файлове - какво пречи да са си разпръснати из директориите и преди да ги харзулна към CVS (SVN при мен) да напиша make clean?

Абе всякак може.... дори както си го намислил

Щом си решил карай така. Но според мен няма да се разминеш хептен без човъркане на мейкове и други простотии за съжаление. Аз просто ти предлагам начин по който да си организираш нещата веднъж и повече да не се занимаваш с глупости или пък да те дразни в последствие... Щото сега ако направиш един проект, утре друг и след време ти се наложи нещо по-сложничко и ще влезеш в собствения си капан. Или трябва да продължиш по стария (не много удобен начин) или да се чудиш как едни и същи сорсове от старите проекти да ги ползваш в новите без да правиш гимнастики.

Иначе бъркаш... по-простата ти организация не означава че ще имаш по-прост мейк файл. Аз съм написал един мейк файл и практически не го редактиктирам изобщо. Ако решиш да го ползваш има само няколко неща да смениш относно опциите на ядрото, нищо повече. В самия мей не изброявам сорс файлове, а само поддиректории и доколкото винаги използвам една и съща структура на директориите, то няма разлика между проектите. Щото винаги ползвам 3 главни директории на проекта - приложение, таргет и ос. От там надолу си правя много поддиректори... що., ами щото си ги групирам нещата логически. Примерно нещата свързани с GUI са си в GUI поддиректория, ако ми трябват включвам я, ако не ми трябват не я включвам.
В всяка поддиректория имам един module.mk файл който казва кои сорсове от текущата директория и кои поддиректории да бъдат включени.

Верно много поддиректории имам:

Тва е един проект, реално сорс файловете са някъде към 140, но с обектите и листингите стават 400. Ако ти мислиш че ще e приятна гледка да имам толкова файла в една директория ОК... Всъщност директориите не са ми толкова много, щото CVS-а ми прави автоматично по една директория във всяка директория... Абе сложи ги средно по 5-10 файла на директория, което е приемливо за мен.

Между другото аз не събирам и хедър файловете накуп на едно място. Първо защото не ми се налага, второ щото не искам. Аз искам всяка логическа част от проекта ми да е поддиректория и да не е обвързана с други, т.е. трябва ми нещо - хоп слагам го, без да се чудя "абе тоя хедър откъде и за какво се ползва"....

Anyway... всеки си има мнение нали знайш.. (и гъз)