Pole retezcu v PROGMEM FAR u XMega192; WinAVR2010

[Jan Waclawek]

Aha, ale to je dokumentovany problem - tu ukazku ste odcitovali prave z
dokumentacie...  :-)

Male ale uplne nepodstatne terminologicke upresnenie, hh8() nie je makro
ale direktiva asembleru, a tu hlasku sice vypise asembler, ale len preto,
lebo ju kompilator explicitne vlozil cez direktivu .warning 

V tom binarnom builde z
http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/
z 25.9.2012 je skutocne uz problem s tym asemblerom vyrieseny - ked som
kompiloval s prepinacom -S do asembleru a nasledne rucne upravil ten
inicializator (treba zapisat vsetky 3 byty osobitne ako lo8(foo), hi8(foo)
a hh8(foo), lebo .word foo skonci s chybou ked je foo na adrese vyssej ako
0xFFFF), tak to pekne zasemblovalo aj zlinkovalo podla ocakavania.

Uz som "poprosil" SprinterSB o novy binarny build,
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=1012096#1012096
, uvidime, ci sa k nemu dokope :-) Napriek tomu, ze je to momentalne
jediny aktivny prispievatel k avr-gcc, je to pokial viem amater, student,
bez akejkolvek podpory zo strany Atmelu.

Este tam pokojne moze byt aj kopa inych problemov, zatial nepoznam nikoho,
kto by to aktivne pouzival. Naviac "stock" avr-gcc nepodporuje uplne
vsetky nove obvody, nie je vylucene, ze tam chyba podpora pre niektore
xmegy, ale mozno ani nie (pokial viem, najviac sa narieka kvoli nejakym
malym tiny, ktore su silne problematicke a patche k nim su len od Atmelu
pre starsi kompilator).

----

Ten moj okec k "staremu sposobu" pristupu k far pamati je na
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=93874 aj
ked asi nezodpoveda vsetky otazky, najma nie inicializatory (co je ako
vidiet aj tak vo verzii binutils < 2.23 neriesitelne aj cez asembler,
musel by sa vymysliet mechanizmus obchadzajuci binutils - nemuselo by to
byt uplne nemozne). S vacsimi pamatami su rozne problemy aj ked sa
pouzivaju na program (ide o nepriame skoky, najma ak sa pouzivaju smerniky
na funkcie, ale niekedy vzniknu aj pri optimalizacii urciteho druhu
switch/case - v pripade zaujmu problematiku rozvediem), doporucujem prave
preto sa snazit data tlacit "hore" aby program ostal "dole", aj za cenu
menej pohodlneho pouzitia.

wek





----- Original Message ---------------
>Je to problém s makrem hh8(). Z dokumentace gcc-4.7.2 plyne, ¾e kód jako
>
>extern const __memx char foo;
>const __memx void *pfoo = &foo;
>
>bude fungovat, pokud binutils podporuje hh8(). Co¾ verze 2.23.1 asi
>splòuje. Jen¾e as stále vyhazuje warning assembling 24-bit address
>needs binutils... Tak¾e pøíslu¹ný patch do /gcc/config/avr.c ve verzi
>gcc-4.7.2 nebyl je¹tì aplikován a jak jsem se doèetl (pokud jsem to
>správnì pochopil), bude plná funkènost zaji¹tìna a¾ od verze 4.8. Tak¾e
>neztrácet trpìlivost, o problému se asi ví a pracuje se na nìm. Mì to
>spí¹ zajímalo jako technický problém, k nièemu to v zásadì nepotøebuji.
>
>
>Mrazík
>
>
>Jan Waclawek pí¹e v Ne 18. 11. 2012 v 08:02 +0100:
>> Priznam sa, ze to bola trochu neseriozna poznamka, lebo ja sam som to este ani neskusal... :-)
>> 
>> (Far data na druhej strane pouzivam pomerne vela "starym sposobom" a nevidim v tom ziadny zasadnejsi problem. Je jasne, ze je lepsie zostat pod 64k, ale niekedy to z roznych dovodov jednoducho nejde.) 
>> 
>> Mozete prosim byt trocha konkretnejsi v tom, co ste skusili a co nefungovalo?
>> 
>> Dakujem,
>> 
>> wek
>