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