złe pliki z defin

Witajcie,

Jest sobie program na atmega8, coś tam mierzy na ADC, mierzy temp. przez DS18B20, wyświetla wszystko na 7-segment i przełącza kilka przekaźników. A problem jest taki - avr-gcc nie wiedzieć czemu (chyba) przy kompilacji używa nieprawidłowych plików z definicjami rejestrów procesora. Oczywiście na początku pliku mam #include <avr/io.h>, a kompilator wywołuje z -mmcu=atmega8. Tylko, że np. taka linijka jest w ogóle pomijana: ADCSRA = _BV(ADEN)|_BV(ADPS1)|_BV(ADPS2); Są też błędy (a może raczej braki) przy konfiguracji innych rejestrów (np. timerów), nie rozpoznaje mi niektórych nazw rejestrów/bitów. IDE którego używam (CodeBlocks pod Ubuntu), pozwala mi na podejrzenie, w którym pliku znajdują się definicje użytych nazw rejestrów/bitów - i tu ciekawostka, wypluwa mi że definicje wziął z pliku ioat94k.h - tak jakby w ogóle olał parametr mmcu i wybrał sobie pierwszy lepszy plik do którego odnosi się avr/io.h. Przejrzałem ten plik (ioat94k) dokładnie - takie nazwy nie są tam zdefiniowane (w końcu to inny procek), dla porównania podejrzałem w iom8.h - tutaj oczywiście są. Więc faktycznie z jakiegoś nieznanego mi powodu zostaje wywołany nieprawidłowy plik z definicjami - dlaczego? Walczę z tym od wczoraj i skończyły mi się pomysły, próbowałem zmieniać ustawienia wywołania avr-gcc, ale nie ma efektów.

Reply to
Jakub Rakus
Loading thread data ...

W dniu 26.03.2013 21:34, Jakub Rakus pisze:

-mmcu=xxx, to opcja kompilatora a nie IDE, więc skąd Codeblocks ma wiedzieć, w którym pliku szukać definicji?

Po prostu przejrzyj plik *.lss i sprawdź, czy kompilator zrobił to co napisałeś (co niekoniecznie będzie się pokrywało z tym co chciałeś).

Reply to
Zbych

Jakub Rakus snipped-for-privacy@op.pl napisał(a):

Na pewno? Nie spotkałem się jeszcze z tym, żeby kompilator sobie coś pomijał. Skąd wiesz, że pimija? W jaki sposób testowałeś?

Jak nie rozpoznaje? Jeśli nie rozpoznaje, to znaczy, że kompilacja kończy się błędem.

Jest sobie warunek: #if defined (__AVR_AT94K__) # include <ioat94k.h>

Nie masz czasem zdefiniowanego __AVR_AT94K__?

Dużo nie wymyślimy bez źródeł, przede wszystkim Makefile.

Reply to
Grzegorz Niemirowski

W dniu 26.03.2013 21:49, Zbych pisze:

Ale tą opcje wybieram poprzez ustawienia projektu w IDE i na podstawie tychże ustawień Codeblocks wywołuje kompilator z odpowiednimi opcjami. Wszystkie użyte w programie funkcje/zmienne/definicje które są zdefiniowane/zadeklarowane w plikach innych niż main.c a dołączonych do niego dyrektywą include mogę sobie podejrzeć prawoklikiem na danej funkcji/zmiennej/definicji - nie dociekam jak to rozwiązali programiści piszący IDE, wiem tylko że dopiero po kompilacji mogę robić taki podgląd, dopóki program nieskompilowany tego podglądu nie ma. Być może jest tak, że ten podgląd szwankuje, a błąd leży gdzie indziej.

Ehh, chciałem tego uniknąć, bo jest spory... no ale zajrzałem i widzę, że teoretycznie w asemblerze mam jak trzeba, czyli problem leży gdzieś indziej, tylko nie mam pomysłu gdzie - wiem tylko, że wszystko zaczęło się tak kaszanić po tym jak dodałem konfigurację timer2 jako PWM, poprzez dwie proste linijki (na początek żeby widzieć w ogóle przebieg na nodze):

TCCR2 = _BV(WGM21)|_BV(COM21)|_BV(CS20); OCR2 = 127;

Z jakiegoś powodu na porcie jest stan niski, konfiguracja pinu PB3/OC2 ustawiona kilka linijek wcześniej jako wyjście z pull-down.

Reply to
Jakub Rakus

Tak jak napisal Zbych, parser w ide nie wie gdzie ma wejść, bo za to odpowiedzialne jest makro automagicznie tworzone przez kompilator w czasie kompilacji na podstawie mmcu, a którego ide nie zna. Popatrz sobie jak wyglądają pliki które includujesz (np io.h) - sa tam dziesiątki ifdefów sprawdzające obecnosc roznych makr np __AVR_ATtiny4313__ .

pozdrawiam

Reply to
Kicer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.