XC32 a pole v RAM vetsi velikosti

[Jan Waclawek]

> Linker souboru nemam

Linker script? Zrejme ld pouzije nejaky defaultny, pravdepodobne na zaklade
specs.

Uz ste skusili ten __attribute__((section(".bss"))) ako som doporucil?

> Me jako programatora nemusi zajimat, jak je pamet alokovana.

No jasne ze nie, ale potom Vam tiez nesmie vadit, ze to nefunguje... :-)

> Microchip vymyslí 
> nìjaké divoké mapování, které je fakticky jen klacek pod nohy 
> uživatelùm 

Ak tomu dobre rozumiem, nema to s MCHP nic spolocneho, to je ciste
MIPSovska zalezitost.

Klasicky problem "ciste" 32-bitovych procesorov (t.j. tych co maju adresnu
aj datovu zbernicu pre instrukcie aj pre data 32 bitov siroku) je, ze do
32-bitovej instrukcie sa neda schovat 32-bitova konstanta; coho
najdramatickejsim nasledkom je, ze dostat do procesora adresu nejakej
premennej je pomerne zdlhavy proces ktory zabera aj pomerne dost pamati -
a to este potom treba citat hodnotu tej premennej (situaciu vyhorsuje
fakt, ze u mcu sa obvykle pouziva nie cisty 32-bitovy procesor, ale
okresana verzia, ktora ma 16-bitovu datovu zbernicu pre instrukcie). Takze
u toho MIPSu je finta, ktorou sa toto urychluje: vyhradeny register, voci
ktoremu sa na pristup k premennym pouziva 16-bitovy ofset - ten sa uz do
32-bitovej instrukcie zmesti. Znamena to, ze v danom programe moze byt
64kByte premennych, ku ktorym sa da pristupovat rychlo. Toto nie je
trivialne rozoznat, ze na ktore premenne sa to ma vztahovat, a nasledne
upravit vsetky pristupy k takejto premennej, teda nie bez zasadnejsieho
zasahu do prekladaca; a tak sa pre jednoduchost (tato "jednoduchost" este
stale nie je trivialna) v tom upravenom gcc tym prepinacom -G zadava
velkost (individualnej) premennej, pod ktoru sa premenna umiestni do
"maleho rychle pristupneho" segmentu - ak je premenna vacsia, tak sa
umiestni do "vseobecneho pomaly pristupovaneho" segmentu.

Toto zafunguje dobre, ak sucet velkosti premennych, ktore su pod velkostou
specifikovanou nejakou defaultnou hodnotou pre to -G, vojde do toho 64kB
segmentu; ak nie, tak vypadne prave uvadzana chyba z linkera (lebo len
linker zhrnie vsetky tie premenne).

Inaksie povedane, ak vas ako programatora tieto veci nezaujimaju, zadajte
jednoducho -G0 (neviem ci treba dat medzeru medzi to -G a parameter alebo
nie). Tym padom vsetky premenne spadnu mimo "rychlo pristupovaneho maleho
segmentu", a uvedena chyba nemoze nastat. No ano, program bude vacsi a
pomalsi, ale to je cena ktoru platite za Vas nezaujem.

wek




----- Original Message ---------------

Subject: Re: XC32 a pole v RAM vetsi velikosti
   From: Libor Koneèný <support at mikrovlny.cz>
   Date: Sat, 14 Mar 2020 15:22:59 +0100
     To: HW-news <hw-list at list.hw.cz>

Linker souboru nemam, musim jej napsat, zatim patram jak.
Pracuji nyni na PIC32MK1024,  kde k MK rade je toho velmi malo k 
hotovemu pouziti,  navic spusta veci neni kompatibilni, ale je reseno 
jinymi registry a jako speciality jsou i takove veci, ze se cely 
interface napr UART musi zastavit, prenastavit a pak zase spustit.
Byl jsem zvykly na MIKROC, kde proste definuji pole temer az na doraz a 
o vse se postara kompilator, od toho snad je.
Me jako programatora nemusi zajimat, jak je pamet alokovana.
Ale stejne me to ceka pri bootloaderu.

LK



Dne 14.3.2020 v 15:16 Miroslav Mraz napsal(a):
> Já jsem do toho jen tak zbìžnì nakoukl a usoudil jsem, že to bude 
> fungovat podobnì jako na AVR, ARM a jiných. To, že Microchip vymyslí 
> nìjaké divoké mapování, které je fakticky jen klacek pod nohy 
> uživatelùm bych docela oèekával. Proto se taky PICùm vyhýbám jak èert 
> køíži. On staèí jen ten velký indián. Pro síové protokoly je celkem 
> dobrý, ale skoro celý okolní svìt žije na malém indiánu a funguje to...
>
> Mrazík
>
> Dne 14. 03. 20 v 10:12 Jan Waclawek napsal(a):
>>> Sice o PIC vím celkem prd
>>
>> +1 (a prd viem aj o MIPSe) a na nasledujuci post som venoval studium v
>> rozsahu asi 10 minut.
>> ...
>> JW
>>