<html><body>No možná jste nepochopili můj dotaz. Neptal jsem se na to zdali se mám naučit Makefile (ten už <br>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 <br>pokud budu publikovat nějakou konstrukci, řekněme i se zdrojáky, zdali by bylo pro osazenstvo <br>konference lepší kdyby to byl Makefile projekt v C::B nebo nativní projekt v C::B. S tím souvisel i <br>dotaz na adresářovou strukturu.<br><br>Jelikož je to nový procesor který se učím, chci si zavést už od počátku "společně-uznávaný" návyk. <br>A cesty Makefile i CodeBlocksích "škrtátek" jsou si dost odlišné a znamená to jinak myslet při stavbě <br>projektu. Proto se ptám na počátku těch zkušenějších.<br><br>Co se týče struktury, tak zatím se přikláním po radě p. Labaje k následujícímu:<br><br>/fw ... složka s obsahem firmware, obsahuje Makefile, *.cbp, případně projektové soubory jiných IDE<br><br>/fw/src/ ... zde jsou *.c, *.S zdrojáky<br>/fw/include/ ... bylo doporučeno p. Labajem dávat sem headery (*.h). U knihovny chápu ale u exe (bin, elf) <br> se mi zdá že to stačí mít v src.<br>/fw/lib/ ... zde jsou zkompilované knihovny třetích stran (*.a) (možná se povede i ty knihovny <br>/fw/ld/ ... zde jsou linker skripty (*.ld) pro každý target zvlášť (přebírám doporučení p. Labaje)<br>/fw/tmp/ ... zde se generují *.o, *.lst, *.aux pro hledání chyb v asm atd ...<br>/fw/doc/ ... zde je dokumentace chování projektu (*.tex soubory), pdf generován do ../bin/<br>/fw/bin/ ... zde je "binárka" programu (*.elf, *.bin, *.hex), případně PDF s dokumentací chování programu<br><br>/sw ... ovládací SW pro PC (struktura podadresářů viz výše)<br>/dps ... desky s plošnými spoji (nesouvisí se zdrojáky, spíš jde o záznam ve verzovacím systému projektu)<br>/doc ... hlavní dokumentace celé sestavy (tex)<br>/ds ... ? datasheety k čipům ? (autorská práva ?)<br><br>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, <br>ale pro inspiraci toho co se snažím vymyslet ve volném čase by to mohlo stačit)<br><br>Chtěl jsem to probírat na hw-listovici ale byl jsem churav :-(<br><br>Dík,<br><br> Franta.<br><br><p>---------- Původní zpráva ----------<br>Od: Miroslav Mraz <mraz@seznam.cz><br>Datum: 26. 1. 2013<br>Předmět: Re: ARM a Makefile</p><br><blockquote>Naučit se psát ručně makefile je velmi významné plus, pokud to myslíte s<br>programováním vážně. Zase to není tak velké drama a jednou napsané<br>"kopyto" dobře poslouží jak pro jiný projekt, tak i při portování na<br>jiný typ procesoru. A už vůbec nemluvím o tom, že nejste závislý na<br>jednom IDE. Třeba to C::B je dobrý kus kódu, ale překlad se nastavuje na<br>3 různých místech a tak se výsledek může i o dost lišit.<br>Co se týče knihoven, u jednočipů se snažím vše, co se týče hardware<br>udržet na úrovni zdrojáků v rámci projektu. Vlastně je pouze důležité si<br>rozmyslet, kde je ta pofidérní hranice, kde končí obsluha periférií a<br>začíná můj vlastní výkonný kód. Vždycky musím mít na mysli, že třeba za<br>rok budu muset použít jiný procesor a mělo by to dát co nejmíň práce.<br>Takže třeba se nebát používat callback funkce, i když to není zrovna<br>přehledné.<br>Někdy se může vyplatit mít v projektu i vlastní (tedy od výrobce čipu)<br>stdio, math atd. a nepoužívat třeba tu newlib. U jednočipů to bývá<br>daleko lépe optimalizováno. Nehledě na to, že ta obecná knihovna je<br>přeložena s nějakými parametry a v projektu se hodí úplně jiné - pak to<br>vůbec neslinkujete (typicky math funkce ve spolupráci s fpu).<br>Verzovací systém se taky vyplatí, není na tom nic složitého, používám<br>SVN a i když na tom dělám sám, někdy se to hodí.<br><br>Mrazík<br><br><br>Petr Labaj píše v So 26. 01. 2013 v 20:41 +0100:<br>> <br>> Proc lidi nepouzivaji Makefile? Protoze spousta lidi ani nevi, co to<br>> je (tim ted zrovna<br>> nemyslim vzorek lidi z hw.cz, i kdyz i tady se obcas vyskytuji nazory,<br>> ze je vhodnejsi<br>> pouzit predchystany example, nez se snazit problemtiku nastudovat).<br>> Kdyz se podivate do prakticky libovolneho fora o programovani nejakeho<br>> procesoru,<br>> tak kazda druha otazka tam je "pod Eclipse to chodi, ale pod mym XYZ<br>> to nejde".<br>> Nikdo z nich nepremysli nad tim, ze preklad je veci kompilatoru, tedy<br>> toolchainu,<br>> a ze s tim ma barevna klikaci nadstavba IDE spojitost jen okrajovou.<br>> <br>> Konkretne:<br>> - knihovny prekladam predem a delam z nich jednu knihovnu (*.a)<br>> - knihovny jsou ulozene v pevne definovanem adresari, ktery je<br>> spolecny pro<br>> vsechny projekty<br>> - adresar projektu ma shodne jseno s projektem, v nem jsou<br>> podadresare:<br>> - src<br>> - include<br>> - ld<br>> - tmp<br>> - v adresari projektu je jen Makefile, vystup "projekt.elf" a soubor s<br>> opisem hlasek<br>> z prekladu "projekt.txt", vcetne vypisu o delce code a data<br>> - v podadresari tmp jsou *.obj, *,lst ke kazdemu modulu, "projekt.map"<br>> a "projekt.dis",<br>> coz je nejkompletnejsi mozny disassembler vysledneho projektu,<br>> vcetne hexdumpu,<br>> tedy veskera informace pro pripadne hledani<br>> - Makefile ma krome obvykleho "clean" jeste "clean_tmp", ktery maze<br>> pracovni soubory,<br>> ale ponecha "projekt.elf" a "projekt.txt".<br>> <br>> Diky predkompilovanym knihovnam je build projektu velmi rychly.<br>> Na urovni systemu je pradnastavena volba -j pro paralelni preklad. Mym<br>> cilem<br>> vzdy je, aby jedno kolo preklad+link nikdy netrvalo dele nez 2 sekundy<br>> (na Linuxu, kde<br>> mi soucasne toolchainy, natr. pro STM32, chodi vyrazne rychleji nez na<br>> Windows).<br>> Pokud by to melo u hodne velkeho projektu trvat dele, je treba se<br>> zamyslet a rozlozit to.<br>> Knihovny pouzivam jen naprosto minimalne, vetsinu veci si radeji<br>> napisu sam a vim,<br>> co a jak tam je. A muzu to snadno preportovat jinam.<br>> Vyjimkou jsou hodne komplexni periferie jako USB a Ethernet.<br>> S verzovacimi SW jsem se nikdy neszil (coz povazuji za svou chybu).<br>> Takze verzovani<br>> pomoci pojmenovanych *.zip.<br>> <br>> PL<br>> <br><br><br><br>_______________________________________________<br>HW-list mailing list - sponsored by www.HW.cz<br>Hw-list@list.hw.cz<br>http://list.hw.cz/mailman/listinfo/hw-list</blockquote></body></html>