ARM a Makefile

[František Burian]

No možná jste nepochopili můj dotaz. Neptal jsem se na to zdali se mám 
naučit Makefile (ten už 
umím ze zkušeností s AVR i jiných projektů, a vím že se mi s ním pracuje 
lépe), šlo mi o to zdali 
pokud budu publikovat nějakou konstrukci, řekněme i se zdrojáky, zdali by 
bylo pro osazenstvo 
konference lepší kdyby to byl Makefile projekt v C::B nebo nativní projekt v
C::B. S tím souvisel i 
dotaz na adresářovou strukturu.

Jelikož je to nový procesor který se učím, chci si zavést už od počátku 
"společně-uznávaný" návyk. 
A cesty Makefile i CodeBlocksích "škrtátek" jsou si dost odlišné a znamená 
to jinak myslet při stavbě 
projektu. Proto se ptám na počátku těch zkušenějších.

Co se týče struktury, tak zatím se přikláním po radě p. Labaje k 
následujícímu:

/fw ...  složka s obsahem firmware, obsahuje Makefile, *.cbp, případně 
projektové soubory jiných IDE

/fw/src/ ... zde jsou *.c, *.S zdrojáky
/fw/include/ ... bylo doporučeno p. Labajem dávat sem headery (*.h). U 
knihovny chápu ale u exe (bin, elf) 
                       se mi zdá že to stačí mít v src.
/fw/lib/  ... zde jsou zkompilované knihovny třetích stran (*.a) (možná se 
povede i ty knihovny 
/fw/ld/ ... zde jsou linker skripty (*.ld) pro každý target zvlášť (přebírám
doporučení p. Labaje)
/fw/tmp/ ... zde se generují *.o, *.lst, *.aux pro hledání chyb v asm atd ..
.
/fw/doc/ ... zde je dokumentace chování projektu (*.tex soubory), pdf 
generován do ../bin/
/fw/bin/ ... zde je "binárka" programu (*.elf, *.bin, *.hex), případně PDF s
dokumentací chování programu

/sw ... ovládací SW pro PC (struktura podadresářů viz výše)
/dps ... desky s plošnými spoji (nesouvisí se zdrojáky, spíš jde o záznam ve
verzovacím systému projektu)
/doc ... hlavní dokumentace celé sestavy (tex)
/ds ... ? datasheety k čipům ? (autorská práva ?)

Myslíte že by to mohlo fungovat ? (Už teď vím že ne - co když budou dva 
odlišné branche pro fw s různou funkcionalitou, 
ale pro inspiraci toho co se snažím vymyslet ve volném čase by to mohlo 
stačit)

Chtěl jsem to probírat na hw-listovici ale byl jsem churav :-(

Dík,

   Franta.


---------- Původní zpráva ----------
Od: Miroslav Mraz <mraz na seznam.cz>
Datum: 26. 1. 2013
Předmět: Re: ARM a Makefile

"Naučit se psát ručně makefile je velmi významné plus, pokud to myslíte s
programováním vážně. Zase to není tak velké drama a jednou napsané
"kopyto" dobře poslouží jak pro jiný projekt, tak i při portování na
jiný typ procesoru. A už vůbec nemluvím o tom, že nejste závislý na
jednom IDE. Třeba to C::B je dobrý kus kódu, ale překlad se nastavuje na
3 různých místech a tak se výsledek může i o dost lišit.
Co se týče knihoven, u jednočipů se snažím vše, co se týče hardware
udržet na úrovni zdrojáků v rámci projektu. Vlastně je pouze důležité si
rozmyslet, kde je ta pofidérní hranice, kde končí obsluha periférií a
začíná můj vlastní výkonný kód. Vždycky musím mít na mysli, že třeba za
rok budu muset použít jiný procesor a mělo by to dát co nejmíň práce.
Takže třeba se nebát používat callback funkce, i když to není zrovna
přehledné.
Někdy se může vyplatit mít v projektu i vlastní (tedy od výrobce čipu)
stdio, math atd. a nepoužívat třeba tu newlib. U jednočipů to bývá
daleko lépe optimalizováno. Nehledě na to, že ta obecná knihovna je
přeložena s nějakými parametry a v projektu se hodí úplně jiné - pak to
vůbec neslinkujete (typicky math funkce ve spolupráci s fpu).
Verzovací systém se taky vyplatí, není na tom nic složitého, používám
SVN a i když na tom dělám sám, někdy se to hodí.

Mrazík


Petr Labaj píše v So 26. 01. 2013 v 20:41 +0100:
>  
> Proc lidi nepouzivaji Makefile? Protoze spousta lidi ani nevi, co to
> je (tim ted zrovna
> nemyslim vzorek lidi z hw.cz, i kdyz i tady se obcas vyskytuji nazory,
> ze je vhodnejsi
> pouzit predchystany example, nez se snazit problemtiku nastudovat).
> Kdyz se podivate do prakticky libovolneho fora o programovani nejakeho
> procesoru,
> tak kazda druha otazka tam je "pod Eclipse to chodi, ale pod mym XYZ
> to nejde".
> Nikdo z nich nepremysli nad tim, ze preklad je veci kompilatoru, tedy
> toolchainu,
> a ze s tim ma barevna klikaci nadstavba IDE spojitost jen okrajovou.
> 
> Konkretne:
> - knihovny prekladam predem a delam z nich jednu knihovnu (*.a)
> - knihovny jsou ulozene v pevne definovanem adresari, ktery je
> spolecny pro
> vsechny projekty
> - adresar projektu ma shodne jseno s projektem, v nem jsou
> podadresare:
> - src
> - include
> - ld
> - tmp
> - v adresari projektu je jen Makefile, vystup "projekt.elf" a soubor s
> opisem hlasek
> z prekladu "projekt.txt", vcetne vypisu o delce code a data
> - v podadresari tmp jsou *.obj, *,lst ke kazdemu modulu, "projekt.map"
> a "projekt.dis",
> coz je nejkompletnejsi mozny disassembler vysledneho projektu,
> vcetne hexdumpu,
> tedy veskera informace pro pripadne hledani
> - Makefile ma krome obvykleho "clean" jeste "clean_tmp", ktery maze
> pracovni soubory,
> ale ponecha "projekt.elf" a "projekt.txt".
> 
> Diky predkompilovanym knihovnam je build projektu velmi rychly.
> Na urovni systemu je pradnastavena volba -j pro paralelni preklad. Mym
> cilem
> vzdy je, aby jedno kolo preklad+link nikdy netrvalo dele nez 2 sekundy
> (na Linuxu, kde
> mi soucasne toolchainy, natr. pro STM32, chodi vyrazne rychleji nez na
> Windows).
> Pokud by to melo u hodne velkeho projektu trvat dele, je treba se
> zamyslet a rozlozit to.
> Knihovny pouzivam jen naprosto minimalne, vetsinu veci si radeji
> napisu sam a vim,
> co a jak tam je. A muzu to snadno preportovat jinam.
> Vyjimkou jsou hodne komplexni periferie jako USB a Ethernet.
> S verzovacimi SW jsem se nikdy neszil (coz povazuji za svou chybu).
> Takze verzovani
> pomoci pojmenovanych *.zip.
> 
> PL
> 



_______________________________________________
HW-list mailing list - sponsored by www.HW.cz
Hw-list na list.hw.cz
http://list.hw.cz/mailman/listinfo/hw-list"
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20130126/8dfc9bf9/attachment.htm>