Основната идея на мейк са "целите". Предполагам си ги разбрал как се описват с двуеточие, но за всеки случай един убав пример:



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

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

Но не винаги целта непременно трябва да е файл. Примерно "make clean" не означава че ти трябва някакъв файл с име "clean". Даже може да се получи кофти ако случайно имаш такъв файл и неговата дата пасне на правилата за clean и тогава мейк ще си помисли че целта му е изпълнена и няма да извика никакви команди.Та за да се избегнат подобни недоразумения е добре да си маркираш като .PHONY всички цели дето не са файлове, а нещо друго като скрипт или каквато там абстракция искаш.






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



Да това са ти модулите на най-високо ниво... Каквото добавиш тук, то ще го търси като поддиректория и ще инклудне module.mk от тая директория.
Ако имаш под-директори на тия под-директории трябва в съответния module.mk да имаш примерно следното:



т.е. в local_module първо изброяваш локалните под-модули, после им добавяш пътя към тях и чак тогава ги натрупваш към глобалната променлива. За удобство навсякъде където попълвам имена на файлове или директории ги попълвам без пътища, а после чрез макроса changepath им добавям пътя...




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


Да много видове сорсове.... И да попълват се във всеки module.mk с конкретните сорсове...




inc_dir си се ползва. Това е за include директории. Аз поради ред причини хедър файловете си ги държа там където са ми С-файловете. Ако съответния модул съдържа хедъри дето трябва да се ползват от други, слагам следното в module.mk:

#add current directory to include path
inc_dirs += $(subdirectory)

И вече хедърите стават видими навсякъде. Не го правя за всеки модул по разбираеми причини. Примерно ОС-а ми главната му директория са все системни хедъри и файлове и затова ги добавям в пътя, но някои под-директории дето са в приложението не искам да се виждат навън. Само в текущата директория... В краен случай предпочитам да сложа пътя в #include "../ala/bala/header.h"


libraries :=
Това е в случай че си компилираш библиотечки сам (аз още не ми се е налагало...)

cdefines :=
adefines :=
Това е ако искаш от тук да си вкараш "#define нещо_си". И това не съм го ползвал.... Предпочитам да си ги напиша изрично в някой хедър вместо да ги подавам така...



Абсолютно.... Може да си правиш каквото искаш дърво с модули с колкото искаш нива надолу... Трябва само във всяка директория да имаш .mk файл, който общо взето е доволно прост - само изборява какво се добавя.... Ех вика се и оня макрос евентуално и се натрупва към някоя от глобалните променливи.



Почти... аз сорс и хедър си ги слагам в една и съща директория - тая на самия модул. Не знам защо, но така ми се вижда най-чисто. Всеки сорс файл от модула вижда всеки хедър от същия модул просто щото са му в локалната директория. То не случайно компилатора първо търси в текущата и чак ако не намери тръгва да търси инклуд директории....
Не знам защо дургите разделят на едно място сорсове на друго хедъри... Не го разбирам това...
Но ти може да си организираш както искаш нещата. Ако искаш да си правиш директория само с хедъри - къв ти е проблема? Тя ще си е пак модул и ще си има .мк файл в който ще има само :
inc_dirs += $(subdirectory)
без да изброяваш никакви сорсове....



да, макар че на мен още не ми се е налагало


виж хелпа на съответните флагове... да не мислиш че аз ги помня
-W по принцип е за warnings -Wa май беше да уорнигс за Алл..... Демек за щяло и нещало ще имаш предупреждения и докато свикнеш ще е зор... Щот аз си мислих че знам С, ма като видях какви warning дава....

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

Ясно. Само че сме се разминали в писането. Бях добавил още един въпрос как викаш линкерския скрипт.

Всъщност досега не успях да открия читав линкерски скрипт за STM32. Единствения на който попаднах има разни неща дето ме смущават. Основно ония секции с много "PROVIDE" в тях. От какъв зор описват всички регистри в линкерския скрипт????

ld --verbose отпечатва линкерския скрипт, който се ползва по подразбиране, в случай че не е зададен друг.

да, предавам го чрез променлива щото нали ти казах че таргет процесора ми може да е различен... И в моята TARGET директория като поддиректориии имам хедър, скриптове и тем подобни дето са модифицирани за конкретното CPU... иначе в самата TARGET няма сорсове, само следния .мк файл:



Тук интересното е че не вкарвам всички поддиректории ами само една, щото само за един таргет компилирам в един момент... Кой точно се задава чрез MCU_CHIP, съотвтно трябва да имам поддиректория с такова име... и скрипт с името на проца и так далше...

На теб едва ли са ти нужни подобни номера, просто сетваш LDSCRIPT със съотвения файл и си готов...




Нямам идея защо го правят с PROVIDE... Нормално всеки си прави един или няколко H-файла дето си декларират регистрите на чипа. Аз в тоя линкерски скрипт не виждам нищо за линкера... само дефиниране на символи.... Да не би да не гледаш самия линкерски скрипт, ами някакъв инклуд файл за линкреския скрипт?
PROVIDE за мен има смисъл когато адреса се изчислява от линкера. Примерно след като задели за статичните променливи да си сложиш символ с адреса на свободната памет. Това няма как да го направиш чрез #define в h-файл. Обаче те тука дефинират константни адреси.... Не знам.. не им разбирам идеята. Иначе ясно - дефинират си определени регистри.

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

аааа с това трябваше да почнеш. Аз хубаво си инициализирам сам LDSCRIPT, ама на кой да му хрумне че и PROJECT не е инициализирана :):) И като напиша make се получаваха едни безумия

Относно линкерския скрипт - ами да, тоя е част от един комплект от 3 файла. Ето ги и другите два. Ама там нещата изглеждат горе долу нормални. Засега.

Следващ проблем компилира се до ниво bin. После обаче nm ме заплюва със следното:


След това и size ме наплюва аналогично:


Явно пак не му се връзват пътищата. Интереснето е че в Command Prompt са ми достъпни туловете през path, както arm-elf-, така и простите имена.

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

най-добре отваряш един команд промпт, отиваш в директорията на проекта и пишеш:

>make all -d

при което ще ти изкара малко дебъг информация от сорта:

а са де. В същия тоя промпт, като си напиша "arm-elf-objdump --version" си работи, т.е. пътя си е ок.

верно шах с пешката

Нямам идея от какво е, но както казва един приятел "като не знайме кво прайме, прайме квото знаем..."

Та ти предлагам да си оправиш пътишата, в същата конзола пишеш
>path

При мен изглежда така:


Идеята е ако случайно директорията в която ти се намира objdump съдържа интервал в името си, както в моя случай по подразбиране беше "program files" и аз съм го сменил на "progra~1"...


С две думи ти като викаш objdump от промпта windowsa си го намира както трябва, обаче sh-то може да не е толкова умно...

Ако го сложиш в кавички не става ли?

Не става Бате.

Миро, тулчейна е във C:\ARMGCC\bin или C:\ARMGCC\elf-bin. И двете са в правия път Остава тирето да го мъчи, ама едва ли.

Най-тъпото е че в същите директории са и gcc, ld а те работят. Не че това е най-важния проблем де. Общо взето да elf и bin го докарах. Утре продължавам борбата с дебъгера.

уфф....

Значи влез в SH, ама гледай да е същото SH дето се ползва от make, т.е. C:\ARMGCC\utils\sh.exe

ще ти изкара някакъв промпт и там може да праскаш команди....

Първо дай:
>echo $PATH

ЗАБЕЛЕЖКА: тва ти е лайнукски шелл и малки/големи букви има значение.... говоря и за команди и за имена на файлове и всичко.... И това важи и за модулите и за сорс-файловете, абе навсякъде!

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

После може да провериш къде ти намериа командите... Най-лесното за което се сещам е примерно:

>hash arm-elf-gcc
>hash

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


Естествено трябва директорията с тулчейна да е в $PATH на SH-то... Може да пробваш да извикаш:

>arm-elf-objdump --version
>hash


Не се сещам за друго... бахти проблема да не може да намери туловете

едит: абе сетих се и друг вариант.... да викаш командите с пълния път..., т.е. това:

TOOLCHAIN_PREFIX = arm-elf-

да замениш с:

TOOLCHAIN_PREFIX = C:\ARMGCC\elf-bin\arm-elf-


и така вече ако не го намери, вземаш една пушка и ...

Бинго. Пътя на sh е съвсем различен от този на бозата, както се вижда от картинката. Въпроса е къде се сетва пътя на sh, защото аз не успях да намеря къде да го сторя.



Това няма да реши проблема. Аз нямам проблем с извикването на туловете от make, те се намират спокойно. Проблема е когато маке вика тул който вика sh който вика нещо друго. Или поне така си мисля. Защото objdump, nm и size викнати от промпта на бозата:



.... си работят нормално! Но извикани от sh промпта - Тц.

А защо тука използваш ">" между двата файла. При мен го пиша само с интервал между тях. Но аз го правя от:
Project->Properties->C/C++Build->Settings->BuildSteps->Post Build Steps
Не знам там от кой шел се извиква.

Относно описването на регистрите с PROVIDE в линкерския файл, това е просто още един начин. Преди време правих сравнение между двата начина този

и този

Разликата доколкото си спомням е че при втория начин понеже символното име се явява като extern, компилатора винаги слага адреса в литерал пула и го зарежда в регистър с четене от там. Докато при първия вариант в някои случаи,например изключена оптимизация, компилатора генерира адреса като константа в кода и ако си забелязал в ARM асемблера това става с две-три аритметични инструкции. Щото 32 битова константа не може да се кодира в 32 битова инструкция. Там имаш само т. нар. "24 bit shift immediate constant". Всъщност може би така се печели само малко от размера на кода. Не съм съвсем сигурен.
Друга разлика която се сещам е че не се налага да инклудваш хедър файл с декларации на регистри създавайки по този начин зависимост между този файл и почти всички файлове от проекта.

Ей намерих го проблема. Всъщност не намерих проблема, предполагам че се дължи на някаква глупост при компилацията на "sh". Но поне намерих как се лекува.

Значи проблема е че като се стартира sh той взима PATH на бозата и се преконвертира до неговия си формат. При тази операция обаче решава да се прави на умен и ако има директори които са в едно дърво с неговата си директория (на sh-a), по неизвестни причини премахва абсолютния път и го заменя с относителен.

Например на мен toolchain-а ми е в c:\armgcc. Вътре си имам \bin и \arm-elf директории където са ми самите тулове (gcc и пр.). Имам и директория \utils където са маке инструментите. Що съм я сложил там - ами щото make ползвам само за това. В пътя на бозата имам c:\armgcc\bin;c:\armgcc\arm-elf;c:\armgcc\utils. А като тръгне това говедо, си прави неговия път да е: \bin:\arm-elf:\utils. Т.е всичко е релативно спрямо c:\armgcc.

То всичко това добре, ама после с тия реалтивни пътища глупака не може да се оправи (ако и той да си ги е правил). Като изнесох \utils (т.е. негоавата директория) извън c:\armgcc и се оправи. Сега неговия път няма релативни пътища вътре.

Дивотия. И после питайте що хората не обичат GNU. Цяла сутрин за нещо тъпо и елементарно. И можеш ли да прочетеш някъде що се получава така. Не. Щото някой е компилирал накриво.