Dariusz Zolna pisze:

> Nie. Ale właśnie się wyjaśniło.
> Kompilator nie ostrzega, że pgm_read_byte() działa tylko z krótkimi
> adresami, bootloader siedzi powyżej 64k, a ja wszystkie dane typu
> teksty/grafika trzymam we flash, no i jak tylko program dochodził do
> miejsca, w którym powinien wyświetlić testowy napis, procek się resetował.
> No i jak zwykle nie tam gdzie szukałem :)

No to pozostaje korzystać z pgm_read_byte_far() i podobnych. Uważaj też
na funkcje typu strcpy_P, printf_P, memcpy_P itd - nie zadziałają bo
trzeba im podać wskaźniki 16- a nie 32-bitowe. Podobnie bez dodatkowego
"obejścia" nie zadziałają wskaźniki na funkcje, używane np. w tablicach
skoków. Ot taka "zaleta" dużej pamięci w procku bądź co bądź
8/16-bitowym. Przerabiałem to ostatnio w zdwojonej formie walcząc z
jeszcze większym ATmega2561.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

Adam Dybkowski pisze:
> No to pozostaje korzystać z pgm_read_byte_far() i podobnych. Uważaj też
> na funkcje typu strcpy_P, printf_P, memcpy_P itd - nie zadziałają bo
> trzeba im podać wskaźniki 16- a nie 32-bitowe. Podobnie bez dodatkowego
> "obejścia" nie zadziałają wskaźniki na funkcje, używane np. w tablicach
> skoków. Ot taka "zaleta" dużej pamięci w procku bądź co bądź
> 8/16-bitowym. Przerabiałem to ostatnio w zdwojonej formie walcząc z
> jeszcze większym ATmega2561.

Tak, już napisałem swoje wersje tych wszystkich funkcji (przynajmniej
tych, które używam). Szkoda tylko, że kompilator nie przypomina o tym.
A właśnie, jak zrobić wskaźniki do funkcji w tablicach? Wprawdzie teraz
nie korzystam z tego, ale może się przydać na przyszłość. Dla wskaźników
w parametrach funkcji mam zrobione makro (choć też troche upierdliwe w
użyciu, bo stringi muszę teraz mieć ponazywane, a nie umieszczone jako
PSTR("...") bezpośrednio w wywołaniu funkcji).

Dariusz Żołna

do góry

> No to pozostaje korzystać z pgm_read_byte_far() i podobnych. Uważaj też
> na funkcje typu strcpy_P, printf_P, memcpy_P itd - nie zadziałają bo
> trzeba im podać wskaźniki 16- a nie 32-bitowe. Podobnie bez dodatkowego
> "obejścia" nie zadziałają wskaźniki na funkcje, używane np. w tablicach
> skoków. Ot taka "zaleta" dużej pamięci w procku bądź co bądź
> 8/16-bitowym. Przerabiałem to ostatnio w zdwojonej formie walcząc z
> jeszcze większym ATmega2561.

Co do wskaznikow na funkcje to nie wydaje mi sie, zeby w ATMega128 byl z
tym problem. CALL wykorzystuje adres slowa, czyli w 16 bitach moze
skakac po calym 128 kB obszarze. Problem zaczyna sie w ATMega256.
Wewnetrzne tabele skokow generowane przez gcc odbywaja sie poprzez ICALL
i rejestr Z, czyli tez maja mozliwosc skoku po calych 128kB.
Niestety w gcc nie ma zaimplementowanych modeli pamieci, implementacja
24-bitowych wskaznikow ze wzgledu na strukture gcc tez jest trudna, a
32-bitowe to marnotrawstwo. Ale widze, ze powoli jednak rozwoj avr-gcc
idzie w kierunku modeli pamieci i bedziemy mieli cos znane z czasow
Borlanda i 80286.

do góry

Dariusz Zolna pisze:
> Adam Dybkowski pisze:
>> No to pozostaje korzystać z pgm_read_byte_far() i podobnych. Uważaj
>> też na funkcje typu strcpy_P, printf_P, memcpy_P itd - nie zadziałają
>> bo trzeba im podać wskaźniki 16- a nie 32-bitowe. Podobnie bez
>> dodatkowego "obejścia" nie zadziałają wskaźniki na funkcje, używane
>> np. w tablicach skoków. Ot taka "zaleta" dużej pamięci w procku bądź
>> co bądź 8/16-bitowym. Przerabiałem to ostatnio w zdwojonej formie
>> walcząc z jeszcze większym ATmega2561.
>
> Tak, już napisałem swoje wersje tych wszystkich funkcji (przynajmniej
> tych, które używam). Szkoda tylko, że kompilator nie przypomina o tym.

Nie ma jak. Zobacz jak wyglada definicja tych funkcji. Jedyna mozliwosc
to wywalanie ostrzezenia przez sama biblioteke przy wywolywaniu ich na
procesorach z >64kB FLASH. Co zreszta ma maly sens, bo gcc domyslnie
umieszcza stale na poczatku programu, czyli dopoki one nie przekrocza
64kB korzystanie z wersji near tych funkcji jest zupelnie ok. Z kolei
wersje far sa bezpieczne (chociaz nie wiem czy dzialaja na procesorach
do 64kB FLASH), ale czasochlonniejsze i FLASHochlonniejsze.
Natomiast jesli korzystales z wersji near, a wskaznik miales
zadeklarowany prawidlowo jako 32-bitowy to kompilator musial wywalic
ostrzezenie (chyba, ze je blokujesz). Tak czy siak, winny byles ty :)

> A właśnie, jak zrobić wskaźniki do funkcji w tablicach? Wprawdzie teraz
> nie korzystam z tego, ale może się przydać na przyszłość. Dla wskaźników
> w parametrach funkcji mam zrobione makro (choć też troche upierdliwe w
> użyciu, bo stringi muszę teraz mieć ponazywane, a nie umieszczone jako
> PSTR("...") bezpośrednio w wywołaniu funkcji).

Np. tak:
const FuncPtr FuncPtrTable[] PROGMEM=
{f1, f2, f3};

I wywolanie:
FPtr=(FuncPtr)pgm_read_word(&FuncPtrTable[funcno]);

*FPtr();

BTW. A propos twojego bootloadera. Piszesz, ze jest strasznie dlugi.
Wiesz, ze w tej sekcji musi byc tylko maly fragment wykonujacy SPM,
raptem pare bajtow, cala reszta moze byc w normalnej pamieci, co
ogranicza rozmiar bootloadera.

do góry