AVRGCC i ja raz jeszcze... ;-)

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 ??

Reply to
Milosz Skowyra
Loading thread data ...

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.

Reply to
J.F.

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

Reply to
Krzysztof 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.

Reply to
Milosz Skowyra
[...]

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 ??

Reply to
Milosz Skowyra

Dzieki.

Reply to
Milosz Skowyra

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

Reply to
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 ??

Reply to
Milosz Skowyra

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.

Reply to
J.F.

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... ;-)

Reply to
Milosz Skowyra

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.

Reply to
J.F.

Jasne.

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

Reply to
Milosz Skowyra

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 ).

Reply to
Jurek Szczesiul

Zmienic rozszerzenie pliku na .cpp

Krzysiek Rudnik

Reply to
Krzysztof Rudnik

Fakt. Dzieki.

Ale zawsze mozna je sobie popodgladac ;-)

O dzieki. Poprobuje.

Reply to
Milosz Skowyra

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

Reply to
Milosz Skowyra

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

Reply to
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

Reply to
Piotr Wyderski

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

Reply to
Milosz Skowyra

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.