Аз като обикновен ламер още от самото начало ползвам т.нар "Managed Project". Този термин в текущата версия на Eclipse май вече отпадна. С две думи оставям make файловете на IDE-то. От make файлове отбирам само толкова доколкото да рагледам някой такъв, когато портвам чужд проект.
Предполагам Миро при теб имаш някакви по-специфични изисквания и за това сам си правиш make файловете. Затова прости ми невежеството и любопитството ама какви са те?
Обектните файлове "IDE генерирания" make ми ги слага в отделни директории. Прави директория с име името на конфигурацията(Debug,Release...)в папката на проекта и в нея прави структура от директории която копира структурата от директории на сорсовете в проекта. Така всичко е подредено и на мястото си. Всичко това го казвам не защото е нещо особенно. Според мен така би трябвало да бъде. И предполагам IAR прави нещо подобно.
Досега не съм имал нужда да си правя сам make файловете. Освен когато използвах gcc за MSP430 без IDE.
Честно казано недоразумявам откъде ви изникват тези проблеми. Макар че знам че имам поглед само върху една малка част от GNU-то която ми се налага да използвам за моите задачи. Досега не съм имал ядове. Ето взимам нова версия на YAGARTO. Трия старата инсталирам новата. Малко дребни ядове докато отворя старите проекти. После откривам дребни промени по default поведението на компилатора и tool-овете. Обаче чак да ми яде толкова време...
Въобще интерфейса в Project->Properties->C/C++Build->Settings ми е напълно достатъчен за да управлявам моите проектчета.

И Цецо сподели после като подкараш нещо за Cortex с YAGARTO. Така като гледам Rowley които поддържат Cortex-М3 на сайта си обявяват че в последната версия нямат никакви патчове по gcc. Мен ме интересува само компилирането засега. Дебъга ще го мисля като му дойде времето.

@miro Гледай сега. Аз не споря с теб, щото нямам основа да го правя Аз питам

Щото от make файлове разбирам горе долу колкото от френски език. Знам да поздравявам и още 20-30 думи и дотам

@Zdrav Я ме открехни как започваш нов проект в eclipse, така че IDE то да ти го менажира. Значи аз ако тръгна през New->C Project, после ми се отваря какъв да е типа на проекта. Там почти навсякъде като единствен toolchain ми дава Cigwin (явно го намира на диска). И единствено в makefile Project имам възможност да задам друг toolchain. Не че имам такъв де.

Всъщност тия откривателски способности на Eclipse много ме объркват. Непрекъснато открива Cigwin-а и ми го пробутва за щяло и нещяло. А Yagarto-то което аз искам да ползвам не го открива само. Това нормално ли е, или аз съм оплел нещо като съм инсталирал?

P.S. Прецаках го Промених името на директорията на Cigwin-а. И му скрих шайбите, не може да го намери :):) Сега New->Project->C Project изглежда значително по елегантно. Сега имам само makefile project

В интерес на истината май не съм започвал съвсем начисто от отдавна. Взимам стар проект там в него се помнят настройки, ключове за извикване на arm-elf-gcc и др. удобства които съм налепил със времето:). Махам сорсовете и добавям новите. Просто така ми е по-удобно.
Освен това видях на сайта на YAGARTO че има нова версия от 11.03.2009. Аз съм с по-старата. Нямам инсталиран Cygwin покрай някоя друга среда. Не съм инсталирал и плъгина от Zylin.
Сигурно има и куп други неща които при мен са по различни. Ще взема да инсталирам това новото YAGARTO и последна версия на Eclipse и ще опитам да направя нов проект начисто. Ама ме хващаш в цайтнот. Ще гледам да отделя малко време през почивните дни. Щото и за мен е ценно да изляза от комфортната развойна екосистема в която вирее благородна микрофлора:):)

здравейте!

@miro_atc, доста интересни неща прочетох за вашата операционна система TMOS, поздравления!
откъде точно може да се изтегли и да се прегледа изходният код на системата? тук http://www.informa-dev.com/products/index.html прочетох:
TMOS is available under GNU General Public License (GPL). Anyone can download the full source code as well as the complete documentation and start using TMOS without any restrictions.

но не успях да разбера как точно да изтегля изходния код на тази система; можеш ли да дадеш малко помощ - как може да се изтегли системата? благодаря, и отново - поздравления!

дано не бъркам и това да е наистина тази система TMOS, за която беше писал по-горе, ако бъркам нещо - прощавай...

поздрави,
стоян шопов

В момента не може... навремето идеята беше за спретнато RTOS-че, щото няма нищо удачно и изпипано за малък АРМ. Но за съжаление идеята се изврати доста, вкарахме я в няколко комерсиални проекта, затова и няма как да публикувам кода, поне не целия... Сега осъзнавам че беше грешка, трябваше да си остане нещо малко, за да е красиво. Получи се грозна картинка... представи си функционалност на голяма ОС, само че окастрена до неузнаваемост и натъпкана в малко контролерче. Единственото приложение за подобно нещо е в специализирани проекти, щото в 64К флаш и 16К RAM ти правя терминал с графичен екран и пълноценен wap-браузър. Естествено ако се прави нещо подобно много по-разумно е да се направи с пълноценна ОС, а не окастрена.
Така че по-голямата част от цялата работа и да я публикувам и да не я публикувам не е разумно да се ползва без сериозна причина. Иначе с удоволствие бих отделил базовата функционалност, стига някой да има желания да я ползва.
Не го правя, щото честно казано няма голям интерес. Ето примерно тая тема, аз казвам че съм пропилял сума си и време да разучавам как се пишат make файлове, разгледал съм сума си и документации, включително изчетах една много хубава книга "Managing Projects with GNU Make, by Robert Mecklenburg". Отне ми може би месец ровене, докато изчистя и смеля най-добрите концепции, така че да пасват за ембедед приложения. Резултатът съм го публикувал (макар и на развален англисйки), мейкфайла съм го обяснил защо и как работи... но както гледам ето Цецо ще копира първия мейкфайл който му попадне, написан вероятно от някой който идея си няма как се пишат мейкфайлове, а той от своя страна взаимстван от друг подобен...


Дали са ми специфични изискванията е спорно... То винаги като става дума за контролер се налага да настройваш един куп неща, най-малкото какво и как да се компилира, как да се линква, на какви адреси и т.н. Една от причините да седна да уча и да правя сам нещата си, е че масово се разпространяват меко казано кофти мейкфайлове. Повечето смесват сорс и output, а пък тези които както обесняваш правят симетрично дърво най-често ползват рекурсивен мейк. Предполагам и Еклипс така прави. Това е масова практика и на мен ми е интересно защо всички я копират... А защо не бива да се прави така е обяснено тук: http://aegis.sourceforge.net/auug97.pdf
Ако го прочетете ще разберете че рекурсията в мейк не гарантира автоматичен контрол в порядъка на компилиране, от там при определени условия възникват "тънки" проблеми и после псуват GNU-то...
Друг често срещан проблем е коректно изграждане на dependancy-тата, особено ако се ползва препроцесора и за асемблер файлове. А пък да не се ползва според мен е мазохизъм.
Та така... на твоя въпрос защо сам си правя сам мейка, защото искам нещата ми да са направени добре. И защото не обичам да копирам чужди неща без да съм сигурен че са достатъчно добри и няма да ми затрият повече време. Друга причина е да не ползвам Еклипс или друг подобен, е че откакто го ползвам излязаха 2-3 версии и към всяка версия има версии на тулчейновете, съответни има малки или по-големи разлики в менажирането на проектите. Не е ли по-разумно веднъж да отделя примерно 20 дена и да се науча как трябва да се правят нещата веднъж за винаги. Вместо на всяка нова версия да бера ядове и губя време.
Пак ще кажа, Еклипса е Еклипс. Аз много го харесвам и го ползвам мисля пълноценно. Но това не е инструмент с който може да един програмист да избегне познаването на мейк. Несериозно е за някой който смята да използва GNU да няма представя как работи мейк. Това не може и не бива да се пропуска като знание. А пък който има подобно знание, не му трябва менажиране на проектите.
Според мен изучаването на менажирането е загубено време. Учиш нещо дето днес е така, а утре по друг начин. Като в също време отказваш да научиш нещо, което по принцип е задължително да знаеш.
Това са фундаментални неща и без тях GNU-то се обезсмисля. Просто идеологията му е такава, че не е едно цяло, а буквално хиляди инструмента, които може да ползваш по произволен начин. Майк е един от начините да стане това. Той прави от многото инструменти един оркестър. Даже нещо повече от това, щото във всеки един момент може да смените част от инструментите и оркестърът да почне да свири коренно различна музика. Просто трябва да се знае, че си имате работа с оркестър от инструменти и че трябва да ги накарате да свирят в синхрон. Иначе по-добре да си вземете един МР3 плейер с един бутон плей/стоп... поне звучи по-приятно от развален оркестър

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

Честно нямам нищо против да ползвам твоя опит, сигурен съм, че си изкопал камари с пръст докато го натрупаш. Единственото което ме притеснява, е че ще ми отнеме повече време от това с което разполагам. Опитвам се в движение да подкарм GNU при разработка на проект който има краен срок (притеснително кратък). Клиента е платил част от парите и чака Почвам да се чудя дали не трябваше да му дам една първоначална версия за тестове билдната на IAR и после да мисля за GNU версия. Но ако и следващата седмица нямам работеща среда - ще направя точно това.

Засега не успявам да схвана как да накарам еклиспа да ми изгенерира Make файла. И поради това ще си го напиша сам. Както казах проекта е прост като структура (макар че май ще е голям като код), все пък толкоз мисля ще успея да го напиша пустия Make фаил. Или поне ще успея да преправя някой че да ми върши работа. Освен маке-а имам да подкарвам още стартъп код, дебъг, линкерски файлове и пр.... та проблемите са купища.

Въпрос 1:
Замислих се върху ракурсията на Маке за която miro говори и що била лоша. Аз честно казано не си го представям по друг начин освен ракурсивно, просто мозъка ми отказва да го разбере Виждам че има дупка в идеята, ама не мога да схвана решението. Миро ще пуснеш ли малко "смляна" информация?

Въпрос 2:
Опитвам се да разгадая един маке фаил и се спъвам на следното:



Въпрос 3:
Като инсталирам yagarto имам вътре две директории с exe-та. Едната (bin) съдържа arm-elf.... exe-та, предполагам че това е версия компилирана за подръжка на ARM. Пускам ги работят. Като че ли. Другата се зове "\arm-elf\bin" и вътре има exe-та дето си носят стандартните имена (gcc, ld и пр.) Те за какво са?

Въпрос 4:
С какво да линквам? с gcc или с ld?

Миро не се съмнявам че знаеш какво правиш. Също както знам че моя подход е ограничен и ламерски. Но честно не виждам как ще се набуча на недостатъците на рекурсивния make ако ползвам проста структура за проекта(едно ниво на поддиректории) и нямам динамично генерирани сорс файлове. Според мен за дребни проекти няма защо да се главоболи човек с make. Нито съм имал случай да не ми се компилира вярно според зависимостите между файловете нито да ми вкара допълнително зависимости освен тези които съм направил аз със #include.
Единственото което имам като проблем е че при промяна само на линкер скрипта не се прави линкване наново. Но това го знам и ръчно го подкарвам.
Тоест не приемай мнението ми като критика към теб и подхода ти. Ако пътят ми минаваше през изучаването на make и аз щях да се заровя в него. Но по стечение на обстоятелствата досега съм успявал да намеря заобиколни пътища и да решавам проблемите без да пиша собствени make файлове.
Нямам намерение да се сравнявам с теб. Мога само да се уча от тебе.
И наистина недоумявам защо всеки който се захване с GNU и започва да мърмори. Хора като теб пък говорят колко сериозна е цялата работа и човек добива представа за GNU като за нещо грозно ама като му свикнеш почваш да си го харесваш. Аз не че толкова съм влюбен в него ама там се чувствам в свои води и имам контрол върху нещата, които ми трябват.
Съгласен съм и с това, че взетите наготово неща ограничават. Особено ако не можеш или нямаш време да ги надскочиш. А понякога това не се и налага.
Цецо, аз и за линкване извиквам arm-elf-gcc той си знае какво и как да извика.

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

Не знам дали го обясних добре, но повярвай ми по-добре е да се изгради една обща база данни с всички зависимости в проекта и да оставиш мейк да ги обработи. Отколкото да накараш мейк да ти обработи една част от проекта, после друга и т.н.

Рекурсивното и многокрано викане на мейк НЕ ДАВА НИКАКВИ предимства, само потенциални главоболия....



За първия израз:
1) CPFLAGS e променлива.
2) Операторът "+=" е нещо като append. Добавя дясната част към стойността на променливата. Важно е да се отбележи, че това е оператор, който прави "рекурсивна" променлива.
Малка скобка... При мейк има два вида променливи - прости и рекурсивни, коя каква се явява зависи от операторите за пресивояване. Стойността на простта применлива се "изчислява" по време на нейното присвояване (с оператор := примерно) т.е. изчислява се по време на парсването. Стойността на рекурсивната променлива се изчислява едва когато се налага, т.е. не по време на парсването на оператора.
3) -MD -MP -MF в слъчая са просто текст. Но иначе това са флагове (параметри) които ако ги подадеш на GCC (arm-elf-gcc) за даден сорс файл, то освен всичко остнало (примерно компилиране) GCC ще генерира информация за зависимости на сорс файла от други файлове. За удобство тая информация се генерира под формата на мейк-правила, щото тя наистина затова се ползва...
С две думи ако сорс файла има #include на хедъри, то GCC ще генерира правила, които гласят, че съответния сорс файл зависи от съответните хедъри. По-късно тая информация се инклудва в мейк-файла и мейк ще я използва когато трябва да реши дали да прекомпилира твоя сорс файл или да си спести труда...

По-конкретно ако те интересува може да видиш документацията за всеки един от горните флагове но приблизително те гласят "MD=make dependancy" "MP = make phony" "MF= make to file", а заради последната трябва да следва и име на файл...

4) тия флагове и всичко до тук има смисъл само ако са вкарани в някакво правило... И това обикновено е правило какво да се прави с даден сорс файл.
Правилата на мейк общо взето описват ЦЕЛ, ЗАВИМОСТИ, КВО ПРАЙМ АКО СЕ НАЛАГА.... Където целта обикновено е сорс файла, зависистотите са евентуално други файлове от което зависи, а "кво прайм" е списък от шел команди дето да се извикат и обикновено се GCC, LD, OBJDUMP, copy, delete...
Сега, за да не се налага да пишеш като хамалин, тоя файл зависи от тоя, пък ако се нала извикай GCC еди как си... се ползват автоматични променливи
Има шест основни такива, но в случая ти ползваш модификация на $@ това съответства на името на целта, което както се подразбира е името на сорс файла... Няма точно изискване какво е "цел", то е нещо абстрактно... може целите да си ги правиш само имена на файлове, или пък пълен път, или пък нещо друго... Затова и се ползват разни модификации... както ти в случая ползваш "F", което ще рече, че ако целта ти е пълно име на файл (с пътища) да се разкарат пътищата и да остане само името на самия файл...



Да обобщим:
1) "-MD -MP -MF .dep/$(@F).d" е израз който ще добави към променливата ти... и ще се преизчислява всеки път когато променливата ти се ползва...

2) ако мейк си постави за цел примерно "c:/work/test.c" и тая цел пасне на някакво правило в което се ползва горната променлива, тя ще преизчисли на:

"-MD -MP -MF .dep/test.c.d"


Сега за втория израз:

1) include си е същото което си мислиш, вмъкват се изброените отдясно файлове...
2) $(shell команда) e начин да се извикат външни програми и квото върнат се ползва...
3) командата е mkdir .dep 2 (няма то обесявам ДОС... предполагам се сещаш че mkdir изкарва квото прави, но за да не се опита мейк-а да инклудва изхода са ти сложели >/dev/null което пренасочва глупостите да не вземат да се върнат)
4) дотук inlcude-a все още нищо не е инклуднал
5) $(wildcard патерн1 патерн2 ... патернN) както може да предположиш връща списък с имена на файлове, които отговарят.... Примерно $(wildcard *.c *.h) връща всичко С и Н файлове в текущата директория.... В случая при теб патернът е .dep/*

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





Файловете са едни и същи (може да ги сравниш ако не вярваш).
По принцип правилите имена са arm-elf... защото това ти е версията на съответния инструмент -> компилатор за арм и т.н.
Но за удобство ги имаш и в "стандартните имена", Идеята е ако имаш някакъв платформо-независим проект, то мейкфайловте му ще трсят стандартен gcc и за да не налага да оправяш мейкове просто имаш наготово копия. Ако освен АРМ имаш и други gcc-версии вече ще трябва да си настройваш пътищата преди да компилираш подобни платформонезависими истори...



И в двата случая линкера е един и същ. Както казах аз предпочитам да викам gcc щото има една група опции дето не са еднакви и за асемблера и за компилатора и за линкера. Но незнайно защо тия опции не се задават по един и същ начин на всеки инструмент. Та вместо да правя различни опции, аз викам gcc и му давам опциите, пък той да се спасява и да ги преформатира според това дали вика линкер или компилатор. Имаше и други някакви предимства, но не е нещо супер... донякъде и е въпрос на вкус
Ако искаш викай LD-то директно, ако искаш остави на GCC да го вика...

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

Значи аз тва се опитах да обесня, не колко го разбирам... (не съм чак такъв разбирач, само в очите на слепите;-) )

Всеки който се захване с GNU вижда един голям брой неща и дето се викат по допотопен начин и трябва да се чудиш кое и как да ползваш. Не е като да имаш едно приложение и само да цъкаш с мишката...
За феновете на лъскавите среди ГНУ-сарите са едва ли не някакви мазохисти дето са свикнали с неудобствата и отказват да приемат колко удобни за wizard-и графичните разширения.
В действителност нещата не стоят точно така. Верно има много какво да се желае за доста от GNU-инструментите. Но като цяло няма чак такова "неудобство" и аз като работя с GNU не правя компромис с навиците си. Познавам много други среди и смело мога да кажа, че няма проблем с неудобство или производителност при GNU. Единственият проблем е, че човек трябва да си направи труда да го поразучи... Но след това всичко си идва на мястото. Човек разбира, че някои неща е по-добре да са си така както са. И няма как да бъдат подобрени чрез визуални средства. Напротив, визуалните средства ограничават възможностите.
Примерно ако имам два различни ядра дето бутват от обща памет, аз мога да направя един мейк файл, който да компилира проекта за едното ядро, да компилира другото и да линкне двата в общ имидж и да го програмира. Практически аз мога да извиквам всякакви приложения, в какъвто си искам порядък и условия. С две думи мога да правя всичко. Докато комерсиалните среди си имат някакви възможности и толкова. Не можеш да надскочиш тия възможности. Примерно IAR за ARM си е само това. Не може да го комбинираш с IAR за MSP430. Два компилатора, от една и съща фирма, но не можеш да ги ползваш съвместно, всеки с различни синтаксиси, опции и т.н. Всеки сам за себе си със собствените опции и фиксирани възможности.
GNU също може да се облече с някаква лъскава визуализация. И сигурно начинаещите ще са много щастливи. Но за хората които се занимават сериозно с програмиране това ще е по-неудобен интерфейс.

1. Относно рекурсията - дай да видя твой make фаил. Ама ако имаш някой по прост, щото много ще питам

2. Относно това със зависимостите - значи идеята е първо да викна компилатора да ми прерови сорсовете за да ги намери (зависимостите) и после му ги подавам на make за да ги изкомпилира, така ли? Ама това не значи ли че трябва да мина на два паса през компилатора?

3. Относно имената на туловете. Забелязах следната странност. В yagarto в make файла викам arm-elf-gcc (от bin). Обаче ако преименувам директорята с другите тулове (която е arf-elf), arm-elf-gcc не иска да работи. Дава ми някакво съобщение от сорта на Create process: Can't find file (или нещо подобно, пиша от домашния компютър). Т.е по някаква причина arm-elf-gcc търси нещо от другата директория (която би трябвало да има същите неща според теб). Защо? Още по странно ми е че пътя до другата директория явно е компилиран вътре в самия arm-elf-gcc, защото аз никъде нямам в make файла или някакви конфигурационни файлове обръщения към нея.

4. Относно линкването (и всякакви други работи) през gcc. Ами цялото ми объркване явно идва от факта, че аз си мислех че GCC значи GNU C Compiler. Пък то било GNU Compiler Collection

Последно вчера вечерта успях да компилирам проект и да го изпрограмирам във флаша през GDB-Jlink. Или поне си мисля че го направих. Обаче после дебъгването се омаза. Утре ще го боря.

значи аз ти доадох тоя pdf и в него има всичко... http://www.informa-dev.com/res/tmos/TMO ... 2_MAKE.pdf
Това не е последнато, в момента съм го разцепил щото нали ти казах че си организирам проектите с една APP за самото приложение, една TARGET поддиректория и в нея като поддиректории слагам нещата за спесифични контролери (в случай че проекта може да се качва на повече от един контролер) и една директория са ОС-а (ти няма да имаш такава).
В главната остава само мейкфайла .gdbinit за дебъгера но никакви сорсове... Не ти давам последния ми мейк файл щото съм го разделил на две части, едната общата, а другата в TARGET добавям флаговете според таргета. Така никога не редактирам главния мейк и при нов проект само copy&paste...
Но ти няма нужда да ги цепиш. Слагай оня от pdf-a и го редактирай за Кортекс. Все пак ти препоръчвам да не слагаш сорсове в главната директория. Така в мейк-файла само задаваш под-директориите и повече не го пипаш.
А вече във всяка сорс-директория пишеш по едно module.mk файлче (така съм ги кръстил). В него само изброяваш сорс файловете от текущата директория дето трябва да се компилират. Нищо повече.
При мен имам много видове различни "сорсове". Щото при ARM7 по различен начин се компилира чист thumb, по друг чист arm, по трети thumb+interworking и т.н. и т.н.
При кортекса предполагам ще имаш само два вида сорсове - С и Асемблер, а като те знаем май само един вид... Така че нещата ще са ти много прости. В тоя module.mk просто ще изброяваш С файловете си и евентуално под-директории за сорсове.....


Става на 1 пас, няма нужда да правиш много пасове. Просто му подаваш флагове за съответно асемблиране, компилиране ПЛЮС флаговете дето правят деп-файловете...




Възможни са много проблеми с пътищата... И аз не съм ги преборил всичките. На някои компютри не тръгва ако в пътищата има интервал... Убий ме не знам защо. То нормално да не тръгва щото интервалите не са по вкуса на лайнукса. Но пък на някои компютри работи. При това и единия и другия компютър съм с едно и също ХР-е с едно и също ягарто...
Друг проблем са наклонените... Бозата се справя и с C:/proba/proba и с C:\proba\proba но не всеки лайнукс инструмент понася подобни безобразия...
Та с пътищата кво да ти кажа има много грижи и не винаги можеш да се ориентираш от къде ти идва. АКо искаш гарантирано да нямаш проблеми - не използвай интервали и уйндовс наклонените...
Ако вече си инсталирал yagartо в "program files" (което не е добра идея както ти казах) то поне може да редактираш PATH и да замениш "Program files" с "progra~1".
Същото важи и за сорсовете - избягвай интервалите... щото влизат като пътища в разни ELF, DRAFT... и тръгваш да дебъгваш, пък то ти казва не мога да намеря еди кой си файл...
Кофти е.... кво да ти кажа. Но ако внимаваш с пътищата проблемите се заобикалят...


btw. @Zdrav ти казваш че знам много, ама не е така... има нещо дето ти май го знаеш пък аз не... Става въпрос за C++ мисля че го ползваш. Кажи как е с две думи, че вече ми писна да симулирам обекти чрез структури и луди каствания...
Не толкова как да го накрам да се компилира, с тва ще се оправя, ма въпроса е как е, струва ли си да се мъча...

След тази тема се съмнявам в много от нещата, които знам
Аз пък неусетно от C++ минавам постепенно на чисто С. Ама причините са други не че С++ е по-зле за ембедед. Чисто и просто за да обособя отделните класове и да направя организацията на проекта на С++ трябва да ми е ясно какво ще представлява проекта като цяло някъде още в самото начало. А не винаги е така. Или просто за това не винаги ми стига вътъка.
От С++ ползвам следните неща:
- Първо: организацията и дисциплината която налага С++;
- наследяване, ползвал съм и множествено наследяване;
- полиморфизъм. Много удобно се оказа в един проект където имаше много менюта, графика и юзър интерфейс;
- виртуални функции в съчетание с горното;
- абстрактни базови класове, пак в съчетание с полиморфизма;
- овърлоаднати функции;
...
и разни други дреболии, които улесняват живота като дефоулт параметри подавани на член функция например.
Не използвам:
- ексепшъни;
- RTTI;
- не използвам динамично създавани обекти, основно глобални статик обекти;
и т.н.
Идеята да ползвам С++ я наследих от един проект, който беше започнат така. Беше писан за PC. После беше правен развой на ембедед PC(DIMM PC) паралелно с развой на PC. След това платформата беше сменена на ARM7.
Като една от идеите например беше за всяка периферия да има отделен клас нещо като драйвер и когато пристигнат DIMM PC-та с различна периферия или сменим LCD контролера например просто да сменим само съответния клас.
Да ама на практика това не се получи. По ред причини историята около които е дълга и широка. Много добре пасна обаче С++ за менютата.
Въобще доста време се борих със субектно дезориентирания модел и сега намирам за по-лесно, когато правя нещо по-просто, да имитирам някои от функционалностите на С++ на чисто С. Някакси при С++ се скриват и разпръскват из множество файлове отделните части на една задача и после когато започне дебъгването ела и гледай.
Сега се задава редизайн на същото устройство с друг процесор, друг LCD контролер и куп други промени и въобще не си правя илюзията че ще пренапиша само някои неща.
Мисля че ти със сигурност ще намериш ценни неща в С++ за ембедед. Нали не изключваме възможноста да се използват едновременно С и С++ файлове в един проект. :wink
В момента на мен проблемите ми са от друго естество не С или С++, а bare metal или OS. Но това е друга тема и не знам дали е за интернет форум въобще.

Това е една от най-повтарящите се теми по мрежата от вече десетилетия .

Може би защото самият въпрос е "погрешен", дали ще е ОС или не зависи от това,
дали ще има файлова система, scheduler и подобни. Ако сам си ги направиш, може и да го
наречеш "bare metal" - и с право, защото за тебе ще е било именно това - но вече
ще е някаква ОС.

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

Инак файдата от обектния начин на мислене/програмиране и т.н. е голяма. Аз го правя
без C/C++ (имам вградена система за поддържане на обектните взаимоотношения
в DPS на runtime ниво), и доста години след като я направих се учех как по-ефикасно
да я използвам; може би това продължава и до днес (10+ години).
Та OO програмирането е добра техника. Чувал съм хора да пищят от C++ като стане дума
за обектно програмиране, но това са глупости, самото C++ е просто една от безбройните
възможности човек да програмира OO - всъщност ми е любопитно колко го правят инак,
ето Миро го прави на C, аз го правя на VPA, други?

начи аз с ООР нямам проблеми, даже ми липсва щото по-голямата част от опита ми в програмиране е там, но досега не съм подкарвал нищо на микроконтролер. И по-големият проблем беше че нямах опит конктретно с GNU CPP. Не знаех какви библиотеки ще иска да качи, как изобщо е имплементирано на ниско ниво и т.н.
И за по-сигурно почнах без С++, да имам контрол и да си знам всичко... И в началото беше ОК, справях се някак си само със структури, енъми и т.н. В един момент обаче се наложи да направя някаква базова "обектна" среда. Първо неща като CString, после списъци, колекции, map-ове. Така покрих постепенно базовите класове на MFC или STL, но без да ползвам обекти.
Само че всичко това почна да изглежда някак си грозно и колкото повече функционалност добавях, толкова по-нефункционално се получаваше.
Изобщо с чисто С всичко е наред докато ползваш 1-2 универсални структури. Но като станат много почваш да се губиш и няма оправия. Става твърде сложно за дебъгване. Ако се базирам на enum, то като дам принт на нещо по-голямо и дебъгера като разпечата всички варианти на enum-ите и се чудиш какво да гледаш. За "обектните" списъци, масиви и map-ве пък реших да ползвам void* че да мога да ги ползвам уж за всичко без постоянно да правя сложни cast-ве. Да, в сорса избягвам кастовете, обаче дебъгера като срещне void указател и до там... ако искам да видя към какво сочи пак трябва да правя кастове.
С две думи ще трябва да мина на С++, но за съжаление вече имам толкова неща без него и поне тоя проект трябва да ги приключа така, щото няма време да го преправям... То затова е важно да почнеш още от начало по правилния начин, ама нямаше кой да ме светне...


Що се отнася до въпроса "bare metal или OS" това определено е реторичен въпрос... Отговорът е 10001% OS, па независимо как ще я наречеш. Аз никога не съм имал подобна дилема и затова може и да изглеждам краен в мнението си, но пък имам претенциите на човек, който е изкълвал доста теория и не една или две книжки по въпроса.
Въпросът е коя ОС да ползваш и ако дадеш малко повече инфо какво смяташ да правиш бих могъл да ти помогна с избора. Мисля че мога да бъда безпристрастен, тъй като моята ОС автоматично отпада, щото е твърдо за SAM7/9 а на теб предполагам ти трябва нещо за LPC-та.

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

1. То май е фундаментален въпрос ->.PHONY - не мога да го разбера това каква му е идеята.

2.



-modules - тука явно трябва да опиша модулите, като всеки си е в собствена директория.
-prebuild / postbuild - тук предполагам описвам това което искам да се случи преди/след билдването. Ама под каква форма - смисъл като правила, прости shell команди или нещо друго?
-as_a_sources/аs_ai_sources/as_t_sources/as_ti_sources/csources/c_ti_sources - тука при мен май ще се трансформира само в asources/csources. Уф това беше една от причините да залитна към Cortex. До колкото разбирам тези променливи се "попълват" в вътрешните ".mk" файлове.
На останалите каква им е идеята? Не виждам да се сетват в вътрешните файлове с описанията (.mk). Тази точка след "inc_dirs := " случайна ли е?

3. Като цяло структурата на проекта трябва да е нещо от сорта:

\project
\project\module1
\project\module1\submodule1
\project\module1\submodule2
\project\module2
\project\out

Като самия маке файл трябва да е в \project. А във всяка \moduleX (респ. \submoduleX) директория трябва да имам .mk файл. В \out ще тъпче временните файлове. Прав ли съм?

А къде слагам хедърфайловете. При тая струцтура ми се струва най-логично, хедър файловете и сорсовете на всеки модул да са си наблъскани в неговата директория. А ако ги сложа във вътрешна директория напр. module\inc и module\src как да му обясня какво искам? Предполагам че за това служи променливата inc_dirs, а?

А ако имаме някакви прекомпилирани библиотеки, тях къде си разчел да ги наместваме (вероятно lib_dirs )?

4. CFLAGS += -Wa,-adhlns=$(BIN_DIR)$(subst $(suffix $<),.lst,$<) - това за какво се прави?

5. Линкерския скрипт как се прикача? Предполагам че е чрез LDSCRIPT, ама не виждам някъде да се сетва.