Cześć wszystkim! Mam niezwykły problem z Eclipsem. Zacząłem sobie tworzyć uniwersalną bibliotekę do SPI i już na wstępie mnie to pokonało. Problem ma miejsce w pliku h:


kompilator generuje mi błędy


Dotarłem już to tego, że nie zna typu uint8_t. Ok, podłączenie w nagłówku <avr/io.h> pomaga, ale w bibliotekach Mirka np do I2C też są typy uint8_t w deklaracjach, nie ma podłączonego io.h a mimo to nie generuja sie błędy. Co zrobiłem nie tak...?

Pierwsze co ci przeszkadza w znalezieniu błędu to właśnie to co piszesz - że to niezwykły problem z Eclipsem. Panie kochany - kiedy w końcu zrozumiesz, że Eclipse pełni tu rolę tylko notatnika - edytora kodu i nie ma nic wspólnego z błędami o których piszesz. Gdybyś to zrozumiał to już byś pewnie szukał rozwiązania gdzieś indziej .... Te błędy generuje kompilator (i sam nawet to piszesz wyżej) AVR GCC a to DUŻA różnica - a nie żaden Eclipse. Eclips tylko ładnie ci je przekazuje ...

Więc jeśli już wiesz że to błędy kompilatora, to chyba rozumiesz - że to oznacza, że coś musiałeś namieszać w swoim projekcie - prawda ?


Zrobiłeś gdzieś błąd w projekcie i to wcale nie w tym miejscu do którego dotarłeś tylko wcześniej nawet .... w związku z tym nie ma nawet jak pomó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 ]

Mhmm wiem, że kompilator. Nie pisałbym, gdyby w każdym pliku nagłówkowym widział błąd, ale tylko w tym SPI kompilator ma problem. Ten sam projekt inne nagłówki z typami uint8_t przyjmuje. Spróbuję jeszcze powalczyć, może stworze nowe pliki a jak nie no to już zostawię tego includa.

EDIT: Ok, przyjmuje już lecz nic nie zmieniałem w ustawieniach projektu.

uint8_t i inne typy o określonej długości lub sposobie pracy (skracam bo nie będę pisał elaboratu co tam jest), masz w <stdint.h>. W <inttypes.h> masz z kolei makra dla printf() które pomagają te typy wyświetlać. Ty potrzebujesz raczej <stdint.h>. Choć po samym pytaniu mogę wnioskować że masz o wiele "grubiej namieszane" :-/

Trochę mało danych... ale mi przestawał "widzieć" uint8_t w hederach, kiedy je dotłaczałem przed io.h



Jak robiłem tak:


wszystko hulało aż miło. Kolejność jest ważna.

Nie wiem dlaczego tak się dzieje, ale na moim marsie po zmianie nazwy hedera eclips zmienia wszystkie inkludy w kodzie, ALE po powrocie do starej nazwy przesuwa mi ją przed io.h nie w pliku main ale w pliku c powiązanym z h. Stąd Twój problem wydał mi się znajomy

_________________
Mr. Nobody

Przy dołączaniu bardzo ważna jest kolejność. Z tego co pamiętam to w BB jest to wyraźnie opisane - najpierw include systemowych a dopiero później własne.

Coś mi tutaj nie chce się wierzyć, ze edytor sam zmienia Ci kod ...

--
Pozdrawiam,
Robert

Ja też nie wierzyłem dopóki nie zobaczyłem. Przed napisaniem wczoraj postu sprawdziłem to, aby nie okazało się, że piszę bzdury.
Dziś wieczorem zrobię jeszcze jedną próbę.....
W BB jest bardzo dużo cennych informacji, niestety mój mózg (nie wiem jak Wasz) po pierwszym czytaniu nie był w stanie zapamiętać wszystkiego..... ech nie mam już 18 lat ;( Dziękuję za wskazówkę, to tam wrócę.
BB jest taką książką, do której się wraca.

_________________
Mr. Nobody

Ha - jednak jest jak pisałem - w załączniki sekcje z hederami plików.
Oryginalnie - wszystko się kompiluje:



Zmieniamy nazwę z 1_wir_usart.h -> 1_wire_usart_old.h
Wszystko się jeszcze kompiluje. Eclips sam podmienia wpisy w plikach źródłowych.



Po czym wracamy do starej nazwy - zonk - kompilacja nie powiodła się. W pliku 1_wire_usart.c została zamieniona kolejność hederów.....




Ciekawe. Być może dlatego, iż plik zaczyna się od cyfry????? U mnie tak się dzieje - nie wiem jak u Was.
Można sobie włosy z głowy rwać (w moim przypadku pęsetą, ale nie jest to meritum sprawy)

_________________
Mr. Nobody