NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Dziwne odczyty i zachowanie kompilatora AVRGCC przy pracy z progmem w C?
Goto page Previous 1, 2, 3, 4, 5, 6, 7 Next
J.F.
Guest
Guest
Sun May 09, 2004 7:53 pm
On Sun, 9 May 2004 16:12:01 +0200, Piotr Wyderski wrote:
Quote:
Jurek Szczesiul wrote:
I tak to jest wlasnie zrobione dla '51 - dodatkowo dla zmiennych (stalych)
okresla sie zadany obszar ( np. code, data, idata, xdata )
A w jaki sposob to konkretnie wyglada? Wprowadzili nowe slowa
kluczowe do jezyka, czy tez korzystaja z __attribute__((...))?
I tak to jest wlasnie zrobione dla '51 - dodatkowo dla zmiennych (stalych)
okresla sie zadany obszar ( np. code, data, idata, xdata )
A w jaki sposob to konkretnie wyglada? Wprowadzili nowe slowa
kluczowe do jezyka, czy tez korzystaja z __attribute__((...))?
w '51 to nei wiem, ale w AVR attribute
http://users.rcn.com/rneswold/avr/c957.html
J.
J.F.
Guest
Guest
Sun May 09, 2004 7:53 pm
On Sun, 09 May 2004 12:10:12 +0200, Milosz Skowyra wrote:
Quote:
"J.F." wrote:
tak ... zmienic procka
Bo ten zawsze bedzie sprawial takie
klopoty.
Tez wyjscie... a co bys polecal ? Irek promuje H8 Renesansa, ponoc
bardzo przyjemne. Jeszcze sie osobiscie nie przygladalem. Pod wzgledem
obudowania peryferiami atrakcyjny moze byc Cypres z rdzeniem '51 i FPGA,
ale raczej w Polsce malo dostepny.
tak ... zmienic procka
Bo ten zawsze bedzie sprawial takie
klopoty.
Tez wyjscie... a co bys polecal ? Irek promuje H8 Renesansa, ponoc
bardzo przyjemne. Jeszcze sie osobiscie nie przygladalem. Pod wzgledem
obudowania peryferiami atrakcyjny moze byc Cypres z rdzeniem '51 i FPGA,
ale raczej w Polsce malo dostepny.
51 bedzie sprawiala takich klopotow jeszcze wiecej :-)
Z maluchow to chyba motorolki hc11 i hc05 mialy jednolita adresacje.
J.
Piotr Wyderski
Guest
Guest
Sun May 09, 2004 8:03 pm
J.F. wrote:
Quote:
mozna zrobic tak jak zrobiono:
prog_char: char __attribute__((progmem))
PGM_P : prog_char const*
Kompilator sie zorientuje ...
prog_char: char __attribute__((progmem))
PGM_P : prog_char const*
Kompilator sie zorientuje ...
....i po pierwszym przypisaniu do zwyklego wskaznika zgubi te
informacje i znow niczego biedaczek nie bedzie wiedzial. :-)
Quote:
ale jak zmusic printf i inne funkcje
zeby sie po adresie orientowaly ?
zeby sie po adresie orientowaly ?
Bez "dynamicznego typowania", czyli kodowania typu
obszaru pamieci we wskazniku wyglada to na problem
nierozstrzygalny podczas statycznej analizy przeplwu
danych. :-)
Quote:
Niby mozna tak jak kolega tu proponowal - wskazniki 3 bajtowe,
pierwszy wskazuje obszar ... tylko ze wtedy zegnaj wydajnosc
pierwszy wskazuje obszar ... tylko ze wtedy zegnaj wydajnosc
No to jest wlasnie rodzaj takiego dynamicznego typowania.
Quote:
Tylko jak to zrobic jesli niektorzy chca 64KB ram, 256KB ROM
i oszczedne 16-bitowe wskazniki.
i oszczedne 16-bitowe wskazniki.
Za pomoca bankowania. :-)
Pozdrawiam
Piotr Wyderski
Adam Dybkowski
Guest
Guest
Sun May 09, 2004 8:48 pm
Milosz Skowyra wrote:
Quote:
tak ... zmienic procka Bo ten zawsze bedzie sprawial takie
klopoty.
Tez wyjscie... a co bys polecal ? Irek promuje H8 Renesansa, ponoc
bardzo przyjemne. Jeszcze sie osobiscie nie przygladalem. Pod wzgledem
obudowania peryferiami atrakcyjny moze byc Cypres z rdzeniem '51 i FPGA,
ale raczej w Polsce malo dostepny.
Bo ten zawsze bedzie sprawial takie
klopoty.
Tez wyjscie... a co bys polecal ? Irek promuje H8 Renesansa, ponoc
bardzo przyjemne. Jeszcze sie osobiscie nie przygladalem. Pod wzgledem
obudowania peryferiami atrakcyjny moze byc Cypres z rdzeniem '51 i FPGA,
ale raczej w Polsce malo dostepny.
Najlepiej przejsc od razu na ARMa. Procesory z tym jadrem wytwarza
conajmniej kilkudziesieciu roznych producentow. Znajdziesz je m.in. u
Philipsa, Atmela, OKI, TI, Intela. Kompilator gcc oczywiscie jest i
bardzo ladnie sobie radzi. Przewaga nad AVR'ami jest wspolna przestrzen
danych/programu i praktycznie brak ograniczen w adresowaniu (32 bity).
Oczywiscie jest to szybki RISC.
--
Adam Dybkowski
adybkows@amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/
Jan Dubiec
Guest
Guest
Sun May 09, 2004 9:34 pm
On Sun, 09 May 2004 22:53:49 +0200, J.F. <jfox_nospam@poczta.onet.pl> wrote:
Quote:
On Sun, 9 May 2004 13:16:23 +0200, Piotr Wyderski wrote:
Krzysztof Rudnik 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.
Jak to sobie konkretnie wyobrazasz? Tj. czym rozni sie
const char* p; wskazujace na dane w RAM od
const char* p; wskazujace na dane w ROM?
mozna zrobic tak jak zrobiono:
prog_char: char __attribute__((progmem))
PGM_P : prog_char const*
Kompilator sie zorientuje ... ale jak zmusic printf i inne funkcje
zeby sie po adresie orientowaly ?
Zmuszać to chyba nie trzeba ponieważ w avr-libc są przecież funkcje z
Krzysztof Rudnik 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.
Jak to sobie konkretnie wyobrazasz? Tj. czym rozni sie
const char* p; wskazujace na dane w RAM od
const char* p; wskazujace na dane w ROM?
mozna zrobic tak jak zrobiono:
prog_char: char __attribute__((progmem))
PGM_P : prog_char const*
Kompilator sie zorientuje ... ale jak zmusic printf i inne funkcje
zeby sie po adresie orientowaly ?
Zmuszać to chyba nie trzeba ponieważ w avr-libc są przecież funkcje z
postfiksem _P. Problem jest w tym że w przypadku dużych AVR-ów wskaźki
wskazujące na dane znajdujące się w pamięci programu powinny być 17 (a
w przyszłości chyba i 1
bitowe a nie 16 bitowe.
[.....]
Quote:
To jest zdaje tzw architektura Harward
Zgadza sie, pamieci danych i programu sa fizycznie rozdzielone.
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
Zgadza sie, pamieci danych i programu sa fizycznie rozdzielone.
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM.
Właśnie po to
są te wszyskie _P funkcje.
Poza tym w architekturze harwardzkiej przestrzeń adresowa z definicji
jest podzielona na dwa obszary i stosowane są różne instrukcje do
zapisu/odczytu danych z tych obszarów. Jest podzielona przynajmniej
logicznie - fizycznie może być różnie - szyna adresowa/danych może być
wspólna a tylko szyny sterujące rozdzielone (np. MCS-51) albo, ze
względu na wydajność (a AFAIK właśnie o to chodziło twórcom tej
architektury), wszystkie szyny zdublowane dla każdego z obszarów jak
chyba jest w zdecydowanej większości DSP (np. w starym ale jarym
ADSP-218x Analoga). I tak jest również w AVR, tylko że tam wszystko
dotyczące pamięci programu jest ukryte wewnątrz kości - tak przynajmniej
wynika z lektury dejtaszitów (nigdy nie używałem tych kości w praktyce).
BTW. Wcale nie należy się tak bardzo przyzwyczajać do schematu że
pamięć programu to jest jakiś ROM. Np. we wspomnianych Analogach, ze
względu na wydajność, pamięcią programu jest RAM - podczas startu kod
jest ładowany do RAM z jakiegoś ROM lub przez IDMA z "procesora
nadrzędnego".
[.....]
Quote:
Ech, to gdzie dostac ARMa w przyzwoitej cenie, detalicznej ilosci i
obudowie nie BGA ?
W Memec-u? Ewentualnie, prawie po sąsiedzku (w MSC), możesz kupić H8.
obudowie nie BGA ?
W Memec-u? Ewentualnie, prawie po sąsiedzku (w MSC), możesz kupić H8.
Regards,
/J.D.
--
Jan Dubiec, jdx@slackware.pl, mobile: +48 506 790442
Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.
J.F.
Guest
Guest
Sun May 09, 2004 10:00 pm
On Sun, 09 May 2004 23:48:36 +0200, Adam Dybkowski wrote:
Quote:
Najlepiej przejsc od razu na ARMa. Procesory z tym jadrem wytwarza
conajmniej kilkudziesieciu roznych producentow. Znajdziesz je m.in. u
Philipsa, Atmela, OKI, TI, Intela.
conajmniej kilkudziesieciu roznych producentow. Znajdziesz je m.in. u
Philipsa, Atmela, OKI, TI, Intela.
Adamie, ale moze konktretniej - gdzie w UE kilka sztuk, po ile,
i czemu w BGA ? :-(
J.
Zbych
Guest
Guest
Sun May 09, 2004 10:04 pm
Pewnego dnia Jan Dubiec przemówił ludzkim głosem:
Quote:
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM.
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM.
Skoro i tak wskaźnik zrobi się dłuższy niż 2 bajty to można by
wykorzystać najstarszy bit z 3 bajtu do rozróżniania obszarów.
--
*Warning*: Dates in Calendar are closer than they appear.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
Milosz Skowyra
Guest
Guest
Sun May 09, 2004 10:31 pm
Piotr Wyderski wrote:
Quote:
Tylko jak to zrobic jesli niektorzy chca 64KB ram, 256KB ROM
i oszczedne 16-bitowe wskazniki.
Za pomoca bankowania.
i oszczedne 16-bitowe wskazniki.
Za pomoca bankowania.
Tia... tylko w AVR bankowanie zaczyna sie od 64 KB. I dodatkowo nie
dziala tak jak powinno... ;-(
--
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 |
|-----------------------------------------------------|
J.F.
Guest
Guest
Sun May 09, 2004 10:39 pm
On 10 May 2004 00:34:22 +0200, Jan Dubiec wrote:
Quote:
To jest zdaje tzw architektura Harward
Zgadza sie, pamieci danych i programu sa fizycznie rozdzielone.
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM. Właśnie po to
są te wszyskie _P funkcje.
Zgadza sie, pamieci danych i programu sa fizycznie rozdzielone.
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM.
Właśnie po to
są te wszyskie _P funkcje.
To wlasnie musialoby byc zaszyte w procku - inny zakres adresow
ma ROM, inny RAM. To ze oprocz tego bylyby rozdzielone i mialy
osobne magistrale to osobna kwestia - ale adresacja jednolita.
Quote:
Poza tym w architekturze harwardzkiej przestrzeń adresowa z definicji
jest podzielona na dwa obszary i stosowane są różne instrukcje do
zapisu/odczytu danych z tych obszarów.
jest podzielona na dwa obszary i stosowane są różne instrukcje do
zapisu/odczytu danych z tych obszarów.
IMHO - te rozne instrukcje to juz nie z definicji.
Quote:
Jest podzielona przynajmniej logicznie - fizycznie może być różnie
Fizycznie w mikrokontrolerach to zawsze jest podzielona - inaczej sie
robi RAM a inaczej EE/E/P/ROM/Flash.
Quote:
BTW. Wcale nie należy się tak bardzo przyzwyczajać do schematu że
pamięć programu to jest jakiś ROM. Np. we wspomnianych Analogach, ze
względu na wydajność, pamięcią programu jest RAM - podczas startu kod
jest ładowany do RAM z jakiegoś ROM lub przez IDMA z "procesora
nadrzędnego".
pamięć programu to jest jakiś ROM. Np. we wspomnianych Analogach, ze
względu na wydajność, pamięcią programu jest RAM - podczas startu kod
jest ładowany do RAM z jakiegoś ROM lub przez IDMA z "procesora
nadrzędnego".
A no chyba ze tak.
J.
Jan Dubiec
Guest
Guest
Mon May 10, 2004 12:14 am
On Mon, 10 May 2004 01:39:04 +0200, J.F. <jfox_nospam@poczta.onet.pl> wrote:
Quote:
On 10 May 2004 00:34:22 +0200, Jan Dubiec wrote:
To jest zdaje tzw architektura Harward
Zgadza sie, pamieci danych i programu sa fizycznie rozdzielone.
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM. Właśnie po to
są te wszyskie _P funkcje.
To wlasnie musialoby byc zaszyte w procku - inny zakres adresow
ma ROM, inny RAM. To ze oprocz tego bylyby rozdzielone i mialy
osobne magistrale to osobna kwestia - ale adresacja jednolita.
No ale to byłoby rozwiązanie sprzętowe. I to dosyć "głębokie". Poza
To jest zdaje tzw architektura Harward
Zgadza sie, pamieci danych i programu sa fizycznie rozdzielone.
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM.
Właśnie po to
są te wszyskie _P funkcje.
To wlasnie musialoby byc zaszyte w procku - inny zakres adresow
ma ROM, inny RAM. To ze oprocz tego bylyby rozdzielone i mialy
osobne magistrale to osobna kwestia - ale adresacja jednolita.
No ale to byłoby rozwiązanie sprzętowe. I to dosyć "głębokie". Poza
tym nie jestem przekonany czy w takim przypadku rozdzielenie szyn
pamięci danych i programu miałoby sens - ów "dekoder adresów" mógłby
być wąskim gardłem. Trzebaby to przemyśleć.
Quote:
Poza tym w architekturze harwardzkiej przestrzeń adresowa z definicji
jest podzielona na dwa obszary i stosowane są różne instrukcje do
zapisu/odczytu danych z tych obszarów.
IMHO - te rozne instrukcje to juz nie z definicji.
Jest podzielona przynajmniej logicznie - fizycznie może być różnie
Fizycznie w mikrokontrolerach to zawsze jest podzielona - inaczej sie
robi RAM a inaczej EE/E/P/ROM/Flash.
Chodzi mi o to że mogą dzielić szynę adresową/danych. BTW. IMO to jest
jest podzielona na dwa obszary i stosowane są różne instrukcje do
zapisu/odczytu danych z tych obszarów.
IMHO - te rozne instrukcje to juz nie z definicji.
Jest podzielona przynajmniej logicznie - fizycznie może być różnie
Fizycznie w mikrokontrolerach to zawsze jest podzielona - inaczej sie
robi RAM a inaczej EE/E/P/ROM/Flash.
Chodzi mi o to że mogą dzielić szynę adresową/danych. BTW. IMO to jest
zaprzeczenie celu w jakim wymyślono architekturę harwardzką.
Regards,
/J.D.
--
Jan Dubiec, jdx@slackware.pl, mobile: +48 506 790442
Głęboka wiara wymaga płytkiego rozumu i nikłej wiedzy.
Artur Lipowski
Guest
Guest
Mon May 10, 2004 5:26 am
Piotr Wyderski wrote:
....
Quote:
Jak to sobie konkretnie wyobrazasz? Tj. czym rozni sie
const char* p; wskazujace na dane w RAM od
const char* p; wskazujace na dane w ROM?
Mozna oczywiscie dodac do jezyka nowe specyfikatory rodzaju
wskazywanej pamieci i zabronic konwersji miedzy nimi, ale to juz
nie bedzie C.
....
const char* p; wskazujace na dane w RAM od
const char* p; wskazujace na dane w ROM?
Mozna oczywiscie dodac do jezyka nowe specyfikatory rodzaju
wskazywanej pamieci i zabronic konwersji miedzy nimi, ale to juz
nie bedzie C.
....
No to Cię zaskoczę, bo to jest C. No może takie jakieś jeszcze młode i
nieopierzone, ale C pełną gębą 8-)
http://std.dkuug.dk/JTC1/SC22/WG14/
Jest duże prawdopodobieństwo, że GCC pójdzie właśnie tą drogą.
Pozdrawiam,
--
Artur Lipowski
Krzysztof Rudnik
Guest
Guest
Mon May 10, 2004 6:30 am
Zbych wrote:
Quote:
Pewnego dnia Jan Dubiec przemówił ludzkim głosem:
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM. :-)
Skoro i tak wskaźnik zrobi się dłuższy niż 2 bajty to można by
wykorzystać najstarszy bit z 3 bajtu do rozróżniania obszarów.
Co nie zabrania istnienia jednolitej adresacji. Np
najstarszy bit adresu wybiera czy dana czytamy z ram czy z rom.
W naszym przypadku to zadziałałoby dla adresów >= 0x10000, ale jak
rozpoznać czy adres np. 0x1000 dotyczy RAM czy ROM. :-)
Skoro i tak wskaźnik zrobi się dłuższy niż 2 bajty to można by
wykorzystać najstarszy bit z 3 bajtu do rozróżniania obszarów.
Ale ta metoda zmuszala by kompilator by kazde odwolanie do
pamieci poprzez wskaznik kompilowal jako sekwencje rozkazow
ze sprawdzeniem wskaznika i wybraniem odpowiedniej instrukcji
w zaleznosci od tego warunku. Kazde odwolanie - to znacznie
wydluzyloby kod.
Krzysiek Rudnik
Zbych
Guest
Guest
Mon May 10, 2004 7:49 am
Pewnego dnia Krzysztof Rudnik przemówił ludzkim głosem:
Quote:
w zaleznosci od tego warunku. Kazde odwolanie - to znacznie
wydluzyloby kod.
wydluzyloby kod.
A teraz gdy masz dwa zestawy funkcji, osobny do każdej przestrzeni
adresowej to myślisz, że kod jest krótki ? Według mnie w keilu
rozwiązali to naprawdę dobrze. Jeśli z góry wiesz do jakiej pamięci się
odwołujesz to jawnie deklarujesz typ pamięci przy wskaźniku. A jeśli
masz funkcje, które muszą obsłużyć dowolny typ pamięci to używasz
"kombinowanej" wersji wskaźnika.
--
*Warning*: Dates in Calendar are closer than they appear.
### /mail: bzb<at>poczta<dot>onet<dot>pl/ ###
Milosz Skowyra
Guest
Guest
Mon May 10, 2004 4:26 pm
Adam Dybkowski wrote:
Quote:
Najlepiej przejsc od razu na ARMa. Procesory z tym jadrem wytwarza
conajmniej kilkudziesieciu roznych producentow. Znajdziesz je m.in. u
Philipsa, Atmela, OKI, TI, Intela. Kompilator gcc oczywiscie jest i
bardzo ladnie sobie radzi. Przewaga nad AVR'ami jest wspolna przestrzen
danych/programu i praktycznie brak ograniczen w adresowaniu (32 bity).
Oczywiscie jest to szybki RISC.
conajmniej kilkudziesieciu roznych producentow. Znajdziesz je m.in. u
Philipsa, Atmela, OKI, TI, Intela. Kompilator gcc oczywiscie jest i
bardzo ladnie sobie radzi. Przewaga nad AVR'ami jest wspolna przestrzen
danych/programu i praktycznie brak ograniczen w adresowaniu (32 bity).
Oczywiscie jest to szybki RISC.
A mozesz podac jakis modelik ARM-a ktory bylby dostepny (nie w Elfie)
choc ulamkowo tak czesto jak '51 czy AVR-y ?? To w naszym kochanym kraju
chyba najwiekszy problem ;-(
--
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 |
|-----------------------------------------------------|
Adam Dybkowski
Guest
Guest
Mon May 10, 2004 8:40 pm
J.F. wrote:
Quote:
Najlepiej przejsc od razu na ARMa. Procesory z tym jadrem wytwarza
conajmniej kilkudziesieciu roznych producentow. Znajdziesz je m.in. u
Philipsa, Atmela, OKI, TI, Intela.
Adamie, ale moze konktretniej - gdzie w UE kilka sztuk, po ile,
i czemu w BGA ?
conajmniej kilkudziesieciu roznych producentow. Znajdziesz je m.in. u
Philipsa, Atmela, OKI, TI, Intela.
Adamie, ale moze konktretniej - gdzie w UE kilka sztuk, po ile,
i czemu w BGA ?
Nie bylo mowy, ze ma miec Flash w srodku. A bez tego w TQFP znalezc ARMy
nie problem. Zapytaj np. w JM Elektronik - moga sprowadzic rozne
atmelowe procki. Ja sie ostatnio w firmie bawie AT91R40008 i jest to
calkiem zacny procek. Ze sprowadzeniem kilku szt. nie mielismy problemu.
--
Adam Dybkowski
adybkows@amwaw.edu.pl
http://www.amwaw.edu.pl/~adybkows/
elektroda NewsGroups Forum Index - Elektronika Polska - Dziwne odczyty i zachowanie kompilatora AVRGCC przy pracy z progmem w C?
