XC32 a pole v RAM vetsi velikosti

Libor Konečný support na mikrovlny.cz
Neděle Březen 15 11:39:04 CET 2020


__attribute__((section(".bss"))) ako som doporuci

Zkusil jsem a nefunguje mi to.

Toto mi nefunguje v projektu kde mam vyuzite cca 64kB RAM a  400kB ROM.

I pres zvyseni parametru G, taktez nic.
Lkr soubory pro dany procesor (i defaultni) tam bohuzel nemam. Ve slozce 
kompilatoru je plno jinych, ale zadny pro radu MK.


Ten program nize je pro PIC32MK1024GPD064?
Jdu tady udelat jednoduchy program a postupne zjistovat kde je chyba.


Ahoj,

cisty projekt a main.c s jednoduchym programom

unsigned char i[100000];

void main(void) {
    unsigned char x[100];

i[0] = 0;
}



Dne 15.3.2020 v 2:40 Jan Waclawek napsal(a):
>> 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 na mikrovlny.cz>
>     Date: Sat, 14 Mar 2020 15:22:59 +0100
>       To: HW-news <hw-list na 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
>>>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list



Další informace o konferenci Hw-list