AVRGCC i ja raz jeszcze... ;-)

May 12, 2004 21 Replies

Ehlo.



Na wstepie... potrzebne do kombajnu marchewkowego ;-)



Mam strukture: typedef struct { int adres[6]; unsigned char preheat[6]; unsigned char limit[6]; unsigned char character[6]; unsigned char nazwa[16] ; }eeprom_set;



Struktura owa jest powiazana w pewien sposob z wielopoziomowym menu. W pewnym miejscu programu tzn. tam gdzie nastepuje wyswietlenie konkretnej wartosci ze struktury, nastepuje ustawienie wskaznika: int *edit_buffer na dana za pomoca: edit_pointer=&ustawienia.adres[mep2-2]; W zupelnie innej czesci programu musze miec mozliwosc edytowania wartosci na ktora wskazuje edit_buffer. Dokonuje tego za pomoca np. (*edit_pointer)++; Teraz problem: Jak widac struktura ma 2 typy danych inty i chary. Tak byc musi, jak zmienie char-y na inty to w EEPROM-ie mi sie nie pomiesci, adres musi byc intem. Procedura edycji danych musi byc jedna i edytowac zmienne int i char. Jak to zrobic zeby wskaznik int *edit_buffer mogl wsazywac obiekty char. Bo wskazywac to potrafi edit_pointer=(int*)(&ustawienia.limit[mep2-2]); ale zapisuje dana jako inta (zajmuje 2 bajty i slusznie). Co powinienem sie dowiedziec ?? I czy w tym przypadku nie mam znow problemu ze wskaznikami ?? Poczytalem K&R ale nie ma tam zasadniczo informacji jak postapic w tym przypadku. Teoretycznie moglbym wykorzystac wskaznik typu void i przepisywac go do wskaznika albo typu char albo typu int. Ale moze da sie bardziej elegancko. Moglbym tez niby przeciazyc funkcje, ale wolalbym miec dwa w jednym... da sie tak ??



U¿ytkownik "Milosz Skowyra" snipped-for-privacy@wp.pl napisa³ w wiadomo¶ci news: snipped-for-privacy@wp.pl...

a cast nie dziala ?

*(char*) edit_pointer = jakas_dana;

chyba zapisze char pod ten wskaznik

Ty cos Miloszu znowu przekombinowujesz. ja nie bardzo rozumiem co chcesz osiagnac ... Jesli jedna procedura ma poprawiac int i char ... to nie moze byc "jedna" - bo jak ma sie zorientowac jaki typ ma poprawic ?

Poprawnie to bedzie cos takiego:

eeprom_set *edit_p;

edit_p=&ustawienia ; //lub =&ustawienia[0]; czy =ustawienia jesli tablica

wyswietl(&(edit_p->adres[mep2-2]));

edytuj_inttab(edit_p->adres); edytuj_chartab(edit_p->preheat);

mozesz oczywiscie zmiescic w jednej, na zasadzie edytuj(void *p, char typ) { .... if (typ==1) //char *(char*)p=... ; else *(int*)p = ....; }

Jesli ci sie nie podoba .. w zasadzie do tego sluza obiekty, ale nie polecam :-)

"zmienic typ" mozesz tak jak wyzej. void nie jest do tego potrzebny

- to tylko dla elegancji i podkreslenia ze ten typ dziwny jest. Mogloby byc tak:

edytuj(int *p, char typ) { .... if (typ==1) //char *(char*)p=... ; else *p = ....; }

Tylko wtedy kompilator bedzie cie ostrzegal przy wywolaniu edytuj(edit_p->preheat+3, 1)

J.

Jakos prosto, automagicznie sie nie da. Moze jakos tak (zeby nie kopiowac procedury edytujacej):

edit_int(int * xint) { (*xint)++; }

edit_char(char * xchar) { int tmp = xchar[0]; edit_int(&tmp); xchar[0] = tmp; }

Komplikuje sie jesli chodzi Ci o cala tablice (wszedzie widze [6]), trzeba by miec tymczasowa tablice. Druga wada to ze traci sie sprawdzenie wartosci.

Krzysiek Rudnik

Proponujesz reinterpret_cast<char *>&edit_pointer ?? Cos nie chce... ;-(

Nie sprawdzalem, ale to nie w ta strone ma dzialac... to znaczy troche. Musialbym najpierw wiedziec ze wskaznik jest na char a nie na int.

[...]

Hint. Kiedys w asmie stworzylem sobie taki uklad menu, ktory dzialal "sam z siebie" tzn. wystarczylo dopisac pozycje menu w definicji menu i reakcje na enter. Teraz chce osiagnac cos podobnego. Ale juz widze ze cos nie bardzo.

No wlasnie, myslalem ze za malo wiem na temat C i dlatego zapytalem.

[...]

Odpuszczam... kilkadziesiat bajtow to nie majatek. Za to przejrzystosc spora.

[...]

Spoko, poradzilem sobie dwoma funkcjami, osobnymi dla typow. Jak mi pamieci zacznie brakowac to moze wtedy zaczne kombinowac. A propo's kompilatora i warninga... to mam jeszcze male 2 pytanka.

Dlaczego zapis: eeprom_set temp; memcpy(&temp,&ustawienia,sizeof(eeprom_set));

wywoluje warninga: menu.c:189: warning: implicit declaration of function `memcpy'

ustawienia tez sa typu eeprom_set. Identyczna definicja kilkanascie linijek nizej w innej funkcji nie wywoluje tego warninga. Nie rozumiem dlaczego kompilator uwaza ze ta deklaracja jest "ukryta" czy "bezgraniczna".

I kolejny problem warninga podczas zapisywania do eepromu.

eeprom_write_block(&ustawienia,&eeust[setting_number],sizeof(ustawienia)); menu.c:215: warning: passing arg 2 of `eeprom_write_block' discards qualifiers from pointer target type

gdzie: eeprom_set ustawienia; static const eeprom_set eeust[3] __attribute__((section(".eeprom"))) ={ {{1,2,3,4,5,6},{0,0,0,0,0,0},{255,255,255,255,255,255},{0,1,2,3,1,2},"1 zestaw nastaw "}, {{2,3,4,5,6,7},{0,0,0,0,0,0},{255,255,255,255,255,255},{0,0,0,0,0,0},"2 zestaw nastaw "}, {{3,4,5,6,7,8},{0,0,0,0,0,0},{255,255,255,255,255,255},{0,0,0,0,0,0},"3 zestaw nastaw "}};

Rozumiem ze nie podoba mu sie to ze adres dostarczam w malostrawnej dla niego postaci. Czy tak ??

Bo:

a) to jest konstrukcja z C++, a nie z C, w ktorym, jak sie domyslam, piszesz. :-) b) paramer podaje sie w nawiasach: reinterpret_cast<char *>(&edit_pointer).

W C piszesz zwyczajnie: (char*) &edit_pointer.

Pozdrawiam Piotr Wyderski

Jasne. Jak rozumiem przez C generalnie rozumie sie ANSI C z pozniejszymi zmianami typu C99 ?? A CPP to pochodna C, rozniaca sie... no wlasnie... czym ??

zapomniales string.h zaincludowac.

Kompilator sam sobie wtedy deklaruje funkcje memcpy - tzn domysla sie parametrow.

Bo teraz memcpy juz jest zdefiniowana :-)

Nie, odrzuca jakis niuans w typie .. moze mu sie nie podoba ze adres tablicy typu const przekazujesz w miejsce parametru ktory const nie ma .. czyli potencjalny problem uzmienniania stalej ?

J.

Jasne... ;-( A propos gdzie mozna znalezc jakis opis gdzie siedzi jaka funkcja ?? Pomijajac te dostepne w plikach *.h ktore ewentualnie mozna znalezc recznie.

W sumie madre i glupie toto... wolalbym dostac error niz warninga ;-(

Jasne. Poszukam, popatrze... ;-)

Siedziec to one siedza w bibliotece. Powinienes gdzies zrodla nawet znalezc.

Zaszlosc historyczna - kiedys C tego w ogole nie sprawdzal, tylko wywolywal jak kazales.

J.

Jasne.

To moze niech juz ten warning zostanie ;-)))

Thu, 13 May 2004 13:21:46 +0200, na pl.misc.elektronika, Milosz Skowyra napisał(a):

Jest jeszcze narzedzie avr-ar, ktorym mozna obejrzec zawartosc biblioteki*.a Inna sprawa, ze w avr-libc nie ma wielkiego asortymentu - wiekszosc siedzi w podstawowej libc.a, matematyka w libm.a - i jeszcze jest pare mniejszych na rozne wersje vprintf.

Jeszcze mozna sprobowac z opcja -Werror / powoduje potraktowanie warninga jako error ( kompilacja zostaje zatrzymana, ale komunikat chyba niestety sie nie zmienia ).

Zmienic rozszerzenie pliku na .cpp

Krzysiek Rudnik

Fakt. Dzieki.

Ale zawsze mozna je sobie popodgladac ;-)

O dzieki. Poprobuje.

No i jeszcze zmienic makefile, ale to kiepski pomysl byl... program z samych bledow sie sklada ;-)))

Najrozsadniej przyjac taka interpretacje.

C++ to zupelnie osobny jezyk, majacy z dzisiejszym C tyle samo wspolnego, co czlowiek z szympansem: wspolnego przodka. :->

Pozdrawiam Piotr Wyderski

Kazales mu uzyc nieznanej funkcji. :-) #include opowieniego pliku zalatwi sprawe.

Pewnie drugim argumentem tej funkcji jest cos*, a nie const cos*, a parametr jest typu const cos*.

Nie, zwroc uwage na const w drugiej linijce. Dajesz procedurze obiekt tylko odczytywalny jako taki, ktory mozna rowniez zapisac, wiec kompilator popadl w zadume i urodzil warninga. :-)

Pozdrawiam Piotr Wyderski

Nie ma to jak solidne wyjasnienie ;-) Dzieki. Probowalem wczoraj troche upic kompilator, ale sie nie dal ;-(

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required