Witam. Ostatnio oglądałem poradnik Mirka o obsłudze klawiszy. Tak mi się spodobało jak on tam wykorzystał strukturę do przekazania zmiennych do funkcji że nie dawało mi to spać i sam chciałem tak zrobić. Ale coś mi kurcze nie działa. Nie będę dużo pisał wrzucę kody plików. Projekt składa się z kilku plików: main.c oczywiście i to co mi nie działa: pliki zegar.c i zegar.h oto ich kody

main.c


zegar.c

zegar.h
W plikach funkcje pomocnicze są tylko: funkcja do ustawiania kursora przy pomocy kodów VT-100 (na razie nie używam) i inicjalizacja trybu asynchronicznego. Dioda w przerwaniu miga mi co sekundę. Problem jest wtedy kiedy chciałem godziny, minuty i sekundy wyświetlać w terminalu. Po odkomentowaniu linijki w funkcji piliku zegar.c funkcja wyświetla mi znak dwukropka co sekundę.
Pytanie mam też o zmienną zadeklarowałem początkowo ją w strukturze jako "volatile" ale nie była widoczna w procedurze przerwania. Dopiero kiedy zadeklarowałem ją tak jak jest teraz to kompilator nie pokazuje błędu, ale mam wątpliwości czy to dobrze że zmienna sek jest zadeklarowana w dwóch miejscach. Proszę o pomoc jak ugryźć te dwa problemy.

Pierwsza kaszana i to spora (ja nie mówię, że to od razu ma wpływ na jakieś tam złe działanie tutaj - ale lekka masakra) to fakt, że definicję zmiennej TCZAS jednostki zrobiłeś w pliku *.h .... Panie kochany - DEFINICJE tworzy się w plikach *.C (przypominam to najcięższe podstawy z Bluebooka )



No i co dalej? To jest dobrze czy źle? Ja nie wiem ... poza tym nie mogę sobie wyobrazić co to może oznaczać, że "wyświetla się znak dwukropka co sekundę" - no to chyba dobrze jak migają sobie dwukropki


Panie, na litość - a jakiego błędu? Kto wie co ty tam wyrabiasz

tym bardziej, że co ma wspólnego zmienna sek luzem ze zmienną w strukturze? Gdyby miała być w strukturze to pewnie że musi mieć volatile jak będzie miała być napędzana w przerwaniu. I co za błąd ? to normalnie musi działać tylko pewnie coś źle zapisałeś w kodzie - ale ANI TEGO NIE POKAZAŁEŚ ani nie pokazałeś jaki błąd i weź się tu człowieku domyślaj o jaką to zagadkę chodzi

_________________
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 pewnie że źle napisałem w kodzie i to pewnie nie mało . Zacznę jeszcze raz od początku. Chcę napisać kod który będzie w konsoli w lewym górnym rogu wyświetlał godzinę (godziny:minuty:sekundy). Udało mi się to zrobić w ten sposób:
Tylko teraz chciał bym wszystko uporządkować i porobić funkcje w plikach projektu a do funkcji zegar przekazywać wskaźnik do struktury.
Zmienna sek ma być inkrementowana w przerwaniu i użyta do wyświetlania sekund. Poniżej daję kody nie wrzucam tylko plików mkuart.h i mkuart.c.
main.c:

zegar.c

zegar.h:

funkcje_pomocnicze.c

funkcje_pomocnicze.h

Po skompilowaniu projektu dostaję taki komunikat:

Po pierwsze skoro masz volatile dla zmiennej sek w strukturze TCZAS to specyfikator volatile dla



jest po grzyba potrzebny wywal go stąd

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

kolejny babol - drastyczny to właśnie to że wciąż kolega nie rozumie czym różni się DEFINICJA zmiennej od DEKLARACJI zmiennej ... co widać i po poprzednim kodzie i po tym kodzie. Bo o ile zrobiłeś już prawidłowo DEFINICJĘ



(tylko to volatile tu jest niepotrzebne - ale też nie przeszkadza w działaniu) ... to powiedz gdzie masz teraz DEKLARACJĘ tej zmiennej ? żeby można było ją widzieć w main.c ??? hmmmm ponieważ jej NIGDZIE nie ma - to nie dziwota że kompilator wymiotuje takimi błędami jak pokazałeś. Skąd kompilator może wiedzieć podczas kompilacji main.c co to jest ?



tzn nazwa jednostki ... przecież każdy plik *.c jest kompilowany oddzielnie - obejrzyj sobie koniecznie poradnik mój o tym jak działa kompilator bo bez zrozumienia tego i bez zrozumienia różnicy czym jest Definicja a czym Deklaracja zmiennej - jak sam widzisz daleko człowiek w C nie zajedzie. Ale jak zaskoczysz - to radość będzie przeogromna - więc pogłówkuj - zajrzyj do BB i daj znać

_________________
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 ]

Trochę poczytałem i obejrzałem poradnik. Poprawiłem kod, teraz kompiluje się bez błędów, ale napisy (godzina) w konsoli wyświetla się co kilka sekund i nie zwiększają się sekundy. Gdzie jeszcze mogę szukać błędu? Oto kod.
main.c
zegar.c
zegar.h

No nic tylko wziąć i czytelnikowi głowę ukręcić za to ... to jest DEKLARACJA zmiennej ????? w pliku *.h .... a czym ona się różni wg ciebie od DEFINICJI którą teraz już prawidłowo zrobiłeś w pliku *.c Ślicznie przeniosłeś definicję typu struktury do *.h ale ... za to DEKLARACJĘ niestety sfafrałeś

Bluebook - rozdział "3.1.2. Definicja a deklaracja"

Bluebook - rozdział "3.5.6. Funkcje w różnych plikach projektu"

w tym drugim masz już jak na patelni pokazane w tabelkach o co chodzi - PODZIAŁ PLIKÓW w projekcie

proszę cię zajrzyj i zobacz koniecznie co to jest DEKLARACJA - już jesteś blisko

_________________
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 ]

Zerujesz wszystkie pola struktury, w tym pole sekund, zaraz na początku funkcji zegar.


Definicja zmiennej w pliku nagłowkowym nie jest błędem składniowym więc faktycznie nie ma znaczenia. Na pewno nie ma wpływu na działanie programu.

_________________
Think for yourself and question authority.

Ale proszę cię nie opowiadaj bajek - oczywiście, że składniowo jest ok ale jeśli ktoś (początkujący) definiuje sobie tę samą zmienną dwa razy, raz w pliku *.c a drugi raz w *.h to w tym najprostszym przypadku - nie wpłynie to na to że program nie zadziała bo linker sobie poradzi.....

ale jeśli później autor sobie zacznie wprowadzać zmiany w większym projekcie i dokona np zmiany nazwy zmiennej tylko w jednym z plików - to katastrofa murowana i długie szukanie błędu (tym bardziej że nie mającego związku ze składnią a więc nie będzie prostego komunikatu) ...

Zatem jeśli już podpowiadasz na forum to miej na uwadze dobre praktyki programowania a nie takie rzucanie sobie - no niestety nie obraź się ale bzdurnych podpowiedzi. Bo to prowadzi do nikąd ...

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

poza tym nie pozwoliłeś mi naprowadzić kolegę powoli na właściwe tory - a dzięki temu doszedłby i zrozumiał różnicę w Definicji i Deklaracji zmiennej ... a tak ? po twoim pseudo wywodzie - który NAWET nie objaśnia takiemu początkującemu "CO" "JAK" i "DLACZEGO" - robi się tylko "misz-masz", a ty wychodzisz na Śpeca przez duże eŚ niestety.

Na drugi raz - proszę poczytaj taki wątek i zobacz o co chodzi ok?

_________________
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 ]

Babol goni babol

Wskazałem gdzie leży błąd oraz gdzie na pewno nie leży. Bzdurnie? Zdarza mi się gadać bzdury, jak każdemu, ale jestem pewien że nie tym razem - błąd jest zbyt oczywisty.
Jeśli mamy mówić o dobrych praktykach programowania to mówmy. Praktyka nr 1: żadnych zmiennych globalnych o łączności zewnętrznej.
Następujący program zgodny z tą zasadą. Zmienna zaliczająca jest zmienną globalną o zasięgu plikowym funkcjonującą poza zmienną strukturalną. Czas liczony jest jako tzw. timestamp, tj. liczy się upływ jednostek czasu (np. sekund) od jakiegoś punktu w czasie (np. jak Unix timestamp od 1 stycznia 1970r UTC albo po prostu od włączenia programu). Zmienna strukturalna służy wyłącznie do zwracania bieżącego czasu przeliczonego na godziny, minuty, sekundy. Ponieważ zmienna timestamp musi być bitowo dłuższa niż 8 trzeba pamiętać o pobieraniu jej wartości w sekcji krytycznej. Szkieletowy kod:
zegar.h


zegar.c

main.c

_________________
Think for yourself and question authority.

Fofex, ale robisz zamieszanie. Przecież to jest początkujący.

Tylko widzisz to co pisałem do ciebie dotyczyło nie wskazania błędu - tylko tego co dalej napisałeś ... a ty znowu udajesz, że nie zauważyłeś

Przynajmniej teraz podpowiedź z jakimś pełnym wyjaśnieniem ...

_________________
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 ]

Jestem bardzo początkujący. Mam naturę taką że nie chcę iść na łatwiznę a liczę na konstruktywne naprowadzenie mnie odpowiednie myślenie. Zadając pytanie na forum, liczę na to co napisał Mirek . No taki już jestem, nawet jak mi coś ciężko idzie to liczę na wędkę nie na rybę.

ok ale daj znać jak idzie czy już do końca rozwiązany problem ?

_________________
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 ]

W zasadzie tak, problem rozwiązałem. Tylko w trackie trwania tego wątku moje myślenie ewoluowało z rozwiązania tego konkretnego problemu do zrozumienia deklaracji, definicji, plików *.h i *.c projektów. Nie wiem jak w innych językach (nie tylko jeżeli chodzi o uC) ale taki pliki projektu mają mega potencjał i powodują niesamowite rozjaśnienie projektu. W tym momencie w kwestii wyjaśnienia mam taki niuans i proszę o sprostowanie jeżeli źle myślę po przeczytania tych dwóch rozdziałów.
W pliku *.h tworzymy deklaracje zmiennych i funkcji, w pliku *.c robimy ich definicje, to po pierwsze.
Pod drugie, czy dobrze rozumiem że zapis w pliku *.h jest deklaracją ale ten zapis w pliku *.c będzie definicją pomimo że zmienna nie została zainicjowana?
Po trzecie skoro w rozdziale 3.1.2 jest napisane: "Wynika z powyższego, że definicja jest równocześnie deklaracją,..." to czy tworząc definicję w pliku *.c zmiennej lub funkcji (o ile w tych plikach tworzymy deklaracje) nie musimy nie musimy jej deklarować w pliku *.h? To chyba na tyle moich pytań na tą chwilę, nie wykluczam że ciąg dalszy w tej kwestii nastąpi.

Co do mojego kodu. Czy skoro w pliku zegar.hjest deklaracją to w pliku zegar.c dodając tą samą linijkę czy to już jest definicja? Dobrze to rozumiem?

Nie, jak masz w pliku *.c



to w pliku *.h można utworzyć jej deklarację tak:



i to jest GIGANTYCZNA różnica. Bo specyfikator extern w *.h powoduje, że kompilator NIGDY nie zarezerwuje miejsca w pamięci na bazie tego wpisu ze słówkiem extern! Za to dzięki zainkludowaniu tego pliku *.h w innych plikach projektu *.c - podczas kompilacji każdego z tych plików *.c kompilator będzie wiedział, że "aha! w innym pliku *.c znajduje się gdzieś DEFINICJA tej zmiennej.

I dopiero po kompilacji wszystkich plików *.c gdy do pracy wchodzi LINKER aby połączyć kod wynikowy w jeden plik wyjściowy BIN czy HEX to dopiero na tym etapie może wyskoczyć ew błąd - jeśli pośród wszystkich plików *.c projektu nie znalazłby się ANI jeden w którym istnieje DEFINICJA tej zmiennej.

------------------------ [ Dodano po: 2 minutach ]

Zatem w twoim przypadku miała być w pliku *.c DEFINICJA



natomiast w pliku *.h jej DEKLARACJA czyli



tak jak w tabeli w Bluebooku pokazanej w rozdziale

Funkcje w różnych plikach projektu

Funkcje w różnych plikach projektu

_________________
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 ]

Ja też nie jestem szpecem w programowaniu, ale wydaje mi się, że w tym akurat przypadku wystarczyło zdefiniować zmienną jednostki w main.c , bo i tak nie była ona używana w innych plikach tylko w mam.c. w pliku zegar.c była tylko definicja funkcji i też nie wiem jak kompilator zachował by się, ponieważ w funkcji zegar () widniała dokładnie ta sama nazwa zmiennej. Tu też mogły być problemy.

Zmienne globalne o łączności zewnętrznej są widoczne w całym programie i są identyfikowane po nazwie. W związku z tym w całym programie może istnieć jedna jedyna zmienna globalna o danej nazwie. Rodzi to groźne konsekwencje tj. dwie (lub więcej) zmiene globalne o łączności zewnętrznej niezależnie zdefiniowane w różnych modulach programu zostaną "zredukowane" do jednej instancji. Zmiena będzie nadpisywana. Nie zmienia tego żadne czary z extern. Przeanalizujcie sobie dokładnie ten przypadek: topic23104.html
Dlatego generalną zasadą jest nieużywanie takich zmiennych.

_________________
Think for yourself and question authority.

extern dla zmiennej to żadne czary i w ogóle to o czym piszę z tym extern nie ma NIC WSPÓLNEGO z tym, że może się stać tak jak piszesz i to jest normalne. O wiele większą BZDURĄ jest definiowanie zmiennej w pliku H i rozprzestrzenianie tego po projekcie bo wtedy jeszcze łatwiej o problem z powodu nieuwagi niż z tego powodu, że ktoś sobie napitoli ileś zmiennych globalnych w różnych plikach C.

Najpierw to początkujący musi zrozumieć podstawy i jak w ogóle podchodzi się do zmiennych globalnych, żeby później można było lepiej mu wyjaśnić dlaczego nie warto używać generalnie zmiennych globalnych dla całego projektu i jakie to może przynosić skutki a także w jaki sobie sposób radzić - tak żeby nie używać wprost takich zmiennych globalnych. Tymczasem ty skaczesz "z kwiatka na kwiatek" rzucając jakieś oderwane od rzeczywistości wątku hasła.

Powiem krótko widać, że wiedzę masz i to dużą w tym zakresie - ale jeśli chodzi o poziom umiejętności przekazywania wiedzy to przykro mi ale jest on na bardzo niskim poziomie przy takim podejściu jak tu na forum.

A wątek który przytoczyłeś z forum, tak jest dobrym przykładem żeby omówić właśnie niebezpieczeństwa stosowania zmiennych globalnych

_________________
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 ]

Acha. Czyli zmienna globalna, zdefiniowana w main lub innych plikach *.c będzie widoczna w całym programie i we wszystkich jego plikach? A jeśli dodatkowo zrobimy deklaracje w pliku *.h dodając extern, to będziemy mogli jej używać w innych plikach, bo bez extern nie moglibyśmy jej używać w innym pliku ,*.c , co nie zmienia faktu że jej nazwa będzie znana we wszystkich plikach projektu, a jeśli chcielibyśmy ją "zamknąć" w jednym pliku, to należy dodać static. I wtedy nawet gdyby nazwa zmiennej została zdublowana , to nie będzie problemu,? Ale wniosek jednak jest taki, że trzeba się starać ograniczać używania zmiennych globalnych. Dzięki i przepraszam, że wtrąciłem się do dyskusji.

Nie, będzie globalna TYLKO dla tego pliku *.c


No TAK ale zrozum, będziesz mógł używać i widzieć tę zmienną w innych plikach *.c jeśli w nich zrobisz #INCLUDE tego pliku *.h. Bez tego w żadnym innym pliku *.c nie zobaczysz tej zmiennej.


No tu ZAMIESZAŁEŚ albo niestety zamieszał ci w głowie kolega fofex. Zapamiętaj - po do jest DEKLARACJA ze słówkiem extern w plikach *.h żeby to za ich pomocą rozprzerstrzeniać widoczność tej zmiennej w innych plikach *.c całego projektu - a nie że ona będzie AUTOMATYCZNIE widoczna!


DOKŁADNIE tak, jeśli dasz specyfikator static to kompilator wywali błąd jeśli zapomnisz wywalić jej deklaracji ze słówkiem extern z pliku *.h bo to się zacznie gryźć wtedy.


Qurczę będzie problem i to trojakiego rodzaju,

1. jeśli masz dwa różne pliki *.c i w każdym zrobisz zwykłą definicję zmiennej np: int a; (ale jej np nie ZAINICJALIZUJESZ na etapie definicji) .... to sam sobie zrobisz QUQU dlatego że kompilator POŁĄCZY te obie zmienne w jedną instancję ! i wcale nie oznacza to że zmienna a jest GLOBALNA i widoczna w każdym pliku *.c .... Tą zmienną "a" będą widziały TYLKO te dwa pliki projektu w których zrobiłeś te dwie nieszczęsne definicje - a nie inne pliki *.c. Bo skąd niby ma być widoczna w innych ? W tym wypadku kompilator NIE ZGŁOSI ci żadnego błędu ale działanie programu może być dla ciebie nieprzewidywalne.

2. SZCZEGÓLNIE jeśli rozpatrzymy inny przypadek i założysz w dwóch plikach *.c dwie zmienne np: int a=17; a w drugim pliku np: int a=5; (Spróbuj sobie zrobić prosty projekt i to przetestować) ... to teraz już kompilator będzie wymiotował błędem - że MULTIPLE definitions zmiennej a ! Ale widzisz ? tylko w przypadku gdy dwóm zmiennym od razu chcesz przypisać wartość przy inicjalizacji.

3. przypadek gdy założysz w jednym pliku definicję np: int a; zaś w drugim pliku: int a=8; ... kompilator nie będzie darł papy że multiple definitions ale się zdziwisz jaką wartość zmiennej a zobaczysz na LCD jak ją sobie wyświetlisz np z mainc gdzie miałeś int a; (cyzli bez inicjalizacji - teoretycznie powinna mieć wartość 0 no nie?) a w drugim pliku napiszesz sobie funkcję która też ma wyświetlć zmienną a i tą funkcję udostępnisz przez *.h do maina. to po wyświetleniu zmiennej a w main.c dostaniesz wartość = OSIEM !!!!! (a miało być niby zero) ... natomiast w drugim pliku np keyb.c jak ją wyświetlisz w drugiej linii to dostaniesz też wartość = OSIEM ale tu spodziewałeś się tego no bo przecież zdefiniowałeś ją jako int a=8; WIDAĆ po tym przypadku jak na dłoni, że kompilator z linkerem weszli w zmowę i połączyli adres w pamięci RAM dla obu zmiennych a z obu twoich plików *.c i jeszcze na dodatek tak jakby każdej z nich przypisali wartość 8 z tego drugiego pliku *.C ... czyli masz JEDNĄ INSTACJĘ i dlatego tak się dzieje ale NIE MA TO NIC WSPÓLNEGO z globalną widocznością tylko z nieprzemyślanym działaniem programisty - no i z tym właśnie - że dopiero ten przypadek pokazuje dobrze jeden z powodów dlaczego nie warto stosować zmiennych GLOBALNYCH !

4. Wystarczy jednej z tych zmiennych a w jednym z plików dać specyfikator static i już program zacznie się normalnie zachowywać i każda z nich będzie miała inną instancję czyli inną lokację w pamięci RAM.

KRÓTKO MÓWIĄC - zanim początkująca osoba zrozumie te opisane tu przypadki to NAJPIERW musi DOKŁADNIE poznać czym różni się definicja od deklaracji ze słówkiem extern i jak przekazywać zmienną a jako globalną do innych plików *.c

Gdy to stanie się jasne to wtedy łatwiej zrozumieć jakie mogą być cyrki gdy człowiek tworzy dużo zmiennych globalnych w różnych plikach *.c swojego projektu, łatwo wtedy po prostu o taką pomyłkę że niechcący zapomnimy że już w innym pliku *.c zdefiniowaliśmy zmienną o tej samej nazwie. I później będzie rwanie włosów z głowy że gdy oba pliki pracują na tej samej zmiennej ale wrzucają w nią inne wartości - to w obu plikach może dochodzić do dziwnych zachowań związanych z taką zmienną

Dlatego warto je albo hermetyzować dodając specyfikator static a jeśli trzeba udostępniać innym plikom to np poprzez jakieś funkcje albo tworzyć struktury ze zmiennymi i posługiwać się w ramach pliku np wskaźnikiem na taką strukturę itp itd

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

To zresztą nadaje się albo na jakiś poradnik albo na wyjaśnienie na jakimś LIVE na YT - może kiedyś to zrobię

_________________
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 panie Mirku za wyczerpujące wyjaśnienie. Po lekkim, zagubieniu i zamieszaniu, które pojawiło się w mojej głowie i błędnym rozumieniu (myślałem że to chodzi o globalną widoczność) , sytuacja się rozjaśniła i naprowadził mnie pan na dobre tory ✋

Jest dokładnie tak jak piszesz: zmienna jest "widoczna" ale nie można jej "użyć". Dziwne i niezrozumiałe? Nie, sensowne i logiczne ale trzeba wrócić do podstaw. Rzekomy problem wynika z użycia słowa "widoczność", które w sensie języka nic nie znaczy. Każdy rozumie je po swojemu, prawdopodobnie każdy inaczej. Trzeba użyć zdefiniowanych przez standard języka słów "zasięg" i "łączność". I tak: zmienna globalna ma łączność we wszystkich plikach projektu ale nie we wszystkich ma zasięg. Zasięg ma w plikach których jest zadeklarowana. Przy czym deklaracja bez specyfikatora extern jest też deklaracją. Zgodnie ze standardem extern jest dla zmiennych specyfikatorem domyślnym więc jego dodanie czy ujęcie nic nie zmienia.
W większości przypadków można się obyć bez zmiennej globalnej. Przypadek uzasadnionego użycia, który mi się teraz nasuwa to użycie w procedurze obsługi przerwania na AVR. Wywołanie funkcji z ISR jest dosyć kosztowne na AVR więc z powodów wydajnościowych można by jej użyć. Z kolei na Cortex-M nie ma sensu ścibiolić na globalach ponieważ wywołanie funkcji z ISR nie niesie dodatkowych kosztów.

_________________
Think for yourself and question authority.

Fofex dzięki również tobie, za rzeczowe wyjaśnienie ✋ w sumie wszystko składa się w logiczną całość. I tak jakby spojrzeć na to z punktu widzenia programu w uC, to (tak mi się przynajmniej wydaje) że jak kompilator napotka w którymś z plików zdefiniowaną zmienną globalną i przydzieli tej zmiennej miejsce w pamięci, to gdy później w innym pliku napotka zmienną globalną o tej samej nazwie, to nie zorientuję się że to jest inna zmienna i nie przydzieli jej innego miejsca w pamięci, ponieważ zmienna o tej nazwie ma "łączność" we wszystkich plikach ponieważ jest globalna (chyba że będzie opatrzona specyfikatorem static, to wtedy ma ”łączność" w tym jednym pliku i będzie traktowana jako zupełnie inna zmienna). Tak to trochę łopatologicznie sobie tłumaczę. W każdym razie dzięki i pozdrawiam.

I to jest przepiękne pobleblanie i wprowadzanie mega zamętu.

1. Bo rzekomy problem
2. Bo każdy coś rozumie po swojemu
3. Bo zmienna ma łączność we wszystkich projektach ale nie we wszystkich ma zasięg
4. Zasięg ma w plikach których jest zadeklarowana
5. Przy czym deklaracja bez specyfikatora extern jest też deklaracją

z czego wychodzi jedna wielka głupota do kwadratu - przykro mi ale bzdet na maxa, wynika bowiem, że "róbta co chceta" czyli jeśli zmienna ma być globalną do walcie definicje w każdym pliku projektu a najlepiej jeszcze w plikach *.h ! No bo przecież wg wypowiedzi fofexa tak można - no można kompilator nawet nie piardnie najmniejszym ostrzeniem jeśli będę miał:

1. w pliku main.c - int a;
2. w pliku keyb.c - int a;
3. w pliku keyb.h (inkludowanym w main.c) - int.a;

to prosty przykład - a wyobraźmy sobie projekt składający się łącznie z kilkunastu podfolderów i łącznie powiedzmy 65 plików *.c i 76 plików *.h

I teraz załóżmy że w 43 plikach *.c potrzebujemy tej zmiennej globalnej "a" która jak dla twórcy wywodzić ma się i miała powstać pierwotnie w pliku keyb.c - ale my idąc tropem fofexa - wpierniczymy w 43 plikach *.c projektu, które mają korzystać z tej zmiennej ich Qurna definicje ... a żeby było lepiej, wpierdzielimy je jeszcze do 26 plików *.h .... no bo co ? MOŻNA ! a kto nam zabroni? kompilator ? NIE! Broń Boże ... kompilator nie piardnie - GRZECZNIE wszystkie te zdefiniowane zmienne umieści w tym samym miejscu w RAM !!!! i fajnie ...

ale... przyjdzie moment, że twórca projektu zechce np żeby ta zmienna "a" była KONIECZNIE zainicjalizowana wartością np 17 .... Ok nadal wg fofexowej idei - można iść po najmniejszej linii oporu i TYLKO uwaga ! w jednym RANDOMOWO wybranym pliku ją zainicjalizować int a=17; W innych nie trzeba - i nadal będzie dobrze ... kompilator nie krzyknie. Ale w ciągu dalszych prac okaże się, że to jednak nie miała być wartość 17 tylko 23 ... po roku czasu i ? ... i teraz przypomnij sobie w którym z 69 plików projektu była ta definicja ... no i szukamy .... Ok - co to za problem ktoś powie ... ale pójdźmy dalej po niedługim czasie twórca dojdzie do wniosku że nadał strasznie głupią nazwę tej zmiennej bo zamiast "a" mógł dać - "poziom_paliwa" ..... hahahahaha no i konia z rzędem temu kto teraz nawet bez najmniejszego grymasu na twarzy będzie z lubością i przyjemnością zmieniał w 69 plikach tę nazwę !!!!!

ale będzie jeszcze gorzej - bo jak przez pomyłkę ktoś zmieni tę nazwę tylko w 53 plikach a w pozostałych nie - to nagle te pozostałe zmienne "a" zaczną żyć swoim życiem w oderwaniu od "poziom_paliwa" !!!! i niektóre pliki *.c mogą zacząć działać już CAŁKIEM po wariacku i w oderwaniu od poziomu paliwa !!!!! chore !!!!!


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

a jeśli w takim wielkim projekcie TYLKO w jednym pliku keyb.c zrobimy DEFINICJĘ - int a; oraz jej deklarację w pliku keyb.h - extern int a; a następnie ZAINKLUDUJEMY w 68 plikach *.c plik keyb.h to do jasnej ciasnej gdy:

1. zechcemy zainicjalizować zmienną wartością np 17, to spokojnie wiemy, że jej definicja wg opisanego przeze mnie sposobu postępowania ZNAJDUJE się TYLKO kuźwa w jednym pliku keyb.c i TYLKO w tym jednym miejscu zmienimy int a; na int a=17; i NIC WIĘCEJ nie robimy !!

2. jeśli zechcemy zmienić nazwę zmiennej "a" na "poziom_paliwa" to nazwę tę zmienimy tylko w DWÓCH plikach projektu !!!!!! keyb.c oraz keyb.h a także w każdym miejscu odwołania się w kodzie do zmiennej a. ALE dzięki temu, że nazwę "a" rozprzestrzeniał po plikach projektu TYLKO jeden plik keyb.h to w konsoli dostanemy całą listę plików w których trzeba zmienić odwołania, i Eclipse ładnie nam zaznaczy czerwonymi krzyżykami te pliki nawet w Exploratorze projektu! Łatwo pójdzie ta zamiana odwołań ale już nie durnych DEFINICJI w każdym pliku *.C

i co ? jest porządek i DOKŁADNIE to samo co mówi standard o łączności i zasięgu czy nie !?!? a pracy i kłopotów w pierdyliard razy mniej

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

na koniec, wyobraźmy sobie jeszcze że tropem fofexa - skoro specyfikator extern jest niejawnie dodawany (zresztą tak jak dla nagłówków funkcji) i dalibyśmy int a; bez specyfikatora extern zarówno w keyb.c jak i keb.h I teraz jeśli w pliku keyb.c zmienimy tę nazwę int a; na int poziom_paliwa; a nie zmienimy int a; w pliku keyb.h bo wg fofexa nie ma on znaczenia - to ja pierdziu - koniec - i dupa zimna bo kompilator nawet nie pokaże nam że zaszła zmiana, powstaną bowiem dwie oddzielne zmienne: "poziom_paliwa" w keyb.c i tam zmienimy odwołania, oraz zmienna "a" z pliku keyb.h !!!!! i tu JEST właśnie szkopuł bo w TYM WŁAŚNIE momencie ten nic nie znaczący specyfikator extern !!!!! w pliku *.h pokaże JAK BARZO ON JEST POTRZEBNY .... wystarczy go wstawić w tym przykładzie - i NAGLE kompilator ślicznie zakrzyczy, że w 64 plikach trzeba zmienić odwołania do zmiennej "a" na "poziom_paliwa"

fofex przeanalizuj sobie te przypadki zanim będziesz na drugi raz pisał takie swoje wywody które same się plączą ze sobą jak groch z kapuchą

_________________
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 ]

Trochę to skomplikowane, przynajmniej jak na mój poziom wiedzy i doświadczenia na tą chwilę. Ale z tego co zrozumiałem albo mi się wydaje w takim przypadku jak mój, powinienem zmienną zadeklarować w pliku *.h ze słowem extern, a zdefiniować ją w pliku *.c tak samo jak zadeklarowałem ale bez słowa extern. I dopiero wtedy mógł bym jej używać w tych plikach w których zainkudowałem plik *.h z deklaracją tej zmiennej.

No DOKŁADNIUŚKO tak jak piszesz - więc nie wiem dlaczego uważasz, że tego nie ogarniasz

_________________
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 ]

Na taka odpowiedź liczyłem. Pisałem że nie ogarniam bo wtedy nie ogarniałem. Będę musiał jeszcze poczytać o tych zmiennych globalnych i lokalnych, kiedy którą gdzie widać itd. to co pisaliście wyżej.

To mam kolejną "zagwózdkę" której na tą chwilę nie ogarniam. Projekt jaki mam to wiadomo z powyższych wpisów, ale w skrócie powtórzę żeby nie trzeba było czytać całości od początku. Deklarację struktury i nowej zmiennej w pliku zegar.h mam zrobioną tak:
z pliku zegar.c zdefiniowałem zmienną w ten sposób:
I teraz zachodzi potrzeba potrzeba użycia struktury w pliku key.c, chciałem w tym pliku zrobić gaszenie diody na określony czas (10min.) po wciśnięciu przycisku na co najmniej jedną sekundę z wykorzystaniem inkrementacji sekund w przerwaniu.

No to co za problem zainkludować w key.c ten plik *.h w którym masz właśnie extern TCZAS jednostki ? toż to zmienna więc dokładnie taka sama zasada

_________________
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 ]