stałe wartości w pliku c czy h

slawek55 · Post autor: **slawek55** » 22 kwie 2012, 8:57

Cześć.
Proszę powiedzcie mi czy jak mam tablicę np z wartościami funkcji sinus to te wartości powinienem umieścić w pliku .c czy .h (czy w pliku sin.c czy w pliku sin.h)? Jaka jest różnica jak umieszczę w jednym a w drugim?
W kursie w EdW STM32 wartości umieszczono w sin.c natomiast w kursie AVR takie dane były w plikach .h
Przy okazji, spotkałem się z definicją funkcji która miała taki zapis

Kod: Zaznacz cały

volatile unsigned char FUNKCJA(.....) {...}

Chodzi mi o użycie volatile w funkcji a nie w zmiennej. Po co i dlaczego?

tymon_x · Post autor: **tymon_x** » 22 kwie 2012, 10:24

array.h

Kod: Zaznacz cały

#define MAX_ARRAY(array) (sizeof(array)/sizeof(array[0]))

extern const uint8_t array_lut[];

array.c

Kod: Zaznacz cały

const uint8_t array_lut[] = {0};

A jak będziesz miał kilka takich tablic lub dodatkowe funkcje ? Plik nagłówkowy powinień być zwarty, a nie zawierać śmieci, czyli wartości. Najlepiej umieścić tablicę w *.c, natomiast dodawać do projektu za pomocą nagłówka *.h, gdzie będzie słówko extern. Jeśli to długa stała tablica i nie chce Ci się liczyć elementów, zastosuj puste [] oraz makro MAX_ARRAY do ustalenia rozmiaru tablicy.

Kod: Zaznacz cały

for(uint8_t i=0; i < MAX_ARRAY(array_lut); i++)
		*(ret++) = array_lut[i];

volatile przy funkcji ? Pierwszy raz widzę taki twór. Że niby wartość zwracana ma nie być optymalizowana, co jest bez sensu (?). Chyba ktoś stawił to volatile w celu uniknięcie warninga na temat niezgodności typów między wartością zawracaną, a do tej której ma być przepisana. Albo udokumentować funkcję, że zwraca wartość jest przepisana do wartości o typie volatile, bo innego sensu to ja nie widzę w tym.

slawek55 · Post autor: **slawek55** » 22 kwie 2012, 10:45

Dobrze piszesz z tymi plikami bo ma to sens, tylko dlaczego w prawie każdym kursie c na mikrokontrolery tablice są właśnie w pliku h?
Pliki c należy kompilować osobno, czy tak? Więc kompiluje się tylko tablica?

A ten twór z funkcją volatile jest np tu i to dość często:
http://stm32.eu/index.php?option=com_at ... load&id=96

tymon_x · Post autor: **tymon_x** » 22 kwie 2012, 12:21

slawek55 pisze:Dobrze piszesz z tymi plikami bo ma to sens, tylko dlaczego w prawie każdym kursie c na mikrokontrolery tablice są właśnie w pliku h?
Pliki c należy kompilować osobno, czy tak? Więc kompiluje się tylko tablica?

Każdy kurs C na mikrokontrolery są po prostu słabe, tak samo dostępne pozycje książek na ten temat ! Są to tylko przepisane datasheet uC na nasz ojczysty język z marnymi przykładami wykorzystania języka C oraz zasobów uC. Dobre książki o samym omówieniu języka C i jego składni mają blisko 1000 stron, tu polecam K.N. King "Język C, Nowoczesne programowanie". Drugie tyle stron będzie o samym praktycznym wykorzystaniu C, jak pisać uniwersalne drivery, wykorzystać wskaźniki na funkcje do tego, pisać pseudo-obiektowe programy w C, modularne i zgodne z ADT i tak dalej... A następne 1000 stron o samym stylowi pisania kodu i organizacji projektu... więc żaden kurs tego nie streści, w dodatku jest pisane według własnych fanaberii autora artykułu.

Jak tam osobno skompilujesz *.c, to kompilator wrzuci tak tablicę do każdego pliku obiektowego, gdzie funkcja korzysta z tej tablicy, natomiast linker po scaleniu to i tak wyrzuci i zostawi jedną tablicę i przypisze do pozostałych plików co taką tablicę wykorzystują wspólny adres. Więc robisz tylko dodatkową pracę na kompilatora/linkera. Sam Sobie odpowiedz na to pytanie, funkcje też możesz definiować w *.h, ale czy tak się robi ? Dobry styl programowania, ukrywa implementację, między innymi zawartość tablicy.

slawek55 pisze:A ten twór z funkcją volatile jest np tu i to dość często:
http://stm32.eu/index.php?option=com_at ... load&id=96

Ten kod to porażka na całej linii. Nie sugeruj się nim. Zobacz do folderu */src/mp3dec, widać że prezentuje zgoła inny poziom (wyższy) niż kod autora, który go wykorzystuje. Volatile przy funkcje to są własne fanaberie. W dodatku bezsensowne jest stosowanie tej biblioteki ST do czegokolwiek. Robi nie potrzebny narzut kodu, tworzy struktury, kiedy jak nie są utworzone lokalnie, marnują tylko pamięć. Zaciemnia całą sprawę. Przykład: inicjalizacja SPI w STM32 to są dwa rejestry ! W tym jeden jest od przerwań, drugi do konfiguracji. A ta bibliotek mieli jakąś tam strukturę Bóg wie czemu i po co. Można tu dyskutować godzinami, na przykład stosowania co rusz w kodzie while(1) {akcja} (?). Bez RTOS nie ma to najmniejszego sensu, bo jak taki stan nie nastąpi i nie wyjdzie z takiej pętli ???

slawek55 · Post autor: **slawek55** » 22 kwie 2012, 13:16

Tan na szybko sprawdziłem.
w pliki sin.c dałem tablice a w pliku sin.h jej deklaracje typu extern char sin[]={....};
Do main.c dodałem tylko sin.h i skompilowałem. Nie dodałem sin.c do plików kompilowanych. Linker zgłosił błąd
motyl.axf: Error: L6218E: Undefined symbol sin (referred from main.o).

Wychodzi ze dając w pliku c samą tablice muszę plik kompilować. Bo z tego co zrozumiałem to pisałeś ze nie muszę, chyba że nie zrozumiałem, to przepraszam.

A tą książkę to kupię sobie bo zapowiada się fajnie.

tymon_x · Post autor: **tymon_x** » 22 kwie 2012, 13:37

slawek55 pisze:Wychodzi ze dając w pliku c samą tablice muszę plik kompilować. Bo z tego co zrozumiałem to pisałeś ze nie muszę, chyba że nie zrozumiałem, to przepraszam.

Musisz, nic takiego nie napisałem, żeby nie kompilować. Skąd niby linker ma wziąć deklarację tej tablicy, jak nie z skompilowanego pliku źródłowego (końcowego obiektowego sin.o).

W sytuacji sin.c, sin.h oraz extern, musisz stworzyć sin.o, i później scalić do main.o, pliki source1.o, source2.o oraz sin.o.

Pobaw się czasem narzędziami z toolchain, którego korzystasz. Na przykład pakietem GNU GCC z linii komend. Tam też są programy do analizy takich plików i etc.. Powinno to lepiej zobrazować całą sytuację.