Chodzi Tobie Weles o błędne działanie samego Eclipse'a? -(w sensie że nie wykrywa zaincludowanych funkcji jak ma to np. pakiet Borlanda 6, czy tam Embarcadero),
czy o to jak wykonuje się samo dzielenie programu w c (projektu) w taki sposób, aby kod main można było przejrzeć nie używając scroll'a?

Jeśli to drugie, to najbardziej konkretna odpowiedź jest zawarta w bluebook'u Pana Mirka. W skrócie ja wykonałbym to tak, że do plików *.h (nagłówkowych) które już masz porobiłbym im odpowiednie pliki *.c, np. do drv_gate.h dorobiłbym drv_gate.c
Dalej te pliki kolejnych modułów, np. drv_gate.h, drv_gate.c, drv_heat_water.h, drv_heat_water.c załączasz normalnie do głównego pliku main.c jak to robiłeś do tej pory. Komplilator widząc plik nagłówkowy (*.h) szuka jego pliku z kodem (*.c). Zasada jest taka, że w plikach *.h trzymasz deklaracje zmiennych i funkcji, a w pliku *.c odpowiadające im definicje zmiennych i funkcji. Plik main.c "widzi" to wszystko, z tym, że jeśli jakaś zmienna ma być globalna w całym projekcie to powinna być poprzedzona dyrektywą extern. Nie wiem, czy dość jasno to opisałem... Najwyżej dopiszę.
Jeśli chodzi o ustawianie środowiska Eclipse, to na tym forum są ludzie którzy dużo lepiej potrafią to wytłumaczyć. Ja jeszcze za słabo znam Eclipse...

Tak poza tym widziałem Twój projekt inteligentnego domu. Jestem pod wielkim, pozytywnym wrażeniem!

Pozdrawiam z Pomorza! Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

Ojej!
Dawno nie widzialem takiego kodu w C. Owszem bedzie to dzialac jako tako. Ale jak widac 'nowsze' interpretacje zasady dzialania #include sobie z tym nie radza, bo nie powinno sie stosowac w taki sposob includow.

Traktujesz includy na zasadzie:
- o, a ten fragment kodu przerzuce sobie do innego pliku, zeby mi sie wygodniej czytalo
a nalezy je traktowac jako biblioteki zawierajace konkretne funkcje i definicje.

Mysle ze powinienes troche sie cofnac i odswiezyc podstawy jezyka C.

elganckiego sposobu nie ma bo, nie jest to zalecany sposob kodowania.

Sprobuj tak:
- zmien nazwe pliku na systemie (nie ecplipsem) TEST_SENSORA.h na TEST_SENSORA.wnc
- w nowym projekcie zaincluduj 'TEST_SENSORA.wnc'.

Tak a nie inaczej, zeby wykluczyc ze eclipse nauczyl sie ze mial juz taki plik w projekcie (w makefile w szczegolnosci).
Jest szansa ze jak nie rozpozna rozszerzenia to nie bedzie probowal cos z tym zrobic poza includowaniem.

ps. nie wiem czy to zadziala.

Przy tylu postach nie wiedzieć jak wstawiamy listingi? Daję czas do północy na poprawienie postu, później leci ostrzeżenie.

_________________
http://www.jaglarz.info

Nie wiem czy to ważne, ale w zasadzie plik nagłówkowy *.h (z ang. header) może mieć dowolne rozszerzenie (nie tylko h). Poza tym Kolega Mokrowski dokładnie opisał całą najważniejszą esensję, czyli że przy już na etapie projektowania (ale jeszcze nie programowania) bierze się pod uwagę podział logiczny i funkcjonalny całego projektu. Logiczny mam na myśli to na ile plików (modułów) będzie to podzielone, funkcjonalny czyli jakie funkcje będą posiadały kolejne moduły.

Kiedyś Pan prof. Jerzy Grębosz opisywał w "Symfonii C++" taki ciekawy problem (podaję go tutaj jako typowy problem logiczny):
Mamy 3 zegary sterujące czujnikami temperatury i chodzi o to, żeby W TYM SAMYM czasie co do milisekundy były odpalone. Jak dobrze zsynchronizować te 3 zegary? -Wprowadza się 4-ty zegar typu master, który posiada JEDEN i ten sam czas i w oparciu o to synchronizowana jest reszta zegarów. Nie wiem, może to co piszę to tutaj może się wydać, że to bzdury, ale PORÓWNANIE problemu wysterowania zegarów i kontroli nad projektem jest takie, że funkcja main.c to taki jakby zegar master, a cała reszta plików (modułów = *.h + *.c) to mogą być albo slave'y, albo kolejne mastery (jednak jako mastery podrzędne w stosunku do głównego mastera main.c).



Strzałka na rysunku wskazuje agregację. Grot strzałki wskazuje na plik(i) które są nadrzędne w stosunku do drugiego końca strzałki. Pliki nadrzędne zawierają w sobie dyrektywy include ładujące potrzebne im moduły (funkcje i zmienne). Na żółto zaznaczona funkcja (moduł) nadrzędna - główny kontroler, czyli tzw. master (w ujęciu master/slave). Na zielono zaznaczone są moduły (funkcje) nadrzędne w stosunku do modułów białych (czujników), ale podrzędne w stosunku do głównego kontrolera (głównego mastera).
Teraz co do samego języka c stosuje się jeszcze dyrektywy preprocesora (np. ifndef, define etc.), bo dalej gdyby miały wchodzić pojęcia typu klasy, funkcje i zmienne wbudowane, to wtedy wkraczamy w język C++. Tam to już inaczej niektóre sprawy się rozwiązuje (enkapsulacja, dziedziczenie, klasy abstrakcyjnie, etc., typy private, protected, public). Moje osobiste zdanie jest takie, że do celów zbudowania np. sterownika inteligentnego domu sam język avr c spokojnie wystarczy. Należy uważać na dostęp do zmiennych i załączenie odpowiednich nagłówków.

Na koniec przepraszam, że używam niezbyt specjalistycznego języka, ale.. cóż.. uważam, że czasem trzeba napisać coś prościej - nawet jeśli jako tłumaczący (czyli ja) mam wyjść na głupka, bo chcąc dobrze mimo wszystko pomyli jakieś pojęcia. Takie ryzyko. A na egzaminie nie jestem, tylko na przyjaznym forum, gdzie czy pochwały, czy wytknięcie błędów jest mile widziane.

Pozdrawiam! Jarek

P.S. Kolego Moderatorze Jaglarz, chyba nie użyłem odpowiedniej składni do kodu na moim rysunku... Upss..

_________________
"O sygnałach bez całek" Czesław Frąc