ARM a Makefile

[hutta.j na seznam.cz]

Pokud IDE nema funkci generovani makefile , muze byt napsani makefile 
slozitejni nez napsani samotneho programu.
Podival jsem se jak je to z podporou makefile u MDK-ARM, jak compiler tak 
linker lze volat z prikazoveho radku, cili pouziti makefile nic nebrani, ale
IDE ( uVision) nema prikaz pro vygenerovani makefile.
Kdyz se podivam na compiler control string, dost pochybuji, ze nekdo bude  
makefile tvorit rucne.

Hutta
 

---------- Původní zpráva ----------
Od: Petr Labaj <labaj na volny.cz>
Datum: 26. 1. 2013
Předmět: Re: ARM a Makefile

"

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

 
 " 
----- Original Message ----- 

From: František Burian(mailto:BuFran na seznam.cz) 

To: hw-list na list.hw.cz(mailto:hw-list na list.hw.cz) 

Sent: Saturday, January 26, 2013 7:58 PM

Subject: ARM a Makefile



Zdravím osazenstvo,

  Mám tu záludné dotazy na sobotní večer. 

  Všechny example které tu proběhly jsou nativní pro Code::Blocks. Chtěl 
bych se zeptat (čistě z neznalosti) 
z jakých důvodů nikdo nevytváříte projekt jako Makefile. Myslím že pro 
možnost kompilace pod různými OS 
(a že tu jsou i lidé z Linuxových luhů a hájů) by byl Makefile lepší volbou.
Zakládat nový projekt na kterém v 
budoucnosti může pracovat více lidí jako Makefile, nebo jako standardní C::B
projekt ?

  Druhý dotaz směřuje k zakládání projektu - když bych chtěl od počátku 
založit projekt tak, aby jej snadno 
chápali druzí, aby zkušení v něm dobře "četli", aby šel například 
zkompilovat i bez Code::Blocks, jakým způsobem 
bych měl rozčlenit adresářovou strukturu ? Rád bych věděl Vaše názory jak 
zakládáte své projekty, případně 
jak členíte strukturu. Řekněme že se jedná o středně rozsáhlý projekt, kde 
bude komunikace s PC, nějaké UI s 
"točítkama" pro uživatele, nějaká matematika. Vše v rámci ARM 
mikrokontroleru (STM32F1 nebo STM32F4). 

  Třetí dotaz směřuje též k založení a "znovupoužití" projektu někým jiným -
jedná se o stahování a instalaci 
periferních knihoven, ve kterých jsou změny oproti originálu. Přikládat a 
verzovat tuto knihovnu společně s 
projektem, nebo raději napsat uživateli postup odkud stáhnout a co kde a jak
přeplácnout a modifikovat v tom 
originálu. Já bych byl pro první variantu, ještě nevím zdali to není rozpor 
s licencí (musím prověřit) ale zdá se 
mi to přístupnější většímu počtu uživatelů. (na zprovoznění by stačilo mít 
provozuschopný toolchain a jen 
stáhnout zdrojový kód z SVN). Uvažujme situaci jeden projekt (tedy NE 
situaci kdy knihovnu využívá vícero 
projektů)

Dík za tipy.

  Franta.
"
"
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20130126/181e11b7/attachment.htm>