Dziwne odczyty i zachowanie kompilatora AVRGCC przy pracy z progmem w C?

Thu May 06, 2004 4:44 pm   

On Thu, 06 May 2004 15:51:19 +0200, Milosz Skowyra wrote:

To nie jest gwalcenie, tylko jawna zmiana typu.
Zakladamy ze programista wie co robi :-)


Ale mi chodzilo o
lcd_port=polish_chars[f] ;


I prawidlowo, bo co tu kazales?
a) bierzemy f-ty element z tablicy polish_chars - nie adres,
ale juz wartosc, czyli te twoje 0x0C np

b) odczytujemy bajt pamieci programu spod adresu bedacego odczytana
poprzednio wartoscia [czyli 0x000C]


A mi sie wydaje ze to na przyszlosc - i tak trzeba wskaznik powiekszyc


bo tu realizujemy b)


wlasnie rozszerzamu uchar do wskaznika czy int


IMHO - bo mu dokladnie wlasnie to kazales.



Bo na ile sie domyslam to:
a) zadeklarowales tablice wskaznikow pol_znak,
wskazujacych na progmem [kompilator musi to wiedziec zeby wlasciwe
instrukcje stosowac].
b) tablica jest jednoelementowa i zawiera adres [wskazanie w/g
Bieleckiego] polish_chars

c) pol_znak[f] jest f-tym wskaznikiem w tablicy pol_znak - czyli
smieciami, bo poza tablica,

d) odczytany wskaznik traktujemy jako adres bajtu w progmem, ktory
pobieramy


f do R30,31


elementy pol_znak sa dwubajtowe, wiec trzeba pomnozyc f przez 2


Dziwne, ale to jest widac adres poczatkowy pol_znak


pobieramy z pamieci polznak[f] - dwa bajty, bo to wskaznik


A to jest lekko dziwaczne - jakby kolejne posrednie adresowanie,
ty nie sklamales z tym lcd_port=pgm_read_byte(pol_znak[f]) ?


Zaraz - jakim cudem to moze dzialac ?


Milosz - my naprawde dobrze radzimy - albo przeczytasz ze zrozumieniem
ksiazke, albo .. na marchewce tez sie mozna dorobic.

J.

Fri May 07, 2004 1:40 pm   

"J.F." wrote:


Jasne... sadzac z ksiazeczki nazywa sie to typecast ))


W asm-ie wiem dokladnie do robie... w C ma to robic za mnie
kompilator... ale za malo piffa z nim wypilem )) Ale sens powyzszego
jest jasny.


Dziala, tylko ze na starcie programu kopiuje cala tablice do RAM, a tego
wlasnie chce uniknac.


Jasne. Probu i wysylke przeprowadzilem w czasie kiedy rozsadek poszedl
na spacer. Dlatego takie wyniki. Teraz sam widze co powyprawialem ;-(((


Nie ma szans, pisalem ze rozsadek mial wolne. Wszystko bylo Copy&Paste.


Nie wiem, ale raczej zbieg okolicznosci Pierwszy znak jest zle
definiowyany, potem ok.


No i wlasnie wrocilem z przebiegu po moim "ukochanym" miescie Opolu.
Bylem w 6 ksiegarniach i tak naprawde to nie ma co kupic. W jenej
znalazlem pozycje "C" Bjorna Stroustrupa, ale w skorze z odcisnietymi
literkami za jedyne 144 pln. Reszta to malo ciekawe dla mnie pozycje,
dotyczace najczesciej obiektowych wersji C, samouczki C, a nawet "C w 24
godziny". Co do ANSI C to nie znalazlem ani jednej pozycji. Z
ciekawostek byly 2 ksiazki typu 99 najczestszych bledow w C++, nawet
ciekawe. Ale jakies 80% porad dotyczylo wersji okienkowych. W koncu juz
w trzeciej bibliotece znalazlem "C" K&R, a dodatkowo pozyczylem z
sentymentu "Sam na sam z jezykiem C" Bieleckiego, opisujacy HiSoft C
na.... ZX Zaczyna sie od slow LOAD ""
Na razie mam "C" K&R, Kieszkonkowy leksykon C i Borland C++. Mysle ze
wystarczy, a jak nie to kupie cos naprawde sensownego ale w interq ))
Dalsze pytania nie wykluczone... Jak bede we Wrocku to stawiam piffo.
Dzieki.

PS. Ksiazki ogrodnicze o uprawie marchewki byly wszedzie... za wyjatkiem
ksiegarni technicznej ;-)

--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek@fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|

Fri May 07, 2004 1:41 pm   

"J.F." wrote:


Nie chcial Milosz nosic teczki to ponosi marcheweczki ))

--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek@fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|

Fri May 07, 2004 3:55 pm   

On Fri, 07 May 2004 16:40:04 +0200, Milosz Skowyra wrote:

Hm, moze przeceniam avrgcc, ale skoro zadeklarowales tablice w
progmem, to nie powinien tego robic.



Bielecki w C byl dobry. Co prawda specyficzny to autor i ksiazki mial
trudne, ale jak go zrozumiesz to i C zrozumiesz
Z tym ze wersja ZX moze byc bardzo uproszczona.

J.

Sat May 08, 2004 11:04 am   

"J.F." wrote:


A kicha... nie dziala. Usiluje czytac z RAM-u ale wczesniej do niego nie
kopiuje stringa.
MOV R14,R21 //w r14-15 adres, poprawny bo napis w flash
leci od 0x0021
LDI R21,0x00
MOV R15,R21

ale samo czytanie odbywa sie z ramu.
MOV R31,R15
MOV R30,R14
LD R24,Z+
MOV R14,R30
MOV R15,R31
OUT 0x18,R24


Zgadza sie, pamietam ksiazki Bieleckiego z okresu ZX-a (bylem gdzies w
4-5 klasie podstawowki) i pozniejsze z pecetologii. Ciezki do czytania i
rozumienia, ale za to trzeba mu przyznac ze wiedze posiadal spora.

--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek@fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|

Sat May 08, 2004 2:25 pm   

Sat, 08 May 2004 14:04:01 +0200, na pl.misc.elektronika, Milosz Skowyra
napisał(a):


To juz nie wiem jak robisz. Taki tu prosty przyklad różnych składni:

const char Tx1[] PROGMEM = "One";
.....................
i=1;
x=pgm_read_byte(Tx1);
x=pgm_read_byte(&Tx1[i]);
i=2;
x=pgm_read_byte(Tx1 + i);

generuje :

i=1;
180: 81 e0 ldi r24, 0x01 ; 1
182: 90 e0 ldi r25, 0x00 ; 0
184: 90 93 70 00 sts 0x0070, r25
188: 80 93 6f 00 sts 0x006F, r24
x=pgm_read_byte(Tx1);
18c: e6 e9 ldi r30, 0x96 ; 150
18e: f0 e0 ldi r31, 0x00 ; 0
190: 84 91 lpm r24, Z
192: 80 93 6c 00 sts 0x006C, r24
x=pgm_read_byte(&Tx1[i]);
196: 31 96 adiw r30, 0x01 ; 1
198: 84 91 lpm r24, Z
19a: 80 93 6c 00 sts 0x006C, r24
i=2;
19e: 82 e0 ldi r24, 0x02 ; 2
1a0: 90 e0 ldi r25, 0x00 ; 0
1a2: 90 93 70 00 sts 0x0070, r25
1a6: 80 93 6f 00 sts 0x006F, r24
x=pgm_read_byte(Tx1 + i);
1aa: 31 96 adiw r30, 0x01 ; 1
1ac: 84 91 lpm r24, Z
1ae: 80 93 6c 00 sts 0x006C, r24


--
Pozdrowienia
Jurek Szczesiul

Sat May 08, 2004 3:04 pm   

Jurek Szczesiul wrote:


Przeciez Jarek ewidentnie pytal czy dziala sekwencja.

wyzej.
Mozesz zreszta pokazac co da w Twoim przypadki x=Tx1[i];

--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek@fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|

Sat May 08, 2004 3:22 pm   

Sat, 08 May 2004 18:04:32 +0200, na pl.misc.elektronika, Milosz Skowyra
napisał(a):


OK, OK
Watek sie cokolwiek pokomplikowal.



x=Tx1[i];
178: 80 91 97 00 lds r24, 0x0097
17c: 80 93 6c 00 sts 0x006C, r24

--
Pozdrowienia
Jurek Szczesiul

Sat May 08, 2004 3:36 pm   

On Sat, 8 May 2004 17:25:03 +0200, Jurek Szczesiul wrote:

Wow - popatrzcie jak optymalizator ladnie sledzi jakie stale wpisujemy
do i

Sat May 08, 2004 5:23 pm   

"J.F." wrote:


Zauwaz rowniez ze wypromowal chara do inta.

--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek@fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|

Sat May 08, 2004 5:28 pm   

Jurek Szczesiul wrote:


Niby tak, tylko ze zoptymalizowalo pod katem odczytu z ramu, a to co
potrzebujemy lezy w romie. O tym rozmawialismy z J.F. IMHO GCC traktuje
wszystko, jak dane umieszczone w pamieci ram, nie patrzac na definicje
obszaru w ktorym zmienna zostala zadeklarowana. Tylko specyficzne
komendy odwoluja sie za pomoca LPM, SPM czy ELPM.

--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek@fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|

Sat May 08, 2004 7:00 pm   

Sat, 08 May 2004 20:28:16 +0200, na pl.misc.elektronika, Milosz Skowyra
napisał(a):


O, teraz wlasnie jest poruszone sedno sprawy. Wlasnie tak jest, bo gcc
pochodzi ze swiata ciaglej pamieci, gdzie nie ma pod takimi samymi adresami
ramu, flasha i eepromu. Wskaznik jest 2-bajtowy i nie ma w nim miejsca na
okreslenie, o ktora pamiec chodzi ( np. w prostym kompilatorku dla 51
mialem wskazniki 3-bajtowe - i tam wszystkie odwolania przebiegaly
tradycyjnie - 3. bajt jednoznacznie okreslal typ pamieci ). Wiec zrobiono
za pomoca makr i funkcji. Chociaz ostatnio coraz czesciej na liscie avr-gcc
pojawiaja sie rozwazania, ze chyba wypadaloby cos z tym w koncu zrobic :-)

--
Pozdrowienia
Jurek Szczesiul

Sat May 08, 2004 10:31 pm   

On Sat, 8 May 2004 22:00:04 +0200, Jurek Szczesiul wrote:

Ale w tym przypadku mamy konkretna tablice, w ktorejs jakos sie
znalazlo miejsce na atrybut "progmem". Printf czy inna funkcja
mialby problemy z okresleniem o ktora pamiec chodzi po wskazniku - ale
tablica[i] kompilator moglby prawidlowo skompilowac, bo wie gdzie
sie ta tablica miesci.


tak ... zmienic procka Bo ten zawsze bedzie sprawial takie
klopoty.

J.

Sun May 09, 2004 8:09 am   

J.F. wrote:


Mozna by to obejsc gdyby narzucic dodatkowy warunek na zgodnosc typow -
atrybut wskaznika jest integralna czescia typu i wskazniki na rozne
typu pamieci sa niekompatybilne. Wtedy w naglowku funkcji moznaby
okreslic jakiego wskaznika oczekuje.



To jest zdaje tzw architektura Harward (nie chce mi sie teraz
wyciagac mojej starej pracy dyplomowej o TMS320),

Krzysiek Rudnik

Sun May 09, 2004 8:59 am   

Sun, 09 May 2004 01:31:17 +0200, na pl.misc.elektronika, J.F. napisał(a):


W zasadzie tak - ja zbyt gleboko tego nie znam, tylko temat czesto wraca na
grupach avrfreaks i tak mniej wiecej 'wiedzacy' wyjasniaja : rozdzielone
obszary sa dla gcc klopotem i zastosowano rozne protezy zeby to obejsc -
wyszlo akurat tak jak jest ( wyglada, ze atrybut obszaru jest raczej
informacja dla binutilsow avr a sam kompilator skorzystac z tego nie umie )


Wiec raczej moze kompilator, ile to IAR kosztuje ? ;-)

BTW - jakos IMHO nie pasuje roszczenie zbytnich pretensji do narzedzia GNU
- zawsze odpowiadaja, ze jak cos nie tak to ochotnicy mile widziani :-)

--
Pozdrowienia
Jurek Szczesiul