Здравейте, имам два въпроса.

1. Всички примери, в папка examples, са с един main.c и поддиректория builg/gcc, в която е мейк-файлът. Не успявам до добавя още фаилове за компилация, в базовата директория на проекта - където е main.c. В прикачените файлове се виждат промените по мейк-файла и съдържанието на новия файл, който искам да добавя за компилиране. Чудя се, защо не намира board.h в keyboard-lyghting.c, като е добавен по същия начин, както и в main.c?

2. С кой пример за USB мога да тествам някаква базова функционалност на интерфейса?

До сега не съм ползвал USB, ще трябва да се осъществи трансфер на няколко байта от и към компютър. Някакви препоръки към документи, с прочита на които да се влезе бързо в материята?

1) не виждам прикачени файлове

2) зависи какво точно искаш, но на първо четене виж примерите за CDC

Добре, ще го видя. Имам още ден-два работа, доде стигна до там, но да не пускам 2 тема. Като го подхвана, ще пиша пак, при нужда. Благодаря!

Ей най-накрая да видя някой начинаещ да бачка с лайнукс и гцц

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

Иначе ти гърми при компилация на keyboard-lighting.c щото си инклуднал board.h а той не знае къде да го намери.... демек няма го в инклуд пътищата.

Добре, ще ти пратя почти първоначалната версия на мейкфайла. Добре за инкуд пътищата, ама тогава main.c защо се компилира? В мейкфайла никъде не видях да указват кои фаилове ще се компилират, но това може и да е, защото многото маймуни там не ми говорят нищо.

дай една по една маймуните да ги научим да говорят

Първо в мейкфайла има правила. Правило е ред с две точки, примерно:



Грубо казано правилото гласи, че ако трябва да се направи "all" трябва да се направят $(bin).... и т.н. Когато пускаш make обикновено задаваш какво трябва да се направи. Примерно "make all" или "make clean" и т.н. В случай че напишеш само "make" в конзолата се взема първото срещнато правило от мейкфайла. Затова не случайно правилото за "all" e обикновено първото правило в мейкфайла.
Сега, нещата дето започват с $() са променливи и за да разбереш какво всъщност гласи контретното правило трябва да ги заместиш със стойността им. Тук обаче трябва да знаеш, че мейкфайла се обработва на два паса. На първи пас се парсва, вадят се правилата и се сортира всичко, на втори пас се изпълнява.
Това е важно, защото като присвояваш стойност на променлива имаш непосредствено присвояване ":=" и индиректно с "=" както "+=" и т.н. Разликата е, че непосредственото присвояване се изпълнява още на първи пас, т.е. изчислява се дясната страна и стойността й се записва в променливата веднага. Докато в другия вариант, просто се запомня дясната част, без обаче да се изчислява. Изчислението се прави чак когато ни дотрябва стойността на променливата. Примерно ако кажеш че "а=$(b)" ще се запомни че променливата "а" е равна на "b" и толкоз. По-надолу в мейкфайла стойността на "b" може да се промени и това ще се отрази и на "а" защото "a=b"...

Да се върнем на


Ако потърсиш bin и obj, ще видиш че им се присвояват две константи със същото име. Съответно като тръгнем да правим "all" ще трябва да направим и "bin" и "obj", което значи че и за тях трябва да има някакво правило и то е малко по-надолу:



Това правило гласи, че bin и obj зависят от "" (нищо), демек не зависят от нищо. Обаче когато под правилото има един или повече редове навътре с табулация това са команди, които мейк трябва да изпълни. Така като търсим правило за "bin" ще трябва да изпълним и mkdir с параметър името на праволото ($@), т.е. ще извикаме "mkdir bin". Демек тия две правила са за да направим двете директории дето може би ще ни трябват...

После стигаме до $(MEMORIES) на което се присвоява flash, обаче по-долу с един for each се вика една процедура RULES на която като първи параметър се подава стойността демек "flash". Но ако $(MEMORIES) имаше повече от една стойност щеше да се извика повече от един път за всяка стойност.
Дефиницията на $(MEMORIES) е между define и endef... Там където ползват $(1) заместваш с първия параметър. Има и едно правило:


Така че като се извика RULES с flash правилото от "$(1): ..." ще стане на "flash: ...". Демек почнахме от "all" то изисква $(MEMORIES) което пък е равно на flash демек ще стигнем до горното правило, което пък зависи от някакви други неща и т.н. и т.н. Ще те оставя малко да се подзвериш сам

Идеята, която трябва да схванеш е, че има правила кое от кое зависи. Обикновено ти трябва някакъв изходен файл (hex или bin) той се прави с една или повече команди (objcopy примерно). Но преди да извикаш тия команди трябва да имаш съответните object (.o) файлове. Затова трябва да има правило, че изходния файл зависи от обектните файлове. И отдолу са комнадите как от обектни файлове да се направи изходния файл.
Всъщносто говоря глупости... изходния файл зависи от elf-файла, а елф-файла зависи от обектните файлове, които пък от своя страна зависят от разни сорс файлове.
Тия зависимости са нужни за първото компилиране, линкване и т.н. При повторно обаче само се проверяват правилата. Демек трябва ни all, той зависи от изходния файл, обаче вече имаме изходен файл а и всичко от което той зависи вече го има и нищо няма да се прави. Нормално, след като имаме всичко защо трябва да се прави нещо?

Сега ако си ме разбрал дотук, вече би трябвало да схванеш защо не се прави както ти беше почнал - т.е. да слагаш сорс файлове директно в командата на някакво правило. Както казах първия път правилото ще сработи и ще му се извикат командичките, втория път обаче духаш супата с твоя сорс... дори и да го редактираш то няма да се компилира. Затова не ги слагай там, виж къде се слагат сорсовете, обикновено е променлива... (подсказка - виж за main.*). Тая променлива участва в разни правила, които ти гарантират че като редактираш дадения сорс файл ще се компилира каквото трябва. Ех, поне може да се надяваш, щото освен самия файл трябва като редактираш и някой хедър от който зависи пак да се прекомпилира. С тоя мейкфайл обаче това няма да стане


Всичко това е относно компилирането.... а грешката както ти казах е друга причина... Като начало махни маймунката пред командата $(CC). Така ще виждаш с какви параметри се вика компилацията. Пътищата за инклуд се задават с "-I" виж какви пътища подаваш и дали въпросния board.h е в тях. Най-вероятно не е, щото иначе нямаше да реве. А не е, защото може би трябва да му го добавиш в съответната променлива за инклуд пътища....

А защо main.c се компилира? Вероятно в main.c има #include... само на хедъри, чиито пътища са добавени с "-I" опцията

Благодаря много за подробното обяснение! Аз разбирам някои работи, колкото да си компилирам мой проект, ама на чуждо писане много не се оправям, синтаксисът ми се струва трудоемък и не съм виждал нужда да отделя толкова време, за да го науча.
Не се бях сетил да махна @, пред компилирането, помогна доста. Вижда се, че нужната директория е добавена в инклуд пътищата на компилатора. Добавих си и @echo в таргетите и се вижда, че първо се вика компилаторът с други параметри. Не съм сигурен, ще успея ли да подкарам правилно нещата за бързо време, а време няма. Ако шефовете ме разберат с какво се занимавам, едва ли ще се очаровани. Утре ще опитам пак, лека вечер, отивам да карам колело

Намерих го, трябвало е да се добави само името на обектния файл:

# Objects built from C source files
C_OBJECTS += main.o keyboard-lighting.o
В един от таргетите долу, незнайно как за мен, се компилира всеки отделен .c файл, с отделно извикване на компилатора. За името на конкретния сорс/обектен файл, се използват автоматични променливи ($@, $<). Доколкото аз разбрах, би трябвало използването на автоматични променливи да извлича само имената на фаиловете, без да ги инициализираш. Предполагам, че тук обектните фаилове се задават изрично, тъй като в отделни директории се разполагат .с и .о фаиловете. Е това е описанието на този таргет:

$$(C_OBJECTS_$(1)): $(OBJ)/$(1)_%.o: %.c Makefile $(OBJ) $(BIN)
@echo "Compiling $$< to $$@"
$(CC) $(CFLAGS) -D$(1) -c -o $$@ $$<

Не разбрах какво прави тук повторното извикване на Makefile, но пък и други неща не разбрах. Благодаря за помощта! След някой ден ще пиша, като изскочат ядове с USB.

Има една книжка "managing projects with gnu make"... някой от този форум ми я беше препоръчал, ама преди много време и не знам дали ще намериш темата или линка. В краен случай мога да я кача някъде... Ако я прочетеш много неща ще ти станат ясни, но не е задължително да я четеш де, ще ти е полезна и само за справки. Примерно интересувате какво прави еди коя си автоматична променлива - отваряш pdf-a, search.... четеш два реда и ти става ясно



С-файловете се компилират един по един, така е при ГЦЦ. А се компилират защото има правило в мейкфайла ти


Променливите са за удобство и да избегнеш тафталогията.... Иначе може и без променливи, но всеки файл трябва веднъж да го споменеш в списъка с правила, втори път трябва го имаш и в командите за викане на компилатора, линкера и т.н. Ще е голямо писане.
За да се избегне това правилата и командите се пишат с променливи и повече не бараш там, а добавяне/премахване на сорс го правиш само при инициализация на съответната променлива. Т.е. редактираш само на едно място, еднократно...




Значи в първия ред от правилото нямаш "извиквания", а само зависимости. В случая е шаблонно правило защото имаш два пъти двуеточие. Но в крайна сметка правилото гласи че което отговаря на шаблона зависи от нещата след последното двуеточие. Като под "зависи" разбирай че ако се промени нещо в дясната част, трябва да се направи и лявата част, за което под правилото с табулация имаш изброени команди как се прави.
Казано простичко обектните файлове в ляво, зависият от с-файловете и от мейкфайла. Ако пипнеш мейкфайла или с-файловете, това ще принуди мейк да изпълни командичките отдолу, за да генерира наново съответните обектни файлове. Аз по принцип не съм привърженик да се редактира мейкфайла, затова и по принцип не го слагам в зависимостите. Но в случая хората са решили да се застраховат.... може да редактираш мейкфайла, примерно да смениш опициите за компилация, като извикаш мейк след това той ще види че е пипнат файла и ще знае какво да направи

Е аз оставам с впечатлението, че редовете:
$$(C_OBJECTS_$(1)): $(OBJ)/$(1)_%.o: %.c Makefile $(OBJ) $(BIN)
@echo "Compiling $$< to $$@"
$(CC) $(CFLAGS) -D$(1) -c -o $$@ $$<
се изпълняват 2 пъти - за всеки от сорс фаиловете. В мой проект, ако ще компилирам няколко сорс файла, пиша:
C_FILES=main.c file2.c file3.c
$(CC) $(C_FILES) ...
и компилаторът се вика веднъж: gcc main.c file2.c file3.c. ...

В случая, сякаш се вика така:
gcc main.c ...
gcc file2.c ...
gcc file3.c ...

Е това вече са подробности де. Още веднъж благодаря за помощта! Налага се да го оставям това и да се захващам с други работи.

Нещо си се объркал.... GCC може да компилира само по един сорс файл наведнъж. То по принцип всеки Ц-компилатор трябва да е така, защото по стандарт имаш compilation unit и отделните с-файлове трябва да се компилират *независимо* един от друг.

Иначе ако те интересува колко пъти мейк вика и защо вика нещо си може да добавиш "-d" опция и ще ти покаже доста подробности....
Примерно:
make all -d

Миро, леко уточнение - GCC всъщност е фронд енд, парсва командния ред и вика съответно каквото трябва - компилатор за съответния език, асемблер, библиотекар, линкер т.е. компилира и по много файлове наведнъж, но може да има само един изходен файл, затова и в 99% от случаите компилира един вход и един изход.

Абе то не и точно фронт енд, защото по gnu терминологията фронт енд е един език

Но аз имах предвид cpp/g++/as компилаторите, те си бачкат на парче... Иначе да, през gcc като тул може да запуснеш почти всички останали тулове - препроцесори, компилатори, асемблери, линкери... кво ли не. И между другото в повечето случаи е по-добре през gcc, отколкото директно.

Не помня казвах ли, че работя с платка на Олимекс - SAM3-P256, а софтуерът е за платката на Атмел - SAM3S-EK. Сравних library директориите на Атмел и на Олимекс - преправих някои дреболии, според платката на Олимекс - При low level init да не се преминава към външен кварц 32kHz; пинът, който отчита напрежението на USB (Vbus) да е друг.

Билднах примера от софтуерния пакет на Атмел: sam3s-ek\examples_usb\usb_cdc_serial, програмирах го и не тръгна, както би следвало! След ресет на платката, се разпознава нов хардуер и успешно му инсталирам драйверa. Той е sam3s-ek\libraries\usb\device\cdc-serial\drv\6119.inf, както са записали в примера да се направи. При включване на платката, след това, се разпознава новото устройство (прикачената картинка), но, при опит да отворя този порт, получавам грешка. Използвам терминал Real Term, а грешката е "A device attached to the system is not functioning". Потърсих в интернет и намерих това:
http://forum.thewindowsclub.com/windows ... oning.html
Сякаш вторият случай изглежда възможен: The external device and drive types are incompatible.
Дали някой се е сблъсквал с такъв проблем и може да ми даде някакви насоки?

когато закачиш USB устройство OS-a го разпитва (DeviceDescriptor и т.н.) и споре типа му търси драйвер... за CDC ти му даваш само inf в което се казва да ползва уйндовския драйвер. Както и да е, тая част явно минава...

Като пуснеш терминал, той обикновено първата му работа е да сетне line codding, baudrate и т.н. това са заявки по контролние ендпоинт на CDC класа. Тук явно не минаваш.... Вариантите са - или софта ти е скапан и не отговаря на тоя ендпоинт. Или хардуерът ти се отвява след първоначалната енумерация...

За да не хвърляме боб, най-добре е да го подслушаш... за windows има разни програмки дето трейсват усб комуникацията, аз обикновено ползвам линукс... dmesg показва някои проблеми, а wireshark на ниво пакети показва останалите неща....