Hej,
Zastanawiam się mocno nad jedną sprawą. Mianowicie na jakieś zasadzie kompilator określa, ze trzeba dołączyć stdlib.h, a kiedy nie trzeba.

W ramach ćwiczenia piszę sobie swoją bibliotekę obsługi wyświetlacza hd44780.
Mam 3 pliki:
-main.c (na razie pusty kompilujący się szablon),
-hd44780.c,
-hd44780h.

W pliku hd44780.h zawarłem deklaracje funkcji


Natomiast w pliku hd44780.c w przybliżonym skrócie i przede wszystkim w takiej kolejności

Dlaczego w pliku .h wyrzuca mi error : unknown type name uint8_t, skoro w pliku hd44780.c załączyłem plik io.h PRZED plikiem nagłówkowym hd44780.h?
Oczywiscie załączenie w pliku .h biblioteki stdlib.h rozwiązuje problem, ale nie rozumiem czemu w jednym projekcie nie muszę tego robić, a w innym muszę..

Sprawa jest dość prosta

powinieneś mieć najpierw w pliku *.C inkluda

stdlib.h

a później swojego inkluda *.h

jeśli nie zachowujesz tej kolejności to musisz dołączać inkluda stdlib.h w swoim pliku *.h

--------------

tylko po co - skoro warto pamiętać o tym co napisałem na początku

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Ok, tylko dlaczego muszę w wypadku tego projektu dołączać a w wypadku innego (np multipleksowanie led 7segm.) wystarczyło na początku pliku 7segm.c dodać?

Ale co ty opowiadasz, nic nie trzeba dołączać. Pomijam już że masz Bluebooka i możesz zajrzeć, że tam w żadnym przykładzie nie ma dodawanego stdlib.h w plikach nagłówkowych i wszystko śmiga - mógłbyś podejrzeć.

A u ciebie jak znam życie to problem bierze się stąd, że w main.c zapewne nakaszaniłeś troszkę z inkludami, czyli zrobiłeś zapewne tak:




zamiast tak:




sprawdź sam ... i zobaczysz, że będzie to działać tak jak pisałem wyżej. Wg mnie najpierw inkludujemy pliki systemowe a później dopiero pliki własne

------------------------ [ Dodano po: 10 minutach ]

krótko mówiąc powinno być tak:



a nie tak:

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Myślę, że tu bardziej chodzi o sytuację, kiedy plik nagłówkowy lcd.h (odnosząc się do przykładowych zrzutów ekranu z postu kolegi Mirka) dołączamy do innego pliku np. menu.c, w którym nie jest dołączany (bezpośrednio lub pośrednio np. poprzez avr/io.h) plik nagłówkowy stdint.h (bo to w nim jest definicja typu uint8_t używanego przez parametr funkcji). W takiej sytuacji, niezależnie od kolejności "inkludowania" nagłówków w pliku lcd.c problem wyniknie podczas kompilacji pliku menu.c. Gdyby w pliku main.c nie było dyrektywy preprocesora #include <avr/io.h>, problem też by wystąpił, ponieważ w deklaracji funkcji write_half() występuje parametr typu uint8_t. Myślę, że o taką sytuację chodziło autorowi tego wątku.


Pliki nagłówkowe nie są analizowane podczas kompilacji oddzielnie, tylko w połączeniu z plikiem *.c, do którego zostały dołączone, oraz w połączeniu z innymi plikami nagłówkowymi dołączonymi do tego pliku *.c. Każdy taki zestaw - plik *.c z dołączonymi do niego plikami nagłówkowymi - to tzw. jednostka translacji.
Z kolei każda taka jednostka translacji jest oddzielnym tworem. Jeśli jedna jednostka translacji ma dołączony plik nagłówkowy definiujący typ uint8_t, to inna jednostka translacji nic o tym nie wie, więc - jeśli ten typ jest użyty np. do zadeklarowania parametru funkcji - musi też mieć dołączony odpowiedni plik nagłówkowy.
To wymusza konieczność zachowania pewnych zależności pomiędzy plikami nagłówkowymi oraz zależności w odpowiedniej kolejności ich dołączania.
W opisanej przez Ciebie sytuacji, jeżeli do pliku hd44780.c dołączyłeś plik nagłówkowy <avr/io.h> przed plikiem nagłówkowym hd44780.h, to będzie OK. Jeśli teraz dołączasz plik nagłówkowy hd44780.h do innego pliku źródłowego *.c, to jest to osobna jednostka translacji, która zna typ uint8_t, lub go nie zna (czytaj: ma dołączony pośrednio lub bezpośrednio plik nagłówkowy stdint.h, lub nie ma). Jeśli więc w tym pliku *.c nie masz jeszcze dołączonego odpowiedniego pliku nagłówkowego stdint.h i typ uint8_t w tej jednostce translacji nie jest znany, to dołączenie pliku nagłówkowego hd44780.h wymusi dołączenie pliku nagłówkowego stdint.h (bezpośrednio lub poprzez dołączenie np. <avr/io.h>).

W takiej sytuacji należy umieścić w pliku nagłówkowym hd44780.h komentarzu w stylu: "przed dołączeniem tego pliku nagłówkowego dyrektywą #include do pliku *.c należy dodać także plik nagłówkowy stdint.h".
Można też na początku pliku hd44780.h dodać po prostu linijkę:
i też będzie OK. Jeśli dołączysz ten plik do pliku *.c, w którym stdint.h jest już dołączone, to nic się nie stanie, ponieważ pliki nagłówkowe mają (a przynajmniej powinny mieć) zabezpieczenie przed wielokrotnym inkludowaniem. Jeśli w tym pliku *.c nie będzie dołączonego stdint.h, to zostanie dołączony poprzez plik hd44780.h

tylko hmmm jaki to ma sens żeby nie było tego inkluda ? ... tzn jeśli ktoś chce sobie robić problemy to owszem - no można nie robić tego inkludowania avr/io.h tylko ... no to troszkę taki masochizm

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Ma duży sens, ponieważ dzięki temu poza inkludowaniem odwołań do modułów procka, jest też automatycznie inkludowany <inttypes.h> a także <stdint.h>

Więc nawet jeśli akurat w danym pliku źródłowym nie korzysta się z odwołań do pinów/portów/timerów i innych modułów to jest ta zaleta, że "za darmo" mam podciągnięte stdint.h a gdy tylko jednak będę potrzebował odwołać się do byle pinu w kodzie, chociażby z powodu włączenia własnych funkcji debugujących to mam od razu <avr/io.h>

A przy okazji też nie muszę sobie zawracać głowy z kolejnością inkludowania stosując zawsze jednolite podejście

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Wow, temat się rozwinął, jest głębszy niż myślałem .

Mirku - bardzo dużo pracy wkładasz w to, żeby nawet screeny przygotować z wyjaśnieniem, dziękuję!
andrews - merytoryczna prosta wypowiedź, piękna sprawa

Rozwiązaniem było zaincludowanie biblioteki <avr/io.h> w pliku main.c.
Nie zaincludowałem go wcześniej, ponieważ myślałem jak kolega:


a mój plik main.c na tym etapie wyglądał tak:

nie widziałem sensu includowania tutaj io.h, bo nigdzie nie odwołuję się do żadnej zmiennej ani funkcji typu uint8_t.

Rozumiem jednak, że nic się nie stanie, gdy przyrośnie mi do palców includowanie io.h w pliku main.c tak po prostu?

No i się zaczyna

Ja obstawiam 5

Sorki to też tak, żeby utrzymać dobre poczucie humoru

------------------------ [ Dodano po: 7 minutach ]


A cóż miałoby się stać prawie nie wyobrażam sobie kodu jakiegokolwiek projektu, który w main.c nie miałby tego inkluda.

Oczywistą sprawą jest, że nie musi się to tyczyć wszystkich plików *.c projektu bo oczywiście koledzy kalani i dziobak7 mają świętą rację ... z jednej strony patrząc ... ale w ten sposób to można się przekomarzać ze dwieście lat a mnie się już nie chce.

Krótko mówiąc gdybyś pisał jakąś bibliotekę, w której przepięknie i wzorcowo rozgraniczyłbyś warstwę abstrakcyjną od sprzętowej - to można śmiało powiedzieć, że "po choinkę" wstawiać do takich plików *.c inkluda z <avr/io.h> .... ? Ten mógłby się znaleźć tylko w plikach *.c odpowiedzialnych za warstwę sprzętową. Zaś w plikach nagłówkowych *.h związanych z plikami źródłowymi warstwy abstrakcyjnej inkludować by trzeba było wszystko co potrzebne ...

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No to muszę skombinować jakiś Wikol czy inny klej i przykleić io.h do main.c na stałe... Zresztą później i tak by się pojawił, bo na pewno odwołam się do jakiejś funkcji lub zmiennej uint8_t.

Ale nie będę sobą, jak nie zrozumiem, dlaczego błąd wywołuje mi brak io.h w pliku main.c, skoro wygląda on tak:

Przecież int jest typem wbudowanym.

Jakby to okreśłił towarzysz Edward G,

no ale tobie chodzi o int czy uint8_t bo to jednak różnica

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Chodzi mi o to, że nie załączałem w pliku main.c biblioteki io.h, ponieważ w pliku main.c miałem tylko funkcję

a skoro int jest typem wbudowanym, to raczej nie potrzebuje biblioteki io.h.

A jednak jest bez niej error, więc zapytałem, dlaczego błąd wywołuje mi brak io.h w pliku main.c

No to właśnie pokaż co to za error ? bo nie powinno go być ale, że nie widzę błędu to ciężko coś podpowiedzieć

------------------------ [ Dodano po: kilkunastu sekundach ]

i pokaż kod tego krótkiego pliku main.c

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Przedstawiłem to jako sytuację hipotetyczną. Chodziło mi raczej o to, że brak #include <avr/io.h> (lub przynajmniej <stdint.h>) w dowolnym pliku *.c, w którym będzie dołączony plik nagłówkowy hd44780.h wygeneruje problem.
Niemniej dołączenie pliku io.h w pliku main.c wcale nie jest obligatoryjne, a czy to stwarza problemy lub jest masochizmem, to zależy od konkretnej implementacji i stylu programowania.


No właśnie, plik main.c też wcale nie musi odwoływać się do sprzętu.

... co nie oznacza, że należy na siłę unikać #include <avr/io.h> w pliku main.c, kiedy jest potrzebny.


Czy na pewno masz tam tylko funkcję int main()?
Jeśli Twój kod w main.c wygląda np. tak:

a plik hd44780.h wygląda tak:

To po preprocesorze kod main.c do kompilacji będzie wyglądał mniej więcej tak:

i wtedy już brakuje definicji typu uint8_t

main.c:

hd44780.c:

hd44780.h:

error w linii 52 pliku .h:
In file included from ../main.c:8:0:
../hd44780.h:64:25: error: unknown type name 'uint8_t'
inline void write_half (uint8_t data);
^
make: *** [main.o] Błąd 1

Kolega andrews chyba rokminił, o co tu chodzi, to logiczne

No zobacz sam masz swój main.c

inkludujesz w nim swój plik lcd4478.h - tak?

co to oznacza? .... Preprocesor, który działa przed kompilatorem - wkleja (można tak wprost powiedzieć) WSZYSTKO co masz w swoim *.h do pliku lcd44780.c - rozumiesz?

No i wkracza kompilator - i teraz skąd on ma wiedzieć co to jest uint8_t ??? (a zauważ, że wcześniej pisałeś że masz niby błąd związany z int) ... tymczasem to błąd związany z uint8_t

Musisz zrozumieć, że kompilator kompiluje ODDZIELNIE KAŻDY plik *.c z takimi wklejonymi bebechami z plików *.h (#include X - to znaczy wklej mnie pan tutaj to co w pliku X)

no i jeśli nie masz w swoim main.c



albo jeśli nie masz



no to Qurczę - skąd kompilator ma wiedzieć co oznacza uint8_t ??? ja się ciebie pytam i kompilator też się ciebie pyta - wymiotując błędami

------------------------ [ Dodano po: 1 minucie ]

Więc jak widzisz nie ma to NIC WSPÓLNEGO z typem "int" który widzisz przed funkcją main()

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No teraz już rozumiem..

Ale jak to początkującemu, niełatwo mi pewne rzeczy tak od kopa przyswoić...teraz jest to dla mnie całkiem logiczne.

Dlatego przeczytałem ze 3 razy rozdział o wyświetlaczu HD44780 i dlatego też próbuję sam napisać na ile umiem z głowy bibliotekę do obsługi tego wyświetlacza. Wychodzę z założenia, że to bardziej pomoże, niż czytanie rozdziału nawet 20-raz

zdecydowanie najlepsza z metod nauki, ale to co jeszcze ważniejsze w tej chwili - to! .... to właśnie to żeby zrozumieć co i jak jest kompilowane

bo później to już będzie "z górki"

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Dzięki jeszcze raz wszystkim!
Miłego weekendu

Victoria

Obejrzyj filmik Mirka o kompilatorze i inkludach. Na pewno Ci się wyklaruje.