ARM a Makefile

Neděle Leden 27 10:40:17 CET 2013

Určitě bude fungovat, když přiložíte jednoduchý textový soubor s popisem 
adresářů. Buď to /fw, nebo do /fw/doc.

Každý projekt to má trošku jinak a je velmi užitečné, když má projekt 
specifikovanou adresářovou (hmm, nebo dneska složkovou?) strukturu, 
které se drží. Ani moc nezáleží na tom, jak ve skutečnosti vypadá.

Přikláním se k makefile (gnumake). Sic nástroj nedokonalý, ale rozšířený 
a pracuje snad na všech platformách. A dají se udržet změny v 
parametrech kompilátorů a podobně na snesitelné míře různorodosti (občas 
je potřeba přeložit kód jinak).

Pokud půjdete cestou IDE, pak je nutné aby všichni ostatní pracovali v 
tom samém IDE a z důvodu nastavení voleb pro překlad sdílely stejné 
nastavení. Ještě jsem nezažil, aby se nastavení neustále vzájemně 
nepřepisovalo a přináší spoustu problémů pro ty, co používají pro vývoj 
specifičtější nástroje (VIM, EMACS ale i eclipse).

ced

Dne 26.1.2013 22:46, František Burian napsal(a):
> 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
>
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list