Do tej pory pisałem swoje programy pod AVR-y w niezbyt elegancki sposób,
umieszczając wszystko w jednym pliku źródłowym. W ramach nauki
postanowiłem jednak zmienić ten nawyk, poza tym pojawiła się potrzeba
wykorzystania cudzych bibliotek.

Stworzyłem więc nowy projekt w Atmel Studio, zaimportowałem plik *.c i
*.h potrzebnej biblioteki, potworzyłem też pliki dla swoich bibliotek.
Mając jeszcze w większości puste pliki (tzn. zawierające jedynie
niezbędne szkielety programu) wykonałem "Build Solution"

Kompilator zwrócił serię błędów, wskazując na plik nagłówkowy
zaimportowanej biblioteki. Wszystkie one dotyczyły nieznanego typu
zmiennej: "unknown type name 'uint16_t'" (tudzież uint8_t),
występującego w deklaracjach nazw funkcji, umieszczonych w owym pliku
nagłówkowym. Same definicje funkcji w pliku .c już o nic nie krzyczały.

Doszedłem do tego, że winny jest brak dyrektywy #include <avr/io.h> na
początku feralnego pliku nagłówkowego, który ze względu na nazwę jest
sprawdzany przez kompilator jako pierwszy.

Mam teraz następujące wyjścia:
1. Umieścić #include już na początku pliku nagłówkowego, ale chyba nie
jest to zbyt eleganckim wyjściem. Na różnych przykłądach widzę, że te
dyrektywy umieszcza się raczej w plikach *.c.
2. Zmienić nazwy plików tak, aby kompilowały się później.

A może istnieje jakiś sposób na poinformowanie kompilatora, żeby
dołączył określony plik już na samym początku? Albo żeby zmienił
kolejność kompilacji poszczególnych plików?

do góry

On Sun, 24 Nov 2013 09:13:07 +0100, Atlantis <m...@w...pl>
wrote:
> A może istnieje jakiś sposób na poinformowanie kompilatora, żeby
> dołączył określony plik już na samym początku? Albo żeby zmienił
> kolejność kompilacji poszczególnych plików?

Kolejność kompilacji nie powinna mieć znaczenia. Skoro kluczowy plik
nagłówkowy jest potrzebny do kompilacji to dlaczego nie chcesz go
załączyć w plikach .c?

--
Marek

do góry

W dniu 2013-11-24 10:47, Marek pisze:

> Kolejność kompilacji nie powinna mieć znaczenia. Skoro kluczowy plik
> nagłówkowy jest potrzebny do kompilacji to dlaczego nie chcesz go
> załączyć w plikach .c?

W pliku .c jest załączony, brakuje go w pliku .h.
Czyli jak mam rozumieć najbardziej prawidłowym rozwiązaniem będzie
przeniesienie dyrektywy #include do pliku nagłówkowego, jeszcze przed
wystąpieniem deklaracji funkcji?

Tylko dziwię się dlaczego w przykładach z książki, z której korzystam
("Mikrokontrolery AVR Język C - podstawy programowania") było to
zrobione odwrotnie. Czyżby akurat ECLIPSE taka sytuacja nie przeszkadzała?

do góry

Atlantis <m...@w...pl> napisał(a):
> Kompilator zwrócił serię błędów, wskazując na plik nagłówkowy
> zaimportowanej biblioteki. Wszystkie one dotyczyły nieznanego typu
> zmiennej: "unknown type name 'uint16_t'" (tudzież uint8_t),
> występującego w deklaracjach nazw funkcji, umieszczonych w owym pliku
> nagłówkowym. Same definicje funkcji w pliku .c już o nic nie krzyczały.
> Doszedłem do tego, że winny jest brak dyrektywy #include <avr/io.h> na
> początku feralnego pliku nagłówkowego, który ze względu na nazwę jest
> sprawdzany przez kompilator jako pierwszy.

Jak to ze względu na nazwę? Kompilator leci po kolei po linijkach kodu.

> Mam teraz następujące wyjścia:
> 1. Umieścić #include już na początku pliku nagłówkowego, ale chyba nie
> jest to zbyt eleganckim wyjściem.

Dlaczego nie? Skoro plik używa tych typów, to powinien zawierać includy
definiujące te typy.

Tutaj jest w ogóle trochę specyficzna sytuacja. Mówimy bowiem o podstawowych
typach dla AVR (i dla innych uC też), które są wykorzystywane praktycznie w
każdym projekcie. Z tego względu praktycznie każdy plik .c będzie miał
includa dla io.h i będzie importować te typy. Często będzie to pierwsza
linijka w pliku .c. Z tego względu jeśli potem jest include biblioteki, to
te typy są już znane i plik .h biblioteki nie musi ich kompilować. Dlatego
autor biblioteki nie zaincludował io.h w pliku .h swojej biblioteki. Po
prostu założył, że Ty to zrobisz w pliku .c i zrobisz to _przed_
includowaniem jego biblioteki.

Przyznam się, że nie wiem jakie wyjście jest tu uznawane za eleganckie. Moim
jednak zdaniem biblioteka powinna zawierać wszystko co potrzeba i jak
zaincludujemy jej plik .h to nie powinniśmy być zmuszaniu do includowania
innych nagłówków definiujących typy wykorzystywane wewnętrznie przez tą
bibliotekę. No chyba, że uznajemy io.h za wyjątek.

> Na różnych przykłądach widzę, że te
> dyrektywy umieszcza się raczej w plikach *.c.

Kompilator analizując plik .c nie może widzieć żadnych nieznanych wyrażeń,
musi mieć wszystko wcześniej zadeklarowane (niekoniecznie zdefiniowane, ale
zadeklarowane tak). Stosujemy więc pliki nagłówkowe żeby udostępniać
deklaracje typów i funkcji, definicje funkcji siedzą w plikach .c.
Tutaj jest sytuacja taka, że plik .h odwołuje się do typów, których nie ma
standardowo w języku C, dlatego w pliku .h może być odwołanie do innego
pliku .h. Nie jest to nic dziwnego w bardziej złożonych projektach.

> 2. Zmienić nazwy plików tak, aby kompilowały się później.

Po pierwsze kolejność kompilacji nie ma nic do rzeczy. Po drugie o
kolejności decyduje plik Makefile albo inny skrypt budujący (zależnie od
środowiska).

> A może istnieje jakiś sposób na poinformowanie kompilatora, żeby
> dołączył określony plik już na samym początku? Albo żeby zmienił
> kolejność kompilacji poszczególnych plików?

Poczytaj sobie jak działa kompilator. Kompiluje oddzielnie poszczególne
pliki .c, zgodnie z tym, co ma wpisane w Makefile. I przestań mylić
kompilację z dołączaniem plików .h. Kolejność kompilacji nie ma nic
wspólnego z kolejnością dołączania. Pytasz o sposób informowania kompilatora
o dołączanie na samym początku. Dołączanie jest przecież realizowane w
kodzie źródłowym poprzez dyrektywy #include. W jakiej kolejności je
napiszesz, w takiej wskazywane przez nie pliki będą dołączane. Poza tym mam
wrażenie, że myślisz, że plik nagłówkowy się dołącza raz na cały projekt.
Nie. On się dołącza w tym miejscu, w którym jest #include. I koniec końców
dołączany jest to jakiegoś jednego, konkretnego pliku .c. Pliki .c są
kompilowane oddzielnie i nie wiedzą o sobie. Dlatego includy często się
powtarzają. Dopiero jak wszystkie pliki .c są skompilowane, to wkracza
linker tworząc wynikowy plik wykonywalny i zapisując w nim skoki pod
określone adresy. Dlatego w jednym pliku .c możesz odwoływać się do funkcji
zdefiniowanej w drugim. Ale ten pierwszy musi znać deklarację.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 2 days, 18 hours, 52 minutes and 5 seconds

do góry

Atlantis <m...@w...pl> napisał(a):
> W pliku .c jest załączony, brakuje go w pliku .h.
> Czyli jak mam rozumieć najbardziej prawidłowym rozwiązaniem będzie
> przeniesienie dyrektywy #include do pliku nagłówkowego, jeszcze przed
> wystąpieniem deklaracji funkcji?

Tak, wtedy nie będziesz się musiał martwić o includowanie w pliku .c w
odpowiedniej kolejności.

> Tylko dziwię się dlaczego w przykładach z książki, z której korzystam
> ("Mikrokontrolery AVR Język C - podstawy programowania") było to
> zrobione odwrotnie. Czyżby akurat ECLIPSE taka sytuacja nie przeszkadzała?

Eclipse nie ma nic do rzeczy bo to nie kompilator.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 2 days, 19 hours, 20 minutes and 30 seconds

do góry

W dniu 24.11.2013 o 09:13 Atlantis <m...@w...pl> pisze:

> Do tej pory pisałem swoje programy pod AVR-y w niezbyt elegancki sposób,
> umieszczając wszystko w jednym pliku źródłowym. W ramach nauki
> postanowiłem jednak zmienić ten nawyk, poza tym pojawiła się potrzeba
> wykorzystania cudzych bibliotek.
>
> Stworzyłem więc nowy projekt w Atmel Studio, zaimportowałem plik *.c i
> *.h potrzebnej biblioteki, potworzyłem też pliki dla swoich bibliotek.
A dołączyłeś w pliku .c ten nagłóówkowy .h ? chyba nie musisz dać coś w
stylu
#include "xxxx.h"
w pliku .c

--

Pozdr
Janusz

do góry

Użytkownik "Atlantis" <m...@w...pl> napisał w wiadomości
news:l6sceu$3r4$1@portraits.wsisiz.edu.pl...
> A może istnieje jakiś sposób na poinformowanie kompilatora, żeby
> dołączył określony plik już na samym początku? Albo żeby zmienił
> kolejność kompilacji poszczególnych plików

Ja robię tak:
============================
// Crc.h
// Obliczanie sum kontrolnych CRC8, CRC16, CRC32
//--------------------------------------------------
----------------------------

#ifndef CrcH
#define CrcH

#ifndef ByteTypesH
#include "ByteTypes.h" // typy byte, word, dword, qword
#endif

int crc8(byte* buf,int n,int crc=0xFF);
int crc16(byte* buf,int n,int crc=0xFFFF);
dword crc32(byte *buf,int n,dword crc=0xFFFFFFFF);

#endif
===========================

P.G.

do góry

> ============================
>
> // Crc.h
>
> // Obliczanie sum kontrolnych CRC8, CRC16, CRC32
>
> //--------------------------------------------------
----------------------------
>
>
>
> #ifndef CrcH
>
> #define CrcH
>
>
>
> #ifndef ByteTypesH
>
> #include "ByteTypes.h" // typy byte, word, dword, qword
>
> #endif

W/g mnie ten drugi #ifdef ByteTypesH nie jest potrzebny. Pliki .h z toolachain'a
zwykle maja juz wbudowane zabezpieczenie przed wielokrornym dolaczaniem ( sekwaencja:
#ifndef __ByteTypes_H__
#define __ByteTypes_H__
//zawartosc pliku ByteTypes.h

#endif
)
Ja uzyl bym po prostu #include "ByteTypes.h" ktory dolaczy sie o ile juz wczesniej
nie zostal dolaczony przez inny plik .h


Marcin

do góry

Uzytkownik "Marcin" <m...@o...pl> napisal w wiadomosci
news:0ead3cc5-a14d-45c8-b2a1-5a1849d963b8@googlegrou
ps.com...

> W/g mnie ten drugi #ifdef ByteTypesH nie jest potrzebny. Pliki .h z
> toolachain'a zwykle maja juz wbudowane zabezpieczenie przed wielokrornym
> dolaczaniem
> Ja uzyl bym po prostu #include "ByteTypes.h" ktory dolaczy sie o ile juz
> wczesniej nie zostal dolaczony przez inny plik .h

Otoczenie #include przez #ifdef zapobiega analizowaniu przez kompilator
wlaczanego pliku. Kompilator nie jest jasnowidzem i po sekwencji:
#ifndef __ByteTypes_H__
#define __ByteTypes_H__
nie wie, ze reszty moze nie czytac - musi wyszukac pasujacy #endif wiec musi
przynajmniej analizowac kolejne #ifcostam (aby pominac odpowiednie
#endif-y), co oznacza koniecznosc czytania calego pliku i co najmniej
minimalnej analizy kazdej kolejnej linii kodu.
Moje pliki .h sa wzglednie krótkie, ale biblioteczne pliki .h potrafia byc
dlugasne.
Kiedys dawno, gdy zaczynalem, komputery nie byly tak szybkie jak teraz (do
tego pierwszy PC jaki kupilismy do firmy byl bez hdd).
Przyjalem sobie wtedy taki zapis (i juz tak zostalo) bo przy kompilacji
wiekszego programu oszczedzalo to otwierania i analizowania wielu plików, co
dawalo wyrazne przyspieszenie kompilacji nawet na komputerze posiadajacym
hdd, a co dopiero na moim.
P.G.

do góry

Rozumiem, optymalizacja czasu kompilacji.
Moze tez sie nad tym zastanowie, bo kompilacja projektu pod Keil'em ponad na 100
plikow .c zaczyna sie dluzyc w pracy.
M

do góry